Re: [TLS] Negotiation in draft-santesson-tls-gssapi
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] Negotiation in draft-santesson-tls-gssapi
On Fri, Jul 20, 2007 at 01:54:25AM +0200, Martin Rex wrote:
> Nicolas Williams wrote:
> > There is no way to piggyback a 1 round-trip GSS
> > context token exchange onto the full handshake pictured in figure 1 of
> > RFC4346.
>
> This is a NO.
>
> I'm confused.
The Finished messages provide a verifier for the entire preceding
handshake. Therefore the entire preceding handshake MUST end no later
than when the first finished message is sent. See Fig. 1 of RFC4346.
> What I was thinking of was piggybacking the initators first context level
> token onto the client's finished message and the acceptors first context
> level token onto the servers finished message.
If you do that then what you have isn't TLS (or you're nesting TLS, in
which case you'll be having another exchange of Finished messages).
> > 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.)
>
> Hello extensions should work with SSLv3 already.
For client hello?
> Is there a size limitation on the Hello extension?
> (because there is no size limitation on the gssapi context level tokens).
TLS has a record size limit -- to exceed it you must fragment.
> Fallback if the security context establishment fails is not
> necessarily a good idea, because if you really want gss-api
> based authentication and that fails for a technical reason,
> you will not see the GSS-API error, but instead get a
> fallback to the TLS handshake.
That's up to the client.
Nico
--
_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.