 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
Martin Rex wrote:
> Larry Zhu Wrote:
> 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?
you can do this in the most straightforward way, when the TLS protection for the GSS data is in place, it should be no worse than what is in your proposal. The difference is that this draft leaves the options open by not requiring a TLS handshake up front.
An appendix can be added to illustrate how this can be done.
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