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

Nicolas.Williams wrote:

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

we do not want to force Kerberos to pay for the perf penalty and extra
round trips.

-----Original Message-----
From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] 
Sent: Thursday, July 19, 2007 9:57 PM
To: Larry Zhu
Cc: tls@lists.ietf.org
Subject: Re: [TLS] encrypting GSS data:
draft-santesson-tls-gssapi-03.txt

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