On 13/05/2015 21:17, Nico Williams wrote:
> We're closer.
>
> On Wed, May 13, 2015 at 07:10:10PM +0200, Jakob Bohm wrote:
>> 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.
> SASL/GS2 is the other way around: GSS in SASL.
>
> The idea is that you can have GSS as SASL mechanisms in a way that sucks
> less than the original GSS-in-SASL bridge in RFC2222 (that added an
> extra round-trip), and which makes it easy to add mechanisms like SCRAM
> as both, a GSS and a SASL mechanism.
>
> I'm perfectly happy to drop SASL though.
Ah, I thought from context it was a way to use SASL
as GSS mechanisms, with GSS presumably beingthe more
powerful API for multi-leg protocols.
Since I generally expect some mechanisms to only have
standards for a form that can be bound to a channel or
MIC, it would be best to keep the ability to reuse both
standards via some existing bridging mechanism.
>
>>>> 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.
> The only complication in a negotiation mechanism is protecting the
> negotiation. Since the TLS handshakes are ultimately integrity-
> protected, there's no complication at all to having the client send a
> list of mechanisms and the server pick one (the client can even send an
> optimistic choice's initial context token). In fact, it's much nicer
> than SPNEGO in many ways; if at all possible one should avoid SPNEGO.
>
> Among other things, not using SPNEGO means that it will be much easier
> to implement this protocol without extensions to GSS (extensions would
> be needed only to optimize it).
Again, please say which GSS extensions would be
needed to use SPNEGO rather thanyet-another-
negotiation-protocol.
>
>>> 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.
> We could extend GSS (see below) to support late channel binding, but
> since a mechanism might not be able to do it, this protocol would have
> to fall back on MIC tokens to complete the channel binding, in some
> cases at a cost of one more round trip.
There is also the fallback to early channel binding (by
not sending the first legs before the channel binding
data is available). The resulting round trip counts
would need to be studied closely to pick one.
>
>>> 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.
> Kerberos in particular supports PROT_READY. There is no Kerberos IV GSS
> mechanism, FYI. I'd never heard of GSS-SRP-6a; do you have a reference?
See other subthread.
>
>>>>>> 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.
> If we finish the channel binding state flag extension we can support
> late channel binding.
>
> The application would provide channel bindings late and the mechanism
> would indicate the channel binding status, and if it couldn't do it then
> the application would have to fall back on MIC tokens. Where PROT_READY
> is indicated early the fallback MIC token exchange never costs extra
> round trips.
>
> For 2- and 3-token mechanisms the MIC token exchange also never costs
> additional round trips regardless of PROT_READY or late channel binding
> support.
>
> For some imaginable mechanisms there is nothing we could do to avoid an
> extra round trip, but most likely they will never exist.
>
>>>> 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.
> Yes, though if the mechanism was not going to expose the client's
> identity in the first context token... but yes, this is much better left
> as an application decision not based on knowledge of the mechanism.
However such an application decision would be meaningless
(and downright stupid) without mechanism knowledge.Note
that I distinguish clearly between knowledge of mechanism
properties (e.g. "Kerberos VI encrypts the client identity
in its 1st leg, NTLM does not"), which is fair game; versus
knowledge of mechanism internals (e.g. where Kerberos
stores/transmits various stuff), which should be known only
inside the mechanism black boxes.
>
>> 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.
> Right.
>
>>>> 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.
> I don't think this works as well as you think, and I see very little
> value in it. For Kerberos this means sending a bogus KRB-ERROR on
> authorization failure which will confuse the user if there was an error
> they could have dealt with, or which will not confuse anyone because it
> will be obvious that this means "authorization denied", so might as well
> have sent an authorization denied message instead.
You are presuming too much. "Call sequence A" etc.
would be mechanisms to somehow generate what would
be indistinguishable from an authentication failure,
including whatever gymnastics is needed to make
Kerberos generate such a message.
Now for traditional 3-way Kerberos, "invalid username
or password" would be a message sent only from the
KDC during the TGT request, not from the target server,
so there would be no way to make this indistinguishable.
But for a Kerberos encapsulation where the TGT request
is relayed via the target server (by encapsulating it
inside the client-server GSS tokens), this would imply
some way of disrupting the process early to protect the
KDC from being indirectly probed for password validity
on accounts that shouldn't have been exposed in the
first place.
> It would be much easier instead to let the application define its own
> authorization status message (if it needs one at all) and send it (or
> shut the door, or provide bogus content, or...) as it pleases.
The whole point is to *integrate* the authentication
and authorization into the TLS setup (as seen from
the application), which completely precludes moving
it to the application level. It may happen that some
implementations of this extension will look like
"application code" to various existing TLS libraries
(such as OpenSSL), but like "TLS code" to the actual
application, as this is the nature of adding TLS
extensions to an existing system. But to the actual
application this should be as easy as calling
"somefunction_to_setup_TLS(options => {...,
Use_GSS_SASL(args), ...}) where "args" includes some
way to indicate which authenticated ids are considered
valid/invalid.
It would be the job of a "plugin" extension library to
implement rejecting unauthorized ids in a way remotely
indistinguishable from use of non-existing ids. And
it would be the job of the extension specification to
say how this should be done in general.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150515/282c3af9/attachment-0001.html>
