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

pgut001@cs.auckland.ac.nz Fri, 27 July 2007 14:07 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 1IEQTI-0002Li-52; Fri, 27 Jul 2007 10:07:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQTH-0002Ld-RF for tls@lists.ietf.org; Fri, 27 Jul 2007 10:07:11 -0400
Received: from moe.its.auckland.ac.nz ([130.216.12.35] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEQTF-0004ue-KV for tls@lists.ietf.org; Fri, 27 Jul 2007 10:07:11 -0400
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2E9D14804E7 for <tls@lists.ietf.org>; Sat, 28 Jul 2007 02:07:06 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RlPjXMzeDS2 for <tls@lists.ietf.org>; Sat, 28 Jul 2007 02:07:06 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 1390C4804E6 for <tls@lists.ietf.org>; Sat, 28 Jul 2007 02:07:06 +1200 (NZST)
Received: from eris.cs.auckland.ac.nz (eris.cs.auckland.ac.nz [130.216.33.46]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id AE758D14CFC for <tls@lists.ietf.org>; Sat, 28 Jul 2007 02:07:05 +1200 (NZST)
Received: from 125-238-114-81.broadband-telecom.global-gateway.net.nz (125-238-114-81.broadband-telecom.global-gateway.net.nz [125.238.114.81]) by webmail.cs.auckland.ac.nz (Horde) with HTTP for <pgut001@webmail.cs.auckland.ac.nz>; Sat, 28 Jul 2007 02:07:02 +1200
Message-ID: <20070728020702.2x3rc53g7bksocc0@webmail.cs.auckland.ac.nz>
Date: Sat, 28 Jul 2007 02:07:02 +1200
From: pgut001@cs.auckland.ac.nz
To: tls@lists.ietf.org
Subject: RE: [TLS] the use cases for GSS-based TLS and the plea for integrating
References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org><C4E819FF73EA6ED22A3906CD@446E7922C82D299DB29D899F> <46A8FD4F.7050203@it.su.se> <FA998122A677CF4390C1E291BFCF598907DF564E@EXCH.missi.ncsc.mil>
In-Reply-To: <FA998122A677CF4390C1E291BFCF598907DF564E@EXCH.missi.ncsc.mil>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.0.1)
X-Originating-IP: 125.238.114.81
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
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

"Kemp, David P." <DPKemp@missi.ncsc.mil> writes:
> Symmetric mechanisms (static passwords, OTP, Kerberos, etc) all have the
> property of requiring communication with an identity provider in real-time to
> authenticate a user (except for pre-placed keys, a non-scalable 
> technique that
> is not under consideration for TLS even though it is supported in IPSec).
>
> Asymmetric (certificate-based) mechanisms can authenticate a user without
> communicating with an identity provider and without giving one party the
> ability to masquerade as the other.
>
> One certainly would not want to remove asymmetric authentication from TLS
> (i.e., it should remain mandatory to implement).

I realise this has the potential to open up a huge can of worms here, but I
can't let this one pass by: "shared keys/passwords/whatever don't scale" is
one of the most persistent myths on computer security.  99.99% of all
authentication is done via pre-shared keys/passwords, including pretty much
arbitrarily large infrastructures like eBay, Amazon, Gmail, any ISP using
RADIUS, and <insert-name-here>.  The ones that we know definitely don't scale
well in comparison are all the others: PKI, Kerberos, yadda yadda yadda, and
in particular the asymmetric-auth ones.

For how many more years do we have to keep flogging the PKI corpse?  If it
worked as intended, the multibillion-dollar phishing industry wouldn't exist.
Why keep it mandatory to implement something that very demonstrably doesn't
work?

Peter.


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