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

Larry Zhu <lzhu@windows.microsoft.com> Wed, 25 July 2007 19: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 1IDmrF-0006tI-Az; Wed, 25 Jul 2007 15:49:17 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDmrE-0006tD-9q for tls@ietf.org; Wed, 25 Jul 2007 15:49:16 -0400
Received: from smtp.microsoft.com ([131.107.115.212]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDmrD-0007qa-J7 for tls@ietf.org; Wed, 25 Jul 2007 15:49:16 -0400
Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Wed, 25 Jul 2007 12:49:14 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.726.0; Wed, 25 Jul 2007 12:49:14 -0700
Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jul 2007 12:49:14 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] the use cases for GSS-based TLS and the plea for integrating
Date: Wed, 25 Jul 2007 12:48:21 -0700
Message-ID: <CAAAEFE273EAD341A4B02AAA9CA6F73306D440AB@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] the use cases for GSS-based TLS and the plea for integrating
Thread-Index: AcfO8VlgSP6s2gjwQV+P/Szohn+fswAAFr7Q
References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org>
From: Larry Zhu <lzhu@windows.microsoft.com>
To: Chris.Newman@Sun.COM, martin.rex@sap.com
X-OriginalArrivalTime: 25 Jul 2007 19:49:14.0211 (UTC) FILETIME=[E0CB4B30:01C7CEF4]
X-Spam-Score: -100.0 (---------------------------------------------------)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
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 use cases, please review my slides and the meeting minutes for the
TLS working group. I would like to recap the main points below:

Methodology wise the way to deal with complexity is to build abstraction
layers. GSS-API is ideal for encapsulating the described complexity. 

We strongly believe there is a confusing message in IETF. Our security
AD made a presentation in the TLS working group yesterday and the
message is that we want everyone to use TLS for everything. But you
can't use Kerberos in TLS in a secure fashion today. The FXA-TLS fills
in this gap. It is not a conspiracy that the two presentations were
arranged together with my slides extending Tim's slides in that sense.
With FXA-TLS, one can use both certificate based authentication and
Kerberos using one mechanism. No one wants to design their protocols
once with Kerberos and once with TLS, no one want to review their
protocols twice. Experience has clearly shown that requiring two set of
mechanisms (one for Kerb and one for TLS) adds a lot of unnecessary
complexity to what is already too complex. Not to mention the burden to
test two sets of mechanisms. We the IETF really should build a better
building block for future IETF standard protocols and deliver a coherent
strategy/solution. 

Non-IETF protocols that do not have a SASL variant do not even have a
choice, we have to integrate Kerberos into the TLS stack to get Kerberos
to work, not to mention the practical reasons due to firewalls and NAT
traversal.

--larry


-----Original Message-----
From: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] 
Sent: Wednesday, July 25, 2007 12:25 PM
To: martin.rex@sap.com; Larry Zhu
Cc: tls@ietf.org
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for
integrating

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