Password-Authenticated Key (PAK) Diffie-Hellman Exchange
RFC 5683
Document | Type |
RFC - Informational
(February 2010; No errata)
Was draft-brusilovsky-pak (sec)
|
|
---|---|---|---|
Authors | Zachary Zeltsan , Sarvar Patel , Igor Faynberg , Alec Brusilovsky | ||
Last updated | 2018-12-20 | ||
Stream | ISE | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | ISE state | (None) | |
Consensus Boilerplate | Unknown | ||
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5683 (Informational) | |
Telechat date | |||
Responsible AD | Tim Polk | ||
Send notices to | rfc-editor@rfc-editor.org |
Independent Submission A. Brusilovsky Request for Comments: 5683 I. Faynberg Category: Informational Z. Zeltsan ISSN: 2070-1721 Alcatel-Lucent S. Patel Google, Inc. February 2010 Password-Authenticated Key (PAK) Diffie-Hellman Exchange Abstract This document proposes to add mutual authentication, based on a human-memorizable password, to the basic, unauthenticated Diffie- Hellman key exchange. The proposed algorithm is called the Password- Authenticated Key (PAK) exchange. PAK allows two parties to authenticate themselves while performing the Diffie-Hellman exchange. The protocol is secure against all passive and active attacks. In particular, it does not allow either type of attacker to obtain any information that would enable an offline dictionary attack on the password. PAK provides Forward Secrecy. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5683. Brusilovsky, et al. Informational [Page 1] RFC 5683 PAK Diffie-Hellman Exchange February 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction ....................................................3 2. Conventions .....................................................3 3. Password-Authenticated Key Exchange .............................4 4. Selection of Parameters .........................................5 4.1. General Considerations .....................................5 4.2. Over-the-Air Service Provisioning (OTASP) and Wireless Local Area Network (WLAN) Diffie-Hellman Parameters and Key Expansion Functions ....................................5 5. Security Considerations .........................................7 6. Acknowledgments .................................................8 7. References ......................................................8 7.1. Normative References .......................................8 7.2. Informative References .....................................8 Brusilovsky, et al. Informational [Page 2] RFC 5683 PAK Diffie-Hellman Exchange February 2010 1. Introduction PAK has the following advantages: - It provides a secure, authenticated key-exchange protocol. - It is secure against offline dictionary attacks when passwords are used. - It ensures Forward Secrecy. - It has been proven to be as secure as the Diffie-Hellman solution. The PAK protocol ([BMP00], [MP05], [X.1035]) has been proven to be as secure as the Diffie-Hellman ([RFC2631], [DH76]) in the random oracle model [BR93]. That is, PAK retains its security when used with low- entropy passwords. Therefore, it can be seamlessly integrated into existing applications, requiring secure authentication based on such low-entropy shared secrets. 2. Conventions - A is an identity of Alice. - B is an identity of Bob. - Ra is a secret random exponent selected by A. - Rb is a secret random exponent selected by B. - Xab denotes a value (X presumably computed by A) as derived by B. - Yba denotes a value (Y presumably computed by B) as derived by A. - A mod b denotes the least non-negative remainder when a is divided by b. - Hi(u) denotes an agreed-on function (e.g., based on SHA-1, SHA-256, etc.) computed over a string u; the various H() act as independent random functions. H1(u) and H2(u) are the key derivation functions. H3(u), H4(u), and H5(u) are the hashShow full document text