Password Authenticated Connection Establishment with IKEv2
draft-kuegler-ipsecme-pace-ikev2-03

Abstract

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.

Status of this Memo

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 February 7, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 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
    1.1.  Terminology
2.  Overview
3.  Protocol Sequence
    3.1.  The IKE_SA_INIT Exchange
    3.2.  The IKE_PACE Exchange
    3.3.  The IKE_PACE_AUTH Exchange
4.  Encrypting and Mapping the Nonce
    4.1.  Encrypting the Nonce
    4.2.  Mapping the Nonce
        4.2.1.  MODP Diffie Hellman
        4.2.2.  Elliptic Curve Diffie Hellman
        4.2.3.  Validation
5.  Protocol Details
    5.1.  Password Processing
    5.2.  The PACE_SUPPORTED Notification
    5.3.  The ENONCE Payload
    5.4.  The PKE (PKEi/PKEr) Payloads
    5.5.  PACE and Session Resumption
6.  Security Considerations
    6.1.  Credential Security Assumptions
    6.2.  Vulnerability to Passive and Active Attacks
    6.3.  Perfect Forward Secrecy
    6.4.  Randomness
    6.5.  Identity Protection
    6.6.  Denial of Service
    6.7.  Choice of Encryption Algorithms
    6.8.  Security Model and Security Proof
    6.9.  Long-Term Credential Storage
7.  IANA Considerations
8.  References
    8.1.  Normative References
    8.2.  Informative References
Appendix A.  Protocol Selection Criteria
    A.1.  Security Criteria
    A.2.  Intellectual Property Criteria
    A.3.  Miscellaneous Criteria
Appendix B.  Change Log
§  Authors' Addresses

1.  Introduction

PACE [TR03110] (BSI, “TR-03110, Advanced Security Mechanisms for Machine Readable Travel Documents - Extended Access Control (EAC), Password Authenticated Connection Establishment (PACE), and Restricted Identification (RI), Version 2.03,” 2010.) 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. This draft describes the integration of PACE into IKEv2 ([RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) and [I‑D.ietf‑ipsecme‑ikev2bis] (Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, “Internet Key Exchange Protocol: IKEv2,” May 2010.)) 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:

• The current best practice to implement password authentication in IKE involves certificate-based authentication of the server plus some 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 for its security on unreliable user behavior.
• Alternatively, native IKEv2 shared secret authentication can be used with passwords. This usage however is insecure, specifically it is vulnerable to active attackers.
• Some newer EAP methods can be used for mutual authentication, and combined with [I‑D.ietf‑ipsecme‑eap‑mutual] (Eronen, P., Tschofenig, H., and Y. Sheffer, “An Extension for EAP-Only Authentication in IKEv2,” June 2010.) 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 be free of patents, and 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 [PACEsec] (Bender, J., Fischlin, M., and D. Kuegler, “Security Analysis of the PACE Key-Agreement Protocol. The extended abstract appeared in Information Security Conference (ISC) 2009, LNCS 5735, pp. 33-48, Springer-Verlag,” 2009.).

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.

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 RFC 2119 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Overview

The following notation is used in this draft:

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 token

At a high level the following steps are performed by the initiator and the responder. They result in exchanges IKE_PACE and IKE_PACE_AUTH as described in Section 3 (Protocol Sequence) that are performed directly after IKE_SA_INIT and fully replace IKE_AUTH.

1. The initiator randomly and uniformly chooses a nonce, encrypts the nonce using the password, and sends the ciphertext ENONCE to the responder.
2. The responder recovers the plaintext nonce with the help of the shared password Pwd.
3. The initiator and the responder perform the following steps:

   A.

   A mapping function Map() is used to derive an ephemeral generator GE = Map(G,s) from the exchanged nonce s and the generator G of the used group.

   B.

   They perform an anonymous Diffie-Hellman key agreement based on the ephemeral generator and compute the shared secret PACESharedSecret.

   C.

   They generate, exchange, and verify the authentication token AUTH using the shared secret PACESharedSecret.

3.  Protocol Sequence

The protocol consists of three exchanges, IKE_SA_INIT, IKE_PACE, and IKE_PACE_AUTH as follows:

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

  IKE_SA_INIT:

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

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

  IKE_PACE:

  HDR, SK{IDi, [IDr,], SAi2,
          TSi, TSr, ENONCE, PKEi} ->

                              <- HDR, SK{IDr, PKEr}

  IKE_PACE_AUTH:

  HDR, SK{AUTH} ->

                              <- HDR, SK{AUTH, SAr2, TSi, TSr}

3.1.  The IKE_SA_INIT Exchange

The initiator sends a PACE_SUPPORTED notification to indicate its support of this extension, and its wish to authenticate using a password. If the responder accepts, it responds with the same notification. Otherwise, it omits the notification to indicate a preference for a regular IKE exchange. In the case of anti-DOS cookies (Sec. 2.6 of [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.)), the notification MUST be resent by each peer every time it sends its IKE_SA_INIT message.

If PACE is supported, 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.

3.2.  The IKE_PACE Exchange

This new exchange (number TBD by IANA) 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. On the other hand, to allow for future extensibility, the initiator MAY choose to proceed with IKE_AUTH instead of IKE_PACE, in which case the peers revert to a normal IKE exchange.

The initiator selects a random nonce s and encrypts it to form ENONCE using the password Pwd, as described in Section 4.1 (Encrypting the Nonce). Then the initiator maps the nonce to an ephemeral generator GE of the group as described in Section 4.2 (Mapping the Nonce), chooses randomly and uniformly an ephemeral key pair (SKEi,PKEi) based on the ephemeral generator and finally generates the payloads ENONCE containing the encrypted nonce and PKEi 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 PKEr 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 IKE_PACE 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 the IKE_PACE request. In particular, certificate-related payloads are allowed, even though their use may not be practical within this mode.

3.3.  The IKE_PACE_AUTH Exchange

This new exchange (number TBD by IANA) is the second part of the PACE authentication of the peers.

The initiator and the responder calculate the shared secret PACESharedSecret:

PACESharedSecret = KA(SKEi, PKEi, GE) = KA(SKEr, PKEr, 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)

See Sec. 2.15 of [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) (further clarified in Sec. 2.15 of [I‑D.ietf‑ipsecme‑ikev2bis] (Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, “Internet Key Exchange Protocol: IKEv2,” May 2010.)) for the definition of signed octets.

The responder calculates:

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

The authentication tokens are then exchanged and each of them MUST be verified by the other party. The behavior when this verification fails is unchanged from [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.).

The IKE_PACE_AUTH 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 IKE_PACE_AUTH 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.

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 prf requires a fixed-size key, the literal string is as needed either truncated or padded with zero octets on the right.

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 Sec. 2.13 of [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.). 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 (Randomness) for additional considerations). The length of s is the block size of the encryption algorithm that was negotiated for the IKE SA, or 32 octets if no such block size exists. To clarify, stream ciphers constructed by applying a block cipher in counter mode, are to be treated as having no block size.

Note: in the case of block ciphers, is critical to the security of the protocol that the nonce be encrypted with no padding.

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

4.2.  Mapping the Nonce

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] (BSI, “TR-03110, Advanced Security Mechanisms for Machine Readable Travel Documents - Extended Access Control (EAC), Password Authenticated Connection Establishment (PACE), and Restricted Identification (RI), Version 2.03,” 2010.) 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 [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.),

SASharedSecret = g^ir

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.

4.2.1.  MODP 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.

4.2.3.  Validation

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] (Zuccherato, R., “Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME,” March 2000.). The Elliptic Curve equivalents of those methods are described in more detail in [TR03111] (BSI, “TR-03111, Elliptic Curve Cryptography, Version 1.11,” 2009.).

Any failure in the validation MUST be interpreted as an attack, and the protocol SHALL be aborted.

5.  Protocol Details

5.1.  Password Processing

The input password string SHOULD be processed according to the rules of the [RFC4013] (Zeilenga, K., “SASLprep: Stringprep Profile for User Names and Passwords,” February 2005.) profile of [RFC3454] (Hoffman, P. and M. Blanchet, “Preparation of Internationalized Strings ("stringprep"),” December 2002.). A password SHOULD be considered a "stored string" per [RFC3454] (Hoffman, P. and M. Blanchet, “Preparation of Internationalized Strings ("stringprep"),” December 2002.) 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.

5.2.  The PACE_SUPPORTED Notification

This protocol defines a new PACE_SUPPORTED notification, with type number TBD by IANA. This is an empty notification: The Protocol ID and SPI size fields are set to zero, and there is no additional data associated with this notification.

5.3.  The ENONCE Payload

This protocol defines a new ENONCE (encrypted nonce) payload, with payload type TBD by IANA. 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        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Initialization Vector                     |
|    (optional, length is block size for encryption algorithm)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Encrypted Nonce                        ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The length of the nonce MUST be an integer multiple of the selected encryption algorithm's block size (if any). Note that the payload format does not support any padding of the encrypted data.

5.4.  The PKE (PKEi/PKEr) Payloads

These payloads have an identical format to the IKEv2 KE payload. However, this protocol defines a new payload type named PKE (Public Key - Ephemeral), whose value is TBD by IANA. Since only one Diffie Hellman group is negotiated, the group denoted by these payloads MUST be identical to the one used in the KE payloads.

5.5.  PACE and Session Resumption

A session resumption [RFC5723] (Sheffer, Y. and H. Tschofenig, “Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption,” January 2010.) ticket may be requested during the IKE_PACE/IKE_PACE_AUTH exchanges. The request MUST be sent in the IKE_PACE request, and any response MUST be sent in the IKE_PACE_AUTH response.

PACE should be considered an "authentication method", in the sense of Sec. 5 of [RFC5723] (Sheffer, Y. and H. Tschofenig, “Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption,” January 2010.), which means that its use MUST be noted in the protected ticket.

Note that even if the initial authentication used PACE and its new exchange types, 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 [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) and [I‑D.ietf‑ipsecme‑ikev2bis] (Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, “Internet Key Exchange Protocol: IKEv2,” May 2010.) 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 (Security Model and Security Proof) 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.

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, and see Sec. 5 of [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) 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.

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.

6.8.  Security Model and Security Proof

PACE is cryptographically proven secure in [PACEsec] (Bender, J., Fischlin, M., and D. Kuegler, “Security Analysis of the PACE Key-Agreement Protocol. The extended abstract appeared in Information Security Conference (ISC) 2009, LNCS 5735, pp. 33-48, Springer-Verlag,” 2009.) in the model of Bellare, Pointcheval, and Rogaway [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.). 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:

• 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 spearate 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 lazy-sampling technique which 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 peers to store the plaintext password. Instead, the value KPwd SHOULD be stored by both peers.

It has been suggested to generate a "long" shared secret after the initial authentication, such that the peers can use it later for standard preshared-secret authentication, in lieu of the short password. We have not been able to identify sufficient security benefits with this approach that would justify the added complexity.

7.  IANA Considerations

IANA is requested to allocate (has allocated) the following values:

• The PACE_SUPPORTED notification type (TBD) from the "IKEv2 Notify Message Types - Status Types" registry.
• A payload type (TBD) for the Encrypted Nonce (ENONCE) payload from the "IKEv2 Payload Types" registry.
• A payload type (TBD) for the Ephemeral Public Key (PKE) payload from the same registry.
• An authentication method (TBD) for Password Authenticated Connection Establishment (PACE) from the "IKEv2 Authentication Method" registry.
• An exchange type (TBD) for the IKE_PACE exchange, from the "IKEv2 Exchange Types" registry.
• An exchange type (TBD) for the IKE_PACE_AUTH exchange, from the same registry.

This document does not define any new registries.

8.  References

8.1. Normative References

8.2. Informative References

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 [I‑D.harkins‑ipsecme‑pake‑criteria] (Harkins, D., “Password-Based Authentication in IKEv2: Selection Criteria and Considerations,” April 2010.). 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 draft of [TR03110] (BSI, “TR-03110, Advanced Security Mechanisms for Machine Readable Travel Documents - Extended Access Control (EAC), Password Authenticated Connection Establishment (PACE), and Restricted Identification (RI), Version 2.03,” 2010.) 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 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. standard or Elliptic Curve) can be used.

MISC11:

The protocol can be implemented easily based on existing cryptographic primitives.

Appendix B.  Change Log

Note to RFC Editor: please remove this appendix before publication.

B.1.  -03

Completed the security considerations (security proof). Reordered some sections for clarity.

B.2.  -02

Added security considerations. Changed encryption of the nonce. Simplified the derivation of the AUTH payloads.

B.3.  draft-kuegler-ipsecme-pace-ikev2-01

Formalized the protocol: added payload formats, error behavior etc.

Authors' Addresses