<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 13/05/2015 21:17, Nico Williams
wrote:<br>
</div>
<blockquote cite="mid:20150513191733.GX7287@localhost" type="cite">
<pre wrap="">
We're closer.
On Wed, May 13, 2015 at 07:10:10PM +0200, Jakob Bohm wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 13/05/2015 17:46, Nico Williams wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, May 13, 2015 at 12:03:33PM +0200, Jakob Bohm wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 12/05/2015 21:45, Nico Williams wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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...).
</pre>
</blockquote>
<pre wrap="">
SASL/GS2 and SPNEGO are incompatible.
</pre>
</blockquote>
<pre wrap="">
How? I thought SPNEGO encapsulated and negotiated
arbitrary GSS mechanisms.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
<tt>Ah, I thought from context it was a way to use SASL <br>
as GSS mechanisms, with GSS presumably being</tt><tt> </tt><tt>the
more <br>
powerful API for multi-leg protocols.</tt><tt><br>
<br>
Since I generally expect some mechanisms to only have <br>
standards for a form that can be bound to a channel or <br>
MIC, it would be best to keep the ability to reuse both <br>
standards via some existing bridging mechanism.<br>
</tt>
<blockquote cite="mid:20150513191733.GX7287@localhost" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
It's quite complex owing to having been underspecified in the first
place then having grown a number of bug workarounds over the years.
</pre>
</blockquote>
<pre wrap="">
Yes, but it is now a mature protocol, and I was trying
to avoid creating yet another near identical
handshake protocol.
</pre>
</blockquote>
<pre wrap="">
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).</pre>
</blockquote>
<tt>Again, please say which GSS extensions would be <br>
needed to use SPNEGO rather than</tt><tt> </tt><tt>yet-another-<br>
negotiation-protocol.</tt><tt><br>
</tt>
<blockquote cite="mid:20150513191733.GX7287@localhost" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
<tt>There is also the fallback to early channel binding (by <br>
not sending the first legs before the channel binding <br>
data is available). The resulting round trip counts <br>
would need to be studied closely to pick one.</tt><tt><br>
</tt>
<blockquote cite="mid:20150513191733.GX7287@localhost" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">With PROT_READY there should be no need for an extra round-trip.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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?</pre>
</blockquote>
See other subthread.<br>
<blockquote cite="mid:20150513191733.GX7287@localhost" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">If we're doing a MIC exchange then we don't need to know the channel
binding a initial security context token production time.
</pre>
</blockquote>
<pre wrap="">However the early channel binding might save a leg.
</pre>
</blockquote>
<pre wrap="">
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).
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
No, this can't be decided on a per-mechanism basis, not without first
modifying GSS significantly.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
<tt>However such an application decision would be meaningless </tt><tt><br>
</tt><tt>(and downright stupid) without mechanism knowledge.</tt><tt>
Note </tt><tt><br>
</tt><tt>t</tt><tt>hat I distinguish clearly between knowledge of
mechanism </tt><tt><br>
</tt><tt>properties (e.g. "Kerberos VI encrypts the client identity
</tt><tt><br>
</tt><tt>in its 1st leg, NTLM does not"), which is fair game; versus
</tt><tt><br>
</tt><tt>knowledge of mechanism internals (e.g. where </tt><tt>Kerberos
<br>
stores/transmits various stuff), which should be </tt><tt>known
only <br>
inside the mechanism black boxes</tt><tt>.</tt><br>
<blockquote cite="mid:20150513191733.GX7287@localhost" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Right.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">For security it is best if successful authentication
of an unauthorized account (thinkroot) is
indistinguishable from unsuccessful authentication of
that account.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
<tt>You are presuming too much. "Call sequence A" etc. <br>
would be mechanisms to somehow generate what would <br>
be indistinguishable from an authentication failure, <br>
including whatever gymnastics is needed to make <br>
Kerberos generate such a message.<br>
<br>
Now for traditional 3-way Kerberos, "invalid username <br>
or password" would be a message sent only from the <br>
KDC during the TGT request, not from the target server, <br>
so there would be no way to make this indistinguishable. <br>
But for a Kerberos encapsulation where the TGT request <br>
is relayed via the target server (by encapsulating it <br>
inside the client-server GSS tokens), this would imply <br>
some way of disrupting the process early to protect the <br>
KDC from being indirectly probed for password validity <br>
on accounts that shouldn't have been exposed in the <br>
first place.<br>
</tt><br>
<blockquote cite="mid:20150513191733.GX7287@localhost" type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<br>
<tt><br>
</tt><tt>The whole point is to *integrate* the authentication <br>
and authorization into the TLS setup (as seen from <br>
the application), which completely precludes moving <br>
it to the application level. It may happen that some <br>
implementations of this extension will look like <br>
"application code" to various existing TLS libraries <br>
(such as OpenSSL), but like "TLS code" to the actual <br>
application, as this is the nature of adding TLS <br>
extensions to an existing system. But to the actual <br>
application this should be as easy as calling <br>
"somefunction_to_setup_TLS(options => {..., <br>
Use_GSS_SASL(args), ...</tt><tt>}) where "args" includes some <br>
way to indicate which authenticated ids are considered <br>
valid/invalid.</tt><tt><br>
</tt><tt><br>
</tt><tt>It would be the job of a "plugin" extension library to <br>
implement rejecting unauthorized ids in a way remotely <br>
indistinguishable from use of non-existing ids.</tt><tt> And <br>
it would be the job of the extension specification to <br>
say how this should be done in general.</tt><br>
<br>
<br>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="http://www.wisemo.com">http://www.wisemo.com</a>
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 </pre>
</body>
</html>