[openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
Jakob Bohm
jb-openssl at wisemo.com
Wed May 13 17:10:10 UTC 2015
For the TL;DR: My original quick writeup included some
mistakes in the details of TLS (forgot about Finished
messages) and SASL/GS2. It is thus in more than
anticipated need of change before it can become a
proper spec, finding and fixing such mistakes is the
main benefit of having this kind of discussion.
On 13/05/2015 17:46, Nico Williams wrote:
> On Wed, May 13, 2015 at 12:03:33PM +0200, Jakob Bohm wrote:
>> 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.
> The problem is that negotiating twice is bad (for various reasons), and
> SASL has non-GSS mechanisms, so negotiating SASL mechanisms, then GSS is
> a two-level negotiation that is fraught with peril, therefore forbidden.
Ok, having not studied the standard SASL in GSS
specification, I presumed each GSS-encapsulated SASL
mechanism would have its own GSS mechanism OID in
some systematic way, leaving just one negotiation.
>
>> 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.
> It's quite complex owing to having been underspecified in the first
> place then having grown a number of bug workarounds over the years.
Yes, but it is now a mature protocol, and I was trying
to avoid creating yet another near identical
handshake protocol.
>
> It'd be much easier to send a list of mechanism OIDs in the ClientHello,
> have the server announce a choice in its response, and have the first
> GSS token sent as early application data in the same flight as the
> client's Finished message (assuming traditional TLS handshakes here),
> with GSS channel binding. When the client knows what mechanism they
> want they could send the initial context token in the ClientHello (if
> it's not too large) and use MIC tokens for channel binding.
But isn't that (essentially) what SPnego does, but in a
standardized way with historic quirks?
>
>>> 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.
> Perhaps so. I would prefer to optimize the GSS flights as well too.
Ditto.
>
>>>> 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.
> In your protocol the client already sent a SPNEGO initial security
> context token. A response is required, as GSS context establishment
> token exchanges are strictly synchronous.
As written, I had forgotten about the "Finished"
messages. Thus the point wasto simply delay the
server GSS response (2. GSS leg) to just after
switching onthe encryption, later in the same
round of messages. The 3. leg (second client to
server "GSS token") would then follow etc.
The ordering of GSS message tokens is of cause
crucial for the security guarantees of many
mechanisms. It was all about when to send the
next token, never about reordering or omitting
them.
>>>> 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.
> With PROT_READY there should be no need for an extra round-trip.
Depends a lot on the mechanism. Some GSS mechanisms
(other than Kerberos IV/V) cannot use their MIC until
they have received a later token from the other end,
but can incorporate binding data earlier than that. I
think GSS-SRP-6a has that property.
>
>>>> 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.
> You mean late. Your idea seems to be to exposed knowledge of when is
> the latest that a mechanism can begin to use the channel binding so as
> to delay giving it the channel binding until we know it. That would be
> a significant change to GSS, and often it won't help (e.g., Kerberos,
> the mechanism of interest in this thread).
The idea would be if an implementation (not the protocol
extension specification as such) is blessed with a
non-standard GSS option to provide the channel binding
after the 1. leg, but not with the early MIC use ability
of Kerberos, the the protocol extension should not prevent
it from taking advantage of this to do the channel binding
before the 2. leg, rather than after the n-th leg.
Like this
ClientHello+GSS1 ----->
<----- ServerHello
<----- "enable crypto"
<----- GSS2 (bound)
Finished ----->
"enable crypto" ----->
GSS3 (bound) ----->
Versus
ClientHello+GSS1 ----->
<----- ServerHello
<----- "enable crypto"
<----- GSS2
Finished ----->
"enable crypto" ----->
GSS3 ----->
<----- MIC(binding)
MIC(binding) ----->
Also even without that ability, if a GSS mechanism (other
than Kerberos) can do the server-to client leg first, but
not tuck MIC signing onto the penultimate leg, then direct
channel binding would still save one leg (half a round).
ClientHello+"" ----->
<----- ServerHello
<----- "enable crypto"
<----- GSS1 (bound)
Finished ----->
"enable crypto" ----->
GSS2 (bound) ----->
<----- GSS3 (bound)
I obviously forgot about this order already saving that
half leg:
ClientHello+GSS1 ----->
<----- ServerHello
<----- "enable crypto"
<----- GSS2
Finished ----->
"enable crypto" ----->
GSS3 ----->
MIC(binding) ----->
<----- MIC(binding)
>
>>>> 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.
> No, this can't be decided on a per-mechanism basis, not without first
> modifying GSS significantly.
The need to encrypt the first leg for privacy (e.g. to
hide the user id) would bea protocol property which
the application could know from standards (no extra
GSS calls or flags needed). E.g. "Mechanism FOO reveals
semi-sensitive information to passive observers of leg1,
but Mechanism BAR does not". As a local matter, this can
even change during the lifetime of the protocol as new
attacks on mechanisms are discovered. An overly
conservative implementation could pretend that all
mechanisms need encryption, an overly optimistic
implementation could pretend that none do.
The lack of need to know the channel binding early can
be determined from either:
- A local or global decision to use the MIC technique
for this mechanism.
- Site local availability of extra GSS calls or flags
to provide channel binding later forsome mechanisms.
>
>>>> 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.
> I was referring to GSS per-message tokens. You're proposing changes to
> GSS -- I hadn't understood that then.
No, I was referring to the apparently existing ability
to do "GSS-style" channel binding in a standard way
for some but not all GSS mechanisms. An ability someone
else mentioned earlier in this thread (first I heard of
itin GSS context, but inherently natural in context, and
thus believable without reading through the RFCs to find
the details).
>
>>> 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.
> With GSS that's not really true. The mechanism token exchange is a
> black box. It may yield failure with error tokens. The application can
> detect this and elect not to send error tokens, but if a final token was
> expected in the success case then the peer will know what happened
> anyways. It's very difficult to generically ensure what you propose,
> and not that valuable.
Like other per mechanism properties, this can be simply
tabulated as:
"for mechanism X, check the authorization before sending
the 2. GSS token and simulate failure using call sequence
A"
"for mechanism Y, check the authorization before sending
the 1. GSS token and simulate failure using call sequence
A"
"for mechanism Z, check the authorization before sending
the 2. GSS token and simulate failure using call sequence
B"
All done opaquely, but with knowledge of where to put
the "square" black boxes versus the "round" black boxes.
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
More information about the openssl-users
mailing list