[openssl-users] Kerberos

[Nico Williams]

On Fri, May 08, 2015 at 05:17:29PM -0400, Nathaniel McCallum wrote:
> I agree that the current situation is not sustainable. I was only
> hoping to start a conversation about how to improve the situation.

RFC2712 uses Authenticator, which is an ASN.1 type quite clearly NOT
intended for use outside RFC1510 because it isn't a PDU.  RFC2712
unnecessarily constructed its own AP-REQ that's different from the
RFC1510 (now 4120) AP-REQ.

This is bad for a variety of reasons, not the least of which are
complicating Kerberos APIs and/or RFC2712 implementations (which might
have to parse out the Authenticator and Ticket from a plain AP-REQ).

I also notice that the EncryptedPreMasterSecret is under-specified (is
it a Kerberos EncryptedData?  who knows?).

RFC2712 could be replaced with a properly-done protocol that uses
Kerberos in the full TLS handshake (i.e., not in session resumption).
This would be the lowest-effort fix.

A generic GSS-in-TLS extension would require much more energy (see
below).

> For instance, there is this: http://tls-kdh.arpa2.net/

Yes, it'd be nice to add PFS to the Kerberos AP exchange, and we just
might get there, but adding Kerberos and/or GSS to TLS is a very
different undertaking.

> I don't see any reason this couldn't be expanded to do GSSAPI.

Well, that's difficult because GSS has arbitrary round trips...

You're not the first to want this, see for example here:

https://tools.ietf.org/html/draft-santesson-tls-gssapi-01
https://tools.ietf.org/html/draft-williams-tls-app-sasl-opt-04

And more if you consider other efforts like False Start and look past
GSS/SASL.  Probably many more than I know of then...

Two main design axis:

1) When does the GSS context token begin, and how is channel binding
done.

 - no GSS mech negotiation, first GSS context token goes in TLS
   ClientHello;

   (channel binding done via MIC tokens or GSS_Pesudorandom() output
   exchanges)

or (e.g., if the client needs to negotiate mechs)

 - TLS ClientHello carries client mechList, server announces a mech in
   its handshake message, first GSS context token goes in second client
   handshake flight with normal channel binding

(Both options could be specified, with clients choosing as desired.)

x

2) How many GSS context tokens can be exchanged and who is responsible
for continuing past the traditional TLS handshake.

 - one round trip only

or

 - arbitrary round trips continued by TLS or by the application

The first order of business is to decide on whether or not to support
multiple round trips (IMO we must; what's the point if not?).

The second is to decide whether or not additional context token round
trips are to be done by the application, both as to how they appear on
the wire and how they appear in the API.

The third is to decide whether GSS mechanism negotiation is supported,
and whether it can be optimized away when it's not needed.

The fourth is to decide whether SASL (with SASL/GS2 to get GSS) isn't
better, since if we're going to spend a pair of flights in negotiation,
we might as well let server-talks-first SASL mechs get a leg up on GSS.
Remember, SASL can do GSS just fine via SASL/GS2 [RFC5801].

> But maybe this mailing list isn't the right place for such a
> discussion.

Well, TLS WG would be the right forum, but they are busy with TLS 1.3.
Some of us could get together elsewhere, probably not here.

> Perhaps the right question to ask is how much interest there would be
> in improving this situation in the TLS WG and whether or not OpenSSL
> would have interest in implementing such a project.

My impression is: none, because TLS WG is too busy at this time, and in
the past it has been very difficult to get the necessary level of
implementor effort.  Past performance is not always a predictor of
future performance.

It would help if GSS had better, less niche mechanisms.  For example: if
Kerberos had PKCROSS (based on DANE, say), that would help.  Or if ABFAB
went viral.  But for now everyone in the TLS world is happy _enough_
with WebPKI for server (should be service, but hey) authentication and
bearer tokens for user authentication.

Part of the problem is that HTTP authentication schemes (whether in HTTP
proper or not) have no real binding to TLS, and HTTP is basically a
routable (and usually routed) protocol anyways, which complicates
everything.  But HTTPS is the main consumer of TLS.  One might think
that adding user authentication options to TLS would be desirable for
HTTP applications, but again, the routing inherent to HTTP means that
routing must pass along user authentication information, but this isn't
always easy.  And HTTP is stateless and so doesn't deal well with
needing continuation of authentication exchanges, so bearer tokens it
basically kinda has to be, so that better mechanisms lose their appeal.

If the main consumer of GSS-in-TLS were to be something other than HTTP,
well, great, but still, HTTPS is the biggest consumer (next is SMTP)...
And it's easier then to think of GSS-in-TLS as optimizing *application*
protocols with TLS by tagging some application data along in handshake
messages -- there have been many proposals like this, and this is by far
the most promising approach for special some applications (e.g., IMAP).
But now we're talking about generic TLS extensions (to be used for GSS)
rather than adding GSS support to TLS, and while that might make it
easier to get this through, it also makes coding applications harder.

I don't mean to sound pessimistic, much less to dissuade you.  Rather, I
want you to know what level of energy it will take to accomplish what
you're after.  Hopefully something does come of this.  I'll be glad to
help.

Nico
--