[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    [TLS] Review of draft-santesson-tls-gssapi-00
From:       Eric Rescorla <ekr () networkresonance ! com>
Date:       2007-01-22 20:19:54
Message-ID: 20070122202751.CCBC45C01E () laser ! networkresonance ! com
[Download RAW message or body]

$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@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls



[prev in list] [next in list] [prev in thread] [next in thread]