INTERNET-DRAFT D. Kuegler
Intended Status: informational (BSI)
Expires: November 4, 2010 May 3, 2010
Password Authenticated Connection Establishment with IKEv2
draft-kuegler-ipsecme-pace-ikev2-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License 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.
Kuegler Expires November 4, 2010 [Page 1]
INTERNET DRAFT PACE May 3, 2010
Abstract
This document provides an adaptation of PACE (Password Authenticated
Connection Establishment) to the setting of IKEv2 to allow for a
password-based authentication mode.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Security Criteria . . . . . . . . . . . . . . . . . . . . . 3
1.2 Intellectual Property Criteria . . . . . . . . . . . . . . 4
1.3 MISC Criteria . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 The IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . 6
3.2 The IKE_PACE Exchange . . . . . . . . . . . . . . . . . . . 7
3.3 The IKE_PACE_AUTH Exchange . . . . . . . . . . . . . . . . 7
4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Diffie Hellman . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Elliptic Curve Diffie Hellman . . . . . . . . . . . . . . . 8
4.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . 8
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 8
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1 Normative References . . . . . . . . . . . . . . . . . . . 9
7.2 Informative References . . . . . . . . . . . . . . . . . . 9
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
Kuegler Expires November 4, 2010 [Page 2]
INTERNET DRAFT PACE May 3, 2010
1 Introduction
This is a preliminary draft describing the possible integration of
the password-based authentication protocol PACE [TR03110] in IKEv2.
PACE establishes an 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.
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
mathematic 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, i.e. the mechanisms used to establish session keys as
provided by IKEv2 are completely maintained.
NOTE: Due to the adaptations of the original protocol [TR03110], the
proof [PACEsec] requires some modifications, that will be provided
once the details of the integration are fixed.
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.
1.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.
Kuegler Expires November 4, 2010 [Page 3]
INTERNET DRAFT PACE May 3, 2010
1.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.
1.3 MISC Criteria
MISC1: One additional exchange is required.
MISC2: The protocol requires the following operations per entity:
o one key derivation from the password,
o one symmetric encryption or decryption,
o one multi-exponentiation for the mapping,
o one exponentiation for the key pair generation,
o one exponentiation for the shared secret calculation, and
o two symmetric authentications (generation & 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.
1.4 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:
E() Symmetric encryption
D() Symmetric decryption
KA() Key agreement
Map() Mapping function
Pwd Shared Password
Kuegler Expires November 4, 2010 [Page 4]
INTERNET DRAFT PACE May 3, 2010
KPwd Symmetric key derived from a password Pwd
G Static group generator
GE Ephemeral group generator
CIPH Enciphered 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 are partially replacing IKE_AUTH.
1. The initiator randomly and uniformly chooses a nonce, encrypts
the nonce, and sends the ciphertext CIPH to the responder.
2. The responder recovers the plaintext 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 = KA(SKEi, PKEi, GE) = KA(SKEr, PKEr, GE).
During the Diffie-Hellman key agreement, each party SHOULD
check that the two public keys PKEi and PKEr differ.
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 Expires November 4, 2010 [Page 5]
INTERNET DRAFT PACE May 3, 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, CIPH, PKEi} ->
<- HDR, SK{IDr, PKEr}
IKE_PACE_AUTH:
HDR, SK{AUTH} ->
<- HDR, SK{AUTH, SAr2, TSi, TSr}
3.1 The IKE_SA_INIT Exchange
Within this exchange the initiator and the responder negotiate the
use of PACE by exchanging a PACE_SUPPORTED notifications.
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 authentication algorithm.
In addition, a new transform type is used to negotiate the password-
based encryption of the nonce. This transform includes the cipher and
it's mode of operation as well as the bit length of the nonce to be
used.
NOTE: The password-based encryption MUST NOT introduce any redundancy
that allows for excluding possible plaintexts with a brute-force
attack on the password.
An example for a suitable password based encryption is a block cipher
in ECB mode using key KPwd = prf+(Pwd, "PACE Password") which is
derived from the shared password Pwd. In this case the size of the
nonce SHALL be the block size of the cipher.
Kuegler Expires November 4, 2010 [Page 6]
INTERNET DRAFT PACE May 3, 2010
3.2 The IKE_PACE Exchange
The initiator selects a nonce s as binary bit string. The nonce MUST
be chosen randomly and uniformly, the length of the nonce SHALL be
according to the negotiated value. The nonce is encrypted to CIPH =
E(Pwd, s) using the negotiated password based-encryption using the
password Pwd.
NOTE: The is no other requirement on the generation of the nonce
other than the fact that it MUST be random and uniformly
distributed.
The initiator maps the nonce to an ephemeral generator of the group
as described in Section 4, chooses randomly and uniformly an
ephemeral key pair (SKEi,PKEi) based on the ephemeral generator and
finally generates the payloads CIPH containing the encrypted nonce
and PKEi containing the ephemeral public key.
The responder decrypts the received encrypted nonce s = D(Pwd, CIPH),
performs the mapping and randomly and uniformly chooses an ephemeral
key pair (SKEr,PKEr) based on the ephemeral generator. The responder
generates the PKEr payload containing the ephemeral public key.
3.3 The IKE_PACE_AUTH Exchange
The initiator and the responder calculate the shared secret
PACESharedSecret, derive the authentication key, and calculate the
authentication token AUTH.
The initiator calculates:
AUTH = prf(prf+(PACESharedSecret, "PACE Authentication i" | IDr |
IDi), PKEr)
The responder calculates:
AUTH = prf(prf+(PACESharedSecret, "PACE Authentication r" | IDi |
IDr), PKEi)
The authentication token are then exchanged and verified by the other
party.
4 Mapping
The mapping is based on a second anonymous Diffe-Hellman key
agreement protocol to create a shared secret which is used together
Kuegler Expires November 4, 2010 [Page 7]
INTERNET DRAFT PACE May 3, 2010
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. This shared
secret SHALL be reused.
Let G, and GE be the generator of the group, and the calculated
ephemeral generator, respectively.
4.1 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.
Implementations that detect such a failure SHOULD choose s again.
4.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.
Implementations that detect such a failure SHOULD choose s again.
4.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 an
Elliptic Curve equivalent) described in Section 2.1.5 of [RFC2631].
For Elliptic Curves compatible cofactor multiplication [TR03111] MAY
be used instead of public key validation. In this case
implementations MUST check that PACESharedSecret is not the point at
infinity.
Any failure in the validation SHALL be interpreted as an attack.
5 Security Considerations
Kuegler Expires November 4, 2010 [Page 8]
INTERNET DRAFT PACE May 3, 2010
TODO: PACE is cryptographically proven secure in [PACEsec]. The
application of PACE in IKEv2 however is however a slightly different
setting that requires a modification of the proof. A new proof will
be provided once the details of the integration are fixed.
6 IANA Considerations
TBD: One notification (N(PACE_SUPPORTED)), one transform type
(Password-based Encryption), two payloads (CIPH, PKEi/PKEr) and an
Auth Method Identifier.
7 References
7.1 Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2361] E. Rescorla, "Diffie-Hellman key agreement method",
RFC 2631, 1999
[I-D.harkins-ipsecme-pake-criteria]
D. Harkins, "Password-Based Authentication in IKEv2:
Selection Criteria and Considerations", draft-harkins-
ipsecme-pake-criteria-00.txt, April 2010
7.2 Informative References
[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
[TR03111] BSI TR-03111, "Elliptic Curve Cryptography", Version
1.11, 2009
[PACEsec] J. Bender, M. Fishlin, D. Kuegler, "Security Analysis of
the PACE Key-Agreement Protocol", Information Security
Conference (ISC) 2009, Lecture Notes in Computer Science,
Volume 5735, pp. 33-48, Springer-Verlag, 2009. Full
version available at http://eprint.iacr.org/2009/624
Kuegler Expires November 4, 2010 [Page 9]
INTERNET DRAFT PACE May 3, 2010
Author's Addresses
Dennis Kuegler
Bundesamt fuer Sicherheit in der Informationstechnik (BSI)
Postfach 200363
53133 Bonn
Germany
EMail: dennis.kuegler@bsi.bund.de
Kuegler Expires November 4, 2010 [Page 10]
