Network Working Group D. Kuegler
Internet-Draft Bundesamt fuer Sicherheit in der
Intended status: Experimental Informationstechnik (BSI)
Expires: February 7, 2011 Y. Sheffer
Independent
August 6, 2010
Password Authenticated Connection Establishment with IKEv2draft-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
Kuegler & Sheffer Expires February 7, 2011 [Page 1]

Internet-Draft IKEv2 with PACE August 20101. 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. This draft describes
the integration of PACE into IKEv2 ([RFC4306] and
[I-D.ietf-ipsecme-ikev2bis]) 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:
o 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.
o Alternatively, native IKEv2 shared secret authentication can be
used with passwords. This usage however is insecure, specifically
it is vulnerable to active attackers.
o Some newer EAP methods can be used for mutual authentication, and
combined with [I-D.ietf-ipsecme-eap-mutual] 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].
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].
2. Overview
The following notation is used in this draft:
Kuegler & Sheffer Expires February 7, 2011 [Page 3]

Internet-Draft IKEv2 with PACE August 2010
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 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:
Kuegler & Sheffer Expires February 7, 2011 [Page 4]

Internet-Draft IKEv2 with PACE August 2010
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}
Figure 1: IKE SA Setup with PACE
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]), 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
Kuegler & Sheffer Expires February 7, 2011 [Page 5]

Internet-Draft IKEv2 with PACE August 2010
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. 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 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] (further clarified in Sec. 2.15 of
[I-D.ietf-ipsecme-ikev2bis]) for the definition of signed octets.
Kuegler & Sheffer Expires February 7, 2011 [Page 6]

Internet-Draft IKEv2 with PACE August 2010
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].
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 Nonce4.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]. 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 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
Kuegler & Sheffer Expires February 7, 2011 [Page 7]

Internet-Draft IKEv2 with PACE August 2010
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] 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],
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
Kuegler & Sheffer Expires February 7, 2011 [Page 8]

Internet-Draft IKEv2 with PACE August 2010
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]. 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.
5. Protocol Details5.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] 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:
Kuegler & Sheffer Expires February 7, 2011 [Page 9]

Internet-Draft IKEv2 with PACE August 2010
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ENONCE Payload Structure
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] 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], 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
Kuegler & Sheffer Expires February 7, 2011 [Page 10]

Internet-Draft IKEv2 with PACE August 2010
protocol. The reader is referred to [RFC4306] and
[I-D.ietf-ipsecme-ikev2bis] 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
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] 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.
Kuegler & Sheffer Expires February 7, 2011 [Page 11]

Internet-Draft IKEv2 with PACE August 20106.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] 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 spearate 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 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:
Kuegler & Sheffer Expires February 7, 2011 [Page 12]

Internet-Draft IKEv2 with PACE August 2010
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] 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.
Kuegler & Sheffer Expires February 7, 2011 [Page 15]