One document matched: draft-kuegler-ipsecme-pace-ikev2-06.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<rfc category="exp" ipr="trust200902"
docName="draft-kuegler-ipsecme-pace-ikev2-06">
<?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>Porticor</organization>
<address>
<email>yaronf.ietf@gmail.com</email>
</address>
</author>
<date year="2011"/>
<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="RFC5996"/> as a new authentication mode, analogous to the existing certificate and PSK authentication modes.
</t><t>
Some of the advantages of our approach, compared to the existing IKEv2, include:
<list style="symbols">
<t>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.</t>
<t>Alternatively, native IKEv2 shared secret authentication can be used with passwords. This usage however is insecure, specifically
it is vulnerable to active attackers.</t>
<t>Some newer EAP methods can be used for mutual authentication,
and combined with <xref target="RFC5998"/> can be well integrated into IKEv2.
This is certainly an option in some cases, but the current proposal may be simpler to implement.</t>
</list>
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 <xref target="PACEsec"/>. The PACE protocol is currently used in an international standard for digital travel documents <xref target="ICAO"/>.
</t><t>
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.
</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 <xref target="RFC2119"/>.
</t>
<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
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
]]>
</artwork>
</figure>
</t>
<t>Any other notation used here is defined in <xref target="RFC5996"/>.</t>
</section>
</section>
<!-- *************************************************************************************** -->
<section title="Overview">
<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 using the password,
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 PACESharedSecret.
</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 anchor="figure-exchange" title="IKE SA Setup with PACE">
<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="RFC5996"/>), 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 encryption algorithm.
</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>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.</t>
<t>
The initiator selects a random nonce s and encrypts it to form ENONCE using the password Pwd, as described in <xref target="encryption"/>. Then the initiator maps the nonce to an ephemeral generator GE 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(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.
</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:
</t><t>
<list>
<t>PACESharedSecret = KA(SKEi, PKEr, GE) = KA(SKEr, PKEi, GE),</t>
</list>
</t><t>
where KA denotes the Diffie Hellman key agreement, e.g. (for MODP groups) modular exponentiation.
Then they calculate the authentication tokens AUTHi and AUTHr.
</t><t>
The initiator calculates:
</t><t>
<list style="empty">
<t>
AUTHi = prf(prf+(Ni | Nr, PACESharedSecret), <InitiatorSignedOctets> | PKEr)
</t>
</list>
</t><t>
See Sec. 2.15 of <xref target="RFC5996"/> for the definition of signed octets.
</t><t>
The responder calculates:
</t><t>
<list style="empty">
<t>
AUTHr = prf(prf+(Ni | Nr, PACESharedSecret), <ResponderSignedOctets> | PKEi)
</t>
</list>
</t><t>
Both AUTH payloads MUST indicate the new PACE authentication method, whose value is TBD by IANA.
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 <xref target="RFC5996"/>.
</t>
<t>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, the ephemeral key pairs, and PACESharedSecret.</t>
</section>
</section>
<!-- *************************************************************************************** -->
<section anchor="nonce" title="Encrypting and Mapping the Nonce">
<section anchor="encryption" title="Encrypting the Nonce">
<t>
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:
</t><t>
<list style="empty"><t>
SPwd = prf("IKE with PACE", Pwd)
</t></list>
</t><t>
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.
</t><t>
<list style="empty"><t>
KPwd = prf+(Ni | Nr, SPwd)
</t></list>
</t><t>
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 <xref target="RFC5996"/>.
The length of KPwd is determined by the key length of the negotiated encryption algorithm.
</t><t>
A nonce s is randomly selected by the initiator (see <xref target="randomness"/> for additional
considerations). The length of s MUST be exactly 32 octets.
</t><t>
Note: Padding MUST NOT be used when encrypting the nonce. The size of the nonce
has been chosen such that is can be encrypted with block ciphers having block
sizes of 32, 64, and 128 bit without any padding.
</t><t>
If an authenticated encryption cipher <xref target="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. 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.
</t><t>
KPwd is now used with the encryption transform to encrypt the nonce:
</t><t>
<list style="empty"><t>
ENONCE = E(KPwd, s)
</t></list>
</t><t>
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.
</t>
</section>
<section anchor="mapping" title="Mapping the Nonce">
<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="RFC5996"/>,
</t><t>
<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. The following subsections describe the mapping for different Diffie Hellman variants.
</t>
<section title="MODP 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 the compatible cofactor exponentiation described in Section 3.1 and Section 3.4, respectively, of <xref target="RFC2785"/>. The Elliptic Curve equivalents of those methods are described in more detail in <xref target="TR03111"/>.
</t><t>
Any failure in the validation MUST be interpreted as an attack, and the protocol SHALL be aborted.
</t>
</section>
</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 depends on the encryption algorithm) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Nonce ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
</t>
<t>See <xref target="encryption"/> 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.</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.
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.</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>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 <xref target="RFC5996"/>
for the generic IKEv2 security considerations.</t>
<section title="Credential Security Assumptions">
<t>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.</t>
</section>
<section title="Vulnerability to Passive and Active Attacks">
<t>The protocol is secure against both passive and active attackers. See <xref target="security-proof"/> for a security proof.
</t><t>
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.
</t>
</section>
<section title="Perfect Forward Secrecy">
<t>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.</t>
</section>
<section anchor="randomness" title="Randomness">
<t>The security of this protocol depends on the quality generation of random quantities, and see Sec. 5
of <xref target="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.
</t>
</section>
<section title="Identity Protection">
<t>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.</t>
</section>
<section title="Denial of Service">
<t>We are not aware of any new denial-of-service attack vector enabled by this protocol. </t>
</section>
<section title="Choice of Encryption Algorithms">
<t>Any transforms negotiated for IKEv2 may be used by this protocol.</t>
</section>
<section anchor="security-proof" title="Security Model and Security Proof">
<t>
PACE is cryptographically proven secure in <xref target="PACEsec"/> in the model of Bellare, Pointcheval, and Rogaway <xref target="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:
<list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list>
The differences in the setting therefore have no impact on the validity of the proof.
</t>
</section>
<section title="Long-Term Credential Storage">
<t>
This protocol does not require peers to store the plaintext password. Instead, the value KPwd SHOULD be stored by both peers.
</t><t>
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.
</t>
</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>
<section title="Acknowledgements">
<t>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.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.2785.xml"?>
<?rfc include="reference.RFC.3454.xml"?>
<?rfc include="reference.RFC.4013.xml"?>
<?rfc include="reference.RFC.5996.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.harkins-ipsecme-pake-criteria.xml"?>
<?rfc include="reference.RFC.5998.xml"?>
<?rfc include="reference.RFC.5282.xml"?>
<?rfc include="reference.RFC.5723.xml"?>
<reference anchor="TR03110">
<front>
<title>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 surname="BSI" fullname="Bundesamt fuer Sicherheit in der Informationstechnik"/>
<date year="2010"/>
</front>
</reference>
<reference anchor="TR03111">
<front>
<title>TR-03111, Elliptic Curve Cryptography, Version 1.11</title>
<author surname="BSI" 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. The extended abstract appeared in Information Security Conference (ISC) 2009, LNCS 5735, pp. 33-48, Springer-Verlag</title>
<author initials="J." surname="Bender" fullname="Jens Bender"/>
<author initials="M." surname="Fischlin" fullname="Marc Fischlin"/>
<author initials="D." surname="Kuegler" fullname="Dennis Kuegler"/>
<date year="2009"/>
</front>
<format type="PDF" target="http://eprint.iacr.org/2009/624"/>
</reference>
<reference anchor="BPRmodel">
<front>
<title>Authenticated Key Exchange Secure against Dictionary Attacks, EUROCRYPT 2000, LNCS 1807, pp. 139–155, Springer-Verlag</title>
<author initials="M." surname="Bellare" fullname="Mihir Bellare"/>
<author initials="D." surname="Pointcheval" fullname="David Pointcheval"/>
<author initials="P." surname="Rogaway" fullname="Phillip Rogaway"/>
<date year="2000"/>
</front>
<format type="PDF" target="http://www.iacr.org/cryptodb/archive/2000/EUROCRYPT/18070139.pdf"/>
</reference>
<reference anchor="ICAO">
<front>
<title>Supplemental Access Control for Machine Readable Travel Documents, version 1.00</title>
<author surname="ISO/IEC JTC1 SC17 WG3/TF5 for ICAO" fullname="ISO/IEC JTC1 SC17 WG3/TF5 for ICAO"/>
<date month="March" year="2010"/>
</front>
</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="-06">
<t>Defined how autheticated-encryption algorithms can be used. Updated references.</t>
</section>
<section toc="exclude" title="-05">
<t>Editorial corrections.</t>
</section>
<section toc="exclude" title="-04">
<t>Editorial corrections.</t>
</section>
<section toc="exclude" title="-03">
<t>Completed the security considerations (security proof). Reordered some sections for clarity.</t>
</section>
<section toc="exclude" title="-02">
<t>Added security considerations. Changed encryption of the nonce. Simplified the derivation of the AUTH payloads.</t>
</section>
<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 04:23:39 |