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

Chris Newman <Chris.Newman@Sun.COM> Wed, 25 July 2007 19:23 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 1IDmSe-000845-D9; Wed, 25 Jul 2007 15:23:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDmSd-000833-Fr for tls@ietf.org; Wed, 25 Jul 2007 15:23:51 -0400
Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDmSc-0002PG-SO for tls@ietf.org; Wed, 25 Jul 2007 15:23:51 -0400
Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6PJNo0c008508 for <tls@ietf.org>; Wed, 25 Jul 2007 19:23:50 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 <0JLR003011NR3Z00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for tls@ietf.org; Wed, 25 Jul 2007 13:23:50 -0600 (MDT)
Received: from [10.1.110.5] (dhcp-26f9.ietf69.org [130.129.38.249]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLR00JJZ1VNGA10@mail-amer.sun.com>; Wed, 25 Jul 2007 13:23:50 -0600 (MDT)
Date: Wed, 25 Jul 2007 14:24:31 -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: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp>
To: martin.rex@sap.com, Larry Zhu <lzhu@windows.microsoft.com>
Message-id: <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org>
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
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

For my IESG review of draft-ietf-tls-srp-14.txt, I voted to abstain with the 
following comment:

------
This a matter of application software architecture that applies to any
user-based authentication mechanism embedded in TLS that involves
or may involve unspecified server storage of per-user credential
information.

TLS stacks and the APIs to TLS stacks have started to ossify into
operating systems, mobile devices and shipping application software.
Such stacks are absolutely critical to application security, and are
already so complex that they are the cause of a significant number of
software defects and security updates.  I am very concerned about
adding unnecessary complexity to such a critical software component.
There is already a great deal of flux upgrading the cipher suites,
cipher modes and hash functions in these stacks.

Meanwhile, all the software infrastructure in applications surrounding
user identity, server credential repositories for users, and identity
federation is highly complex and in a great deal of flux.  If one looks
at the amount of complexity in the GSSAPI or deployed general
purpose SASL APIs and imagines the complexity of a software stack
including all those APIs blended with a TLS API, I find the prospect
daunting.  Indeed the complexity is sufficiently great that I consider
it bad architecture.

Meanwhile, there's a viable alternative.  If TLS and an authentication
framework such as GSSAPI, EAP or SASL are loosely bound using a
mechanism such as TLS channel bindings (TLS negotiates the security
layer which is subsequently bound to a completely separate user
authentication), then there is a very simple and clean boundary
between the two software stacks, leading to a much more pragmatic
real-world architecture.
------

I have subsequently spoken to other implementers in the applications area who 
integrate TLS and identity stacks into their application server software.  They 
all shared this concern to varying degrees.

This issue clearly also applies to a mechanism that embeds GSS in TLS.  As a 
measure of IETF consensus in support of such a mechanism, I want to see 
evidence there are real-world consumers of this technology sufficient that it 
might deploy.  Specifically, is this likely to be implemented in multiple TLS 
stacks?  Are applications that consume TLS stacks interested in using this 
instead of their present identity APIs and models?

                - Chris Newman
                Applications Area Director


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