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

[Stefan Santesson <stefans at microsoft.com>]

Eric,

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.

2) The extended roundtrips is an un-escapable consequence. If necessary I believe we can define an upper boundary of the number of roundtrips. You are right that the TLS state machine must rely on GSS-API for validating and concluding the GSS-API exchange. Without being handed the resulting key material from the GSS-API layer, the TLS state machine must fail. I feel convinced that it is possible to define the appropriate set of rules for the TLS state machine on when to close the connection and fail graciously.

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


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Eric Rescorla [mailto:ekr at networkresonance.com]
> Sent: den 22 januari 2007 21:20
> To: tls at ietf.org
> Subject: [TLS] Review of draft-santesson-tls-gssapi-00
>
> $Id: draft-santesson-tls-gssapi-00-rev.txt,v 1.3 2007/01/22 20:27:34
> ekr Exp $
>
> I have reviewed this document and as I indicated in San Diego, I have
> serious architectural concerns about the way that it interconnects TLS
> and GSS-API.
>
> 1. It's totally unclear what security guarantees TLS is supposed
> to be getting from GSS. In fact, it's not possible to be clear
> because there is just some set of mechanism IDs. That may be
> fine in limited environments but it's not fine in the general case
> where other extensions might be used with TLS.
>
> 2. TLS assumes a fixed number of round trips which is determinable
> from the resumption state. By contrast, once this draft establishes
> that GSS is to be used, an arbitrary number of round trips may occur
> in some way that is invisible to TLS. First, that's a big change to
> the state machine and second it's architecturally problematic.  It's
> true that there's an indicator in the message for whether it's the
> last payload or not, but there's no way for the TLS state machine to
> independently determine whether that has been tampered with. It needs
> to rely on the GSS state machine. That's problematic both from an
> engineering and security standpoint.
>
> 3. It sets a precedent that the way to interconnect TLS to external
> security mechanisms is via creating a hole in TLS to carry their
> mechanisms. This makes TLS more complicated, which is of course
> the enemy of security protocols.
>
>
> TLS provides a generic mechanism for linking up to externally exchanged
> keys, courtesy of RFC 4279. All you need to do is arrange for your
> mechanism to create a PSK-Identity binding on both sides and then
> you can do an ordinary TLS exchange using TLS PSK.
>
> In the WG meeting, I heard concerns from the proponents of this draft
> that they then needed to arrange a way to carry the GSS handshake and
> that since their application protocols already had a cutout for TLS
> they wanted to exploit that cutout. I'm not insensitive to this point,
> but that doesn't make it architecturally sound.
>
>
> -Ekr
>
> _______________________________________________
> TLS mailing list
> TLS at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls

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