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 --
