One document matched: draft-kuegler-ipsecme-pace-ikev2-01.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<rfc category="exp" ipr="trust200902"
docName="draft-kuegler-ipsecme-pace-ikev2-01">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<front>
<title abbrev="IKEv2 with PACE">Password Authenticated Connection Establishment with IKEv2</title>
<author initials="D." surname="Kuegler" fullname="Dennis Kuegler">
<organization>Bundesamt fuer Sicherheit in der Informationstechnik (BSI)</organization>
<address>
<postal>
<street>Postfach 200363</street>
<city>Bonn</city>
<code>53133</code>
<country>Germany</country>
</postal>
<email>dennis.kuegler@bsi.bund.de</email>
</address>
</author>
<author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
<organization>Independent</organization>
<address>
<email>yaronf.ietf@gmail.com</email>
</address>
</author>
<date year="2010"/>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
PACE <xref target="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 (<xref target="RFC4306"/> and <xref target="I-D.ietf-ipsecme-ikev2bis"/>) as a new authentication mode, analogous to the existing certificate and PSK authentication modes.
</t><t>
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 <xref target="PACEsec"/>.
</t><t>
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.
</t><t>
NOTE: Due to the adaptations of the original protocol <xref target="TR03110"/>, the proof <xref target="PACEsec"/> requires some modifications, that will be provided once the details of the integration are fixed.
</t>
<section title="Terminology">
<t>
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 <xref target="RFC2119"/>.
</t>
</section>
</section>
<!-- *************************************************************************************** -->
<section title="Overview">
<t>
The following notation is used in this draft:
<figure>
<artwork>
<![CDATA[
E() Symmetric encryption
D() Symmetric decryption
KA() Key agreement
Map() Mapping function
Pwd Shared 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
]]>
</artwork>
</figure>
</t><t>
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 <xref target="sequence"/>
that are performed directly after IKE_SA_INIT and fully replace IKE_AUTH.
<list style="numbers">
<t>
The initiator randomly and uniformly chooses a nonce, encrypts the nonce, and sends the ciphertext ENONCE to the responder.
</t><t>
The responder recovers the plaintext nonce with the help of the shared password Pwd.
</t><t>
The initiator and the responder perform the following steps:
<list style="letters">
<t>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.
</t><t>They perform an anonymous Diffie-Hellman key agreement based on the ephemeral generator and compute the shared secret
<list style="empty">
<t>PACESharedSecret = KA(SKEi, PKEi, GE) = KA(SKEr, PKEr, GE).</t>
</list>
</t><t>
They generate, exchange, and verify the authentication token AUTH using the shared secret PACESharedSecret.
</t>
</list>
</t>
</list>
</t>
</section>
<!-- *************************************************************************************** -->
<section anchor="sequence" title="Protocol Sequence">
<t>
The protocol consists of three exchanges, IKE_SA_INIT, IKE_PACE, and IKE_PACE_AUTH as follows:
</t>
<figure>
<artwork>
<![CDATA[
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}
]]>
</artwork>
</figure>
<section title="The IKE_SA_INIT Exchange">
<t>
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 <xref target="RFC4306"/>), the notification MUST be resent by
each peer every time it sends its IKE_SA_INIT message.
</t><t>
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.
</t><t>
<!-- TODO: should not negotiate an encryption transform. Instead, should adjust the nonce length to eliminate redundancy. -->
In addition, a new transform type is used to negotiate the password-based encryption of the nonce.
This transform includes the cipher and its mode of operation as well as the bit length of the nonce to be used.
</t><t>
NOTE: The password-based encryption MUST NOT introduce any redundancy that allows
for excluding possible plaintexts with a brute-force attack on the password.
</t><t>
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.
</t>
</section>
<section title="The IKE_PACE Exchange">
<t>This new exchange (number TBD by IANA) is the first part of the PACE authentication of the peers.</t>
<t>
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 ENONCE = E(Pwd, s) using the negotiated password based-encryption using the password Pwd.
</t><t>
The initiator maps the nonce to an ephemeral generator of the group as described in <xref target="mapping"/>, 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.
</t><t>
The responder decrypts the received encrypted nonce s = D(Pwd, ENONCE), 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.
</t><t>
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.
</t>
<t>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.</t>
</section>
<section title="The IKE_PACE_AUTH Exchange">
<t>This new exchange (number TBD by IANA) is the second part of the PACE authentication of the peers.</t>
<t>
The initiator and the responder calculate the shared secret PACESharedSecret, derive the authentication key, and calculate the authentication token AUTH.
</t><t>
The initiator calculates:
</t><t>
<list style="empty">
<t>
AUTHi = prf(prf+(PACESharedSecret, "PACE Authentication i" | IDr | IDi | PKEr), <InitiatorSignedOctets>)
</t>
</list>
See Sec. 2.15 of <xref target="RFC4306"/> (further clarified in Sec. 2.15 of <xref target="I-D.ietf-ipsecme-ikev2bis"/>)
for the definition of signed octets.
</t><t>
The responder calculates:
<list style="empty">
<t>
AUTHr = prf(prf+(PACESharedSecret, "PACE Authentication r" | IDi | IDr | PKEi), <ResponderSignedOctets>)
</t>
</list>
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 <xref target="RFC4306"/>.
</t>
<t>Provided authentication was successful, 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.</t>
<t>Following authentication, all temporary values MUST be deleted by the peers, including in particular
s, the ephemeral generator and public keys, and PACESharedSecret.</t>
</section>
</section>
<!-- *************************************************************************************** -->
<section anchor="mapping" title="Mapping">
<t>
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.
</t><t>
While in <xref target="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 <xref target="RFC4306"/>,
<list style="empty">
<t>SASharedSecret = g^ir</t>
</list>
</t><t>
Let G and GE be the generator of the negotiated DH group, and the calculated ephemeral generator, respectively.
</t>
<section title="Diffie Hellman">
<t>
The function Map:G->GE is defined as GE = G^s * SASharedSecret.
</t><t>
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.
</t>
</section>
<section title="Elliptic Curve Diffie Hellman">
<t>
The function Map:G->GE is defined as GE = s*G + SASharedSecret.
</t><t>
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.
</t>
</section>
<section title="Validation">
<t>
Implementations MUST verify that the shared secrets SASharedSecret and PACESharedSecret are elements of the group generated by G to prevent small subgroup attacks.
</t><t>
It is RECOMMENDED to use the public key validation method (or an Elliptic Curve equivalent) described in Section 2.1.5 of <xref target="RFC2631"/>.
</t><t>
For Elliptic Curves compatible cofactor multiplication <xref target="TR03111"/> MAY be used instead of public key validation. In this case implementations MUST check that PACESharedSecret is not the point at infinity.
</t><t>
Any failure in the validation SHALL be interpreted as an attack.
</t>
</section>
</section>
<!-- *************************************************************************************** -->
<section title="Protocol Details">
<section title="Password Processing">
<!-- TODO: password storage -->
<t>
The input password string SHOULD be processed according to the
rules of the <xref target="RFC4013"/> profile of <xref target="RFC3454"/>.
A password SHOULD be
considered a "stored string" per <xref target="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.
</t>
</section>
<section title="The PACE_SUPPORTED Notification">
<t>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.</t>
</section>
<section title="The ENONCE Payload">
<t>This protocol defines a new ENONCE (encrypted nonce) payload, with payload type TBD by IANA. Its format is as follows:</t>
<t>
<figure anchor="enonce-payload" title="ENONCE Payload Structure">
<artwork>
<![CDATA[
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
</t>
<t>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.</t>
</section>
<section title="The PKE (PKEi/PKEr) Payloads">
<t>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.</t>
</section>
<section title="PACE and Session Resumption">
<t>A session resumption <xref target="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.</t>
<t>PACE should be considered an "authentication method", in the sense of Sec. 5 of <xref target="RFC5723"/>,
which means that its use MUST be noted in the protected ticket.</t>
<t>Note that even if the initial authentication used PACE and its new exchange types, session resumption will still
include the normal IKE_AUTH exchange.</t>
</section>
</section>
<!-- *************************************************************************************** -->
<section title="Security Considerations">
<t>
TODO: PACE is cryptographically proven secure in <xref target="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.
</t>
<t>What follows is an outline of the security considerations for this protocol.</t>
<section title="Credential Security Assumptions">
</section>
<section title="Vulnerability to Passive and Active Attacks">
<!-- rate limiting -->
</section>
<section title="Perfect Forward Secrecy">
</section>
<section title="Identity Protection">
</section>
<section title="Denial of Service">
</section>
<section title="Choice of Encryption Algorithms">
<!-- No autheticated encryption -->
</section>
<section title="Security Model and Security Proof">
</section>
<section title="Long-Term Credential Storage">
<!-- Talk also about the possibility to derive a strong long-term credential -->
</section>
</section>
<!-- *************************************************************************************** -->
<section title="IANA Considerations">
<t>
IANA is requested to allocate (has allocated) the following values:
<list style="symbols">
<t>The PACE_SUPPORTED notification type (TBD) from the "IKEv2 Notify Message Types - Status Types" registry.</t>
<t>A payload type (TBD) for the Encrypted Nonce (ENONCE) payload from the "IKEv2 Payload Types" registry.</t>
<t>A payload type (TBD) for the Ephemeral Public Key (PKE) payload from the same registry.</t>
<t>An authentication method (TBD) for Password Authenticated Connection Establishment (PACE)
from the "IKEv2 Authentication Method" registry.</t>
<t>An exchange type (TBD) for the IKE_PACE exchange, from the "IKEv2 Exchange Types" registry.</t>
<t>An exchange type (TBD) for the IKE_PACE_AUTH exchange, from the same registry.</t>
</list>
This document does not define any new registries.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.2631.xml"?>
<?rfc include="reference.RFC.3454.xml"?>
<?rfc include="reference.RFC.4306.xml"?>
<?rfc include="reference.RFC.4013.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.harkins-ipsecme-pake-criteria.xml"?>
<?rfc include="reference.I-D.ietf-ipsecme-ikev2bis.xml"?>
<?rfc include="reference.RFC.5723.xml"?>
<reference anchor="TR03110">
<front>
<title>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</title>
<author fullname="Bundesamt fuer Sicherheit in der Informationstechnik"/>
<date year="2010"/>
</front>
</reference>
<reference anchor="TR03111">
<front>
<title>BSI TR-03111, "Elliptic Curve Cryptography", Version 1.11</title>
<author fullname="Bundesamt fuer Sicherheit in der Informationstechnik"/>
<date year="2009"/>
</front>
</reference>
<reference anchor="PACEsec">
<front>
<title>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.</title>
<author fullname="Jens Bender"/>
<author fullname="Marc Fischlin"/>
<author fullname="Dennis Kuegler"/>
<date year="2009"/>
</front>
<format type="PDF" target="http://eprint.iacr.org/2009/624"/>
</reference>
</references>
<!-- *************************************************************************************** -->
<section title="Protocol Selection Criteria">
<t>
To support the selection of a password-based protocol for inclusion in IKEv2, a number of criteria
are provided in <xref target="I-D.harkins-ipsecme-pake-criteria"/>. In the following sections,
those criteria are applied to the PACE protocol.
</t>
<section title="Security Criteria">
<t>
<list style="format SEC%d:">
<t>
PACE is a zero knowledge protocol.
</t><t>
The protocol supports perfect forward secrecy and is resistant to replay attacks.
</t><t>
The identity protection provided by IKEv2 remains unchanged.
</t><t>
Any cryptographically secure Diffie-Hellman group can be used.
</t><t>
The protocol is proven secure in the Bellare-Pointcheval-Rogaway model.
</t><t>
Strong session keys are generated.
</t><t>
A transform of the password can be used instead of the password itself.
</t>
</list>
</t>
</section>
<section title="Intellectual Property Criteria">
<t>
<list style="format IPR%d:">
<t>
The first draft of <xref target="TR03110"/> was published on May 21, 2007.
</t><t>
BSI has developed PACE aiming to be free of patents. BSI has not applied for a patent on PACE.
</t><t>
The protocol itself is believed to be free of IPR.
</t>
</list>
</t>
</section>
<section title="Miscellaneous Criteria">
<t>
<list style="format MISC%d:">
<t>
One additional exchange is required.
</t><t>
The protocol requires the following operations per entity:
<list style="symbols">
<t>
one key derivation from the password,
</t><t>
one symmetric encryption or decryption,
</t><t>
one multi-exponentiation for the mapping,
</t><t>
one exponentiation for the key pair generation,
</t><t>
one exponentiation for the shared secret calculation, and
</t><t>
two symmetric authentications (generation and verification).
</t>
</list>
</t><t>
The performance is independent of the type/size of password.
</t><t>
Internationalization of character-based passwords is supported.
</t><t>
The protocol uses the same group as negotiated for IKEv2.
</t><t>
The protocol fits into the request/response nature of IKE.
</t><t>
The password-based symmetric encryption must be additionally negotiated.
</t><t>
Neither trusted third parties nor clock synchronization are required.
</t><t>
Only general cryptographic primitives are required.
</t><t>
Any secure variant of Diffie Hellman (e.g. standard or Elliptic Curve) can be used.
</t><t>
The protocol can be implemented easily based on existing cryptographic primitives.
</t>
</list>
</t>
</section>
</section>
<section title="Change Log">
<t>Note to RFC Editor: please remove this appendix before publication.</t>
<section toc="exclude" title="draft-kuegler-ipsecme-pace-ikev2-01">
<t>Formalized the protocol: added payload formats, error behavior etc.</t>
</section>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 07:14:40 |