| Network Working Group | D. Kuegler |
| Internet-Draft | Bundesamt fuer Sicherheit in der Informationstechnik (BSI) |
| Intended status: Experimental Protocol | Y. Sheffer |
| Expires: October 18, 2012 | Porticor |
| April 18, 2012 |
Password Authenticated Connection Establishment with IKEv2
draft-kuegler-ipsecme-pace-ikev2-10
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 PACE (Password Authenticated Connection Establishment) to the setting of IKEv2 and demonstrates the advantages of this integration.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 18, 2012.
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.
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 draft describes the integration of PACE into IKEv2 [RFC5996] as a new authentication mode, analogous to the existing certificate and PSK authentication modes.
Some of the advantages of our approach, compared to the existing IKEv2, include: [PACEsec]. The PACE protocol is currently used in an international standard for digital travel documents [ICAO].
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 standard 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 is cryptographically secure. The protocol itself is also proven to be cryptographically secure
The integration aims at keeping as much as possible of IKEv2 unchanged, e.g. the mechanisms used to establish Child SAs as provided by IKEv2 are maintained with no change.
The 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.
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].
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
The following notation is used in this draft:
Any other notation used here is defined in [RFC5996].
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.
to the responder. The responder recovers the plaintext nonce s with the help of the shared password Pwd.
where G is the generator of the selected MODP group and SASharedSecret is a shared secret that has been generated in the IKE_SA_INIT step.
respectively, based on the ephemeral generator GE and exchange the public keys.
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.
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.
The protocol consists of three round trips, IKE_SA_INIT, and a 2-round IKE_AUTH exchange, as shown in the next figure. An optional Informational exchange may follow (see Section 3.4).
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)] }
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.
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 (standard Diffie-Hellman or Elliptic Curve Diffie-Hellman), the group to be used, and the encryption algorithm.
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.
During the Diffie-Hellman key agreement, each party MUST check that the two public keys PKEi and PKEr differ. Otherwise, it MUST abort the protocol.
The request is equivalent to the IKE_AUTH request in a normal IKEv2 exchange, i.e. any payload which 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.
This is the second part of the PACE authentication of the peers.
The initiator and the responder calculate the shared secret PACESharedSecret:
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:
See Sec. 2.15 of [RFC5996] for the definition of signed octets.
The responder calculates:
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:
Section 3.4 for more details about this facility.
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
This round's response is equivalent to the IKE_AUTH response in a normal IKEv2 exchange, i.e. any payload which 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.
To reduce the time that the peers store a hashed password, it is RECOMMENDED to replace the password by a dedicated shared secret, according to the method described in this section. See Appendix 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 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 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_PERIST)} ---------->
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
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 authenicated the initiator, it MUST generate a new PSK, store 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.
The LongTermSecret MUST be used as a regular IKE 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.
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:
where the literal string consists of ASCII characters with no zero terminator. If the negotiated prf requires a fixed-size key, the literal string is either truncated or padded with zero octets on the right, as needed.
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 Sec. 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.
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 bit 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 GCM and all 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 a 8 octet 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.
KPwd is now used with the encryption transform to encrypt the nonce:
If an Initialization Vector (IV) is required by the cipher, it MUST be included in the GSPM(ENONCE) payload. It is RECOMMENDED to choose the IV randomly and uniformly distributed, even though this condition is not necessary for the cryptographic security of the protocol.
The mapping is based on a second anonymous Diffie-Hellman key agreement protocol to create a shared secret which 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],
Let G and GE be the generator of the negotiated DH group, and the calculated ephemeral generator, respectively. The following subsections describe the mapping for different Diffie-Hellman variants.
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.
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.
Implementations MUST verify that the shared secrets SASharedSecret and PACESharedSecret are elements of the group generated by G to prevent small subgroup attacks.
It is RECOMMENDED to use the public key validation method or the compatible cofactor exponentiation described in Section 3.1 and Section 3.4, respectively, of [RFC2785]. The Elliptic Curve equivalents of those methods are described in more detail in [TR03111].
Any failure in the validation MUST be interpreted as an attack, and the protocol SHALL be aborted.
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] and unassigned code points are therefore 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 Sec. 3 of [RFC4013] for examples of SASLprep processing.
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[RFC6467] defines a new type of Notify payload to indicate support for Secure Password Methods (SPM) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secure Password Method #1 | Secure Password Method #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secure Password Method #3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Notification Data contains the list of the 16-bit secure password method numbers:
This document defines the PSK_PERSIST notification type, whose value is TBD by IANA. This notification MUST be sent with no data. However, for future extensibility, the receiver MUST ignore any notification data if such data is present.
This document defines the PSK_CONFIRM notification type, whose value is TBD by IANA. This notification MUST be sent with no data. However, for future extensibility, the receiver MUST ignore any notification data if such data is present.
This protocol defines the ENONCE (encrypted nonce) payload, which reuses the 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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 must be rejected by the receiver if it is not 0.
PACE reuses the 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.
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 Sec. 5 of [RFC5723], which means that its use MUST be noted in the protected ticket. The format of the ticket is not standardized, however we RECOMMEND that this indication should 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.
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 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.
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 and therefore this guidance applies to client-side implementations as well.
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.
The security of this protocol depends on the quality generation of random quantities, and see Sec. 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 passes the raw random material through a strong prf to ensure the statistical qualities of the nonce.
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.
We are not aware of any new denial-of-service attack vector enabled by this protocol.
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.
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:
The differences in the setting therefore have no impact on the validity of the proof.
This protocol does not require peers to 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 Appendix B for alternatives to this approach.
IANA is requested to allocate (has allocated) the following values:
This document does not define any new registries.
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 to amplify the password into a persistent shared secret.
| [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. |
To support the selection of a password-based protocol for inclusion in IKEv2, a number of criteria are provided in [I-D.harkins-ipsecme-pake-criteria]. In the following sections, those criteria are applied to the PACE protocol.
This protocol requires that passwords should 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 adopted 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:
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.
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,
where the hash function is a symmetric hash (e.g. HMAC-SHA-256), 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 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.
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.
The implementation proposed here requires a composite number n that is common to all peers. The composite number n can be either 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
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:
This transformation is used as a salting mechanism only and the salted values themselves are never sent on the wire.
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.
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 long 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.
Note to RFC Editor: please remove this appendix before publication.
Changed the symbolic name of the PACE authentication method, as agreed with IANA. Filled in a few values defined by RFC 6467.
Implemented a number of IESG comments.
Added the option to replace the password by a stronger shared secret. Thanks, Sony.
Adopted the framework proposed in [RFC6467]. However this document is self-contained. Changed the PKEi/r payloads to reuse the normal KE payloads; they are disambiguated by the context: which exchange they are used in. Added an appendix on password salting for symmetric protocols.
Defined how authenticated-encryption algorithms can be used. Updated references.
Editorial corrections.
Editorial corrections.
Completed the security considerations (security proof). Reordered some sections for clarity.
Added security considerations. Changed encryption of the nonce. Simplified the derivation of the AUTH payloads.
Formalized the protocol: added payload formats, error behavior etc.