ietf-sasl

On Thu, May 28, 2009 at 10:49:03PM +0100, Alexey Melnikov wrote:
> 1). SCRAM should just use a single allowed TLS channel binding and don't 
> have any negotiation of other TLS channel bindings (*) (**)
> a). the default is tls-unique
> b). the default is tls-server-end-point
> 2). SCRAM should just use tls-server-end-point, fallback to tls-unique, 
> no negotiation of other TLS channel bindings (*)
> 3). SCRAM should always use channel binding negotiation (*)
> 4). SCRAM should have a default TLS channel binding with optional 
> negotiation of TLS channel bindings (*)
> a). the default is tls-unique
> b). the default is
> 5). I have another opinion [this is for the case when there is some 
> valid choice which you think should be considered by the WG]

(1a) future-proofed would be my preferred approach.  I.e., (1a) with the
'**' details filled out.

I believe we can do this by adding a field to the GS2 header that would
be present *only* when the channel binding type used is not the default
one.  Since this would not materially change SCRAM/GS2, I believe this
would be the ideal solution.

So, really, I want (5), which in my case is:

 - by default use tls-unique (in the case of TLS channels, of course)
   (this is (1a) so far)
 - if the client wishes to use any other channel binding type then it
   must indicate which type that is via a GS2 header field that would
   otherwise not be present
 - if we ever need to add channel binding type negotation we can do it
   later because of the previous item.

My (5) is almost indistinguishable from (1a).  It adds a single
conditional to server implementations of SCRAM/GS2 and nothing at all to
clients.

(1b) is not acceptable.  tls-unique is available for all TLS channels;
the same can't be said for tls-server-end-point, which makes it not
suitable for use as the only channel binding type.

(2) would be OK, BUT, keep in mind that this has to be true for GS2 as 
well, and that there may be mechanisms like YAP for which
tls-server-end-point is a weaker channel binding type than tls-unique
(see below!).

(3) seems too complicated.

(4a) is almost like my (1a)/my (5), but with "later" being "now".  (4a)
is not worthwhile at this time.

I don't know what (4b) mean.  Did you mean to say "tls-server-end-point"
or "<fill in the blank>"?  Either way, (1a)/my (5) is preferable.


As for whether tls-server-end-point is weaker than tls-unique for YAP...
That's a very interesting question!  Sam and I spent quite a bit of time
today discussing it.

And the answer is not as obvious as we'd thought.  Clearly YAP with
tls-server-end-point (or any non-unique channel binding type) is subject
to replays, but if the only entities that could do the replaying are the
client and the server, then there's no real harm.  The assumption buried
there is that there are no trusted proxies -- perhaps not a good
assumption!  Also, suppose there was an end-point channel binding type
that uses the server end-point's name rather than the end-point's
cert/public key, then you get an additional weakness: a dependency on
trust anchors being actually trust-worthy.  Another weakness for YAP
with non-unique channel binding types may be that an attacker can
compute a dictionary of YAP messages, off-line, one for every possible
password, and if SASL authentication is retriable then the attacker gets
as many tries as the server allows.  Whereas with unique channel
bindings the attacker must do the computation in real-time.

So unique channel binding types are a better fit for YAP and YAP-like
mechanisms, but it's not clear that end-point channel binding types are
fatal to YAP.  In fact, if there are no proxies and the client uses a
TLS cipher suite with confidentiality protection, then it should be fine
for the client to use YAP with tls-server-end-point, provided that the
server has an N-strikes-you're-locked-and-must-change-your-password
policy.  But clearly unique channel binding types are stronger in the
face of authentication mechanisms like YAP that need a nonce from an
external source and use the channel binding as one.

Now consider that SCRAM is a GS2 mechanism, and that someone could have
a GSS-API mechanism that is like YAP (i.e., it depends on unique channel
bindings for non-replayability).  This argues for a preference for
tls-unique over tls-server-end-point.

The above analysis is the reason that I support (1a)/my (5).  I believe
Sam is also on board with this.

Thanks,

Nico
--