Re: iSCSI: PAK: an alternative to SRP and DH-CHAP

[Bill Strahm <bill@strahm.net>]

So is the goal of the working group now to propose a "new and 
improved" authentication method every 2 months so we can never
make forward progress...

I have no problems with having the ability to use optional 
authentication methods, but we need to be VERY careful of specifying
MUST/SHOULD algorithms, and the number should be really small, 
VERY well understood, and as widespread as possible.

From my understaning of PAK, I don't see a way of plugging this into
a legacy RADIUS environment (I don't have the password avail at the 
iSCSI endpoint, only the ability to say please authenticate this for me)

Please stop the madness

Bill

On Mon, Apr 29, 2002 at 08:20:34AM -0400, Philip MacKenzie wrote:
> Two weeks ago I heard there was an issue regarding
> password-authenticated key exchange in the iSCSI proposal,
> and after studying the mailing list archive to
> understand the issue and its history, I thought that
> it may be worthwhile to propose an alternative
> that may be more acceptable to the members of this group.
> 
> I am writing an Internet Draft proposing the PAK protocol
> for inclusion in iSCSI.  I expect that it will be published
> within a couple days, but I thought it would be best to present
> the protocol and start the discussion as soon as possible.
> I know that this proposal is coming later in the process
> that desired, but since DH-CHAP was so recently introduced,
> I would hope that this proposal is also not too late.
> 
> PAK is a password-authenticated key exchange protocol that
> is designed to solve the same problem as SRP, namely, it
> is a key exchange protocol that uses a password for
> authentication, but is immune to offline dictionary attacks,
> even against an active attacker who may insert, modify, or
> delete messages on the network.  The basic idea is very
> simple: it's a Diffie-Hellman key exchange with one of the
> Diffie-Hellman messages multiplied by a hash of the password.
> 
> Graphically, it is just:
> 
>      Alice                             Bob
> 
>                     H(pw) * g^x
>               -------------------->
>                   g^y, Conf-hash
>               <--------------------
>                      Conf-hash'
>               --------------------->
> 
> where the secret value is g^{xy}.  Notice that Bob
> must divide out H(pw) from the message he gets from Alice.
> The confirmation hashes are necessary, unless Bob also
> multiplies his value g^y by a hash of the password.
> 
> 
> A complete version of the protocol may be found at:
> 
> http://www.integritysciences.com/p1363/submissions/pak-suite.pdf
> 
> The Internet Draft will have a completely specified version
> of this protocol, with all parameters, etc.
> 
> Reasons for preferring PAK over DH-CHAP:
> - security against active attacks (same as SRP vs. DH-CHAP)
> 
> Reasons for preferring PAK over SRP:
> - PAK has a mathematical proof of security
> (assuming the hash functions are modeled as random functions).
> - PAK is more elegant (IMHO).
> 
> Efficiency:
> - As you can see, PAK is about as efficient as DH-CHAP or SRP
> 
> Acceptance:
> - PAK has been published in Eurocrypt (2000), one
> of the 2 top crypto conferences.
> - PAK is basically a refinement of EKE, the well-known
> encrypted key exchange protocol by Bellovin and Merritt.
> - PAK is being used in Plan9 from Lucent.
> - PAK is one of the protocols being standardized in IEEE P1363.2
> - We are also planning to implement PAK as part
> of the Lucent's iSCSI protocol implementation in FreeBSD.
> 
> Once again, the draft should be available in a day or two,
> but I am happy to answer any questions and comments
> in the meanwhile!
> 
> -Phil MacKenzie
> Bell Labs
> 
> 
> 
> 
>