On 12/05/2015 21:45, Nico Williams wrote:
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.
How? I thought SPNEGO encapsulated and negotiated
arbitrary GSS mechanisms.
I am of cause aware that some existing mechanisms have
both SASL native and GSS native bindings and that those
bindings are mutually exclusive, such that one must
decide at standardization time if the SASL native or
GSS native form shall be used for interoperability.
To me the key benefit of SPNEGO is the existence of
already battle tested negotiation code readily available
i many/most current GSS implementation. It is one less
thing to design and implement wrong.
The ALPN approach is to do the mechanism negotiation via ALPN. This is
much better than SPNEGO in general.
However I strongly suspect that using ALPN will cause
practical conflicts with early HTTP/2 implementations
and early ALPN implementations, as such early
implementations are likely to only cater to that
single use of ALPN.
In contrast there are now multiple unrelated deployed
TLS extensions, so that mechanism is more stable and
more ready to handle new uses.
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.)
This is why I specified the alternate ordering below.
Note however that not all versions of all GSS
implementations (notable the Microsoft SSPI variant)
may support the GSS channel binding mechanism.
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.
No, see below.
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.
However if it is negotiated via a TLS extension rather
than TLS 1.2+ ALPN, thenintegration in the TLS stack
will be unavoidable anyway.
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.
Yep, however as this entails extra round trips, it is
not the only option.
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.
However the early channel binding might save a leg.
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.
However if the first leg need not be encrypted and
need not know thechannel binding, it can be sent a
round earlier. This can (I hope) be decided on a per
mechanism basis, thus if a GSS mechanism need not know
its channel binding until the second leg,
implementations that can provide the binding to the
GSS layer later can take advantage of it.
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.
And why would this not work with any other form of
channel binding? Key requirement is that the TLS
key exchange is bound to the specific authentication
in some way not susceptible to man in the middle.
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.
However it is going to exist for SPDY backward
compatibility for a few years, so the non-conflict
needs to be specified, if only by a few words.
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.
For security it is best if successful authentication
of an unauthorized account (thinkroot) is
indistinguishable from unsuccessful authentication of
that account.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
