RFC 6631

Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2)

📅 published June 2012, from ietf

RFC 6631: Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2) 💖

okay bestie, this is an Experimental RFC from June 2012 (ISSN 2070-1721), published by the IETF. It was written by D. Kuegler of BSI and Y. Sheffer of Porticor. The header has no Obsoletes or Updates line, so it doesn't replace or change any earlier RFC. 🎀

Abstract ✨

IKEv2 can't do secure peer authentication when you use short credential strings, aka passwords 🙈. People have proposed a bunch of ways to bolt password-authentication protocols onto IKE. This doc adapts PACE (Password Authenticated Connection Establishment) to IKEv2 and shows why that combo is worth it. 🔥

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 doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details.

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6631. 💅

Copyright (c) 2012 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 they stand on the publication date. 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 come without warranty as described in the Simplified BSD License. ⭐

Table of Contents 🦋

1. Introduction ....................................................3
   1.1. Terminology ................................................4
   2. Overview ........................................................5
   3. Protocol Sequence ...............................................6
      3.1. The IKE_SA_INIT Exchange ...................................6
      3.2. The IKE_AUTH Exchange, Round #1 ............................7
      3.3. The IKE_AUTH Exchange, Round #2 ............................7
      3.4. Public Key Validation ......................................8
      3.5. Creating a Long-Term Shared Secret .........................9
      3.6. Using the Long-Term Shared Secret .........................11
   4. Encrypting and Mapping the Nonce ...............................11
      4.1. Encrypting the Nonce ......................................11
      4.2. Mapping the Nonce .........................................12
           4.2.1. Modular Diffie-Hellman .............................13
           4.2.2. Elliptic Curve Diffie-Hellman ......................13
   5. Protocol Details ...............................................13
      5.1. Password Processing .......................................13
      5.2. The SECURE_PASSWORD_METHODS Notification ..................14
      5.3. The PSK_PERSIST Notification ..............................15
      5.4. The PSK_CONFIRM Notification ..............................15
      5.5. The GSPM(ENONCE) Payload ..................................15
      5.6. The KE (KEi2/KEr2) Payloads in PACE .......................16
      5.7. PACE and Session Resumption ...............................16
   6. Security Considerations ........................................16
      6.1. Credential Security Assumptions ...........................16
      6.2. Vulnerability to Passive and Active Attacks ...............16
      6.3. Perfect Forward Secrecy ...................................17
      6.4. Randomness ................................................17
      6.5. Identity Protection .......................................17
      6.6. Denial of Service .........................................17
      6.7. Choice of Encryption Algorithms ...........................17
      6.8. Security Model and Security Proof .........................18
      6.9. Long-Term Credential Storage ..............................18
   7. IANA Considerations ............................................19
   8. Acknowledgments ................................................19
   9. References .....................................................19
      9.1. Normative References ......................................19
      9.2. Informative References ....................................20
   Appendix A. Protocol Selection Criteria ...........................22
     A.1. Security Criteria ..........................................22
     A.2. Intellectual Property Criteria .............................22
     A.3. Miscellaneous Criteria .....................................22
   Appendix B. Password Salting ......................................23
     B.1. Solving the Asymmetric Case with Symmetric Cryptography ....24
     B.2. Solving the Fully Symmetric Case with Asymmetric
          Cryptography ...............................................25
     B.3. Generation of a Strong, Long-Term, Shared Secret ...........26

1. Introduction ✨

PACE [TR03110] is a security protocol that sets up a mutually authenticated (and encrypted) channel between two parties using weak (short) passwords. ✨ It gives you strong session keys that don't depend on how strong the password is, which is so iconic. PACE belongs to a family of protocols often called Zero-Knowledge Password Proof (ZKPP) protocols, and they all amplify weak passwords into strong session keys. This doc describes how PACE gets integrated into IKEv2 [RFC5996] as a new authentication mode, sitting alongside the existing certificate and Pre-Shared Key (PSK) modes. 🔐

Here's how our approach compares to what IKEv2 already does:

  • The current best practice for password authentication in IKE is certificate-based authentication of the server, plus some Extensible Authentication Protocol (EAP) method to authenticate the client. That needs two non-trivial infrastructure components (PKI and EAP/AAA). Plus, certificate authentication is hard to get right and often depends on unreliable user behavior for its security. 😭
  • You can also use native IKEv2 shared secret authentication with passwords. However, this usage is insecure. Specifically, it's vulnerable to active attackers. 💀
  • Some newer EAP methods can do mutual authentication and, combined with [RFC5998], they can integrate nicely into IKEv2. This is definitely an option in some cases, but the current proposal may be simpler to implement. 🍓

Compared to other protocols with similar goals, PACE has several perks. It was designed to be super flexible about cryptographic algorithms. For example, it can be implemented on Modular Diffie-Hellman as well as Elliptic Curve Diffie-Hellman, with no restrictions on the mathematical group, other than that the group has to be cryptographically secure. 👑 The protocol itself is also proven to be cryptographically secure [PACEsec], and PACE is already used in an international standard for digital travel documents [ICAO]. Iconic. 🛂

The integration tries to keep IKEv2 unchanged as much as possible. For example, the mechanisms IKEv2 uses to establish Child security associations (SAs) stay exactly the same. 🦋

The Password-Authenticated Key Exchange (PAKE) framework document [RFC6467] defines a set of payloads for different types of PAKE methods within IKEv2, and this document reuses that framework. Note that this document is self-contained. All the relevant payloads and semantics are redefined here, so you don't need to go hunting. 🌸

1.1. 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 [RFC2119].

Here's the notation this doc uses:

   E()      Symmetric encryption
   D()      Symmetric decryption
   KA()     Key agreement
   Map()    Mapping function
   Pwd      Shared password
   SPwd     Stored password
   KPwd     Symmetric key derived from a password Pwd
   G        Static group generator
   GE       Ephemeral group generator
   ENONCE   Encrypted nonce
   PKEi     Ephemeral public key of the initiator
   SKEi     Ephemeral secret key of the initiator
   PKEr     Ephemeral public key of the responder
   SKEr     Ephemeral secret key of the responder
   AUTH     Authentication payload

Any other notation used here is defined in [RFC5996]. 🩷

2. Overview 🌷

Okay, the big picture. At a high level, the initiator and the responder do the following steps. Together they make up a two-round IKE_AUTH exchange, which Section 3 below covers. 🎀

  1. The initiator randomly and uniformly picks a nonce s, encrypts it with the password, and sends the ciphertext ENONCE = E(KPwd, s) to the responder. The responder recovers the plaintext nonce s with the help of the shared password Pwd. 🔑
  2. The nonce s gets mapped to an ephemeral generator GE = G^s * SASharedSecret. Here G is the generator of the selected Modular Exponential (MODP) group, and SASharedSecret is a shared secret that was generated during the IKE_SA_INIT step. ✨
  3. Both the initiator and the responder calculate an ephemeral key pair, (SKEi, PKEi = GE^SKEi) and (SKEr, PKEr=GE^SKEr) respectively, based on the ephemeral generator GE. Then they swap the public keys. 🦋
  4. Finally, they compute the shared secret PACESharedSecret = PKEi^SKEr = PKEr^SKEi, and then generate, exchange, and verify the IKE authentication token AUTH using that shared secret. 🏆

The encryption function E() must be picked carefully to prevent dictionary attacks, which would otherwise let an attacker recover the password. Section 4.1 describes those restrictions. Details on the mapping function, including the elliptic curve variant, are in Section 4.2. 🧁

Heads up: a short password is risky to keep around. Passwords often get reused across different apps, so this protocol lets the peers jointly convert the password into a much stronger shared secret. 💅

That shared secret can then be stored by both peers instead of the original password or its salted variants. Way safer, periodt. 🫶

3. Protocol Sequence 💅

okay so the protocol is basically three round trips 🎀: one IKE_SA_INIT exchange and then a 2-round IKE_AUTH exchange. There's also an optional Informational exchange at the end if you want it (more on that in Section 3.5 ✨). Here's the whole flow:

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

  IKE_SA_INIT:

  HDR, SAi1, KEi, Ni, N(SECURE_PASSWORD_METHODS)  ->

                   <- HDR, SAr1, KEr, Nr, N(SECURE_PASSWORD_METHODS)

  IKE_AUTH round #1:

  HDR, SK{IDi, [IDr,], SAi2,
          TSi, TSr, GSPM(ENONCE), KEi2} ->

                                               <- HDR, SK{IDr, KEr2}

  IKE_AUTH round #2:

  HDR, SK{AUTH [, N(PSK_PERSIST)] } ->

                <- HDR, SK{AUTH, SAr2, TSi, TSr [, N(PSK_PERSIST)] }

                  Figure 1: IKE SA Setup with PACE

Figure 1: IKE SA Setup with PACE

3.1. The IKE_SA_INIT Exchange

The initiator kicks things off by sending a SECURE_PASSWORD_METHODS notification 🙌. That tells the responder two things: it supports this extension, and it wants to authenticate with a password. The rest of this text assumes the responder fires back its own SECURE_PASSWORD_METHODS notification, and that it's showing a preference for PACE 🦋.

If PACE gets picked, then the algorithms negotiated in SAi1 and SAr1 get reused for PACE too. That covers the key agreement protocol (Modular Diffie-Hellman or Elliptic Curve Diffie-Hellman), the group to use, and the encryption algorithm 🧚.

3.2. The IKE_AUTH Exchange, Round #1

This is the first half of PACE authentication between the two peers ✨. Important bit: this exchange MUST NOT be used unless both peers indicated support of this protocol 🙅‍♀️.

So the initiator picks a random nonce s and encrypts it into ENONCE using the password Pwd (see Section 4.1 for how). Then it maps that nonce to an ephemeral generator GE of the group (Section 4.2 has the details 💜). Next it randomly and uniformly picks an ephemeral key pair (SKEi,PKEi) based on that generator. Finally it builds the payloads GSPM(ENONCE), which holds the encrypted nonce, and KEi2, which holds the ephemeral public key 🫶.

The responder decrypts the nonce with s = D(KPwd, ENONCE), does the same mapping, and randomly and uniformly picks its own ephemeral key pair (SKEr,PKEr) based on GE. Then it makes the KEr2 payload with its ephemeral public key 💅.

Honestly, this request is basically the normal IKEv2 IKE_AUTH request. Any payload that's valid in an IKE_AUTH request is valid here too, with the same meaning. Certificate-related payloads are allowed as well, even though they're probably not very practical in this mode 🙈.

3.3. The IKE_AUTH Exchange, Round #2

This is the second half of the PACE authentication 🔥.

Both sides work out the same shared secret, PACESharedSecret:

PACESharedSecret = KA(SKEi, PKEr, GE) = KA(SKEr, PKEi, GE),

Here KA means the Diffie-Hellman key agreement, which for MODP groups is modular exponentiation 🧮. After that, they each compute their authentication tokens, AUTHi and AUTHr 🔐.

The initiator calculates:

AUTHi = prf(prf+(Ni | Nr, PACESharedSecret),
<InitiatorSignedOctets> | PKEr)

For the definition of signed octets, check Section 2.15 of [RFC5996] ✨.

The responder calculates:

AUTHr = prf(prf+(Ni | Nr, PACESharedSecret),
<ResponderSignedOctets> | PKEi)

Both AUTH payloads MUST indicate their authentication method as the Generic Secure Password Authentication Method [RFC6467], which has the value 12 🏷️. The tokens get swapped, and each side MUST verify the other's. If that verification fails, the behaviour is the same as in [RFC5996] 🚨.

Now here's the fun part 🎉. Either peer MAY generate a long-term credential at this point, but only after it has verified the other peer's identity. That shared secret is:

LongTermSecret = prf(Ni | Nr, "PACE Generated PSK" |
PACESharedSecret),

The literal string is ASCII-encoded, with no zero terminator 🔤. The generated secret MUST be persisted to stable memory before the response gets sent 💾. More on that facility in Section 3.5.

This round's response is basically the normal IKEv2 IKE_AUTH response too. Any payload that's valid in an IKE_AUTH response is valid here, with the same semantics 🌸.

And once authentication is done, the peers have to delete all their temporary values 🧹. That includes s, the ephemeral generator, the ephemeral key pairs, and PACESharedSecret. Gone, gone, gone 👋.

3.4. Public Key Validation

This part is serious, bestie 🚨. The whole protocol depends on mixing a weak password with strong shared secrets (SASharedSecret and PACESharedSecret) that the initiator and responder generate together, randomly. If an attacker can influence the randomness of those secrets, the password's confidentiality can get hit directly 😭.

So implementations MUST verify that SASharedSecret and PACESharedSecret are random elements of the group generated by G. That's how you stop small subgroup attacks 🛡️. You do it by validating the public keys (KEi, PKEi, and KEr, PKEr).

First, each party MUST check that the public keys PKEi, PKEr, KEi, and KEr all differ. If they don't, it MUST abort the protocol 🛑.

For each received public key PK, the following tests SHOULD be performed. And if any validation fails, it MUST be interpreted as an attack, and the protocol SHALL be aborted 🚫.

  • Verify that PK is an element of the Diffie-Hellman Group.
    • For Modular Diffie-Hellman, check that PK lies within the interval [2,p-2].
    • For Elliptic Curve Diffie-Hellman, check that PK is a point on the Elliptic Curve and not the point at infinity.
  • Verify that PK is an element of the cryptographic subgroup of order q.
    • For Modular Diffie-Hellman, check that PK^q = 1 (mod p).
    • For Elliptic Curve Diffie-Hellman, check that q * PK = 0.

Quick note 🤓: for most of the MODP groups, the order is q = (p-1)/2. That goes for the standard groups #2, #5, and #14, which are commonly used in IKE. For ECP and MODP groups that aren't based on safe primes, the order q is explicitly stated in the parameters 📜.

There's also an alternative to public key validation: compatible cofactor exponentiation/multiplication. It's often more efficient, but it means changing how the key agreement is implemented 🧠. The details are in [RFC2785] for Modular Diffie-Hellman and in [TR03111] for Elliptic Curve Diffie-Hellman 💫.

3.5. Creating a Long-Term Shared Secret

Okay, this is my favourite part 💖. Storing a hashed password for a long time is risky, so the peers can swap it out for a dedicated shared secret. It's RECOMMENDED to do that, using the method in this section 🎀. And if you want the threat analysis, that's in Appendix B 👀.

Both peers generate LongTermSecret during round #2 of IKE_AUTH, like we saw above. Later on, they swap PERSIST_PSK notifications 🔁. As long as both peers support this mechanism (say, the IKE implementation can change its own credential store), each peer permanently deletes its stored password when it gets the notification, and replaces it with LongTermSecret 🗑️➡️🔑. These credentials live in the Peer Authorization Database (PAD) [RFC4301] and are tied to the identity of the other peer 🪪.

This solution is a two-phase commitment, so no matter when something fails, the peers never end up with zero shared secrets 🛟.

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

  IKE_AUTH round #2:

  HDR, SK{..., N(PSK_PERSIST)} ---------->
                              Responder computes and stores PSK

                        <------- HDR, SK{..., N(PSK_PERSIST)}

  Initiator computes and stores PSK

  HDR, SK{N(PSK_CONFIRM)} -------------->

                              Responder deletes the short password

                        <-------------- HDR, SK{N(PSK_CONFIRM)}

  Initiator deletes the short password

Figure 2: IKE SA Setup with PACE and PSK Generation

Here's how it plays out 🎬. In the second round of IKE_AUTH, the initiator MAY send a PSK_PERSIST notification if it wants this mechanism. If the responder agrees, and only after it has authenticated the initiator, it MUST generate a new PSK and save it to stable storage (for example, to disk) 💽. It MUST also respond with a PSK_PERSIST notification. If it doesn't agree, it just leaves the notification out of its reply 🙅. When the initiator gets that reply, and after it has authenticated the responder, it MUST also generate the PSK and save it in stable storage 📥.

If the peers negotiated this mechanism, the initiator MUST send the PSK_CONFIRM notification in an Informational exchange shortly after the IKE SA is set up ⏱️. When the responder gets it, the responder MUST delete the stored short password from its credential database, and then respond with a PSK_CONFIRM notification 🫡. Once the initiator gets that notification, it deletes its own copy of the short password 💅.

And a last cleanup note 🧽: if the LongTermSecret isn't saved to persistent storage, it MUST be deleted when the IKE SA is rekeyed or when it's torn down. It SHOULD be deleted 1 hour after the initial IKE SA has been set up ⏳.

3.6. Using the Long-Term Shared Secret

The LongTermSecret MUST be used as a regular IKE Pre-Shared Key (PSK), and NOT with PACE or any other password-based authentication method 🔑. Wait, let me say that properly: it MUST be used as a regular IKE Pre-Shared Key (PSK), rather than with PACE or any other password-based authentication method ✨.

Normally, once this protocol finishes, both peers have either a shared password or a shared PSK 🤝. The protocol is designed so that the peers always end up with a shared credential, even when something goes wrong. But in some failure cases, the initiator can wind up with both a short password and a PSK for the same peer 😵‍💫. In that case, it MUST first try to authenticate with the password. If that works, it MUST attempt to convert the password into a PSK 🔄. If password authentication fails, it MUST use the PSK instead, and once the IKE SA is set up successfully, it MUST permanently delete the password 🗑️🔥.

4. Encrypting and Mapping the Nonce ✨

4.1. Encrypting the Nonce ✨

okay so the shared password is NOT used as is 🙈 instead it SHOULD get turned into a "stored password" SPwd, so the plaintext password doesn't have to just sit around for long periods 🔒 SPwd is defined as:

SPwd = prf("IKE with PACE", Pwd),

where the literal string is ASCII characters with no zero terminator 💅 If the negotiated pseudorandom function (prf) needs a fixed-size key, the literal string gets truncated or padded with zero octets on the right, whatever's needed. Multiple copies of SPwd MAY be stored if the prf function isn't known in advance 🫶

Next up, KPwd:

KPwd = prf+(Ni | Nr, SPwd),

where Ni and Nr are the regular IKE nonces, stripped of any headers 🧚 If the negotiated prf takes a fixed-length key and the lengths of Ni and Nr don't add up to that length, half the bits must come from Ni and half from Nr, taking the first bits of each. "prf+" is defined in Section 2.13 of [RFC5996]. The length of KPwd is determined by the key length of the negotiated encryption algorithm.

A nonce s is randomly selected by the initiator (see Section 6.4 for additional considerations) 🎀 The length of s MUST be exactly 32 octets.

Now KPwd gets used with the encryption transform to encrypt the nonce:

ENONCE = E(KPwd, s)

If an Initialization Vector (IV) is required by the cipher, it MUST be included in the GSPM(ENONCE) payload 💜 It is RECOMMENDED that the IV be chosen both randomly and uniformly distributed, even though this condition is not necessary for the cryptographic security of the protocol.

Note: Padding MUST NOT be used when encrypting the nonce. The size of the nonce has been chosen such that it can be encrypted with block ciphers having block sizes of 32, 64, and 128 bits without any padding. (this part is so clever, no cap 🦋)

If an authenticated encryption cipher [RFC5282] has been negotiated for the IKE SA, it MUST NOT be used as is, because such use would be vulnerable to dictionary attacks 💀 Instead, the corresponding unauthenticated mode MUST be used. All Galois/Counter Mode (GCM) and all Counter with CBC-MAC (CCM) encryption algorithms are mapped to the corresponding counter-mode algorithm. For example, if the negotiated encryption algorithm (Transform Type 1) is "AES-GCM with an 8-octet Integrity Check Value (ICV)", then ENCR_AES_CTR (with the same key length) is used to encrypt the nonce. If such a mapping does not exist for a particular cipher, then it MUST NOT be used within the current protocol. 🚫

4.2. Mapping the Nonce 🌸

The mapping is based on a second anonymous Diffie-Hellman key agreement protocol. It creates a shared secret that gets used together with the exchanged nonce to calculate a common secret generator of the group.

While in [TR03110] the generation of the shared secret is part of the mapping, in the setting of IKEv2, a shared secret SASharedSecret has already been generated as part of the IKE_SA_INIT step. Using the notation of [RFC5996]:

SASharedSecret = g^ir

Let G and GE be the generator of the negotiated Diffie-Hellman group, and the calculated ephemeral generator, respectively. The following subsections describe the mapping for different Diffie-Hellman variants 👑

4.2.1. Modular Diffie-Hellman

The function Map:G->GE is defined as GE = G^s * SASharedSecret.

Note that the protocol will fail if G^s = 1/SASharedSecret. If s is chosen randomly, this event occurs with negligible probability. In implementations that detect such a failure, the initiator SHOULD choose s again 🙃

4.2.2. Elliptic Curve Diffie-Hellman

The function Map:G->GE is defined as GE = s*G + SASharedSecret.

Note that the protocol will fail if s*G = -SharedSecret. If s is chosen randomly, this event occurs with negligible probability. In implementations that detect such a failure, the initiator SHOULD choose s again.

5. Protocol Details 💖

5.1. Password Processing

The input password string SHOULD be processed according to the rules of the [RFC4013] profile of [RFC3454]. A password SHOULD be considered a "stored string" per [RFC3454], so unassigned code points are prohibited 🙅‍♀️ The output is the binary representation of the processed UTF-8 character string. Prohibited output and unassigned codepoints encountered in SASLprep preprocessing SHOULD cause a preprocessing failure, and the output SHOULD NOT be used. A compliant implementation MUST NOT apply any other form of processing to the input password, other than as described in this section. Main character rules, fr 💅

See Section 3 of [RFC4013] for examples of SASLprep processing.

5.2. The SECURE_PASSWORD_METHODS Notification 🦋

[RFC6467] defines a new type of Notify payload to indicate support for Secure Password Methods (SPMs) in the IKE_SA_INIT exchange. The SPM Notify payload is defined as follows:

                      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                       ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: SECURE_PASSWORD_METHODS Payload Structure

The Protocol ID is zero, and the SPI Size is also zero, indicating that the SPI field is empty. The Notify Message Type is SECURE_PASSWORD_METHODS (value 16424) 🌈

The Notification Data contains the list of the 16-bit secure password method numbers:

                      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     | ...                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: SECURE_PASSWORD_METHODS Payload Data

For the current method, the list of proposed methods MUST include the value PACE (1) 🔥

5.3. The PSK_PERSIST Notification

This document defines the PSK_PERSIST notification type, whose value is 16425. This notification MUST be sent with no data. However, for future extensibility, the receiver MUST ignore any notification data if such data is present. 🫶

5.4. The PSK_CONFIRM Notification

This document defines the PSK_CONFIRM notification type, whose value is 16426. This notification MUST be sent with no data. However, for future extensibility, the receiver MUST ignore any notification data if such data is present. ✨

5.5. The GSPM(ENONCE) Payload 🍓

This protocol defines the ENONCE (encrypted nonce) payload, which reuses the Generic SPM (GSPM) payload type [RFC6467] (value 49). Its format is as follows:

  0                   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        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | PACE-RESERVED |     Initialization Vector                     |
 +-+-+-+-+-+-+-+-+                                               +
 |     (optional, length depends on the encryption algorithm)    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Encrypted Nonce                        ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: ENONCE Payload Structure

See Section 4.1 for further details about the encrypted nonce. Note that the protocol -- and in particular this payload's format -- does not support any padding of the encrypted data.

The PACE-RESERVED field must be sent as zero, and it must be rejected by the receiver if it is not 0.

5.6. The KE (KEi2/KEr2) Payloads in PACE 🦋

PACE reuses the Key Exchange (KE) payload for its Diffie-Hellman exchange, with the new payloads being sent within the IKE_AUTH exchange. Since only one Diffie-Hellman group is negotiated, the group denoted by these payloads MUST be identical to the one used in the "regular" KE payloads in IKE_SA_INIT.

5.7. PACE and Session Resumption 🌸

A session resumption [RFC5723] ticket may be requested during the IKE_AUTH exchange. The request MUST be sent in the request of the first round, and any response MUST be sent in the response of the second one.

PACE should be considered an "authentication method", in the sense of Section 5 of [RFC5723], which means that its use MUST be noted in the protected ticket. The format of the ticket is not standardized; however, it is RECOMMENDED that this indication distinguish between the different secure password authentication methods defined for IKE.

Note that even if the initial authentication used PACE and its extended IKE_AUTH, session resumption will still include the normal IKE_AUTH exchange.

6. Security Considerations 🔐

A major goal of this protocol has been to maintain the level of security provided by IKEv2. What follows is an analysis of this protocol. The reader is referred to [RFC5996] for the generic IKEv2 security considerations. This part is seriously important, bestie, so read it twice 😭

6.1. Credential Security Assumptions

This protocol makes no assumption on the strength of the shared credential. Best common practices regarding minimal password length, use of multiple character classes, etc. SHOULD be followed 💅

6.2. Vulnerability to Passive and Active Attacks ⚠️

The protocol is secure against both passive and active attackers. See Section 6.8 for a security proof.

While not attacking the cryptography, an attacker can still perform a standard password-guessing attack. To mitigate such attacks, an implementation MUST include standard protections, such as rate-limiting the number of allowed password-guessing attempts, possibly locking identities out after a certain number of failed attempts, etc. Note that the protocol is symmetric; therefore, this guidance applies to client-side implementations as well. 🙈

6.3. Perfect Forward Secrecy 💜

The key derivation for the IKE SA and any Child SAs is performed as part of IKEv2 and remains unchanged. It directly follows that perfect forward security is provided independent of the authentication additionally performed by PACE.

6.4. Randomness 🎲✨

okay bestie, randomness is SUPER important here 😭 the security of this protocol depends on the quality generation of random quantities (see Section 5 of [RFC5996] for more details). any deviation from randomness of the nonce s might compromise the password 💀 so it is strongly RECOMMENDED that the initiator pass the raw random material through a strong prf to make sure the nonce has good statistical qualities 🫶

6.5. Identity Protection 🦋

this protocol is identical to IKEv2 in the quality of identity protection it gives 💖 both peers' identities are safe from passive attackers, but both peers' identities are exposed to active, man-in-the-middle attackers 🙈 the lurkers can't see you, but the meddlers can 👀

6.6. Denial of Service 🛡️

we are not aware of any new denial-of-service attack vector enabled by this protocol ✨ no new DoS vibes from this one, we checked 💅

6.7. Choice of Encryption Algorithms 🔐

any transforms negotiated for IKEv2 may be used by this protocol 🎀 please refer to Section 4.1 for the considerations regarding authenticated encryption ("combined mode") algorithms 💜

6.8. Security Model and Security Proof 👑

PACE is cryptographically proven secure in [PACEsec] in the model of Bellare, Pointcheval, and Rogaway [BPRmodel] 😤 the setting is slightly different from the one used in IKEv2 though, so here's the tea ☕

  • Part of the mapping is already performed within IKEv2 before PACE is started. This rearrangement does not affect the proof, as the resulting PACESharedSecret remains close to uniformly distributed in the group generated by G.
  • The keys for the IKE SA and any Child SAs are already generated within IKEv2 before PACE is started. While those session keys could also be derived in PACE, only the keys for the authentication token are considered in the proof, which explicitly recommends a separate key for this purpose.
  • IKEv2 allows the negotiation of a stream cipher for PACE, while the proven variant always uses a block cipher. The ideal cipher is replaced in the proof by a lazy-sampling technique that is similarly applicable to the stream-cipher-based construction.

so the differences in the setting have no impact on the validity of the proof 🌸 we're good!

6.9. Long-Term Credential Storage 💾

this protocol doesn't require peers to store the plaintext password 🙅‍♀️ instead, the value SPwd SHOULD be stored by both peers 🔑

the protocol also lets both peers swap the password out for a crypto-strength shared secret ✨ this improves the system's security (since passwords often get reused across multiple applications), but it costs you in implementation complexity 😵‍💫 in particular, if this optional mechanism is going to be used, the credential database would need to be writable by the key management subsystem 📝

See Appendix B for alternatives to this approach 🧚

7. IANA Considerations 📋✨

IANA has allocated the following values:

  • A PACE value of 1 from the "IKEv2 Secure Password Methods" registry [RFC6467].
  • A PSK_PERSIST value of 16425 and a PSK_CONFIRM value of 16426 from the "IKEv2 Notify Message Types - Status Types" registry. We note that these notification types are generic and that other password authentication methods may also choose to use them 💜

8. Acknowledgments 🙏🌸

We would like to thank Dan Harkins for pointing out a security issue with our use of combined-mode algorithms in a previous version of the protocol. We thank Tero Kivinen for his generic framework document, and for a thorough and fruitful review. Hugo Krawczyk proposed that the password be amplified into a persistent shared secret 🫶

9. References 📚

9.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785, March 2000.
  • [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.
  • [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
  • [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.

9.2. Informative References

  • [BPRmodel] Bellare, M., Pointcheval, D., and P. Rogaway, "Authenticated Key Exchange Secure against Dictionary Attacks", EUROCRYPT 2000, LNCS 1807, pp. 139-155, Springer-Verlag, 2000, <http://www.iacr.org/cryptodb/archive/2000/EUROCRYPT/18070139.pdf>.
  • [ICAO] ISO/IEC JTC1 SC17 WG3/TF5 for the International Civil Aviation Organization (ICAO), "Supplemental Access Control for Machine Readable Travel Documents", Version 1.01, November 2010.
  • [IKEv2-CONS] Harkins, D., "Password-Based Authentication in IKEv2: Selection Criteria and Considerations", Work in Progress, October 2010.
  • [PACEsec] Bender, J., Fischlin, M., and D. Kuegler, "Security Analysis of the PACE Key-Agreement Protocol", LNCS 5735, pp. 33-48, Springer-Verlag (the extended abstract appeared in Information Security Conference (ISC) 2009), December 2009, <http://eprint.iacr.org/2009/624>.
  • [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008.
  • [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
  • [RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension for EAP-Only Authentication in IKEv2", RFC 5998, September 2010.
  • [RFC6467] Kivinen, T., "Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)", RFC 6467, December 2011.
  • [TR03110] BSI, "TR-03110, Advanced Security Mechanisms for Machine Readable Travel Documents, Part 2 - Extended Access Control Version 2 (EACv2), Password Authenticated Connection Establishment (PACE), and Restricted Identification (RI)", Version 2.10, March 2012.
  • [TR03111] BSI, "TR-03111, Elliptic Curve Cryptography", Version 1.11, April 2009.

Appendix A. Protocol Selection Criteria 🕵️

to support the selection of a password-based protocol for inclusion in IKEv2, a number of criteria are provided in [IKEv2-CONS]. in the following sections, those criteria are applied to the PACE protocol 💅

A.1. Security Criteria 🔒

  • SEC1: PACE is a zero-knowledge protocol.
  • SEC2: The protocol supports perfect forward secrecy and is resistant to replay attacks.
  • SEC3: The identity protection provided by IKEv2 remains unchanged.
  • SEC4: Any cryptographically secure Diffie-Hellman group can be used.
  • SEC5: The protocol is proven secure in the Bellare-Pointcheval-Rogaway model.
  • SEC6: Strong session keys are generated.
  • SEC7: A transform of the password can be used instead of the password itself.

A.2. Intellectual Property Criteria ⚖️

  • IPR1: The first version of [TR03110] was published on May 21, 2007.
  • IPR2: BSI has developed PACE aiming to be free of patents. BSI has not applied for a patent on PACE.
  • IPR3: The protocol itself is believed to be free of IPR.

A.3. Miscellaneous Criteria 🧩

  • MISC1: One additional exchange is required.
  • MISC2: The protocol requires the following operations per entity:
    • one key derivation from the password,
    • one symmetric encryption or decryption,
    • one multi-exponentiation for the mapping,
    • one exponentiation for the key pair generation,
    • one exponentiation for the shared secret calculation, and
    • two symmetric authentications (generation and verification).
  • MISC3: The performance is independent of the type/size of password.
  • MISC4: Internationalization of character-based passwords is supported.
  • MISC5: The protocol uses the same group as that negotiated for IKEv2.
  • MISC6: The protocol fits into the request/response nature of IKE.
  • MISC7: The password-based symmetric encryption must be additionally negotiated.
  • MISC8: Neither trusted third parties nor clock synchronization are required.
  • MISC9: Only general cryptographic primitives are required.
  • MISC10: Any secure variant of Diffie-Hellman (e.g., Modular or Elliptic Curve) can be used.
  • MISC11: The protocol can be implemented easily based on existing cryptographic primitives.

Appendix B. Password Salting 🧂

this protocol requires that passwords not be stored in plaintext 🙅 instead, we store a hash of the password with a fixed hash. this value is then used in the ZKPP protocol, replacing the original password and acting as a "password equivalent". the main benefit of this solution is that a system administrator or an undetermined attacker does not get immediate access to the passwords. we believe this is sufficiently secure for the main usage scenario of the protocol ✨

however, the common practice of password salting is clearly more powerful, and this appendix presents a few ideas on how password salting can be applied and/or adapted to fit into a symmetric protocol such as IKE 🌈 first, let us list the threats that we expect salting to handle, as well as the non-threats:

  • The plain password should not be visible to a casual onlooker, as noted above. It is assumed that very often the same password is used for multiple applications, and so a password exposed allows an attacker a starting point for further attacks.
  • An attacker must not be able to construct lookup tables (such as the famous "rainbow tables") that enable her to discover the plain password.
  • IKE is a symmetric protocol, in the sense that any of the peers might initiate an IKE exchange to another peer. As a result, all peers must have stored credentials (passwords or password equivalents) that would enable them to set up an IKE exchange. So, an attacker that reaches the credential store would in fact be able to impersonate IKE to another peer. We believe that this reduces, but does not invalidate, the importance of salting, because of the other threats that remain.

below we present different scenarios and solutions that support password salting in this setting 👀

we assume that each credential is used to authenticate exactly two peers to one another; i.e., (as per the best practice), group credentials are not allowed 💖

B.1. Solving the Asymmetric Case with Symmetric Cryptography 🦋

Okay so the protocol is symmetric, but real life isn't always 50/50 💅. Picture a company with a headquarters and a bunch of branch offices, set up as a hub-and-spoke network 🌸. Sessions can be started by the center or by any branch, but only the center actually holds the big credential database. That's the asymmetry, bestie.

For this setup, traditional password salting works just fine ✨. The stored value is built like this:

stored password = hash(salt, password),

The hash is a symmetric one, like HMAC-SHA-256 with the salt used as its key 🔐. The salt gets picked at random for every password. It has to be sent in the very first exchange of the protocol, no matter which side starts the session 🫶. Here's the lowkey twist: unlike normal salted passwords, the thing the follow-on ZKPP protocol uses is the stored password, not the original one 🙈.

B.2. Solving the Fully Symmetric Case with Asymmetric Cryptography 👑

Now for the fully symmetric case, which is giving main character energy 💖. The proposed salting method is based on a commutative one-way function. It's basically a brand-new variant of the RSA protocol 🧚. With this solution, every single protocol peer can store the password in salted form. Iconic.

The implementation needs a composite number n that's shared by all the peers 🌈. That n can be generated by a trusted (third) party as:

n = p * q

where p and q are strong primes, meaning:

p = 2 * p' + 1
q = 2 * q' + 1

and p' and q' are also primes 🍓. The trusted party has to promise not to keep a copy of the primes. Pinky promise 🤞.

There's also an alternative: n can be picked at random and then tested for "small" prime factors ✨. Ngl, this one comes with a catch. It is certainly not guaranteed that n is made of only two primes 😭. The upside is that nobody knows the factorization of n. The downside is that n is likely to be significantly easier to factor 💀.

Next, each peer picks a public encryption key e. In a simple implementation, each peer generates e randomly, using a different value for each password it stores 🎀. Here's the tea: even though the pair (n,e) looks a lot like an RSA public key, the usual rules for generating e in RSA don't apply here 🙅‍♀️. A random e is sufficient. The password gets hashed by a symmetric hash function H (for example, SHA-256 🔥).

Each peer i stores these two values:

e_i, H(P)^e_i (mod n),

where P is the original password 🦋. The e_i values get exchanged by the peers before the ZKPP protocol even starts. In IKEv2-PACE, that happens in IKE_SA_INIT 🌸. Then, in the ZKPP protocol run that follows, this value gets used in place of the original password:

H(P) ^ (e_i * e_j) (mod n).

This transformation is only used as a salting mechanism, and the salted values themselves are never sent on the wire 🔒. Not even once, bestie.

This scheme can be made even cuter by basing e on each peer's identity (IDi, IDr), for example by making it a simple hash of the identity 💜. That way, e doesn't need to be sent explicitly, and the identity of the peer gets bound to its secret too 🫶.

B.3. Generation of a Strong, Long-Term, Shared Secret ✨

Another option, instead of salting, is to store the plain passwords, but only for a short while ⏳. As soon as the first IKE SA is set up between two peers, the peers exchange nonces and generate a strong shared secret based on IKE's SK_d 🧁. Then they destroy the short password and replace it with the new secret. Poof, gone 💨.

This method has been added to the current protocol as an optional mechanism 🌈.

Authors' Addresses 💌

Dennis Kuegler
Bundesamt fuer Sicherheit in der Informationstechnik (BSI)
Postfach 200363
Bonn  53133
Germany

EMail: dennis.kuegler@bsi.bund.de


Yaron Sheffer
Porticor

EMail: yaronf.ietf@gmail.com
📦 where this page comes from