[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on YAP
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
> >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
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.