doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc6631.txt b/doc/rfc/rfc6631.txt
new file mode 100644
index 0000000..31ece75
--- /dev/null
+++ b/doc/rfc/rfc6631.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        D. Kuegler
+Request for Comments: 6631                                           BSI
+Category: Experimental                                        Y. Sheffer
+ISSN: 2070-1721                                                 Porticor
+                                                               June 2012
+
+
+            Password Authenticated Connection Establishment
+       with the Internet Key Exchange Protocol version 2 (IKEv2)
+
+Abstract
+
+   The Internet Key Exchange protocol version 2 (IKEv2) does not allow
+   secure peer authentication when using short credential strings, i.e.,
+   passwords.  Several proposals have been made to integrate password-
+   authentication protocols into IKE.  This document provides an
+   adaptation of Password Authenticated Connection Establishment (PACE)
+   to the setting of IKEv2 and demonstrates the advantages of this
+   integration.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are a candidate for any level of
+   Internet Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6631.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kuegler & Sheffer             Experimental                      [Page 1]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+Copyright Notice
+
+   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) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided 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
+
+
+
+
+Kuegler & Sheffer             Experimental                      [Page 2]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+      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 establishes a mutually
+   authenticated (and encrypted) channel between two parties based on
+   weak (short) passwords.  PACE provides strong session keys that are
+   independent of the strength of the password.  PACE belongs to a
+   family of protocols often referred to as Zero-Knowledge Password
+   Proof (ZKPP) protocols, all of which amplify weak passwords into
+   strong session keys.  This document describes the integration of PACE
+   into IKEv2 [RFC5996] as a new authentication mode, analogous to the
+   existing certificate and Pre-Shared Key (PSK) authentication modes.
+
+   Some of the advantages of our approach, compared to the existing
+   IKEv2, include the following:
+
+   o  The current best practice to implement password authentication in
+      IKE involves certificate-based authentication of the server plus
+      some Extensible Authentication Protocol (EAP) method to
+      authenticate the client.  This involves two non-trivial
+      infrastructure components (PKI and EAP/AAA).  Moreover,
+      certificate authentication is hard to get right and often depends
+      on unreliable user behavior for its security.
+
+   o  Alternatively, native IKEv2 shared secret authentication can be
+      used with passwords.  However, this usage is insecure;
+      specifically, it is vulnerable to active attackers.
+
+
+
+
+
+
+
+Kuegler & Sheffer             Experimental                      [Page 3]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+   o  Some newer EAP methods can be used for mutual authentication and,
+      combined with [RFC5998], can be well integrated into IKEv2.  This
+      is certainly an option in some cases, but the current proposal may
+      be simpler to implement.
+
+   Compared to other protocols aiming at similar goals, PACE has several
+   advantages.  PACE was designed to allow for a high level of
+   flexibility with respect to cryptographic algorithms; e.g., it can be
+   implemented based on Modular Diffie-Hellman as well as Elliptic Curve
+   Diffie-Hellman without any restrictions on the mathematical group to
+   be used, other than the requirement that the group be
+   cryptographically secure.  The protocol itself is also proven to be
+   cryptographically secure [PACEsec].  The PACE protocol is currently
+   used in an international standard for digital travel documents
+   [ICAO].
+
+   The integration aims at keeping IKEv2 unchanged as much as possible;
+   e.g., the mechanisms used to establish Child security associations
+   (SAs) as provided by IKEv2 would be maintained with no change.
+
+   The Password-Authenticated Key Exchange (PAKE) framework document
+   [RFC6467] defines a set of payloads for different types of PAKE
+   methods within IKEv2.  This document reuses this framework.  Note
+   that the current document is self-contained; i.e., all relevant
+   payloads and semantics are redefined here.
+
+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].
+
+   The following notation is used in this document:
+
+      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
+
+
+
+
+
+Kuegler & Sheffer             Experimental                      [Page 4]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+      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
+
+   At a high level, the following steps are performed by the initiator
+   and the responder.  They result in a two-round IKE_AUTH exchange,
+   described in Section 3 below.
+
+   1.  The initiator randomly and uniformly chooses a nonce s, encrypts
+       the nonce using 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 is mapped to an ephemeral generator
+
+          GE = G^s * SASharedSecret,
+
+       where G is the generator of the selected Modular Exponential
+       (MODP) group and SASharedSecret is a shared secret that has been
+       generated in the IKE_SA_INIT step.
+
+   3.  Both the initiator and the responder each calculate an ephemeral
+       key pair
+
+          (SKEi, PKEi = GE^SKEi) and (SKEr, PKEr=GE^SKEr),
+
+       respectively, based on the ephemeral generator GE, and exchange
+       the public keys.
+
+   4.  Finally, they compute the shared secret
+
+          PACESharedSecret = PKEi^SKEr = PKEr^SKEi
+
+       and generate, exchange, and verify the IKE authentication token
+       AUTH using the shared secret PACESharedSecret.
+
+   The encryption function E() must be carefully chosen to prevent
+   dictionary attacks that would otherwise allow an attacker to recover
+   the password.  Those restrictions are described in Section 4.1.
+   Details on the mapping function, including the elliptic curve
+   variant, can be found in Section 4.2.
+
+
+
+Kuegler & Sheffer             Experimental                      [Page 5]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+   To avoid the risks inherent in storing a short password (e.g., the
+   fact that passwords are often reused for different applications),
+   this protocol allows the peers to jointly convert the password into a
+   cryptographically stronger shared secret.  This shared secret can
+   then be stored by both peers, in lieu of the original password or its
+   salted variants.
+
+3.  Protocol Sequence
+
+   The protocol consists of three round trips -- an IKE_SA_INIT exchange
+   and a 2-round IKE_AUTH exchange -- as shown in the next figure.  An
+   optional Informational exchange may follow (see Section 3.5).
+
+     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
+
+3.1.  The IKE_SA_INIT Exchange
+
+   The initiator sends a SECURE_PASSWORD_METHODS notification that
+   indicates its support of this extension and its wish to authenticate
+   using a password.  The following text assumes that the responder sent
+   back a SECURE_PASSWORD_METHODS notification that indicates its
+   preference for PACE.
+
+
+
+
+
+
+
+Kuegler & Sheffer             Experimental                      [Page 6]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+   If PACE was chosen, the algorithms negotiated in SAi1 and SAr1 are
+   also used for the execution of PACE, i.e., the key agreement protocol
+   (Modular Diffie-Hellman or Elliptic Curve Diffie-Hellman), the group
+   to be used, and the encryption algorithm.
+
+3.2.  The IKE_AUTH Exchange, Round #1
+
+   This is the first part of the PACE authentication of the peers.  This
+   exchange MUST NOT be used unless both peers indicated support of this
+   protocol.
+
+   The initiator selects a random nonce s and encrypts it to form ENONCE
+   using the password Pwd, as described in Section 4.1.  Then, the
+   initiator maps the nonce to an ephemeral generator GE of the group as
+   described in Section 4.2, chooses randomly and uniformly an ephemeral
+   key pair (SKEi,PKEi) based on the ephemeral generator, and finally
+   generates the payloads GSPM(ENONCE) containing the encrypted nonce
+   and KEi2 containing the ephemeral public key.
+
+   The responder decrypts the received encrypted nonce s = D(KPwd,
+   ENONCE), performs the mapping, and randomly and uniformly chooses an
+   ephemeral key pair (SKEr,PKEr) based on the ephemeral generator GE.
+   The responder generates the KEr2 payload containing the ephemeral
+   public key.
+
+   The request is equivalent to the IKE_AUTH request in a normal IKEv2
+   exchange; i.e., any payload that is valid in an IKE_AUTH request is
+   valid (with the same semantics) in this round's request.  In
+   particular, certificate-related payloads are allowed, even though
+   their use may not be practical within this mode.
+
+3.3.  The IKE_AUTH Exchange, Round #2
+
+   This is the second part of the PACE authentication of the peers.
+
+   The initiator and the responder calculate the shared secret
+   PACESharedSecret
+
+      PACESharedSecret = KA(SKEi, PKEr, GE) = KA(SKEr, PKEi, GE),
+
+   where KA denotes the Diffie-Hellman key agreement, e.g., (for MODP
+   groups), modular exponentiation.  Then, they calculate the
+   authentication tokens AUTHi and AUTHr.
+
+   The initiator calculates
+
+      AUTHi = prf(prf+(Ni | Nr, PACESharedSecret),
+      <InitiatorSignedOctets> | PKEr)
+
+
+
+Kuegler & Sheffer             Experimental                      [Page 7]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+   See Section 2.15 of [RFC5996] for the definition of signed octets.
+
+   The responder calculates
+
+      AUTHr = prf(prf+(Ni | Nr, PACESharedSecret),
+      <ResponderSignedOctets> | PKEi)
+
+   Both AUTH payloads MUST indicate as their authentication method the
+   Generic Secure Password Authentication Method [RFC6467], whose value
+   is 12.  The authentication tokens are exchanged, and each of them
+   MUST be verified by the other party.  The behavior when this
+   verification fails is unchanged from [RFC5996].
+
+   Each of the peers MAY generate a long-term credential at this point,
+   after it has verified the opposite peer's identity.  The shared
+   secret is
+
+      LongTermSecret = prf(Ni | Nr, "PACE Generated PSK" |
+      PACESharedSecret),
+
+   where the literal string is ASCII-encoded, with no zero terminator.
+   The generated secret MUST be persisted to stable memory before
+   sending the response.  See Section 3.5 for more details about this
+   facility.
+
+   This round's response is equivalent to the IKE_AUTH response in a
+   normal IKEv2 exchange; i.e., any payload that is valid in an IKE_AUTH
+   response is valid (with the same semantics) in the second round's
+   response.
+
+   Following authentication, all temporary values MUST be deleted by the
+   peers, including in particular s, the ephemeral generator, the
+   ephemeral key pairs, and PACESharedSecret.
+
+3.4.  Public Key Validation
+
+   The security of the protocol relies on the entanglement of a weak
+   password with cryptographically strong shared secrets, SASharedSecret
+   and PACESharedSecret, mutually and randomly generated by the
+   initiator and the responder.  If an attacker can influence the
+   randomness of those shared secrets, the confidentiality of the
+   password may be directly affected.
+
+   Implementations MUST therefore verify that the shared secrets
+   SASharedSecret and PACESharedSecret are random elements of the group
+   generated by G to prevent small subgroup attacks.  This can be
+   achieved by a validation of the public keys (i.e., KEi, PKEi, and
+   KEr, PKEr).
+
+
+
+Kuegler & Sheffer             Experimental                      [Page 8]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+   First of all, each party MUST check that the public keys PKEi, PKEr,
+   KEi, and KEr differ.  Otherwise, it MUST abort the protocol.
+
+   For each received public key PK, the following tests SHOULD be
+   performed.  Any failure in the validation MUST be interpreted as an
+   attack, and the protocol SHALL be aborted.
+
+   o  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.
+
+   o  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.
+
+   Note that for most of the MODP groups, the order q = (p-1)/2.  This
+   applies in particular to the standard groups #2, #5, and #14,
+   commonly used in IKE.  For ECP and MODP groups not based on safe
+   primes, the order q is explictly stated in the parameters.
+
+   As an alternative to the public key validation, the compatible
+   cofactor exponentiation/multiplication may be used, which is often
+   more efficient but requires changes to the implementation of the key
+   agreement.  Details on the implementation can be found in [RFC2785]
+   and in [TR03111] for Modular Diffie-Hellman and Elliptic Curve
+   Diffie-Hellman, respectively.
+
+3.5.  Creating a Long-Term Shared Secret
+
+   To reduce the time that the peers store a hashed password, it is
+   RECOMMENDED that the password be replaced by a dedicated shared
+   secret, according to the method described in this section.  See
+   Appendix B for more discussion of the security threats involved.
+
+   Both peers generate the value LongTermSecret during round #2 of
+   IKE_AUTH, as shown above.  Later on, they exchange a PERSIST_PSK
+   notification.  Assume that both peers support this mechanism (e.g.,
+   the IKE implementation is able to modify its own credential store).
+   Then, each of the peers, when receiving the notification, permanently
+
+
+
+
+
+Kuegler & Sheffer             Experimental                      [Page 9]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+   deletes the stored password and replaces it with LongTermSecret.
+   These credentials are stored in the Peer Authorization Database (PAD)
+   [RFC4301] and are associated with the identity of the opposite peer.
+
+   This solution is designed as a two-phase commitment, so that failure
+   at any time cannot result in the peers not having any shared secret.
+
+     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
+
+   In the second round of IKE_AUTH, the initiator MAY send a PSK_PERSIST
+   notification if it wishes to use this mechanism.  If the responder
+   agrees, and only after it has authenticated the initiator, it MUST
+   generate a new PSK, save it to stable storage (e.g., to disk), and
+   MUST respond with a PSK_PERSIST notification.  Otherwise, it simply
+   does not include the notification in its reply.  When receiving the
+   reply, and after authenticating the responder, the initiator MUST
+   also generate the PSK and save it in stable storage.
+
+   If the peers have negotiated this mechanism, the initiator MUST send
+   the PSK_CONFIRM notification in an Informational exchange shortly
+   after the IKE SA has been set up.  When the responder receives it, it
+   MUST delete the stored short password from its credential database
+   and respond with a PSK_CONFIRM notification.  Upon receiving this
+   notification, the initiator deletes its copy of the short password.
+
+   If not saved to persistent storage, the LongTermSecret MUST be
+   deleted when the IKE SA is rekeyed or when it is torn down.  It
+   SHOULD be deleted 1 hour after the initial IKE SA has been set up.
+
+
+
+Kuegler & Sheffer             Experimental                     [Page 10]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+3.6.  Using the Long-Term Shared Secret
+
+   The LongTermSecret MUST be used as a regular IKE Pre-Shared Key
+   (PSK), rather than with PACE or any other password-based
+   authentication method.
+
+   Normally, at the completion of this protocol, both peers will have
+   either a shared password or a shared PSK.  The protocol is designed
+   so that the peers will have a shared credential, regardless of any
+   protocol failures.  However, in some failure cases, the initiator may
+   find itself with both a short password and a PSK for a particular
+   peer.  In that case, it MUST first try to authenticate with a
+   password and, upon success, MUST attempt to convert it to a PSK.  If
+   password authentication fails, it MUST use the PSK and upon
+   successful setup of the IKE SA MUST permanently delete the password.
+
+4.  Encrypting and Mapping the Nonce
+
+4.1.  Encrypting the Nonce
+
+   The shared password is not used as is.  Instead, it SHOULD be
+   converted into a "stored password" SPwd, so that the plaintext
+   password does not need to be stored for long periods.  SPwd is
+   defined as
+
+      SPwd = prf("IKE with PACE", Pwd),
+
+   where the literal string consists of ASCII characters with no zero
+   terminator.  If the negotiated pseudorandom function (prf) requires a
+   fixed-size key, the literal string is either truncated or padded with
+   zero octets on the right, as needed.  Multiple copies of SPwd MAY be
+   stored, if the prf function is not known in advance.
+
+      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 do not 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.
+
+
+
+
+
+
+Kuegler & Sheffer             Experimental                     [Page 11]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+   KPwd is now 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.
+
+   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 to create a shared secret that is 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.
+
+
+
+
+
+
+Kuegler & Sheffer             Experimental                     [Page 12]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+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]; therefore, 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.
+
+   See Section 3 of [RFC4013] for examples of SASLprep processing.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kuegler & Sheffer             Experimental                     [Page 13]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+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).
+
+
+
+
+
+
+
+
+Kuegler & Sheffer             Experimental                     [Page 14]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+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.
+
+
+
+
+
+
+
+
+
+Kuegler & Sheffer             Experimental                     [Page 15]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+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.
+
+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
+
+
+
+
+Kuegler & Sheffer             Experimental                     [Page 16]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+   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
+
+   The security of this protocol depends on the quality generation of
+   random quantities; see Section 5 of [RFC5996] for more details.
+   Specifically, any deviation from randomness of the nonce s might
+   compromise the password.  Therefore, it is strongly RECOMMENDED that
+   the initiator pass the raw random material through a strong prf to
+   ensure the statistical qualities of the nonce.
+
+6.5.  Identity Protection
+
+   This protocol is identical to IKEv2 in the quality of identity
+   protection it provides.  Both peers' identities are secure from
+   passive attackers, and both peers' identities are exposed to active,
+   man-in-the-middle attackers.
+
+6.6.  Denial of Service
+
+   We are not aware of any new denial-of-service attack vector enabled
+   by this protocol.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kuegler & Sheffer             Experimental                     [Page 17]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+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 in which
+   PACE is proven secure is, however, slightly different from the
+   setting used in IKEv2.  The differences are described in the
+   following:
+
+   o  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.
+
+   o  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.
+
+   o  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.
+
+   The differences in the setting therefore have no impact on the
+   validity of the proof.
+
+6.9.  Long-Term Credential Storage
+
+   This protocol does not require that peers store the plaintext
+   password.  Instead, the value SPwd SHOULD be stored by both peers.
+
+   In addition, the protocol allows both peers to replace the password
+   by a crypto-strength shared secret.  This solution improves the
+   system's security (since passwords are often used for multiple
+   applications), but at the cost of implementation complexity.  In
+   particular, if this optional mechanism is to be used, the credential
+   database would need to be writable by the key management subsystem.
+
+   See Appendix B for alternatives to this approach.
+
+
+
+
+
+
+
+
+
+
+
+Kuegler & Sheffer             Experimental                     [Page 18]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+7.  IANA Considerations
+
+   IANA has allocated the following values:
+
+   o  A PACE value of 1 from the "IKEv2 Secure Password Methods"
+      registry [RFC6467].
+
+   o  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.
+
+
+
+
+
+
+
+Kuegler & Sheffer             Experimental                     [Page 19]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+Kuegler & Sheffer             Experimental                     [Page 20]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kuegler & Sheffer             Experimental                     [Page 21]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+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,
+
+
+
+
+
+
+Kuegler & Sheffer             Experimental                     [Page 22]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+            *  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.
+
+
+
+
+
+
+
+
+
+
+Kuegler & Sheffer             Experimental                     [Page 23]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+   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:
+
+   o  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.
+
+   o  An attacker must not be able to construct lookup tables (such as
+      the famous "rainbow tables") that enable her to discover the plain
+      password.
+
+   o  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
+
+   Despite the protocol's symmetry, there are use cases that are
+   somewhat asymmetric.  Consider the case of an organization that
+   consists of a headquarters and branches, using a hub-and-spoke
+   architecture.  Communication sessions can be initiated by the center
+   or by any of the branches, but only the center holds a large
+   credential database.
+
+   Here it would be possible to use traditional password salting,
+
+      stored password = hash(salt, password),
+
+   where the hash function is a symmetric hash (e.g., HMAC-SHA-256,
+   using the salt as its key), and the salt is picked at random for each
+   password.  The salt would need to be sent in the first exchange of
+   the protocol, regardless of which side initiates the session.  Unlike
+
+
+
+Kuegler & Sheffer             Experimental                     [Page 24]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+   the normal use of salted passwords, here it is the stored password,
+   rather than the original password, that is used by the follow-on ZKPP
+   protocol.
+
+B.2.  Solving the Fully Symmetric Case with Asymmetric Cryptography
+
+   For the fully symmetric case, we propose a salting method based on a
+   commutative one-way function.  This is essentially a novel variant of
+   the RSA protocol.  Using this solution, all protocol peers can store
+   the password in a salted form.
+
+   The implementation proposed here requires a composite number n that
+   is common to all peers.  The composite number n can be generated by a
+   trusted (third) party as n = p * q, where p and q are strong primes
+   (i.e., p = 2 * p' + 1 and q = 2 * q' + 1, where p' and q' are also
+   primes), and the trusted party promises not to retain a copy of the
+   primes.  Alternatively, n can be chosen randomly and tested for
+   "small" prime factors.  In the latter case, it is certainly not
+   guaranteed that n is composed of only two primes.  While this has the
+   advantage that no one knows the factorization of n, the disadvantage
+   is that n is likely to be significantly easier to factor.
+
+   Each peer then chooses a public encryption key "e".  In a simple
+   implementation, the encryption key is generated randomly by each
+   peer, picking a different value for each of the passwords that it
+   stores.
+
+   Note that although the pair (n,e) is similar to an RSA public key,
+   the usual rules for generating "e" for the RSA protocol do not apply
+   here, and a random "e" is sufficient.  The password is hashed by a
+   symmetric hash function H (e.g., SHA-256).  Each peer i stores the
+   two values
+
+      e_i, H(P)^e_i (mod n),
+
+   where P is the original password.  The values e_i are exchanged by
+   the peers before the ZKPP protocol commences (in IKEv2-PACE, this
+   would be in IKE_SA_INIT), and the following value is used in the ZKPP
+   protocol run that follows, in lieu of the original password:
+
+      H(P) ^ (e_i * e_j) (mod n).
+
+   This transformation is used as a salting mechanism only, and the
+   salted values themselves are never sent on the wire.
+
+
+
+
+
+
+
+Kuegler & Sheffer             Experimental                     [Page 25]
+
+RFC 6631                     IKEv2 with PACE                   June 2012
+
+
+   This scheme can be enhanced by basing the value "e" on each peer's
+   identity (IDi, IDr), e.g., making it a simple hash of the identity.
+   This eliminates the need to send "e" explicitly and additionally
+   binds the identity of the peer with its secret.
+
+B.3.  Generation of a Strong, Long-Term, Shared Secret
+
+   An alternative to 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.  They now destroy the short password and replace
+   it with the new secret.
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kuegler & Sheffer             Experimental                     [Page 26]
+