RE: [TLS] Negotiation in draft-santesson-tls-gssapi

[Larry Zhu <lzhu at windows.microsoft.com>]

Nicolas Williams wrote:
> BTW, the protocol in figure 1 of draft-santesson-tls-gssapi is
> confusing: the server can't be the first to send a TokenTransfer
unless it sends an empty one (because the GSS-API is an
initiator-sends-first 
> framework).

This is a typographical error that has been fixed in -03 at
http://www.secure-endpoints.com/tls-gss/draft-santesson-tls-gssapi-03.tx
t.

-----Original Message-----
From: Nicolas Williams [mailto:Nicolas.Williams at sun.com] 
Sent: Thursday, July 19, 2007 4:17 PM
To: Martin Rex
Cc: Larry Zhu; tls at ietf.org
Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi

On Thu, Jul 19, 2007 at 04:05:13AM +0200, Martin Rex wrote:
> Larry Zhu wrote:
> > 
> > The current ID gives us the means to do both, the GSS data can be in
> > clear text or encrypted.
> 
> *I* certainly can not see that in the current draft.
> 
> >
> > The GSS-API token can contain the real GSS
> > mechanism tokens protected by certificate-based TLS.
> 
> How?  You mean by renegotiation -- similar to how one can
> protect the SSL client cert?  that would add roundtrips, wouldn't it?

By nesting TLS.

> > Comparing Martin's rough proposal, the current ID optimizes for the
> > minimal # of roundtrips and gives us more a more generic and more
> > extensible solution. 
> 
> If you coalesce the first GSS-API context establishment roundtrip
> onto the TLS finished messages you have the same amount of roundtrips
> for a TLS+rfc-1964 kerberos authentication than for a plain TLS
> handshake.   

The way TLS works it depends on the finished message derivation having
as input all preceding hello and handshake messages, and in order.  This
means that at most one GSS-API token can be sent in the same "write" as
a Finished message.  There is no way to piggyback a 1 round-trip GSS
context token exchange onto the full handshake pictured in figure 1 of
RFC4346.  Nor is there a way to piggiback the first context token into
the client Hello message without first extending the client Hello, but
how can we extend the client Hello?  (AFAICS we cannot.)

> Did I miss a clever roundtrip reduction of the TLS handshake
> in the current ID, or could there be an error in your counting?

I think Larry meant that if the GSS-API context fails to be established
then we can fallback on other TLS key exchange and/or authentication
methods, which means that in some cases the use of the GSS-API will only
add round-trips.

One reason the GSS-API security context establishment might fail is that
the client tried a mechanism not supported by the server.  This is
preventable, either by using SPNEGO or by extending the server Hello to
allow the server to advertise what mechanisms it supports and has
acceptor credentials for.

That is, by providing for negotiation of GSS mechanisms, one way or
another, we can eliminate a situation in which this extension might do
nothing more than add a round-trip.

BTW, the protocol in figure 1 of draft-santesson-tls-gssapi is
confusing: the server can't be the first to send a TokenTransfer unless
it sends an empty one (because the GSS-API is an initiator-sends-first
framework).

Nico
-- 


_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls