Internet Draft                                              P. MacKenzie
Document: draft-mackenzie-ips-iscsi-pak-00.txt       Lucent Technologies
Expires: November 2002                                          May 2002


           PAK: Password-Authenticated Key Exchange for iSCSI

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
      http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html.

Abstract

   This draft describes a password-authenticated key exchange protocol
   called PAK [PAK,PAK-Orig] that is secure against both a passive
   eavesdropper and an active attacker, i.e., one who may insert, block,
   or modify messages sent over a network.  In particular, it does not
   allow either type of attacker to obtain any information that would
   enable an off-line dictionary attack on the password.  We discuss how
   this password-authenticated key exchange protocol may be used with
   iSCSI [iSCSI].

1. Introduction

   PAK [PAK] is a password-authenticated key exchange protocol that is a
   refinement of the Diffie-Hellman-based EKE protocol [EKE].  It is
   designed to be secure against both a passive eavesdropper and an
   active "man-in-the-middle" attacker, who may insert, block, or modify
   messages sent between the participants of the protocol.  In
   particular, neither type of attacker can obtain information to enable
   an offline dictionary attack on the password.  Thus the only attack
   allowed is an online attack, in which the attacker can test at most


MacKenzie                                                       [Page 1]

Internet Draft    draft-mackenzie-ips-iscsi-pak-00.txt        April 2002


   one password per online authentication attempt.

   The security of the PAK protocol relies on the security of
   unauthenticated Diffie-Hellman key exchange [DH], plus the security
   of the hash function used.  In fact, assuming that the hash function
   is random (i.e., assuming the "random oracle" model [BR]), it has
   been shown that breaking the PAK protocol with success better than
   that of a simple online attack implies that a passive eavesdropper
   could break an unauthenticated Diffie-Hellman key exchange [PAK].


2. Notations, Conventions, and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

   All hash functions operate on and produce byte strings.

   The notation <a|b|...|z> denotes the concatenation of the byte
   strings a,b,...,z.  The *, ^, and % operators denote multiplication,
   exponentiation and modular reduction, respectively.  The XOR operator
   denotes the exclusive-or operation.

   The := operator denotes the assignment of a value to a variable.

   For 0<=i<=255, the notation [i] denotes the byte i.

   The notation "a := Random(S)" denotes the assignment of a random
   element from the set S to the variable a.  The notation "Z_a" denotes
   the set {0,1,...,a-1} (i.e., the integers modulo a), and for a prime
   N, the notation "Z*_N" denotes the set {1,2,...,N-1} (i.e., the
   multiplicative group of integers modulo N).

   We use the same convention as [Jablon] in implicit conversion between
   byte strings and unsigned big integers when necessary, with the first
   bits of a byte string representing the high order bits of the
   corresponding integer.  In particular, we implicitly use the OS2IP
   and FE2OSP conversion operators from [IEEE 1363].

   We use the following parameters:

         N     field order, a 1024-bit prime of the form kq + 1
         q     order of the multiplicative group, a 160-bit prime
         k     the "co-factor" (about 864-bits)
         g     a generator of the subgroup of Z*_N of order q
         hash  a hash function with output in Z*_N based on SHA-1
         kdf   a hash function with 128-bit output based on SHA-1


MacKenzie                                                       [Page 2]

Internet Draft    draft-mackenzie-ips-iscsi-pak-00.txt        April 2002


   The parameters N, q, k, and g are of the same type as those used in
   the US Government DSA signature algorithm [FIPS186]. Note that for
   efficiency these use a 160-bit subgroup of the multiplicative group
   modulo N, and thus they allow (short) 160-bit exponents.

   In practice, we expect to have a list of fixed standard values for N,
   q, k, and g that the two parties in the protocol may agree on.  For
   instance, the following parameters are used for PAK in the Plan9
   distribution [Plan9] (in hex):

         N: C41CFBE4D4846F67A3DF7DE9921A49D3B42DC33728427AB159CEC8CBB
            DB12B5F0C244F1A734AEB9840804EA3C25036AD1B61AFF3ABBC247CD4
            B384224567A863A6F020E7EE9795554BCD08ABAD7321AF27E1E92E3DB
            1C6E7E94FAAE590AE9C48F96D93D178E809401ABE8A534A1EC4435973
            3475A36A70C7B425125062B1142D

         q: E0F0EF284E10796C5A2A511E94748BA03C795C13

         k: DF310F4E54A5FEC5D86D3E14863921E834113E060F90052AD332B3241
            CEF2497EFA0303D6344F7C819691A0F9C4A773815AF8EAECFB7EC1D98
            F039F17A32A7E887D97251A927D093F44A55577F4D70444AEBD06B9B4
            5695EC23962B175F266895C67D21C4656848614D888A4

         g: 2F1C308DC46B9A44B52DF7DACCE1208CCEF72F69C743ADD4D23271734
            44ED6E65E074694246E07F9FD4AE26E0FDDD9F54F813C40CB9BCD4338
            EA6F242AB94CD410E676C290368A16B1A3594877437E516C53A6EEE54
            93A038A017E955E218E7819734E3E2A6E0BAE08B14258F8C03CC1B30E
            0DDADFCF7CEDF0727684D3D255F1

   Both hash and kdf are assumed to have the properties of a random
   oracle, and thus we define them as follows, using SHA-1 [SHA1] as the
   basis:

        f1(x)   := SHA-1(x) mod 2^128
        f2(x,j) := < f1(<[1]|x>) | f1(<[2]|x>) | ... | f1(<[j]|x>) >
        kdf(x)  := f1(<len(x)|x>)
        hash(x) := (f2(<len(x)|x>,9) % (N-1))+1

   The function len(x) denotes the bit length of x stored in a 32-bit
   word in big-endian order, i.e., high byte first.  We prepend len(x)
   to x in order to prevent simple padding attacks on SHA-1, given that
   our inputs may have variable lengths. Note that hash(x) always
   produces a value in Z*_N.  Also, in hash(x) we use f2(-,9) instead of
   f2(-,8) in order to produce a final output that is more uniformly
   distributed in Z*_N.





MacKenzie                                                       [Page 3]

Internet Draft    draft-mackenzie-ips-iscsi-pak-00.txt        April 2002


3. PAK protocol

3.1 Initialization

   Before any authentication and key exchange protocol, the client and
   server must have their shared secrets initialized.  The client must
   remember a password p, while the server stores

      v := (hash(<T0|p>))^(-k) % N,

   along with the client's username U, and the paramIndex indicating the
   set of parameters (N,q,k,g) to be used.  (Note that the server could
   simply store the password instead of v, but that would force the
   server to do an exponentiation by k in each session.)  The value T0
   is the type, which is defined below to be [0].


3.2 The PAK protocol

3.2.1 Identification and Parameter Selection

   The first two messages are for the client to send a username U to the
   server, and for the server to respond with the index of the set of
   Diffie-Hellman parameters.  As is the case with SRP authentication in
   iSCSI, these are announced parameters that cannot be negotiated; the
   client MUST either accept them or close the connection.

        Client                              Server

                            U
              ----------------------------->

                                   Retrieve (U,v,paramIndex)
                                   Retrieve (N,q,k,g) using paramIndex

                        paramIndex
              <-----------------------------

        Retrieve (N,q,k,g) using paramIndex


3.2.2 Key Exchange

   The intuition behind the PAK protocol is that it does a standard
   unauthenticated Diffie-Hellman, except that it multiplies the
   client's Diffie-Hellman value by the hash of the password (raised to
   the power k so the result lies in the subgroup of order q).   We say
   that the client's value is "entangled" with the password.  The client


MacKenzie                                                       [Page 4]

Internet Draft    draft-mackenzie-ips-iscsi-pak-00.txt        April 2002


   then receives the server's Diffie-Hellman value and a key
   confirmation hash, and if it is OK, sends out its own key
   confirmation hash.

   IMPORTANT: As is specified in the protocol description below, the
   client MUST receive and verify a key confirmation from the server
   before continuing with the protocol.  The basic reason is that the
   server's Diffie-Hellman value has not been entangled with the
   password (see [PAK] for details), and thus without this verification,
   an active attacker may obtain enough information to perform an
   offline dictionary attack.

   On the server side, the server retrieves the entangled value from the
   client, checks that it is not equal to zero modulo N, computes its
   own Diffie-Hellman value, and disentangles the value retrieved from
   the client in order to compute the Diffie-Hellman secret.  Then it
   sends back its own Diffie-Hellman value and a key confirmation hash,
   and waits for the client to send its key confirmation hash.

   IMPORTANT: As is specified in the protocol description below, the
   server MUST verify that the value received by the client is not equal
   to zero modulo N (i.e., that it is not equal to zero nor any multiple
   of N).  If this is not done, then an active attacker may obtain
   enough information to perform an offline dictionary attack.

   The protocol is as follows, with the values U, v, N, q, k, and g
   taken from the identification and parameter selection protocol above.























MacKenzie                                                       [Page 5]

Internet Draft    draft-mackenzie-ips-iscsi-pak-00.txt        April 2002


          Client                              Server

          x := Random(Z_q)
          a := g^x % N
          u := (hash(<T0|p>))^k % N
          m := a*u % N
                              m
                ----------------------------->

                                         Abort if (m % N) = 0
                                         y := Random(Z_q)
                                         w := g^y % N
                                         a := m*v % N
                                         s := a^y % N
                                         c0 := kdf(<T1|U|m|w|s|v>)
                            <w,c0>
                <-----------------------------

          s := w^x % N
          v := u^(-1) % N
          Abort if c0 <> kdf(<T1|U|m|w|s|v>)
          c1 := kdf(<T2|U|m|w|s|v>)
          K := kdf(<T3|U|m|w|s|v>)

                              c1
                ----------------------------->

                                         Abort if
                                            c1 <> kdf(<T2|U|m|w|s|v>)
                                         K := kdf(<T3|U|m|w|s|v>)


   All values from Z*_N input to kdf and hash are assumed to be stored
   in big-endian order, and MUST include any necessary leading 0 bits to
   be of full size, i.e., |m|=|w|=|s|=|v|=1024.  This prevents any types
   of unforeseen "collisions" that could occur when hashing two or more
   values of variable length, e.g., h("xy"|"z") = h("x"|"yz").

   K is the shared session key.

   The values T0,T1,T2,T3 are the types of the functions, and are
   defined as

         T0 := [0]
         T1 := [1]
         T2 := [2]
         T3 := [3]



MacKenzie                                                       [Page 6]

Internet Draft    draft-mackenzie-ips-iscsi-pak-00.txt        April 2002


4. Discussion

4.1 External Authentication Servers

   We note that authentication in PAK cannot be outsourced to a RADIUS
   server that does not implement EAP, since it is essential to the key
   exchange to have the password hash v.

4.2 PAK and EAP

   The Extensible Authentication Protocol (EAP) (defined in [RFC 2284],
   being updated in [2284bis]) describes a framework that allows the use
   of multiple authentication mechanisms. In a future draft we will
   provide the details of how to incorporate PAK into EAP, most likely
   based on [EAP-SRP].


5. Security Considerations

   The main reason to use PAK for password-authenticated key exchange is
   to obtain the strongest security possible for key exchange, while
   using passwords (i.e., relatively short secrets) for authentication.
   In particular, PAK achieves security against active attackers, so
   that no information is leaked to allow an offline dictionary attack
   on the password.  By comparison, the DH-CHAP protocol [DH-CHAP] is
   only designed to be secure against passive eavesdroppers.

   As discussed above, PAK has a mathematical proof of security against
   active attackers, when the hash functions are assumed to behave like
   random functions.  (This is a very common assumption to use for
   practical security protocols, such as OAEP [OAEP,OAEP+,RSA-OAEP].)
   In comparison, neither the SRP protocol [RFC 2945] nor the SPEKE
   protocol [SPEKE] have this level of proven security.

   Note that the version of PAK we are proposing does not attempt to
   provide security against insider attacks on the server.  That is,
   someone who obtains the password file from the server may impersonate
   a client, without even running a dictionary attack.  In constrast,
   SRP is designed to force someone who obtains the password file to run
   an offline dictionary attack before impersonating a client. There are
   extensions to PAK that also provide this security property [PAK], and
   these could be proposed in future drafts.


6. Intellectual Property Notice

   This is to inform you that Lucent Technologies has applied for and/or
   has patent(s) that relates to the attached submission.


MacKenzie                                                       [Page 7]

Internet Draft    draft-mackenzie-ips-iscsi-pak-00.txt        April 2002


   This submission is being made pursuant to the provisions of IETF IPR
   Policy, RFC 2026, Sections 10.3.1 and 10.3.2.

   Lucent Technologies Inc.  will offer patent licenses for submissions
   made by it which are adopted as a standard by your organization as
   follows:

   If part(s) of a submission by Lucent is included in a standard and
   Lucent has patents and/or pending applications that are essential to
   implementation of the included part(s) in said standard, Lucent is
   prepared to grant - on the basis of reciprocity (grant back) - a
   license on such included part(s) on reasonable, non-discriminatory
   terms and conditions.

Acknowledgements

   The PAK protocol described in this document is a result of work by
   the author in collaboration with Victor Boyko, Sarvar Patel, and Eric
   Grosse.  Many thanks to Daniel Bleichenbacher, Sarvar Patel, Eric
   Grosse, and Jeff Fellin for helpful comments on this draft.



References

   [BR] M. Bellare, P. Rogaway, "Random oracles are practical: A
      Paradigm for Designing Efficient Protocols," In 1st ACM Conference
      on Computer and Communications Security, pp. 62-73, November 1993.

   [OAEP] M. Bellare, P. Rogaway, "Optimal Asymmetric Encryption," In
      Eurocrypt '94 (Lecture Notes in Computer Science 950), pp. 92-111,
      1995.

   [EKE] Bellovin S., and M. Merritt, "Encrypted Key Exchange:
      Password-based protocols secure against dictionary attacks," In
      IEEE Symposium on Research in Security and Privacy, pp. 72-84, May
      1992.

   [DH-CHAP] D. Black, "DH-CHAP: Diffie-Hellman Enhanced CHAP for
      iSCSI," draft-black-ips-iscsi-dhchap-00.txt, Work in Progress,
      April 2002.

   [RFC 2284]  L. Blunk, J. Vollbrecht, "PPP Extensible Authentication
      Protocol (EAP)," RFC 2284, March 1998

   [2284bis]  L. Blunk, J. Vollbrecht, B Aboba, "Extensible
      Authentication Protocol (EAP)," draft-ietf-pppext-rfc2284bis-
      03.txt, Work in Progress, 2 April 2002


MacKenzie                                                       [Page 8]

Internet Draft    draft-mackenzie-ips-iscsi-pak-00.txt        April 2002


   [PAK-Orig] V. Boyko, P. MacKenzie, S. Patel, "Provably Secure
      Password Authentication and Key Exchange using Diffie-Hellman,"
      Eurocrypt 2000 (Lecture Notes in Computer Science 1807), pp. 156-
      171, 2000.

   [EAP-SRP]  J. Carlson, B. Aboba, H. Haverinen, "EAP SRP-SHA1
      Authentication Protocol", draft-ietf-pppext-eap-srp-03.txt, Work
      in Progress, July 2001

   [RSA-OAEP] E. Fujisaki, T. Okamoto, D. Pointcheval, J. Stern, "RSA-
      OAEP is Secure under the RSA Assumption," In Crypto 2001 (Lecture
      Notes in Computer Science 2139), pp. 260-274, 2001.

   [P1363.2] IEEE P1363.2, "Standard Specifications for Public-Key
      Cryptography: Password-Based Techniques", (work in progress),
      IEEE, <http://grouper.ieee.org/groups/1363/>.

   [FIPS186] FIPS186, "Digital Signature Standard," U.S. Department of
      Commerce/NIST National Technical Information Service, Springfield,
      VA, 1994.

   [SPEKE] D. Jablon, "The SPEKE Password-Based Key Agreement Methods,"
      draft-jablon-speke-00.txt, February 2002.

   [PAK] P. MacKenzie, "The PAK Suite: Protocols for Password-
      Authenticated Key Exchange," manuscript, April 2002.
      <http://cm.bell-labs.com/who/philmac/research/pak-suite.pdf>

   [SHA1] National Institute of Standards and Technology (NIST),
      "Announcing the Secure Hash Standard", FIPS 180-1, U.S.
      Department of Commerce, April 1995.

   [Plan9] R. Pike, D. Presotto, S. Dorward, B. Flandrena, K. Thompson,
      H. Trickey, P. Winterbottom, "Plan 9 from Bell Labs," Computing
      Systems, Vol. 8, No. 3, pp. 221-254, 1995.  (http://netlib.bell-
      labs.com/plan9dist/)

   [iSCSI] Satran, J., et. al., "iSCSI", draft-ietf-ips-iscsi-11.txt,
      Work in Progress, March 2002.

   [OAEP+] V. Shoup, "OAEP Reconsidered," In Crypto 2001 (Lecture Notes
      in Computer Science 2139), pp. 239-259, 2001.

   [RFC 2945] Wu, T., "The SRP Authentication and Key Exchange System",
      RFC 2945, September 2000.





MacKenzie                                                       [Page 9]

Internet Draft    draft-mackenzie-ips-iscsi-pak-00.txt        April 2002


Author's Address

      Philip MacKenzie
      Lucent Technologies
      Bell Laboratories
      600 Mountain Ave.
      Murray Hill, NJ 07974

      Phone: (908) 582-7625

      EMail: philmac@lucent.com

Full Copyright Statement

   "Copyright (C) The Internet Society (2002). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into followed, or as
   required to translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.











MacKenzie                                                      [Page 10]