Network Working Group A. Brusilovsky Internet-Draft Lucent Technologies Expires: May, 2006 October 15, 2005 Password Authenticated Diffie-Hellman Exchange (PAK) draft-brusilovsky-pak-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on December 20, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document proposes to add mutual authentication, based on human-memorizable password, to the basic unauthenticated Diffie-Hellman key exchange. The proposed algorithm is called Password Authenticated Key exchange (PAK). PAK adds mutual authentication without changing the basic messaging on the Diffie-Hellman key exchange. PAK is secure against a passive eavesdropper, as well as an active attacker. Pak does not allow an attacker to obtain any information that would enable them to mount an offline dictionary attack on the password. Brusilovsky [Page 1] Internet Draft draft-brusilovsky-pak-00.txt October 2005 Table of Contents 1. Introduction 2. Password Authendicated Key exchange 3. Diffie-Hellman parameters 4. IANA considerations 5. Security Considerations 6. Acknowledgments 7. References Authors' and Contributors' Addresses 1. Introduction When we propose PAK, we adhered to the following set of requirements: a. Mutual authentication based on just a pre-shared, human-memorizable password. b. Fulfillment of the need to guard against a man-in-the-middle and against offline dictionary attack.  c. Simplicity and openness, to promote widespread adoption and to minimize flaws.  PAK (Password Authenticated Key exchange) satisfies all of the above. PAK was presented at the sacred WG meeting at the IETF63 in PAris, where it was proposed as a new work item for the sacred WG. PAK advantages are listed here: - Provides strong key exchange with weak passwords - Foils the man-in-the-middle attack - Provides explicit mutual authentication The security of the PAK protocol relies on the security of unauthenticated Diffie-Hellman key exchange [DH76], plus the security of the hash function used. [Mau94] has shown that breaking the Diffie-Hellman protocol is equivalent to computing discrete logarithms under certain assumptions. It is the proven security of the "standard" Diffie-Hellman key exchange plus added security of the utilized hash function that define PAK security. PAK retains its security when used with low-entropy passwords, it can be seamlessly integrated into existing applications, which require secure authentication. Brusilovsky [Page 2] Internet Draft draft-brusilovsky-pak-00.txt October 2005 2. Password Authendicated Key exchange We briefly describe PAK in this section. Details of the protocol are omitted for simplicity. Diffie-Hellman key agreement requires that both the sender and recipient of a message have key pairs. By combining one's private key and the other party's public key, both parties can compute the same shared secret number. This number can then be converted into cryptographic keying material. X and y are global (public) values. For selection of x and y values please refer to the Section 3 of this I-D and Sections 2.1.1 and 2.2 of [RFC2631]; PW (relatively weak secret) is shared by Alice and Bob. K is shared by Alice and Bob. Alice generates a random private value Ra and Bob generates a random private value Rb. This phase is performed independently by the two parties intending to agree on a secret key. Both Ra and Rb are integers relatively prime to x-1 A --> B: HASH(PW) * (y^Ra mod x), Bob calculates S1 and K: S1 = HASH("1", PW, y^Ra mod x, y^Rb mod x, y^RaRb mod x) K=HASH("3",PW, y^RaRb mod x) A <-- B: HASH(PW) * (y^Rb mod x), S1 Alice verifies S1 and calculates S2 and K: S2 = HASH("2", PW, y^Rb mod x, y^Ra mod x, y^RaRb mod x) K=HASH("3",PW, y^RbRa mod x) A --> B: S2 ^ denotes exponentiation. 3. Diffie-Hellman parameters: Generation of public and private Diffie-Hellman parameters (including, their sizes) is described in [RFC2631]. [OTASP] and [WLAN] recommend to pre-set public parameters x and y to their "published" values. In addition, [OTASP] and [WLAN] provide some requirements for the generation of private Diffie-Hellman parameters Ra and Rb. The necessary PAK restrictions for the selection of Diffie-Hellman parameters will be discussed in the next version of this I-D. 4. IANA considerations No IANA considerations at this time 5. Security Considerations PAK involves the use of shared keys. Protection the shared values and managing (limiting) their exposure over time is of outmost importance. 6. Acknowledgments Special thank you goes to Igor Faynberg for his generous assistance, thoughtful comments and guidance. The author also wishes to thank Shehryar Qutub for his expert advice, review and suggestions. Brusilovsky [Page 3] Internet Draft draft-brusilovsky-pak-00.txt October 2005 7. References [DH76] W. Diffie and M.E. Hellman, New directions in cryptography, IEEE Transactions on Information Theory 22 (1976), 644-654. [Mau94] U. Maurer, Towards the equivalence of breaking the Diffie-Hellman protocol and computing discrete logarithms, Advances in Cryptology - Crypto '94, Springer-Verlag (1994), 271-281. [RFC2631] IETF RFC 2631, E. Rescorla, Diffie-Hellman Key Agreement Method, Standards track,1999 [SHA1] National Institute of Standards and Technology (NIST), "Announcing the Secure Hash Standard", FIPS 180-1, U.S. Department of Commerce, April 1995. [OTASP] Over-the-Air Service Provisioning of Mobile Stations in Spread Spectrum Standards, 3GPP2 C.S0016-C v. 1.0 5, 3GPP2, 10/2004. [WLAN] Wireless Local Area Network (WLAN) Interworking, 3GPP2 X.S0028-0, v.1.0, 3GPP2, 4/2005 Authors' and Contributors' Addresses Alec Brusilovsky Lucent Technologies 1960 Lucent Lane, Naperville, IL 60564 USA Tel: +1 630 979 5490 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Brusilovsky [Page 4] Internet Draft draft-brusilovsky-pak-00.txt October 2005 Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights." This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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." Brusilovsky [Page 5]