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 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() hash(x) := (f2(,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())^(-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())^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() <----------------------------- s := w^x % N v := u^(-1) % N Abort if c0 <> kdf() c1 := kdf() K := kdf() c1 -----------------------------> Abort if c1 <> kdf() K := kdf() 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, . [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. [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]