Re: [TLS] Review of draft-santesson-tls-gssapi-00

[Eric Rescorla <ekr at networkresonance.com>]

Stefan Santesson <stefans at microsoft.com> writes:

>> Thank you for the review and the initiative to get a discussion going
>> on this draft.
>>
>> All of your comments are valid and lines up with what I thought would
>> be the critical issues to discuss. In the end it's a question of
>> whether these changes to TLS are defendable in relation to the benefit
>> to the industry and the usability of the protocol.
>>
>> Response to your comments 1-3.
>>
>> 1) TLS gets no guarantee of the quality of parameters given by GSS-API.
>> But TLS is no entity so in a way that is the wrong question. The
>> implementers of this protocol choose to trust the properties of their
>> GSS-API based technology. The solution of this draft enables them to
>> extend the trusted authentication methods for TLS sessions to the GSS-
>> API methods they already use and trust. This can't accidently degrade
>> the security for regular TLS users. But this is nothing new. This line
>> was already crossed by RFC 2712.

I don't agree. RFC 2712 had a clear interface to Kerberos, namely
a ticket was in the ClientKeyExchange. I'm not saying that worked,
but it was clear. By contrast this draft just creates a hole
where you can shove arbitrary GSS messages, as evidenced by the
fact that you have to extend the state machine to allow an
arbitrary number of roundtrips.


>> 2) The extended roundtrips is an un-escapable consequence. If necessary
>> I believe we can define an upper boundary of the number of roundtrips.

Well, any number >2 is a radical change in the TLS state machine.



>> 3) I believe the precedent was set by RFC 2712. Security wise we do
>> nothing worse than RFC 2712 already do. This draft do however solve a
>> number of problems with RFC 2712. I do not agree that this makes a hole
>> in TLS.

Obviously, we disagree on this point.


>> This feature will not be enabled unless its specifically agreed
>> between the parties who thereby make the decision to trust GSS-API to
>> provide authentication and keying material.

It seems to me that this argument could be used to justify any
new cipher suite, no matter how broken. The purpose of having
a TLS WG is to decide whether new extensions are worth doing,
not to punt the decision to users.
   
-Ekr

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