RFC 5683
Password-Authenticated Key (PAK) Diffie-Hellman Exchange
RFC 5683: Password-Authenticated Key (PAK) Diffie-Hellman Exchange 🎀
Okay bestie, this one is RFC 5683, and the title is Password-Authenticated Key (PAK) Diffie-Hellman Exchange ✨. It's an Independent Submission, which means it goes through the RFC Series on its own and isn't tied to any other stream 🦋. The category is Informational, the ISSN is 2070-1721, and it's dated February 2010. The authors are A. Brusilovsky, I. Faynberg, Z. Zeltsan (all from Alcatel-Lucent), and S. Patel (from Google, Inc.) 💜. The title block doesn't say it obsoletes or updates anything, so it doesn't mess with any other RFCs 🌈.
Abstract 🔐
So the big idea is adding mutual authentication to plain, unauthenticated Diffie-Hellman key exchange 💅. The authentication is based on a password that humans can actually memorize. The algorithm is called PAK, short for Password-Authenticated Key exchange, and it lets two parties authenticate each other while they're doing the Diffie-Hellman exchange. Iconic 😭.
PAK is secure against all passive and active attacks. Even better, neither type of attacker can get any information that would let them run an offline dictionary attack on the password 🙈. And PAK provides Forward Secrecy 🔥.
Status of This Memo 📝
This document is not an Internet Standards Track specification. It's published for informational purposes 🌸.
It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment. Documents the RFC Editor approves for publication aren't a candidate for any level of Internet Standard. For that, see Section 2 of RFC 5741 ✨.
For info on the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc5683 🧚.
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) as in effect on the date of publication. Please read these carefully, because 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 .....................................81. Introduction 🦋
PAK has some really good perks ✨:
- 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 Diffie-Hellman ([RFC2631], [DH76]) in the random oracle model [BR93]. That means PAK keeps its security even when it's used with low-entropy passwords 🫶. So it can be seamlessly plugged into existing applications that need secure authentication based on those kinds of low-entropy shared secrets 💅.
2. Conventions 📚
Here's the notation the document uses, so you can follow along 🧠:
Ais an identity of Alice.Bis an identity of Bob.Rais a secret random exponent selected by A.Rbis a secret random exponent selected by B.Xabdenotes a value (X presumably computed by A) as derived by B.Ybadenotes a value (Y presumably computed by B) as derived by A.A mod bdenotes 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)andH2(u)are the key derivation functions.H3(u),H4(u), andH5(u)are the hash functions.s|tdenotes concatenation of the strings s and t.^denotes exponentiation.- Multiplication, division, and exponentiation are performed over
(Zp)*. In other words:a*balways meansa*b (mod p).a/balways meansa * x (mod p), where x is the multiplicative inverse of b modulo p.a^bmeansa^b (mod p).
3. Password-Authenticated Key Exchange 🎀
Diffie-Hellman key agreement needs both the sender and the recipient of a message to create their own secret, random numbers and then exchange the exponentiation of those numbers 🔑.
PAK has two parties, Alice (A) and Bob (B), who share a secret password PW that satisfies these conditions 💜:
H1(A|B|PW) != 0
H2(A|B|PW) != 0The global Diffie-Hellman publicly known constants, a prime p and a generator g, are carefully picked so that ✨:
- A safe prime p is large enough to make computing discrete logarithms infeasible, and
- Powers of g modulo p cover the entire range of p-1 integers from 1 to p-1. (References show working examples of these selections.)
To start, Alice (A) picks a secret, random exponent Ra and computes g^Ra. Bob (B) picks a secret, random exponent Rb and computes g^Rb 🌸. For efficiency, short exponents could be used for Ra and Rb, as long as they have a certain minimum size. Then the exchange goes like this 🧚:
A --> B: {A, X = H1(A|B|PW)*(g^Ra)}
(The above precondition on PW ensures that X != 0)
Bob
receives Q (presumably Q = X), verifies that Q != 0
(if Q = 0, Bob aborts the procedure);
divides Q by H1(A|B|PW) to get Xab, the recovered value of g^Ra
B --> A: {Y = H2(A|B|PW)*(g^Rb), S1 = H3(A|B|PW|Xab|g^Rb|(Xab)^Rb)}
(The above precondition on PW ensures that Y != 0)
Alice
verifies that Y != 0;
divides Y by H2(A|B|PW) to get Yba, the recovered value of g^Rb,
and computes S1' = H3(A|B|PW|g^Ra|Yba|(Yba)^Ra);
authenticates Bob by checking whether S1' = S1;
if authenticated, then sets key K = H5(A|B|PW|g^Ra|Yba|(Yba)^Ra)
A --> B: S2 = H4(A|B|PW|g^Ra|Yba|(Yba)^Ra)
Bob
Computes S2' = H4(A|B|PW|Xab|g^Rb|(Xab)^Rb) and
authenticates Alice by checking whether S2' = S2;
if authenticated, then sets K = H5(A|B|PW|Xab|g^Rb|(Xab)^Rb)If any of those verifications fails, the protocol halts. Otherwise, both parties have authenticated each other and established the key 🔥.
4. Selection of Parameters 🧁
This section gives guidance on picking the PAK parameters. It starts with general considerations, then reports on specific implementations 💖.
4.1. General Considerations 🌷
In general implementations, the parameters must be selected to meet the algorithm requirements of [BMP00] 📖.
4.2. Over-the-Air Service Provisioning (OTASP) and Wireless Local Area Network (WLAN) Diffie-Hellman Parameters and Key Expansion Functions 📡
[OTASP], [TIA683], and [WLAN] pre-set the public parameters p and g to their "published" values. This is necessary to protect against an attacker sending bogus p and g values. Otherwise they could trick the legit user into doing improper Diffie-Hellman exponentiation, leaking some info about the password 🙈.
According to [OTASP], [TIA683], and [WLAN], g shall be set to 00001101, and p to the following 1024-bit prime number (most significant bit first) 🔢:
0xFFFFFFFF 0xFFFFFFFF 0xC90FDAA2 0x2168C234 0xC4C6628B
0x80DC1CD1 0x29024E08 0x8A67CC74 0x020BBEA6 0x3B139B22
0x514A0879 0x8E3404DD 0xEF9519B3 0xCD3A431B 0x302B0A6D
0xF25F1437 0x4FE1356D 0x6D51C245 0xE485B576 0x625E7EC6
0xF44C42E9 0xA637ED6B 0x0BFF5CB6 0xF406B7ED 0xEE386BFB
0x5A899FA5 0xAE9F2411 0x7C4B1FE6 0x49286651 0xECE65381
0xFFFFFFFF 0xFFFFFFFFIf short exponents [MP05] are used for the Diffie-Hellman parameters Ra and Rb, then they should have a minimum size of 384 bits 🌈. The independent, random functions H1 and H2 should each output 1152 bits, assuming prime p is 1024 bits long and session keys K are 128 bits long. H3, H4, and H5 each output 128 bits. More info on instantiating random functions with hash functions can be found in [BR93] 📚. Below, we use the FIPS 180 SHA-1 hashing function [FIPS180] to instantiate the random function, the same way [WLAN] does. SHA-256 can also be used ✨:
H1(z):
SHA-1(1|1|z) mod 2^128 | SHA-1(1|2|z) mod 2^128 |...|
| SHA-1(1|9|z) mod 2^128
H2(z):
SHA-1(2|1|z) mod 2^128 | SHA-1(2|2|z) mod 2^128 |...|
| SHA-1(2|9|z) mod 2^128
H3(z): SHA-1(3|len(z)|z|z) mod 2^128
H4(z): SHA-1(4|len(z)|z|z) mod 2^128
H5(z): SHA-1(5|len(z)|z|z) mod 2^128To get the 1152 output bits for H1 and H2, nine calls to SHA-1 are made, and the 128 least significant bits of each output are used. The input payload of each SHA-1 call consists of 🧮:
a) 32 bits of function type, which is 1 for H1 and 2 for H2; b) a 32-bit counter value, which goes from 1 to 9, incremented for each call to SHA-1; c) the argument z [for (A|B|PW)].
The functions H3, H4, and H5 need only one call to the SHA-1 hashing function, and their payloads consist of 💅:
a) 32 bits of function type (e.g., 3 for H3); b) a 32-bit value for the bit length of the argument z; c) the actual argument, repeated twice.
Finally, the 128 least significant bits of the output are used 🦋.
5. Security Considerations 🔐
Okay bestie, this is the serious section, so pay attention 🥺 Here's everything you need to watch out for:
- Identifiers. Any protocol that uses PAK must specify a method for producing a single representation of identity strings. ✨
- Shared secret. PAK involves the use of a shared secret. Protecting the shared values and limiting how long they stay exposed is essential, and you can do that with well-known security policies and measures 🔒 If a single secret is shared among more than two entities (e.g., Alice, Bob, and Mallory), then Mallory can represent himself as Alice to Bob without Bob being any the wiser. 💀
- Selection of Diffie-Hellman parameters. The parameters p and g must be carefully selected so the shared secret doesn't get compromised 😤 Only previously agreed-upon values for parameters p and g should be used in the PAK protocol. This matters because it protects against an attacker sending bogus p and g values and tricking the other party into an improper Diffie-Hellman exponentiation. Both parties also need to randomly select a new exponent every time the key-agreement protocol runs. If both parties re-use the same values, then Forward Secrecy property is lost 💔
In addition, if short exponents Ra and Rb are used, then they should have a minimum size of 384 bits (assuming that 128-bit session keys are used). Historically, the developers were going for 128-bit security (so they picked 256-bit exponents) and then added 128 bits to the exponents to make sure the security reduction proofs worked. That's why an "odd" length of 384 shows up 🙈
- Protection against attacks.
- a) There's a potential attack called the discrete logarithm attack on the multiplicative group of congruencies modulo p. An adversary can build a table of discrete logarithms and use it as a "dictionary" 📖 A sufficiently large prime, p, must be selected to protect against this. A proper 1024-bit value for p and an appropriate value for g are published in [WLAN] and [TIA683]. That's what's been implemented for now, but a larger prime (one that's 2048 bits long, or even larger) will definitely give better protection 🛡️ Once you do that, the generator must be changed too, so this task must be approached with extreme care 🫶
- b) An online password attack happens when an attacker keeps guessing the password and trying to authenticate over and over. Implementers of PAK should consider using mechanisms (such as lockouts) to stop these attacks 🚫
- Recommendations on H() functions. The independent, random functions H1 and H2 should output 1152 bits each, assuming prime p is 1024 bits long and session keys K are 128 bits long. The random functions H3, H4, and H5 should output 128 bits 🧚
An example of secure implementation of PAK is provided in [Plan9] 🌈
6. Acknowledgments 💜
The authors are so grateful for the thoughtful comments from Shehryar Qutub, Ray Perlner, and Yaron Sheffer 🥹 Special thanks go to Alfred Hoenes, Tim Polk, and Jim Schaad for their careful reviews and invaluable help in getting the final version done. Iconic behavior from the whole crew 👑
7. References 📚
7.1. Normative References
[X.1035] ITU-T, "Password-authenticated key exchange (PAK)
protocol", ITU-T Recommendation X.1035, 2007.
[TIA683] TIA, "Over-the-Air Service Provisioning of Mobile
Stations in Spread Spectrum Systems", TIA-683-D, May
2006.7.2. Informative References
[Plan9] Alcatel-Lucent, "Plan 9 from Bell Labs",
http://netlib.bell-labs.com/plan9/.
[BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably secure
password authentication and key exchange using Diffie-
Hellman", Proceedings of Eurocrypt 2000.
[BR93] Bellare, M. and P. Rogaway, "Random Oracles are
Practical: A Paradigm for Designing Efficient Protocols",
Proceedings of the 5th Annual ACM Conference on Computer
and Communications Security, 1998.
[DH76] Diffie, W. and M.E. Hellman, "New directions in
cryptography", IEEE Transactions on Information Theory 22
(1976), 644-654.
[FIPS180] NIST Federal Information Processing Standards,
Publication FIPS 180-3, "Secure Hash Standard", 2008.
[MP05] MacKenzie, P. and S. Patel, "Hard Bits of the Discrete
Log with Applications to Password Authentication", CT-RSA
2005.
[OTASP] 3GPP2, "Over-the-Air Service Provisioning of Mobile
Stations in Spread Spectrum Systems", 3GPP2 C.S0016-C v.
1.0 5, October 2004.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
2631, June 1999.
[WLAN] 3GPP2, "Wireless Local Area Network (WLAN) Interworking",
3GPP2 X.S0028-0, v.1.0, April 2005.Authors' Addresses 💌
Alec Brusilovsky
Alcatel-Lucent
Room 9B-226, 1960 Lucent Lane
Naperville, IL 60566-7217 USA
Tel: +1 630 979 5490
EMail: Alec.Brusilovsky@alcatel-lucent.com
Igor Faynberg
Alcatel-Lucent
Room 2D-144, 600 Mountain Avenue
Murray Hill, NJ 07974 USA
Tel: +1 908 582 2626
EMail: igor.faynberg@alcatel-lucent.com
Sarvar Patel
Google, Inc.
76 Ninth Avenue
New York, NY 10011 USA
Tel: +1 212 565 5907
EMail: sarvar@google.com
Zachary Zeltsan
Alcatel-Lucent
Room 2D-150, 600 Mountain Avenue
Murray Hill, NJ 07974 USA
Tel: +1 908 582 2359
EMail: zeltsan@alcatel-lucent.com📦 where this page comes from
- ietf: rfc5683 2010-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms