Re: [TLS] the use cases for GSS-based TLS and the plea for integrating

Chris Newman <Chris.Newman@Sun.COM> Fri, 27 July 2007 13:49 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQCI-0005kb-1q; Fri, 27 Jul 2007 09:49:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQCG-0005kV-Qe for tls@ietf.org; Fri, 27 Jul 2007 09:49:36 -0400
Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEQCE-0004cH-Tb for tls@ietf.org; Fri, 27 Jul 2007 09:49:36 -0400
Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6RDnYFZ004408 for <tls@ietf.org>; Fri, 27 Jul 2007 13:49:34 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLU00B01BJ4OQ00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for tls@ietf.org; Fri, 27 Jul 2007 07:49:34 -0600 (MDT)
Received: from [10.1.110.5] (dhcp-1695.ietf69.org [130.129.22.149]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLU006G2BQJCK10@mail-amer.sun.com>; Fri, 27 Jul 2007 07:49:34 -0600 (MDT)
Date: Fri, 27 Jul 2007 08:50:17 -0500
From: Chris Newman <Chris.Newman@Sun.COM>
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating
In-reply-to: <46A8FD4F.7050203@it.su.se>
To: Leif Johansson <leifj@it.su.se>
Message-id: <97106756681A40418FDFFE56@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.6 (Mac OS X)
Content-type: text/plain; format="flowed"; charset="us-ascii"
Content-transfer-encoding: 7bit
Content-disposition: inline
References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> <C4E819FF73EA6ED22A3906CD@446E7922C82D299DB29D899F> <46A8FD4F.7050203@it.su.se>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

Leif Johansson wrote on 7/26/07 22:00 +0200:
>> I'd agree that implementers only want to integrate one security
>> services layer. But some implementers want their security services
>> layer and identity stack to be as cleanly separated as possible so a
>> tight binding between the two is not desirable.  TLS only provides
>> certificate-based identity today, a mechanism that is very different
>> from other user identity services because it does not require the TLS
>> stack to perform a user identity network lookup in the middle of the
>> TLS handshake.  Doing that means the TLS stack suddenly has to
>> communicate problems talking to the identity lookup service through
>> the TLS stack and back to the application.
>>
> Username+password has the same property right?

Yes.

> Would you support a password-based scheme inside TLS or

Most schemes that embed user authentication in the TLS state machine have 
similar issues.  Since GSSAPI is a framework for authentication mechanisms in 
general, it inherits the superset of all authentication-identity-related issues.

> would you support removing authentication from TLS entierly?

No.  Server certificate authentication is useful in practice as part of today's 
interim solution to authentication despite certain dubious qualities.  As 
client certificate authentication is a rarely used feature of TLS, it's 
questionable whether it should have been included in the original design. 
However, given that the mechanism has deployed well in implementations and is 
actually used in some enclaves, it would be far too disruptive to change now. 
Client certificates are also less problematic because the identity service 
lookup can be deferred to the application layer using a mechanism such as SASL 
EXTERNAL or IMAP "* PREAUTH".

                - Chris


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