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

"Kemp, David P." <DPKemp@missi.ncsc.mil> Mon, 30 July 2007 15:15 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 1IFWy2-0008Cr-4y; Mon, 30 Jul 2007 11:15:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFWy1-0008Ck-0o for tls@ietf.org; Mon, 30 Jul 2007 11:15:29 -0400
Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFWxz-0000QB-Ra for tls@ietf.org; Mon, 30 Jul 2007 11:15:28 -0400
Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l6UFFPZi004523 for <tls@ietf.org>; Mon, 30 Jul 2007 11:15:25 -0400 (EDT)
Received: from 144.51.60.33 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Mon, 30 Jul 2007 11:15:25 -0400
Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Jul 2007 11:15:25 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [TLS] the use cases for GSS-based TLS and the plea for integrating
Date: Mon, 30 Jul 2007 11:15:13 -0400
Message-ID: <FA998122A677CF4390C1E291BFCF598907DF5B6C@EXCH.missi.ncsc.mil>
In-Reply-To: <97106756681A40418FDFFE56@446E7922C82D299DB29D899F>
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: AcfQVRHmAgF77DMERoW29pd7DA248wCW9BQA
References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp><48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org><C4E819FF73EA6ED22A3906CD@446E7922C82D299DB29D899F><46A8FD4F.7050203@it.su.se> <97106756681A40418FDFFE56@446E7922C82D299DB29D899F>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: tls@ietf.org
X-OriginalArrivalTime: 30 Jul 2007 15:15:25.0899 (UTC) FILETIME=[74D291B0:01C7D2BC]
X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-15332000
X-TM-AS-Result: : Yes--12.055700-0-31-1
X-TM-AS-Category-Info: : 31:0.000000
X-TM-AS-MatchedID: : 150567-703215-708647-701741-701455-703489-706471-702609-710019-702342-709584-702113-121414-700667-121124-701576-121257-702376-707866-704445-702126-702626-704430-705802-700783-705861-110024-700982-705891-390078-710970-706691-711402-702020-700901-701499-706454-702638-113284-704096-702762-139006-701207-700073-700075-139010-707663-701618-708752-700994-702726-704980-701236-700104-701387-148039-148050
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc:
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

"Today's interim solution to authentication"???  What do you 
see as the ideal, goal solution to authentication?

Dubious qualities related to factory-default trust lists,
issuance practices, etc can be addressed by changing practices
without changing technologies.  If there were a perfect
(non-dubious) scheme for establishing Kerberos credentials
for all TLS servers on the Internet and configuring clients
to trust only "suitable" servers, that same system could be
implemented more easily and scaleably using certificates.

If the X.500 naming system is considered dubious, certificates
could (and IMO should) be issued using names relevant to the
application (DNS-based, UPNs, issuer/account, etc) rather
than artificially creating ISO Directory names where they are
not needed.

In short, I see SSO being as over-hyped today as PKI
was a decade ago.  Every website that requires users to
create password accounts today could just as easily issue
certificates instead and users would get SSO for free.
An Amazon cert, an eBay cert, banking and brokerage account
certs, IM, discussion forum and online gaming certs, all
unlocked with a single password.  TLS supports that today
(well, almost - it could be easier to manage your whole
wallet of certs on a USB flash drive) but for some reason
(perceptions created by the CA industry?) PKI does not.

So my question at the top is genuine - what characteristics
of today's authentication solutions make them "interim" and
dubious, and what characteristics are required of ideal
Internet-scale authentication solutions?

Dave


-----Original Message-----
From: Chris Newman [mailto:Chris.Newman@Sun.COM] 

Leif Johansson wrote on 7/26/07 22:00 +0200:
> Would you support a password-based scheme inside TLS or
> 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