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

[Martin Rex <Martin.Rex at sap.com>]

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?

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

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


> 
> The # of roundtrip is important for some applications and environments.
> Therefore the current ID wins with a clear cut in term of the required #
> of round-trips.

When SPNEGO is used in the current proposal and the optimistic
token is wrong on the, then the current ID incurs an additional roundtrip.
My proposal didn't need an optimistic token and therefore can not
suffer such an additional-roundtrip penalty.

To me, this looks like equal roundtrips, and a loss for the current ID
if the optimistic token is wrong compared to my envisoned architecture.

-Martin

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