Re: [TLS] encrypting GSS data: draft-santesson-tls-gssapi-03.txt

[Nicolas Williams <Nicolas.Williams at sun.com>]

On Thu, Jul 19, 2007 at 08:43:04PM -0700, Larry Zhu wrote:
> A new section is inserted in -03: the TCPWrap pseudo mechanism is
> defined to describe how to TLS protect GSS-data.
> 
> http://www.secure-endpoints.com/tls-gss/draft-santesson-tls-gssapi-03.tx
> t
> 
> 6.  Protecting GSS-API Authentication Data
> 
>    GSS-API [RFC2743] provides security services to callers in a generic
>    fashion, supportable with a range of underlying mechanisms and
>    technologies and hence allowing source-level portability of
>    applications to different environments.  For example, Kerberos is a
>    GSS-API mechanism defined in [RFC4121].  It is possible to design a
>    GSS-API mechanism that can be used with FKA-TLS in order to, for
>    example, provide client authentication, and is so weak that its GSS-
>    API token MUST NOT be in clear text over the open network.  A good
>    example is a GSS-API mechanism that implements basic authentication.

I don't think we want to have such a mechanism, ever (LIPKEY isn't it --
it relies on another mechanism to provide protection; also we'd not want
to use LIPKEY-like things in TLS, ever).

I think a DIGEST-MD5-type mechanism would be a much better example.  And
privacy protection for mechanisms that send client identities in the
clear.

>    Although such mechanisms are unlikely to be standardized and will be
>    encouraged in no circumstance, they exist for practical reasons.

Unlikely indeed :)

>    In order to provide a standard way for protecting weak GSS-API data
>    for use over FKA-TLS, TLSWrap is defined in this section as a pseudo
>    GSS-API mechanism that wraps around the real GSS-API authentication
>    context establishment tokens.  This pseudo GSS-API mechanism does not
>    provide per-message security.

Hmm, why not just do a TLS exchange with anon suites then nest another
TLS exchange with GSS and channel binding to the first exchange?

Sounds much simpler to me.  (Queue Martin's comment that GSS mechs don't
necessarily support channel binding, our answer to which would be that
all Internet standards track GSS mechs will :) :)

Nico
-- 

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