Nicolas Williams wrote:
> 
> > > 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.

This is be a YES (to sending one context-level gss-api token).

>                        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.

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.

I admit that I'm not sufficiently familiar with the crypto of the SSL/TLS 
handshake to determine whether this is possible.

I just noticed, that technically implementations like OpenSSL have
implemented the exchange of the Finished messages in a half-duplex
fashion.  I don't know whether this is strict requirement from the
protocol or whether it is because it is easier to implement and
it wouldn't be a good idea to let the client application send data
before the server's finished message was received and verified.

If the latter, then there is no technical issue against sending
the initiators first context level token without waiting for
the servers finished message.  

But for architectures like OpenSSL, piggybacking on the client
finished message would require a significant change of the
clients state machine and SSL_connect API semantics, which is
why *I* would not put such an optimization into OpenSSL...

If I understand Microsoft's software architecture correctly,
then they have a TLS implementation without transport,
where adding such an optimization should be _much_ easier
to add and be fairly compatible to the exitinge API semantics.


>
> 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.
Is there a size limitation on the Hello extension?
(because there is no size limitation on the gssapi context level tokens). 


> 
> > 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.

Coming up with good "fallback semantics" will be challenging.
Fallback to the regular TLS handshake when there is no common
gssapi mechanism is fine (similar to my idea).

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.


Several serious bugs in Microsoft Kerberos go unnoticed because
of the fallback to NTLM kicking in for most of Microsoft's own
communication protocols.  On the one hand this is a security problem
(NTLM authentication is significantly weaker than Kerberos), and
on the other it becomes a showstopper for (mosty non-Microsoft-only)
scenarios where the use of Kerberos is a requirement. 


Fallback for an unsupported/unavailable feature is usualls OK,
fallback for a security-relevant error is often the cause of
security vulnerabilities or mysterious behaviours (works sometimes
but not always).  


-Martin

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