[Prev][Next][Index][Thread]

RE: Shared Secret Authentication

I know of no sense in which our shared-secret authentication proposal is
less secure than Bellovin-Merritt-style authentication.  The major
difference between the two is that our proposal only authenticates *one*
party (the TLS client) using the shared key; the other party (the TLS
server) must still have a certified public key to authenticate.  In
Bellovin-Merritt-style authentication, *both* sides authenticate using
the same shared key.  This second authentication actually *reduces* the
security of the protocol; for example, *both* sides (not just the
server) must guard against online brute-force attacks on the shared key.
 (On the "plus" side, it eliminates the need for one party to have a
certified public key.)

We decided that for the applications we had in mind, requiring that the
server obtain a certificate was not as problematic as worrying about
attacks on the client.  Of course, if people are very enthusiastic about
having Bellovin-Merritt-style two-way shared-key authentication as an
option in TLS, then I would invite them to write up a proposal in
Internet Draft form and submit it to the ietf-tls list.  I, for one,
would certainly not oppose its inclusion, provided it is incorporated in
as secure a manner as possible.

			Daniel Simon
			Cryptographer, Microsoft Corp.
			(dansimon@microsoft.com)    

>-----Original Message-----
>From:	David P. Jablon 
>Sent:	Thursday, February 06, 1997 3:52 PM
>To:	ietf-tls@w3.org
>Subject:	Shared Secret Authentication
>
>
>Earlier threads on this list seem to have focused debate on
>weak methods for password/passphrase/shared-secret authentication.
>
>Methods that are immune to unconstrained dictionary attack
>have been around since 1992, from Bellovin & Merritt's EKE family
>of protocols, to the SPEKE method developed by myself.
>I find it curious that the debate has settled down upon
>demonstrably weaker alternatives, as in the current drafts.
>
>I would suggest that the passauth-00.txt "Addition of
>Shared Key Authentication" document be modified to use
>strong password authentication.  Presenting weak password
>authentication as an alternative to strong public-key
>methods seems sloppy.
>
>I really prefer the combination of strong public-key AND
>strong memorizable passwords, as two independent factors for
>authentication, but that's probably asking for a bit much at
>this point.
>
>------------------------------------
>David P. Jablon
>Integrity Sciences, Inc.
>Westboro, MA
>Tel: +1 508 898 9024
>http://world.std.com/~dpj/
>E-mail: dpj@world.std.com
>