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
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
