RFC 6628

Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2

📅 published June 2012, from ietf

Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2 🎀

RFC 6628 💖 Category: Experimental 🧪 ISSN: 2070-1721 Date: June 2012 📅 Authors: S. Shin and K. Kobara, both from AIST 👩‍💻👩‍💻 Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates 🙅‍♀️

Okay bestie, this is the RFC that's basically "password-only login, but make it secure and efficient" ✨ It's an experimental spec, so it's for trying things out and evaluating them, not a finished standard. We're getting the vibes right at the top so you know what you're reading 🦋

Abstract

Okay so the big idea here is an augmented password-only authentication and key exchange (AugPAKE) protocol 🔐 The user only has to remember a low-entropy password, and the server stores a verifier for it. Lowkey the scary part is that passwords usually come from a small set of dictionary words, which means an attacker can just run exhaustive searches (aka off-line dictionary attacks) 😭

The AugPAKE protocol in this doc is built to hold up against passive attacks, active attacks, and off-line dictionary attacks (on the messages that got captured during passive or active attacks). It also gives you resistance to server compromise, which is iconic because it's the whole point of the "augmented" part 👑 The doc also explains how AugPAKE gets plugged into the Internet Key Exchange Protocol version 2 (IKEv2) 🌸

Status of This Memo

This document is not an Internet Standards Track specification 🙅‍♀️ It's published for examination, experimental implementation, and evaluation 🧪

It defines an Experimental Protocol for the Internet community ✨ It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious about that 🤓

For the current status of this document, any errata, and how to send feedback, look at http://www.rfc-editor.org/info/rfc6628 🔗

Copyright Notice

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 read these carefully, because they spell out your rights and restrictions for this document 📜 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🧾

   1. Introduction ....................................................3
      1.1. Keywords ...................................................4
   2. AugPAKE Specification ...........................................4
      2.1. Underlying Group ...........................................4
      2.2. Notation ...................................................5
           2.2.1. Password Processing .................................6
      2.3. Protocol ...................................................7
           2.3.1. Initialization ......................................7
           2.3.2. Actual Protocol Execution ...........................7
   3. Security Considerations .........................................9
      3.1. General Assumptions ........................................9
      3.2. Security against Passive Attacks ..........................10
      3.3. Security against Active Attacks ...........................10
           3.3.1. Impersonation Attacks on User U ....................10
           3.3.2. Impersonation Attacks on Server S ..................11
           3.3.3. Man-in-the-Middle Attacks ..........................11
      3.4. Security against Off-line Dictionary Attacks ..............12
      3.5. Resistance to Server Compromise ...........................12
   4. Implementation Consideration ...................................13
   5. AugPAKE for IKEv2 ..............................................13
      5.1. Integration into IKEv2 ....................................13
      5.2. Payload Formats ...........................................15
           5.2.1. Notify Payload .....................................15
           5.2.2. Generic Secure Password Method Payload .............16
   6. IANA Considerations ............................................16
   7. References .....................................................16
      7.1. Normative References ......................................16
      7.2. Informative References ....................................17
   Appendix A.  Evaluation by PAKE Selection Criteria.................19

1. Introduction ✨

In the real world, tons of apps need secure channels between the parties involved, like Web mail and internet banking, shopping, and trading 💅 These channels can be set up with an authentication and key exchange (AKE) protocol, which lets the parties authenticate each other and generate a temporary session key 🔑 That session key then protects the communication that comes after 🛡️

Password-only AKE (called PAKE) protocols have gotten a lot of attention because logging in with just a password is super convenient for users 🥰 But designing a secure PAKE is not trivial, because of off-line dictionary attacks on passwords. These attacks work because passwords come from a fairly small dictionary, so an attacker can run exhaustive searches 😬 Bellovin and Merritt [BM92] brought this problem up, and lots of work has followed (see some examples in [IEEEP1363.2]). A PAKE is considered secure if the best an active attacker can do is on-line dictionary attacks, where each guessed password can only be checked by interacting with the honest party 🙌

An augmented PAKE (for example [BM93], [RFC2945], [ISO]) adds extra protection against server compromise. The idea is that an attacker who grabs a password verifier from a server can't impersonate the user without running off-line dictionary attacks on that verifier 🧠 This extra security is known as "resistance to server compromise" 👑

The AugPAKE protocol in this document is an augmented PAKE, and it's also measurably more efficient than some earlier work, namely SRP [RFC2945] and AMP [ISO] 📈 The authors believe the following (see [SKI10] for the formal security proof): 1) AugPAKE is secure against passive attacks, active attacks, and off-line dictionary attacks (on the messages obtained during passive/active attacks), and 2) it provides resistance to server compromise 🫶 AugPAKE also has computational efficiency similar to plain Diffie-Hellman key exchange [DH76], which doesn't provide authentication by itself 🦋 Specifically, the user and the server need to compute 2 and 2.17 modular exponentiations, respectively, in AugPAKE. After you leave out pre-computable costs, the user and the server are required to compute only 1 and 1.17 modular exponentiations, respectively 🧮 Compared with SRP [RFC2945] and AMP [ISO], AugPAKE is more efficient 1) than SRP in terms of the user's computational costs and 2) than AMP in terms of the server's computational costs 🏆

This document also describes how AugPAKE is integrated into IKEv2 [RFC5996] 🌈

1.1. Keywords 🗝️

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 [RFC2119] 📖

2. AugPAKE Specification 🧁

2.1. Underlying Group 💎

AugPAKE can be implemented over the following group:

Let p and q be sufficiently large primes such that q is a divisor of ((p - 1) / 2), and every factor of ((p - 1) / 2) is also a prime comparable to q in size. This p is called a "secure" prime. By G, we denote a multiplicative subgroup of prime order q over the field GF(p), the integers modulo p. Let g be a generator for the subgroup G so that all the subgroup elements are generated by g. The group operation is denoted multiplicatively (in modulo p).

Using a secure prime p gives AugPAKE some computational efficiency gains 🚀 Specifically, it does not require the order check of elements received from the counterpart party ✨ Note that the groups defined in Discrete Logarithm Cryptography [SP800-56A] and RFC 5114 [RFC5114] are not necessarily the secure prime groups above 🤷‍♀️

Alternatively, AugPAKE can be implemented over the following groups:

Let p and q be sufficiently large primes such that p = (2 * q) + 1. This p is called a "safe" prime. By G, we denote a multiplicative subgroup of prime order q over the field GF(p), the integers modulo p. Let g be any element of G other than 1. For example, g = h^2 mod p where h is a primitive element. The group operation is denoted multiplicatively (in modulo p).
Let p and q be sufficiently large primes such that q is a divisor of ((p - 1) / 2). By G, we denote a multiplicative subgroup of prime order q over the field GF(p), the integers modulo p. Let g be a generator for the subgroup G so that all the subgroup elements are generated by g. The group operation is denoted multiplicatively (in modulo p). If p is not a "secure" prime, the AugPAKE protocol MUST perform the order check of received elements 🚨

2.2. Notation ✨

okay bestie, notation time 🧚 these are the symbols the whole protocol is written in, so let's lock them in before the good stuff 💅

U: The user's identity (e.g., as defined in [RFC4282]). It's a string in {0,1}^*, where {0,1}^* means the set of finite binary strings 🦋
S: The server's identity (e.g., as defined in [RFC4282]). It's a string in {0,1}^* 💜
b = H(a): A binary string a goes into a secure one-way hash function H (e.g., the SHA-2 family [FIPS180-3]), which spits out a fixed-length output b. H maps {0,1}^* to {0,1}^k, where {0,1}^k is the set of binary strings of length k, and k is a security parameter 🔥
b = H'(a): A binary string a goes into a secure one-way hash function H', which maps the input a in {0,1}^* to the output b in Z_q^*. Z_q^* is a set of positive integers modulo prime q 🌈
a | b: concatenation of the binary strings a and b in {0,1}^* 🎀
0x: a hexadecimal value, shown with a "0x" in front 🍓
X * Y mod p: multiplication of X and Y modulo prime p ✨
X = g^x mod p: the g^x means multiplying g by itself x times. The result, taken modulo prime p, gets assigned to X. The discrete logarithm problem says it's computationally hard to get x back from X, g, and p. so iconic 🧠
w: the password the user remembers. This password may be used as an effective password (instead of itself) in the form H'(0x00 | U | S | w) 🔐
W: the password verifier registered in the server. It's computed as W = g^w mod p, where the user's password w is used itself, or as W = g^w' mod p, where the effective password w' = H'(0x00 | U | S | w) is used 💖
bn2bin(X): converts a multiple precision integer X into its binary string. If X is an element over GF(p), its binary representation MUST have the same bit length as the binary representation of prime p 🙈
U -> S: msg: the user U sends a message msg to the server S 📨
U:: a local computation done by user U, with no outgoing messages 🧚

2.2.1. Password Processing

the input password MUST be processed according to the rules of the [RFC4013] profile of [RFC3454]. the password SHALL be considered a "stored string" per [RFC3454], which means unassigned code points are prohibited. the output SHALL be the binary representation of the processed UTF-8 character string. prohibited output and unassigned code points that show up during SASLprep pre-processing SHALL cause a pre-processing failure, and the output SHALL NOT be used with the AugPAKE protocol. this part is giving strict, and i respect it 💅

here's a table showing how different character data gets transformed by the [RFC4013] profile rules 👑

#  Input            Output     Comments
-  -----            ------     --------
1  I<U+00AD>X       IX         SOFT HYPHEN mapped to nothing
2  user             user       no transformation
3  USER             USER       case preserved, will not match #2
4  <U+00AA>         a          output is NFKC, input in ISO 8859-1
5  <U+2168>         IX         output is NFKC, will match #1
6  <U+0007>                    Error - prohibited character
7  <U+0627><U+0031>            Error - bidirectional check

2.3. Protocol

okay so the AugPAKE protocol has two phases: initialization and the actual protocol execution 🦋 the initialization phase SHOULD be finished in a secure manner between the user and the server, and it happens all at once. after that, whenever the user and the server need a secure channel, they can run the actual protocol execution over an open network (aka the Internet) where an active attacker might be lurking 👀

2.3.1. Initialization

U -> S: (U, W): the user U computes W = g^w' mod p, where w' is the effective password, and sends W to the server S. the server registers W as user U's password verifier. meanwhile, user U just remembers the password w 🔑

if resistance to server compromise isn't necessary, and a node needs to act as both initiator and responder (e.g., as a gateway), then the node can store w' instead of W even when it's acting as server S. either way, server S SHOULD NOT store any plaintext passwords 🙅‍♀️

as noted above, this phase SHOULD be performed securely and all at once ✨

2.3.2. Actual Protocol Execution

this is the main event 🎀 the actual protocol execution lets the user and the server share an authenticated session key over an open network. check out the picture (Figure 1) 🦋

+-----------------+                              +------------------+
|     User U      |                              |  Server S (U,W)  |
|                 |            (U, X)            |                  |
|                 |----------------------------->|                  |
|                 |                              |                  |
|                 |            (S, Y)            |                  |
|                 |<-----------------------------|                  |
|                 |                              |                  |
|                 |             V_U              |                  |
|                 |----------------------------->|                  |
|                 |                              |                  |
|                 |             V_S              |                  |
|                 |<-----------------------------|                  |
|                 |                              |                  |
+-----------------+                              +------------------+

                    Figure 1: Actual Protocol Execution

U -> S: (U, X): the user U picks a random element x from Z_q^* and computes its Diffie-Hellman public value X = g^x mod p. then the user sends this first message (U, X) to the server S 🌸
S -> U: (S, Y): if the X the server got from user U is 0, 1, or -1 (mod p), server S MUST terminate the protocol execution 🛑 otherwise, the server picks a random element y from Z_q^* and computes Y = (X * (W^r))^y mod p, where r = H'(0x01 | U | S | bn2bin(X)). the note here is that X^y * g^(w * r * y) mod p can be computed from y and (w * r * y) efficiently using Shamir's trick [MOV97]. then server S sends the second message (S, Y) to the user U 🧠
U -> S: V_U: if the Y the user got from server S is 0, 1, or -1 (mod p), user U MUST terminate the protocol execution 🛑 otherwise, the user computes K = Y^z mod p, where z = 1 / (x + (w * r)) mod q and r = H'(0x01 | U | S | bn2bin(X)). the user also generates an authenticator V_U = H(0x02 | U | S | bn2bin(X) | bn2bin(Y) | bn2bin(K)). then the user sends the third message V_U to the server S 💅
S -> U: V_S: if the V_U the server got from user U is not equal to H(0x02 | U | S | bn2bin(X) | bn2bin(Y) | bn2bin(K)), where K = g^y mod p, server S MUST terminate the protocol execution 🛑 otherwise, the server generates an authenticator V_S = H(0x03 | U | S | bn2bin(X) | bn2bin(Y) | bn2bin(K)) and a session key SK = H(0x04 | U | S | bn2bin(X) | bn2bin(Y) | bn2bin(K)). then server S sends the fourth message V_S to the user U 🎀
U:: if the V_S the user got from server S is not equal to H(0x03 | U | S | bn2bin(X) | bn2bin(Y) | bn2bin(K)), user U MUST terminate the protocol execution 🛑 otherwise, the user generates a session key SK = H(0x04 | U | S | bn2bin(X) | bn2bin(Y) | bn2bin(K)) 👑

in the actual protocol execution, the order of the message exchanges is super important to avoid attacks. for example, if the server S sends the second message (S, Y) and the fourth message V_S together, any attacker can easily derive the correct password w with off-line dictionary attacks. yikes 💀 do not do this, bestie 🙅‍♀️

the session key SK is only shared if the user and the server successfully authenticate each other. it MAY be generated using a key derivation function (KDF) [SP800-108]. after generating SK, the user and the server MUST delete all the internal states (e.g., the Diffie-Hellman exponents x and y) from memory 🧹

for the formal proof [SKI10] of the AugPAKE protocol, the computation of Y (in the S -> U: (S, Y) step above) and K (in the S -> U: V_S step above) changes slightly, like this: Y = (X * (W^r))^y' and K = g^y', where y' = H'(0x05 | bn2bin(y)) 🔬

3. Security Considerations ✨

this section explains why the AugPAKE protocol (aka the actual protocol execution) is secure against passive attacks, active attacks, and off-line dictionary attacks, and also why it's resistant to server compromise 🛡️

3.1. General Assumptions

an attacker is computationally bounded 🧠
any hash functions used in the AugPAKE protocol are secure in terms of pre-image resistance (one-wayness), second pre-image resistance, and collision resistance 🔐

3.2. Security against Passive Attacks

an augmented PAKE protocol is secure against passive attacks in the sense that an attacker who eavesdrops on the exchanged messages cannot compute an authenticated session key (shared between the honest parties in the protocol) 👀

in the AugPAKE protocol, an attacker can grab the messages (U, X), (S,Y), V_U, and V_S by eavesdropping, and then wants to compute the session key SK. the attacker's goal is to derive the correct K from the messages X and Y it captured, because the hash functions are secure and the only secret in the computation of SK is K = g^y mod p. note that:

X =     g^x mod p and

Y =     (X * (W^r))^y = X^y * W^(r * y) = X^y * (g^y)^t = X^y * K^t

hold where t = w' * r mod q. even though t can be worked out from possible password candidates and X, the only way for the attacker to pull K out of X and Y is to compute X^y. however, the probability of the attacker computing X^y is negligible in the security parameter for the underlying groups, since both x and y are random elements chosen from Z_q^* 🦋 so the AugPAKE protocol is secure against passive attacks 💖

3.3. Security against Active Attacks

an augmented PAKE protocol is secure against active attacks in the sense that an attacker who completely controls the exchanged messages cannot compute an authenticated session key (shared with the honest party in the protocol) with a probability better than that of on-line dictionary attacks. in other words, the probability of an active attacker computing the session key is limited by on-line dictionary attacks, and it grows linearly with the number of interactions with the honest party 📈

in the AugPAKE protocol, the user (respectively, the server) computes the session key SK only if the received authenticator V_S (respectively, V_U) is valid. there are three cases to be considered in the active attacks 🚨

3.3.1. Impersonation Attacks on User U

okay so if an attacker pretends to be user U, they can only end up with the same SK (the one meant to be shared with server S) if the authenticator V_U is valid 👀. For a valid V_U, they'd have to compute the correct K from X and Y, and that's a big no-go because the hash functions are secure 🔒. In this attack the attacker already knows the discrete logarithm x of X 🤓, so they just guess a password w'' from the password dictionary. That means their chance of getting the correct K is bounded by the probability that w = w''. Basically, this attack is stuck with on-line dictionary attacks, where the attacker can only try a guessed password by talking to the honest server S 💅. So AugPAKE is secure against impersonation attacks on user U, periodt ✨.

3.3.2. Impersonation Attacks on Server S

when an attacker pretends to be server S, they can only get the same SK (the one meant to be shared with user U) if the authenticator V_S is valid 🎀. Same deal as before: for a valid V_S they'd need the correct K from X and Y, and the hash functions are secure, so no shortcuts 🙅‍♀️. Here the attacker picks a random element y and guesses a password w'' from the password dictionary, so that:

Y =     (X * (W'^r))^y = X^y * W'^(r * y) = X^y * (g^y)^t'

where t' = w'' * r mod q. The chance of getting the correct K is bounded by the probability that w = w''. Also, the attacker can tell whether their guess was right by seeing the authenticator V_U they receive 👀. But if w is not equal to w'', the chance of getting the correct K is negligible in the security parameter for the underlying groups, because the attacker also has to guess the discrete logarithm x (which was chosen by user U) 🧠. So this attack is limited by on-line dictionary attacks, where the attacker can only try a guessed password by talking to the honest user U. Therefore, AugPAKE is secure against impersonation attacks on server S 🦋.

3.3.3. Man-in-the-Middle Attacks

when an attacker runs a man-in-the-middle attack, they can only compute the same SK (to be shared with user U or server S) if one of the authenticators V_U or V_S is valid 😤. Note that if the attacker just relays the exchanged messages honestly, that's basically a passive attack 🌸. To generate a valid V_U or V_S, they'd still need the correct K from X and Y, and the hash functions are secure, so they're in the same spot we already talked about. Yes, the attacker can test two passwords here (one with user U and one with server S), but that doesn't change the fact that it's still restricted by on-line dictionary attacks, where the attacker can only try a guessed password by communicating with the honest party 🙄. So AugPAKE is also secure against man-in-the-middle attacks 💖.

3.4. Security against Off-line Dictionary Attacks

an augmented PAKE protocol is considered secure against off-line dictionary attacks if an attacker who completely controls the exchanged messages can't shrink the list of possible passwords any better than on-line dictionary attacks can 🧚. Quick reminder: in an on-line dictionary attack, the attacker can test one guessed password per protocol run (aka by communicating with the honest party) 📞.

As we covered in Section 3.2, an attacker doing passive attacks doesn't compute X^y (and the correct K = g^y mod p) from the messages X and Y they observe 👀. This analysis also shows that even if the attacker can guess a password, K is derived independently from that guessed password 🔐. Next up, we look at an active attacker whose main goal is to run off-line dictionary attacks against AugPAKE 😈. As in Section 3.3, the attacker can 1) test one guessed password by impersonating user U or server S, or 2) test two guessed passwords by impersonating server S (to the honest user U) and impersonating user U (to the honest server S) in man-in-the-middle attacks. Whenever the honest party receives an invalid authenticator, it ends the actual protocol execution without sending any message 🛑. This is super important, because it stops an attacker from testing more than one password in active attacks. Since passive and active attacks can't cut down the possible password candidates any faster than on-line dictionary attacks can, AugPAKE is secure against off-line dictionary attacks 🏆.

3.5. Resistance to Server Compromise

we're looking at an attacker who has grabbed a (user's) password verifier from a server 😱. For (augmented) PAKE protocols there are two known limitations [BJKMRSW00]: 1) the attacker can find the correct password from the password verifier with off-line dictionary attacks, because the verifier has the same entropy as the password; and 2) if the attacker impersonates the server using the password verifier, this attack is always possible, because the attacker has enough info to simulate the server 💀. An augmented PAKE protocol is said to provide resistance to server compromise if the attacker can't impersonate the user without doing off-line dictionary attacks on the password verifier 🫶.

To show that AugPAKE has resistance to server compromise, we look at an attacker who has the password verifier W and tries to impersonate user U without doing off-line dictionary attacks on W 🕵️‍♀️. As a general attack, the attacker picks two random elements c and d from Z_q^* and computes:

X =     (g^c) * (W^d) mod p

then sends the first message (U, X) to server S. To impersonate user U successfully, the attacker needs the correct K = g^y mod p, where y is randomly chosen by server S 🎯. After getting Y from the server, the attacker's goal is to find a value e that satisfies Y^e = K mod p. That is:

            log_g (Y^e) = log_g K mod q

            (c + (w' * d) + (w' * r)) * y * e = y mod q

            (c + w' * (d + r)) * e = 1 mod q

where log_g K is the logarithm of K to the base g. Since there's no off-line dictionary attack on W, the only solution is e = 1 / c mod q and d = -r mod q. But the latter isn't possible, because r is determined by X (i.e., r = H'(0x01 | U | S | bn2bin(X))) and H' is a secure hash function 🙅‍♀️. So AugPAKE provides resistance to server compromise, and that's iconic behaviour 👑.

4. Implementation Consideration 🌈

as we covered in Section 3, AugPAKE is secure against passive attacks, active attacks, and off-line dictionary attacks, and it provides resistance to server compromise 💪. BUT, an attacker doing on-line dictionary attacks can check whether one password (guessed from the password dictionary) is correct by interacting with the honest party 😬. Let N be the number of possible passwords in a dictionary. The attacker's success probability grows with the probability of (I / N), where I is the number of interactions with the honest party 📈. To provide a reasonable security margin, implementation SHOULD take a countermeasure against on-line dictionary attacks ⭐. For example, it would take about 90 years to test 2^(25.5) passwords with a one-minute lock-out after 3 failed password guesses (see Appendix A in [SP800-63]) ⏳.

5. AugPAKE for IKEv2 🦋

5.1. Integration into IKEv2

IKE is a primary component of IPsec, used to provide mutual authentication and establish security associations between two peers 🤝.

The AugPAKE protocol, described in Section 2, can be easily integrated into IKEv2 [RFC5996] as a "weak" pre-shared key authentication method (see Figure 2) 🎀. This integrated protocol keeps the IKEv2 structure and security guarantees (e.g., identity protection) ✨. Note that AugPAKE can be used in three scenarios for IKEv2: "Security Gateway to Security Gateway Tunnel", "Endpoint-to-Endpoint Transport", and "Endpoint to Security Gateway Tunnel" 🌸.

 Initiator                               Responder
-----------                             -----------

IKE_SA_INIT:

 HDR, SAi1, KEi, Ni,
 N(SECURE_PASSWORD_METHODS)      -->
                                 <--  HDR, SAr1, KEr, Nr,
                                      N(SECURE_PASSWORD_METHODS)

IKE_AUTH:

 HDR, SK {IDi, GSPM(PVi), [IDr,]
          SAi2, TSi, TSr}        -->
                                 <--  HDR, SK {IDr, GSPM(PVr)}
 HDR, SK {AUTHi}                 -->
                                 <--  HDR, SK {AUTHr, SAr2, TSi, TSr}

                    Figure 2: AugPAKE into IKEv2

The changes from IKEv2 are summed up like this 💅:

In addition to IKEv2, one round trip is added 🔁.
The initiator (respectively, the responder) sends an N(SECURE_PASSWORD_METHODS) notification to show it's willing to use AugPAKE in the IKE_SA_INIT exchange 🙋‍♀️.
The added values GSPM(PVi) and GSPM(PVr) in the IKE_AUTH exchange correspond to X and Y of the AugPAKE protocol in Section 2, respectively 💜.
From K (represented as an octet string) derived in Section 2, the AUTH values in the IKE_AUTH exchange are computed as:

   AUTHi = prf( prf(K, "AugPAKE for IKEv2"),
   <InitiatorSignedOctets> | GSPM(PVi) | GSPM(PVr) | IDi | IDr)
   AUTHr = prf( prf(K, "AugPAKE for IKEv2"),
   <ResponderSignedOctets> | GSPM(PVr) | GSPM(PVi) | IDr | IDi)

5.2. Payload Formats 🧚

5.2.1. Notify Payload ✨

okay so the Notify Payload N(SECURE_PASSWORD_METHODS) [RFC6467] is how you say "hey, I'm down to use AugPAKE in the IKE_SA_INIT exchange" 💖 Here's the layout:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!  Protocol ID  !   SPI Size    !      Notify Message Type      !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                Security Parameter Index (SPI)                 ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                       Notification Data                       ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

As in [RFC5996], the Protocol ID and SPI Size SHALL be set to zero, which means the SPI field SHALL be empty. Bestie, that part is important 🫶 The Notify Message Type will be 16424 [RFC6467] 🌸

The Notification Data holds a list of 16-bit secure password method numbers, like so:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Secure Password Method #1     ! Secure Password Method #2     !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Secure Password Method #3     ! ...                           !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The response Notify Payload contains exactly one 16-bit secure password method number (i.e., for AugPAKE here) inside the Notification Data field 🦋

5.2.2. Generic Secure Password Method Payload 🧚

The Generic Secure Password Method (GSPM) Payload, which is denoted GSPM(PV) in Section 5.1, looks like this 💜

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                                                               ~
!          Data Specific to the Secure Password Method          !
~                                                               ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The GSPM Payload Type will be 49 [RFC6467] 🍓

Since the GSPM(PV) value is a group element, the encoded octet string is actually what goes in the "Data Specific to the Secure Password Method" field. Literally that's the whole trick 💅

6. IANA Considerations 🌈

IANA has assigned value 2 to the method name "AugPAKE" from the "IKEv2 Secure Password Methods" registry in [IKEV2-IANA] 👑

7. References 📚

7.1. Normative References

[FIPS180-3] Information Technology Laboratory, "Secure Hash Standard (SHS)", NIST FIPS Publication 180-3, October 2008, <http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf>.
[IKEV2-IANA] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", <http://www.iana.org/assignments/ikev2-parameters>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[SP800-108] Chen, L., "Recommendation for Key Derivation Using Pseudorandom Functions (Revised)", NIST Special Publication 800-108, October 2009, <http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf>.

7.2. Informative References

[BJKMRSW00] Bellare, M., Jablon, D., Krawczyk, H., MacKenzie, P., Rogaway, P., Swaminathan, R., and T. Wu, "Proposal for P1363 Study Group on Password-Based Authenticated-Key-Exchange Methods", IEEE P1363.2: Password-Based Public-Key Cryptography, Submissions to IEEE P1363.2, February 2000, <http://grouper.ieee.org/groups/1363/passwdPK/contributions/p1363-pw.pdf>.
[BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: Password-based Protocols Secure against Dictionary Attacks", Proceedings of the IEEE Symposium on Security and Privacy, IEEE Computer Society, 1992.
[BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key Exchange: A Password-based Protocol Secure against Dictionary Attacks and Password File Compromise", Proceedings of the 1st ACM Conference on Computer and Communication Security, ACM Press, 1993.
[DH76] Diffie, W. and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory Volume IT-22, Number 6, 1976.
[H10] Harkins, D., "Password-Based Authentication in IKEv2: Selection Criteria and Considerations", Work in Progress, October 2010.
[IEEEP1363.2] IEEE P1363.2, "Password-Based Public-Key Cryptography", Submissions to IEEE P1363.2, <http://grouper.ieee.org/groups/1363/passwdPK/submissions.html>.
[ISO] ISO/IEC JTC 1/SC 27 11770-4, "Information technology -- Security techniques -- Key management -- Part 4: Mechanisms based on weak secrets", April 2006, <http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39723>.
[MOV97] Menezes, A., Oorschot, P., and S. Vanstone, "Simultaneous Multiple Exponentiation", in Handbook of Applied Cryptography, CRC Press, 1997.
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000.
[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman Groups for Use with IETF Standards", RFC 5114, January 2008.
[RFC6467] Kivinen, T., "Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)", RFC 6467, December 2011.
[SKI10] Shin, S., Kobara, K., and H. Imai, "Security Proof of AugPAKE", Cryptology ePrint Archive: Report 2010/334, June 2010, <http://eprint.iacr.org/2010/334>.
[SP800-56A] Barker, E., Johnson, D., and M. Smid, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", NIST Special Publication 800-56A, March 2007, <http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf>.
[SP800-63] Burr, W., Dodson, D., and W. Polk, "Electronic Authentication Guideline", NIST Special Publication 800-63 Version 1.0.2, April 2006, <http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf>.

Appendix A. Evaluation by PAKE Selection Criteria 🔍

Okay, this is the self-check where AugPAKE grades itself against the PAKE selection criteria [H10] 💅 Giving main character energy, obviously 👑

SEC (Security) 🔐

SEC1: AugPAKE is zero knowledge (password) proof. It is secure against passive/active/off-line dictionary attacks. It is also resistant to server-compromise impersonation attacks.
SEC2: AugPAKE provides Perfect Forward Secrecy (PFS) and is secure against Denning-Sacco attack.
SEC3: IKEv2 identity protection is preserved.
SEC4: Any cryptographically secure Diffie-Hellman groups can be used.
SEC5: The formal security proof of AugPAKE can be found at [SKI10].
SEC6: AugPAKE can be easily used with strong credentials.
SEC7: In the case of server compromise, an attacker has to perform off-line dictionary attacks while computing modular exponentiation with a password candidate.
SEC8: AugPAKE is secure regardless of the transform negotiated by IKEv2.

IPR (Intellectual Property Rights) ⭐

IPR1: AugPAKE was publicly disclosed on Oct. 2008.
IPR2: AIST applied for a patent in Japan on July 10, 2008. AIST would provide royal-free license of AugPAKE.
IPR3: IPR disclosure (see https://datatracker.ietf.org/ipr/1284/)

MISC (Miscellaneous) 🧁

MISC1: AugPAKE adds one round trip to IKEv2.
MISC2: The initiator needs to compute only 2 modular exponentiation computations while the responder needs to compute 2.17 modular exponentiation computations. AugPAKE needs to exchange 2 group elements and 2 hash values. This is almost the same computation/communication costs as the plain Diffie-Hellman (DH) key exchange. If we use a large (e.g., 2048/3072-bits) parent group, the hash size would be relatively small.
MISC3: AugPAKE has the same performance for any type of secret.
MISC4: Internationalization of character-based passwords can be supported.
MISC5: AugPAKE can be implemented over any ECP (Elliptic Curve Group over GF[P]), EC2N (Elliptic Curve Group over GF[2^N]), and MODP (Modular Exponentiation Group) groups.
MISC6: AugPAKE has request/response nature of IKEv2.
MISC7: No additional negotiation is needed.
MISC8: No Trusted Third Party (TTP) and clock synchronization
MISC9: No additional primitive (e.g., Full Domain Hashing (FDH) and/or ideal cipher) is needed.
MISC10: As above, AugPAKE can be implemented over any ECP/EC2N groups.
MISC11: Easy implementation. We already implemented AugPAKE and have been testing in AIST.

Authors' Addresses 🦋

SeongHan Shin AIST Central 2, 1-1-1, Umezono Tsukuba, Ibaraki 305-8568 JP

Phone: +81 29-861-2670 EMail: seonghan.shin@aist.go.jp

Kazukuni Kobara AIST

EMail: kobara_conf@m.aist.go.jp

📦 where this page comes from

ietf: rfc6628 2012-06
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms