On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote: > How about the following simplifications for the new > extension, lets call it "GSS-2" (at least in this e-mail). > > 1. GSS (including SASL/GS2) is always done via the SPNego > GSS mechanism, which provides standard handling of > mechanism negotiation (including round-trip optimizations), > and is already its own standard (complete with workarounds > for historic bugs in the dominant implementation...). SASL/GS2 and SPNEGO are incompatible. The ALPN approach is to do the mechanism negotiation via ALPN. This is much better than SPNEGO in general. We don't have to use the ALPN approach, and we don't have to support SASL. But see below. > 2. The TLS client always begins by sending the first > GSS/SPNego leg in a (new) TLS extension "GSS-2". This is incompatible with doing channel binding the GSS way. Instead we'd have to exchange MICs of the channel binding when the GSS context is fully established. (This is fine, of course, and not a criticism, just pointing this out.) > 3. The TLS server (if it supports and allows the extension) > responds with a 0 byte TLS extension "GSS-2" to confirm > support. Well, presumably the first response GSS token should go here. > 4. The second and subsequent legs of the GSS handshake are > sent as the sole contents of the first encrypted records, > actual application data is not sent until the GSS handshake > succeeds. Note that the first encrypted server to client > record (containing the second leg) can be sent in the same > protocol round trip as the second half of the TLS > handshake. It is an open design issue if these TLS records > should be tagged as application records or key exchange > records. This is just as in the ALPN approach. They should be tagged as application records so that the implementation can be either at the application layer or in the TLS library. > 5. In the last legs, the GSS mechanism is told to (mutually > if possible) authenticate some already defined hash of the > TLS handshake, thereby protecting the key exchange.Other > than the round trip saving for the first 2 legs, this is > what distinguishes GSS-2 from simply doing application level > GSS over a TLS connection. Any GSS negotiated keys are not > used beyond this authentication of the TLS key exchange. This is the MIC exchange I mention above. > 6. If the GSS mechanism preferred by the client requires the > authenticated hash value to be known before sending the > first GSS leg, then the client shall simply abstain from > including that first leg in the first leg SPNego message > if sent in the client hello extension. If we're doing a MIC exchange then we don't need to know the channel binding a initial security context token production time. > 7. If the client wants encryption of the first GSS leg, it > can either abstain from including that leg in the first > SPNego GSS leg, or it can send a 0-byte first leg and then > send the real first SPNego leg in the first encrypted client > o server record, with the server responding with the second > leg in the first encrypted server to client record as before > (but no longer in the same round trip as the second half of > the TLS handshake). With the ALPN approach this is a given. > 8. If the GSS mechanism reports failure, the TLS connection > SHALL be aborted with a specified alert. Yes. > 9. When the "GSS-2" extension is negotiated, TLS > implementations SHOULD allow anonymous (unauthenticated) > cipher suites even if they would not otherwise do so, > however they MUST be able to combine the "GSS-2" extension > with any and all of the cipher suites and TLS versions they > otherwise implement. For instance, if an implementation of > the "GSS-2" extension is somehow bolted on to a fully > patched OpenSSL 1.0.0 library (via generic extension > mechanisms), then that combination would support it with > TLS 1.0 only, and TLS 1.3 capable implementations would be > negotiating TLS 1.0 when doing "GSS-2" with such an > implementation. If only GSS mechanisms that provide integrity protection or better as used, then this is fine. > 10. Session resumption and Session renegotiation shall have > the same semantics for the GSS authentication result as > they do for certificate validation results done in the > same handshakes. Yes. > 11. NPN and ALPN are neither required nor affected by GSS-2 > and operate as they would with any other TLS mechanisms, > such as certificates. NPN is out of the question now. You're missing a status message for authorization (GSS authentication might complete, but authorization fail), though this is not strictly necessary: the server can simply close the connection, including sending an alert about this (or not) just before closing the connection. Nico --
