Re: Comments on YAP

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Wed, Apr 29, 2009 at 10:54:38AM -0700, Kurt Zeilenga wrote:
> On Apr 29, 2009, at 9:30 AM, Nicolas Williams wrote:
> >On Wed, Apr 29, 2009 at 09:01:24AM -0700, Kurt Zeilenga wrote:
> >> YAP relies on client to authenticate the server within this lower-
> >>level security layer to avoid information disclosure to rogue  
> >>servers.
> >
> >I don't think that's a good idea.  Here's why: if you're really
> >authenticating the server at the lower layer then why are you using
> >channel binding in YAP?
> 
> The channel binding also ensures the client lower-level and YAP end  
> points are the same.
> 
> One problem in many uses of TLS in application protocols is that the  
> server has no clue wether the client's user well authenticated the  
> server, hence the server has to be leery of man-in-the-middle  
> attacks.  By using channel bindings, the server need not be concerned  
> about whether the client's user well authenticated the server as it  
> can rely on the channel binding to avoid man-in-the-middle attacks.

What you seem to be asking for is something like what SSHv2 does: first
key exchange and server authentication, then user authentication with
channel binding and with privacy protection.  SSHv2 pubkey userauth
consists of a message bearing a signature of the SSHv2 session ID, which
in turn binds the entire key exchange.  And you want this in just half a
round-trip because between TCP, TLS and the application's framing of
SASL and mechanism negotiation you're already up to an obnoxiously large
number of round-trips (1.5 for TCP, 2 for TLS, 1 for mechanism
negotiation, N for SASL mech, and up to 1 for the SASL app's outcome of
authentication message).

You might be interested in draft-williams-tls-app-sasl-opt-03.txt then.
That I-D would reduce the number of round-trips to: 1.5 for TCP, 2 for
TLS, N-1 for the SASL mech, and in the generic-sasl protocol specified
therein, 0 for the outcome of authentication message.  A total reduction
of 3 round-trips.

I'm not sure that I care for YAP as an Experimental mechanism when I
believe we ought to be looking at reducing the number of round-trips and
we can get a significantly larger round-trip reduction than the .5
round-trips that YAP saves over a variant that authenticates the server.

And if we can greatly simplify channel binding type negotiation in the
process, then let's.

Nico
--