One document matched: draft-tschofenig-eap-ikev2-15.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY I-D.ietf-eap-keying SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-eap-keying.xml">
<!ENTITY RFC3575 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3575.xml">
<!ENTITY I-D.ietf-pppext-eap-ttls SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pppext-eap-ttls.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="no"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<rfc category="exp" ipr="full3978" docName="draft-tschofenig-eap-ikev2-15.txt">
<front>
<title abbrev="EAP-IKEv2">EAP-IKEv2 Method</title>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization abbrev="Nokia Siemens Networks">Nokia Siemens Networks</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<region>Bavaria</region>
<code>81739</code>
<country>Germany</country>
</postal>
<email>Hannes.Tschofenig@nsn.com</email>
<uri>http://www.tschofenig.com</uri>
</address>
</author>
<author initials="D." surname="Kroeselberg" fullname="Dirk Kroeselberg">
<organization abbrev="Nokia Siemens Networks">Nokia Siemens Networks</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<region>Bavaria</region>
<code>81739</code>
<country>Germany</country>
</postal>
<email>Dirk.Kroeselberg@nsn.com</email>
</address>
</author>
<author initials="A." surname="Pashalidis" fullname="Andreas Pashalidis">
<organization abbrev="NEC">NEC</organization>
<address>
<postal>
<street>Kurfuersten-Anlage 36</street>
<city>Heidelberg</city>
<code>69115</code>
<country>Germany</country>
</postal>
<email>Andreas.Pashalidis@netlab.nec.de</email>
</address>
</author>
<author initials="Y." surname="Ohba" fullname="Yoshihiro Ohba">
<organization abbrev="Toshiba">Toshiba America Research, Inc.</organization>
<address>
<postal>
<street>1 Telcordia Drive</street>
<city>Piscataway</city>
<region>NJ</region>
<code>08854</code>
<country>USA</country>
</postal>
<email>yohba@tari.toshiba.com</email>
</address>
</author>
<author initials="F." surname="Bersani" fullname="Florent Bersani">
<organization abbrev="France Telecom">France Telecom R&D</organization>
<address>
<postal>
<street>38, rue du General Leclerc</street>
<city>Issy-Les-Moulineaux</city>
<region>Cedex</region>
<code>92794</code>
<country>France</country>
</postal>
<email>bersani_florent@yahoo.fr</email>
</address>
</author>
<date year="2007"/>
<!-- <area>Security Area</area>
<workgroup>EAP WG</workgroup> -->
<keyword>Internet-Draft</keyword>
<abstract>
<t> This document specifies EAP-IKEv2, an Extensible Authentication Protocol (EAP)
method that is based on the Internet Key Exchange (IKEv2) protocol. EAP-IKEv2
provides mutual authentication and session key establishment between an EAP peer and
an EAP server. It supports authentication techniques that are based on passwords,
high-entropy shared keys, and public key certificates. EAP-IKEv2 further provides
support for cryptographic ciphersuite negotiation, hash function agility, identity
confidentiality (in certain modes of operation), fragmentation, and an optional
"fast reconnect" mode. EAP-IKEv2 has sucessfully passed Designated Expert Review as
mandated by RFC 3748. </t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t> This document specifies EAP-IKEv2, an EAP method that is based on the Internet Key
Exchange Protocol version 2 (IKEv2) <xref target="IKEv2"/>. The IKEv2 protocol is
also able to carry AP exchanges inside IKEv2 but this method does not inherit the
capabilites to tunnel EAP methods inside this EAP method. EAP-IKEv2 provides mutual
authentication and session key establishment between an EAP peer and an EAP server.
It supports authentication techniques that are based on the following types of
credential. </t>
<t>
<list style="symbols">
<t> Asymmetric key pairs: these are public/private key pairs where the public
key is embedded into a digital certificate, and the corresponding private
key is known only to a single party.</t>
<t> Passwords: these are low-entropy bit strings that are known to both the
server and the peer.</t>
<t> Symmetric keys: these are high-entropy bit strings that known to both the
server and the peer.</t>
</list>
</t>
<t> It is possible to use a different authentication credential (and thereby technique)
for each direction, e.g., the EAP server may authenticate itself using a
public/private key pair and the EAP client may authenticate itself using a symmetric
key. In particular, the following combinations are expected to be used in practice.
These are referred to as "use cases or modes" in the remainder of this document. </t>
<t>
<list style="numbers">
<t> EAP server: asymmetric key pair, EAP peer: asymmetric key pair</t>
<t> EAP server: asymmetric key pair, EAP peer: symmetric key</t>
<t> EAP server: asymmetric key pair, EAP peer: password</t>
<t> EAP server: symmetric key, EAP peer: symmetric key</t>
</list>
</t>
<t> Note that, in use cases 2 and 4, a symmetric key is assumed to be chosen uniformly
at random from its key space; it is therefore assumed that symmetric keys are not
derived from passwords. Deriving a symmetric key from a password is insecure when
used with mode 4 since the exchange is vulnerable to dictionary attacks, as
described in more detail in <xref target="dictattack"/>. Also note that, in use case
3, the EAP server must either have access to all passwords in plaintext, or,
alternatively, for each password store the value prf(password,"Key Pad for
EAP-IKEv2") for all supported pseudorandom functions (also see <xref
target="authpayload"/> below and Section 2.15 of <xref target="IKEv2"/>). Other
conceivable use cases are not expected to be used in practice due to key management
issues, and have not been considered in this document. </t>
<t> The remainder of this document is structured as follows.</t>
<t>
<list style="symbols">
<t>
<xref target="terminology"/> provides an overview of the terminology and the
abbreviations used in this document.</t>
<t>
<xref target="overview"/> provides an overview of the full EAP-IKEv2
exchange and thereby specifies the protocol message composition. </t>
<t>
<xref target="fastrec"/> specifies the optional EAP-IKEv2 "fast reconnect"
mode of operation.</t>
<t>
<xref target="keyderivation"/> specifies how exportable session keys are
derived. </t>
<t>
<xref target="elementexport"/> specifies how the Session-ID, Peer-ID, and
Server-ID elements are derived. </t>
<t>
<xref target="errorhandling"/> specifies how errors that may potentially
occur during protocol execution are handled. </t>
<t>
<xref target="formats"/> specifies the format of the EAP-IKEv2 data fields.
<xref target="flagsfield"/> describes how fragmentation is handled in
EAP-IKEv2. </t>
<t>
<xref target="extensibility"/> specifies the payload type values and
describes protocol extensibility. </t>
<t>
<xref target="sec"/> provides a list of claimed security properties. </t>
</list>
</t>
</section>
<section anchor="terminology" title="Terminology">
<t> This document makes use of terms defined in <xref target="EAP"/> and <xref
target="IKEv2"/>. In addition, the keywords MUST, MUST NOT, REQUIRED, SHALL,
SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in
this document, are to be interpreted as described in <xref target="2119"/>. </t>
<t> A list of abbreviations that are used in this document follows. </t>
<t>
<list style="hanging">
<t hangText="AUTH:"><vspace blankLines="1"/> Denotes a data field containing
either a MAC or a signature. This field is in embedded into an
Authentication payload, defined in <xref target="authpayload"/>. </t>
<t hangText="CERT:"><vspace blankLines="1"/> Public key certificate or similar
structure. </t>
<t hangText="CERTREQ:"><vspace blankLines="1"/> Certificate Request.</t>
<t hangText="NFID:"><vspace blankLines="1"/> Next Fast-ID payload (see <xref
target="nfidpayload"/> and <xref target="fastrec"/>)</t>
<t hangText="EMSK:"><vspace blankLines="1"/> Extended Master Session Key,
defined in <xref target="EAP"/>. </t>
<t hangText="HDR:"><vspace blankLines="1"/> EAP-IKEv2 header, defined in <xref
target="header"/>. </t>
<t hangText="I:"><vspace blankLines="1"/> Initiator, the party that sends the
first message of an EAP-IKEv2 protocol run. This is always the EAP server. </t>
<t hangText="MAC:"><vspace blankLines="1"/> Message Authentication Code. The
result of a cryptographic operation that involves a symmetric key. </t>
<t hangText="MSK:"><vspace blankLines="1"/> Master Session Key, defined in <xref
target="EAP"/>. </t>
<t hangText="prf:"><vspace blankLines="1"/> Pseudorandom function: a
cryptographic function whose output is assumed to be indistinguishable from
that of a truly random function. </t>
<t hangText="R:"><vspace blankLines="1"/> Responder, the party that sends the
second message of an EAP-IKEv2 protocol run. This is always the EAP peer. </t>
<t hangText="SA:"><vspace blankLines="1"/> Security Association. In this
document SA denotes a type of payload that is used for the negotiation of
the cryptographic algorithms that are to be used within an EAP-IKEv2
protocol run. Specifically, SAi denotes a set of choices that are accepted
by an initiator, and SAr denotes the choice of the responder.</t>
<t hangText="Signature:"><vspace blankLines="1"/> The result of a cryptographic
operation that involves an asymmetric key. In particular, it involves the
private part of a public/private key pair. </t>
<t hangText="SK:"><vspace blankLines="1"/> Session Key. In this document, the
notation SK{x} denotes that x is embedded within an Encrypted payload,
i.e.,, that x is encrypted and integrity-protected using EAP-IKEv2 internal
keys. These keys are different in each direction.</t>
<t hangText="SK_xx:"><vspace blankLines="1"/> EAP-IKEv2 internal key, defined in
Section 2.14 of <xref target="IKEv2"/>.</t>
<t hangText="SKEYSEED:"><vspace blankLines="1"/> Keying material, defined in
Section 2.14 of <xref target="IKEv2"/>. </t>
</list>
</t>
</section>
<section anchor="overview" title="Protocol Overview">
<t> In this section, the full EAP-IKEv2 protocol run is specified. All messages are sent
between two parties, namely an EAP peer and an EAP server. In EAP-IKEv2, the EAP
server always assumes the role of the initiator (I), and the EAP peer that of the
responder (R) of an exchange. </t>
<t> The semantics and formats of EAP-IKEv2 messages are similar, albeit not identical,
to those specified in IKEv2 <xref target="IKEv2"/> for the establishment of an IKE
Security Association. The full EAP-IKEv2 protocol run consists of two roundtrips
that are followed by either an EAP-Success or an EAP-Failure message. An optional
roundtrip for exchanging EAP identities may precede the two exchanges. </t>
<t>
<figure anchor="fullsuccess" title="EAP-IKEv2 full, successful protocol run">
<artwork><![CDATA[
1. R<-I: EAP-Request/Identity
2. R->I: EAP-Response/Identity(Id)
3. R<-I: EAP-Req (HDR, SAi, KEi, Ni)
4. R->I: EAP-Res (HDR, SAr, KEr, Nr, [CERTREQ], [SK{IDr}])
5. R<-I: EAP-Req (HDR, SK{IDi, [CERT], [CERTREQ], [NFID], AUTH})
6. R->I: EAP-Res (HDR, SK{IDr, [CERT], AUTH})
7. R<-I: EAP-Success
]]></artwork>
</figure>
</t>
<t>
<xref target="fullsuccess"/> shows the full EAP-IKEv2 protocol run, including the
optional EAP identity exchange (messages 1 and 2). A detailed specification of the
message composition follows.</t>
<t> Messages 1 and 2 are a standard EAP Identity Request and Response, as defined in
<xref target="EAP"/>. Message 3 is the first EAP-IKEv2-specific message. With
this, the server starts the actual EAP authentication exchange. It contains the
initiator SPI in the EAP-IKEv2 header (HDR) (the initiator selects this value on a
per-protocol run basis), the set of cryptographic algorithms the server is willing
to accept for the protection of EAP-IKEv2 traffic (encryption and integrity
protection) and the derivation of the session key. This set is encoded in the
Security Association payload (SAi). It also contains a Diffie-Hellman payload (KEi),
and a Nonce payload (Ni).</t>
<t> When the peer receives message 3, it selects a set of cryptographic algorithms from
the ones that are proposed in the message. In this overview, it is assumed that an
acceptable such set exists (and is thus selected), and that the Diffie-Hellman value
KEi belongs to an acceptable group. The peer then generates a non-zero Responder SPI
value for this protocol run, its own Diffie-Hellman value (KEr) and nonce (Nr), and
calculates the keys SKEYSEED, SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr
according to Section 2.14 of <xref target="IKEv2"/>. The peer then constructs
message 4. In the context of use cases 1, 2 and 3, the peer's local policy MAY
dictate the inclusion of the optional CERTREQ payload in that message, which gives a
hint to the server to include a certificate for its public key in its next message.
In the context of use case 4, the peer MUST include the optional SK{IDr} payload,
which contains its EAP-IKEv2 identifier, encrypted and integrity-protected within an
Encrypted payload. The keys used to construct this Encrypted payload are SK_er (for
encryption) and SK_ar (for integrity protection), in accordance with <xref
target="IKEv2"/>. The responder's EAP-IKEv2 identifier (IDr) is likely to be
needed in these use cases by the server in order to select the correct symmetric key
or password for the construction of the AUTH payload of message 5. </t>
<t> Upon reception of message 4, the server also computes SKEYSEED, SK_d, SK_ai, SK_ar,
SK_ei, SK_er, SK_pi, and SK_pr according to Section 2.14 of <xref target="IKEv2"/>.
If an SK{IDr} payload is included, the server decrypts it and verifies its integrity
with the corresponding keys. In this overview, decryption and verification is
assumed to succeed. The server then constructs message 5 which contains only the
EAP-IKEv2 header followed by a single Encrypted payload. The keys used to generate
the encrypted payload MUST be SK_ei (for encryption) and SK_ai (for integrity
protection), in accordance with <xref target="IKEv2"/>. The initiator MUST embed at
least two payloads in the Encrypted Payload, as follows. An Identification payload
with the initiator's EAP-IKEv2 identifer MUST be embedded in the Encrypted payload.
The Authentication payload MUST be embedded in the Encrypted payload. A Certificate
payload, and/or a Certificate Request payload MAY also be embedded in the Encrypted
payload. Moreover, a Next Fast-Reconnect Identifier payload MAY also be embedded in
the Encrypted payload. Message 5 is sent to the responder.</t>
<t> Upon reception of message 5, the responder (EAP peer) authenticates the initiator
(EAP server). The checks that are performed to this end depend on the use case,
local policies, and are specified in <xref target="IKEv2"/>. These checks include
(but may not be limited to) decrypting the Encrypted payload, verifying its
integrity, and checking that the Authentication payload contains the expected value.
If all checks succeed (which is assumed in this overview), then the responder
constructs message 6. That message MUST contain the EAP-IKEv2 header followed by a
single Encrypted payload, in which at least two further payloads MUST be embedded,
as shown in <xref target="fullsuccess"/>. </t>
<t> Upon reception of message 6, the initiator (EAP server) authenticates the responder
(EAP peer). As above, the checks that are performed to this end depend on the use
case, local policies, and MUST include decryption and verification of the Encrypted
payload, as well as checking that the Authentication payload contains the expected
value. If the optional SK{IDr} payload was included in message 4, the EAP server
MUST also ensure that the IDr payload in message 6 is identical to that in message
4. </t>
<t> If authentication succeeds, an EAP-Success message is sent to the responder as
message 7. The EAP server and the EAP peer generate a Master Session Key (MSK) and
an Extended Master Session Key (EMSK) after a successful EAP-IKEv2 protocol run,
according to <xref target="keyderivation"/>.</t>
</section>
<section anchor="fastrec" title="Fast Reconnect">
<t> This section specifies a "fast reconnect" mode of operation for EAP-IKEv2. This mode
is mandatory to implement, but optional to use. The purpose of fast reconnect is to
enable an efficient re-authentication procedure that also results in a fresh MSK and
EMSK. The "fast reconnect" mode can only be used where an EAP-IKEv2 security context
already exists at both the server and the peer, and its usage is subject to the
local policies. In other words, it can only be used by an EAP server/EAP peer pair
that has already performed mutual authentication in a previous EAP-IKEv2 protocol
run. </t>
<t> The fast reconnect mode makes use of dedicated "fast reconnect EAP identifiers". The
idea is that the server indicates its willingness to engage in "fast reconnect"
protocol runs in the future by including the optional "Next Fast-ID" (NFID) payload
in message 5 of a "full" protocol run (see <xref target="fullsuccess"/>), or in
message 3 of a "fast reconnect" protocol run (see <xref target="fast"/>). This NFID
payload contains a special EAP identity, denoted Fast Reconnect Identity (FRID) as
the NAI in the EAP-Response/Identity message. The FRID contains an obfuscated
username part and a realm part. When generating a FRID the following aspects should
be considered:</t>
<t>
<list style="empty">
<t> The FRID and therefore the pseudonym usernames are generated by the EAP
server. The EAP server produces pseudonym usernames in an
implementation-dependent manner. Only the EAP server needs to be able to map
the pseudonym username to the permanent identity. </t>
<t> EAP-IKEv2 includes no provisions to ensure that the same EAP server that
generated a pseudonym username will be used on the authentication exchange
when the pseudonym username is used. It is recommended that the EAP servers
implement some centralized mechanism to allow all EAP servers of the home
operator to map pseudonyms generated by other severs to the permanent
identity. If no such mechanism is available, then the EAP server, failing to
understand a pseudonym issued by another server, can request the peer to
send the permanent identity. </t>
<t> When generating FRIDs, the server SHOULD choose a fresh and unique FRID that
is different from the previous ones that were used after the same full
authentication exchange. The FRID SHOULD include a random component in the
username part. The random component works as a reference to the security
context. Regardless of the construction method, the pseudonym username MUST
conform to the grammar specified for the username portion of an NAI. Also,
the FRID MUST conform to the NAI grammar <xref target="NAI"/>. The EAP
servers, which subscribers of an operator can use, MUST ensure that the
username part of a FRIDs that they generate are unique. </t>
</list>
</t>
<t> The peer MAY use the FRID to indicate to start a "fast reconnect" protocol run. The
EAP Identity Response MUST be sent at the beginning of a "fast reconnect" protocol
run. If, in the previous successful "full" EAP-IKEv2 protocol execution, the server
had not included an NFID payload in message 5 (resp. 3), then the peer MUST NOT
start a fast reconnect protocol run. On reception of FRID, the server maps it to an
existing EAP-IKEv2 security context. Depending on local policy, the server either
proceeds with the "fast reconnect" protocol run, or proceeds with message 3 of a
"full" protocol run. If the server had advertised the FRID in the previous EAP-IKEv2
protocol execution, it SHOULD proceed with a "fast reconnect" protocol run. The peer
MUST be able to correctly handle a message 3 of a "full" protocol run, even if it
indicated a FRID in its EAP Identity Response. </t>
<t> Because the peer may fail to save a FRID that was sent in the NFID payload (for
example, due to malfunction), the EAP server SHOULD maintain, at least, the most
recently used FRID in addition to the most recently issued FRID. If the
authentication exchange is not completed successfully, then the server MUST NOT
overwrite the FRID that was issued during the most recent successful authentication
exchange.</t>
<t> The EAP-IKEv2 fast reconnect exchange is similar to the IKE-SA rekeying procedure as
specified in Section 2.18 of <xref target="IKEv2"/>. Thus, it uses a CREATE_CHILD_SA
request and response. The SPIs on those two messages would be the SPI's negotiated
on the previous exchange. During fast reconnect, the server and the peer MAY
exchange fresh Diffie-Hellman values. </t>
<t>
<figure anchor="fast" title="Fast Reconnect Protocol Run">
<artwork><![CDATA[
1. R<-I: EAP-Request/Identity
2. R->I: EAP-Response/Identity(FRID)
3. R<-I: EAP-Req(HDR, SK{SA, Ni, [KEi], [NFID]})
4. R->I: EAP-Res(HDR, SK{SA, Nr, [KEr]})
5. R<-I: EAP-Success
]]></artwork>
</figure>
</t>
<t>
<xref target="fast"/> shows the message exchange for the EAP-IKEv2 fast reconnect
mode. As in the full mode, the EAP server is the initiator and the EAP peer is the
responder. The first two messages constitute the standard EAP identity exchange.
Note that, in order to use the "fast reconnect" mode, message 2 MUST be sent. This
is in order to enable the peer to indicate its "fast reconnect" identity FRID in
message 2. If the server can map the FRID to an existing EAP-IKEv2 context it
proceeds with message 3. Note that, in this message, the server MAY embed a NFID
payload into the encrypted payload to provide a new FRID to the peer. The server MAY
choose to perform a full EAP-IKEv2 run, in which case it would respond with a
message that conforms to the format of message 3 in <xref target="fullsuccess"/>. </t>
<t> Messages 3 and 4 establish a new EAP-IKEv2 security context. In message 3, the
initiator MUST select a new (non-zero) value for the SPI field in each proposal
substructure in the SA payload (see Section 3.3 of <xref target="IKEv2"/>). The
value of the IKE_SA Responder's SPI field in HDR MUST be the one from the previous
successful EAP-IKEv2 protocol run. The nonce inside the Nonce payload (Ni) MUST be
fresh, and the Diffie-Hellman value inside the Diffie-Hellman payload (if present,
KEi) MUST also be fresh. If present, the Diffie-Hellman value MUST be drawn from the
same group as the Diffie-Hellman value in the previous successful full EAP-IKEv2
protocol run. Note that the algorithms and keys that are used to construct the
Encrypted payload in message 3, are the same as in the previous successful EAP-IKEv2
protocol run.</t>
<t> Upon reception of message 3, the responder (EAP peer) decrypts and verifies the
Encrypted payload. If successful (as assumed in <xref target="fast"/>), it
constructs message 4 in a fashion similar to the construction of message 3. The
responder MUST choose a new (non-zero) value for the SPI field in each proposal
substructure. Upon reception of message 4, the initiator (EAP server) decrypts and
verifies the Encrypted payload.
<!-- If the server does not receive message 4 within a
reasonable amount of time, then it MAY resend message 3 up to a predetermined amount
of times before deeming re-authentication to have failed.-->
If a correct message 4 is received, then this protocol run is deemed successful, and
the server responds with an EAP-Success message (message 5). </t>
<t> After successful EAP-IKEv2 fast reconnect protocol run, both the initiator and the
responder generate fresh keying material, that is used for the protection of
subsequent EAP-IKEv2 traffic. Furthermore, both the initiator and the responder MUST
generate a fresh MSK and EMSK and export them. </t>
<t> The new EAP-IKEv2-specific keying material is computed in the same way as in the
full EAP-IKEv2 protocol run, and in accordance with Section 2.18 of <xref
target="IKEv2"/>. That is, SKEYSEED is computed as SKEYSEED = prf(SK_d (old),
[g^ir (new)] | Ni | Nr), where SK_d (old) is the key SK_d from the previous
successful EAP-IKEv2 protocol run, Ni and Nr are the nonces (without the Nonce
payload headers) that were exchanged in messages 3 and 4, and g^ir (new) is the
newly computed Diffie-Hellman key, if both the values KEi and KEr were present in
messages 3 and 4. The remaining EAP-IKEv2-specific keys (SK_d, SK_ai, SK_ar, SK_ei,
SK_er, SK_pi, and SK_pr) are generated as in the full EAP-IKEv2 protocol run.</t>
<t> The generation of a fresh MSK and EMSK follows the generation of the
EAP-IKEv2-specific keys and adheres to the rules in <xref target="keyderivation"/>. </t>
<t> Note 1: In EAP-IKEv2, the EAP server initiates the fast reconnect mode and thereby
causes fresh session keys to be established.</t>
<t> Note 2: It is conceivable that an adversary tries to launch a replay attack against
the EAP-IKEv2 fast reconnect mode of operation. In particular, the adversary may try
to send a previously captured message 3 in a subsequent fast reconnect protocol run.
This replay attempt will, however, fail because the keys that the responder will use
to verify and decrypt the Encrypted payload are changed with every successful
reconnect protocol run. </t>
</section>
<section anchor="keyderivation" title="Key Derivation">
<t> This section describes how the Master Session Key (MSK) and the Extended Master
Session Key (EMSK) are derived in EAP-IKEv2. It is expected that the MSK and the
EMSK are exported by the EAP-IKEv2 process and be used in accordance with the EAP
keying framework <xref target="I-D.ietf-eap-keying"/>. </t>
<t> During an EAP-IKEv2 protocol run, the initiator and the responder generate a number
of keys, as described above and in accordance with Section 2.14 of <xref
target="IKEv2"/>. The generation of these keys is based on a pseudorandom
function (prf) that both parties have agreed to use and which is applied in an
iterative fashion. This iterative fashion is specified in Section 2.13 of <xref
target="IKEv2"/> and is denoted by prf+. </t>
<t> In particular, following a successful EAP-IKEv2 protocol run, both parties generate
128 octets of keying material, denoted KEYMAT, as KEYMAT = prf+(SK_d, Ni | Nr),
where Ni and Nr are the nonces (just payload without headers) from messages 3 and 4
shown in <xref target="fullsuccess"/> (in the context of a full EAP-IKEv2 protocol
run) or <xref target="fast"/> (in the context of a fast reconnect EAP-IKEv2 protocol
run). Note that only the nonces are used, i.e., not the entire Nonce payload that
contains them. </t>
<t> The first 64 octets of KEYMAT are exported as the EAP MSK, and the second 64 octets
are exported as the EMSK.</t>
<t> The MSK and EMSK MUST NOT be generated unless an EAP-IKEv2 protocol run completes
successfully. Note that the EAP-IKEv2 method does not produce an initialisation
vector <xref target="I-D.ietf-eap-keying"/>. </t>
</section>
<section anchor="elementexport" title="Session ID, Peer ID, and Server ID">
<t> The EAP key management framework <xref target="I-D.ietf-eap-keying"/> requires that
EAP methods export three information elements, called the Session-ID, the Peer-ID,
and the Server-ID. In EAP-IKEv2 these elements are derived as follows.</t>
<t>
<list style="symbols">
<t> The Session-ID is constructed and exported as the concatenation of the
following three elements, in this order: (a) the EAP Code Type for EAP-IKEv2
(to be defined by IANA), (b) the contents of the Nonce Data field of the
Nonce Payload Ni from message 3, (c) the contents of the Nonce Data field of
the Nonce Payload Nr from message 4.</t>
<t> In case of a full EAP-IKEv2 protocol run, the Peer-ID is constructed and
exported as the content of the Identification Data field of the
Identification Payload IDr from message 6. Note that only the "actual"
identification data is exported, as indicated in the Payload Length field;
if the Identification Data field contains any padding, this padding is
ignored. In case of a "fast reconnect" protocol run, the Peer-ID field is
constructed in exactly the same manner, where message 6 refers to the full
EAP-IKEv2 protocol run that originally established the security context
between the EAP peer and EAP server. </t>
<t> In case of a full EAP-IKEv2 protocol run, the Server-ID is constructed and
exported as the contents of the Identification Data field of the
Identification Payload IDi from message 5. Note that only the "actual"
identification data is exported, as indicated in the Payload Length field;
if the Identification Data field contains any padding, this padding is
ignored. In case of a "fast reconnect" protocol run, the Server-ID field is
constructed in exactly the same manner, where message 5 refers to the full
EAP-IKEv2 protocol run that originally established the security context
between the EAP peer and EAP server. </t>
</list>
</t>
</section>
<section anchor="errorhandling" title="Error Handling">
<t> This section specifies how errors are handled within EAP-IKEv2. For conveying error
information from one party to the other, the Notify payload is defined and used (see
<xref target="notifypayload"/>). </t>
<t> If, in a full EAP-IKEv2 protocol run, authentication fails (i.e., the verification
of the AUTH field fails at the server or the peer), but no other errors have
occurred, the message flow deviates from that described in <xref target="overview"
/>. The message flows in the presence of authentication failures are specified in
<xref target="failedruns"/>. </t>
<t> If, in message 3 of a full EAP-IKEv2 protocol run (see <xref target="fullsuccess"
/>), the responder receives a Diffie-Hellman value (KEi) that belongs to a group
that is not supported (and in the absence of other errors), then the responder MUST
send a message of the form shown in <xref target="wrongdh"/> to the initiator. This
effectively becomes message 4 in the full protocol run.</t>
<t>
<figure anchor="wrongdh" title="Error handling in case of unsupported D-H value">
<artwork><![CDATA[
1. R<-I: EAP-Request/Identity
2. R->I: EAP-Response/Identity(Id)
3. R<-I: EAP-Req (HDR, SAi, KEi, Ni)
4. R->I: EAP-Res (HDR, N(INVALID_KE_PAYLOAD))
]]></artwork>
</figure>
</t>
<t> The above message consists of the EAP-IKEv2 header and a Notification payload with
the value of the Notify Message Type field value set to 17 (INVALID_KE_PAYLOAD).
There are two octets of data associated with this notification: the number of the
selected DH Group in big endian order, as specified in Section 3.10.1 of <xref
target="IKEv2"/>. This number MUST represent a DH group that is supported by
both the initiator and the responder. </t>
<t> If, during a full EAP-IKEv2 protocol run (see <xref target="fullsuccess"/>), the
initiator receives a message conforming to <xref target="wrongdh"/> instead of the
usual message 4, then it MUST check whether or not the indicated DH group was
proposed in message 3. If it was not, then the initiator MUST silently discard the
message. Otherwise, the protocol continues with a new message 3 that the initiator
sends to the peer. In this new message 3 the initiator MUST use a Diffie-Hellman
value that is drawn from the group that is indicated in the Notify payload of
message 4 in <xref target="wrongdh"/>.
<!-- If the error persists (e.g., no "normal"
message 4 is received after a predetermined number of retransmissions of message 3),
then the initiator MUST give up with an EAP-Failure message.-->
</t>
<t> If, in the context of use case 4 and during a full EAP-IKEv2 protocol run (see <xref
target="fullsuccess"/>), the initiator receives, in message 4, an SK{IDr}
payload that decrypts to a non-existent or unauthorised EAP-IKEv2 responder
identifier IDr*, then the server SHOULD continue the protocol with a message
conforming to the format of message 5. The AUTH payload in that message SHOULD
contain a value that is computationally indistinguishable from a value that it would
contain if IDr* was valid and authorised. This can be accomplished, for example, by
generating a random key and calculate AUTH as usual (however, this document does not
mandate a specific mechanism). Only after receiving message 6, the server SHOULD
respond with an authentication failure notification, i.e., a message conforming to
message 6 in <xref target="fullsauthfailed"/>. The purpose of this behaviour is to
prevent an adversary from probing the EAP-IKEv2 peer identifier space. </t>
<t> If, in the context of use cases 1, 2, or 3 and during a full EAP-IKEv2 protocol run
(see <xref target="fullsuccess"/>), the initiator receives, in message 4, an SK{IDr}
payload that decrypts to an EAP-IKEv2 responder identifier IDr*, then the server
MUST continue the protocol as usual (note that such a payload would not be required
in these use cases). The server MUST compare IDr* with the IDr received in message 6
and, in case of a mismatch, MUST respond with an authentication failure
notification, i.e., a message conforming to message 6 in <xref
target="fullsauthfailed"/>. If no mismatch is detected, normal processing
applies.</t>
<t> Other errors do not trigger messages with Notification payloads to be sent, and MUST
be treated as if nothing happened (i.e., the erroneous EAP-IKEv2 packet MUST be
silently discarded). This includes situations where at least one of the following
conditions is met, with respect to an incoming EAP-IKEv2 packet.</t>
<t>
<list style="symbols">
<t> The packet contains an Encrypted payload that, when decrypted with the
appropriate key, yields an invalid decryption. </t>
<t> The packet contains an Encrypted payload with a Checksum field that does not
verify with the appropriate key.</t>
<t> The packet contains an Integrity Checksum Data field (see <xref
target="genformat"/>) that is incorrect.</t>
<t> The packet does not contain a compulsory field. </t>
<t> A field in the packet contains an invalid value (e.g., an invalid
combination of flags, a length field that is inconsistent with the real
length of the field or packet, or the responder's choice of a cryptographic
algorithm is different to NONE and any of those that were offered by the
initiator). </t>
<t> The packet contains an invalid combination of fields (e.g., it contains two
or more Notify payloads with the same Notify Message Type value, or two or
more Transform substructures with the same Transform Type and Transform ID
value).</t>
<t> The packet causes a defragmentation error. </t>
<t> The format of the packet is invalid.</t>
<t> The identity provided by the EAP peer in the EAP-Response/Identity cannot be
associated with either an established security context (in case of a fast
reconnect) or with a real user account (in case of a full protocol exchange)
then the packet is silently discarded. With an outstanding message from the
EAP server the client may either retransmit the previous request or, in case
of a fast reconnect, assume that state information was deleted (e.g., due to
garbage collection) at the EAP server and to fall back to a previously used
FRID or to the full protocol exchange. </t>
</list>
</t>
<t> If an incoming packet contains an error for which behaviour is specified in this
section, and an error that, in the absence of the former error, would cause the
packet to be silently discarded, then the packet MUST be silently discarded. </t>
</section>
<section anchor="formats" title="Specification of Protocol Fields">
<t> In this section, the format of the EAP-IKEv2 data fields and applicable processing
rules are specified. <xref target="genformat"/> shows the general packet format of
EAP-IKEv2 messages, and the embedding of EAP-IKEv2 into EAP. The EAP-IKEv2 messages
are embedded in the Data field of the standard EAP Request/Response packets. The
Code, Identifier, Length and Type fields are described in <xref target="EAP"/>. The
EAP Type for this EAP method is TBD by IANA. </t>
<t>
<figure anchor="genformat" title="General packet format of EAP-IKEv2">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | HDR + payloads ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Checksum Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t> The Flags field is always present and is used for fragmentation support, as
described in <xref target="flagsfield"/>. The Message Length field is not always
present; it's presence is determined by a certain flag in the Flags field, as
described in <xref target="flagsfield"/>. The field denoted as "HDR + payloads" in
<xref target="genformat"/> contains the EAP-IKEv2 header (see <xref
target="header"/>), followed by a number of payloads, in accordance with the
composition of EAP-IKEv2 messages, as described in the previous sections. Note that
each payload begins with a generic payload header that is specified in Section 3.2
of <xref target="IKEv2"/>. </t>
<t> The Integrity Checksum Data field is not always present; its presence is determined
by a certain flag in the Flags field, as described in <xref target="flagsfield"/>. </t>
<t> In the remainder of this section, the protocol fields that are used in EAP-IKEv2 are
specified. This specification heavily relies on the IKEv2 specification <xref
target="IKEv2"/>, and many fields are constructed, formatted and processed in
way that is almost identical to that in IKEv2. However, certain deviations from
standard IKEv2 formatting and processing exist. These deviations are highlighted in
the remainder of this section.</t>
<section anchor="flagsfield"
title="The Flags, Message Length, and Integrity Checksum Data fields">
<t> This section describes EAP-IKEv2 fragmentation, and specifies the encoding and
processing rules for the Flags, Message Length, and Integrity Checksum Data
field shown in <xref target="genformat"/>. </t>
<t> Fragmentation support in EAP-IKEv2 is provided by the Flags and Message Length
fields shown in <xref target="genformat"/>. These are encoded and used as
follows.</t>
<t>
<figure anchor="fragsup" title="Flags field">
<artwork><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|L M I 0 0 0 0 0|
+-+-+-+-+-+-+-+-+
L = Length included
M = More fragments
I = Integrity Checksum Data included
]]></artwork>
</figure>
</t>
<t> The Flags field is defined in <xref target="fragsup"/>. Only the first three
bits (0-2) are used; all remaining bits MUST be set to zero and and ignored on
receipt. The L flag indicates the presence of a Message Length field, and the M
flag indicates whether or not the current EAP message has more fragments. In
particular, if the L bit is set, then a Message Length field MUST be present in
the EAP message, as shown in <xref target="genformat"/>. The Message Length
field is four octets long and contains the length of the entire message (i.e.,
the length of the EAP Data field.). Note that, in contrast, the Length field
shown in <xref target="genformat"/> contains the length of only the current
fragment. (Note that there exist two fields that are related to length: the
Length field, which is a generic EAP field, and the Message Length field, which
is an EAP-IKEv2-specific field.) If the L bit is not set, then the Message
Length field MUST NOT be present.</t>
<t> The M flag MUST be set on all fragments except the last one. In the last
fragment, the M flag MUST NOT be set. Reliable fragment delivery is provided by
the retransmission mechanism of EAP. </t>
<t> The Integrity Checksum Data field contains a cryptographic checksum that covers
the entire EAP message, starting with the Code field, and ending at the end of
the EAP Data field. This field, shown in <xref target="genformat"/>, is present
only if the I bit is set in the Flags field. The Integrity Checksum Data field
immediately follows the EAP Data field without padding. </t>
<t> Whenever possible, the Integrity Checksum Data field MUST be present (and the I
bit set) for each fragment, including the case where the entire EAP-IKEv2
message is carried in a single fragment. The algorithm and keys that are used to
compute the Integrity Checksum Data field MUST be identical to those used to
compute the Integrity Checksum Data field of the Encrypted Payload (see <xref
target="encpayload"/>). That is, the algorithm and keys that were negotiated
and established during this EAP-IKEv2 protocol run are used. Note that this
means that different keys are used to compute the Integrity Checksum Data field
in each direction. Also note that, for messages where this algorithm and the
keys are not yet established, the Integrity Checksum Data field cannot be
computed and is therefore not included. This applies, for example, to messages 3
and 4 in <xref target="fullsuccess"/>. </t>
<t> In order to minimize the exposure to denial-of-service attacks on fragmented
packets, messages that are not protected with an Integrity Checksum Data field
SHOULD NOT be fragmented. Note, however, that those packets are not likely to be
fragmented anyway since they do not carry certificates. </t>
</section>
<section anchor="header" title="EAP-IKEv2 header">
<t> The EAP-IKEv2 header, denoted HDR in this specification, is constructed and
formatted according to the rules specified in Section 3.1 of <xref
target="IKEv2"/>. </t>
<t> In the first EAP-IKEv2 message that is sent by the initiator (message 3 in <xref
target="fullsuccess"/>), the IKE_SA Responder's SPI field is set to zero.
This is because, at this point in time, the initiator does not know what SPI
value the responder will choose for this protocol run. In all other messages,
both SPI fields MUST contain non-zero values that reflect the initiator and
responder-chosen SPI values. </t>
<t> In accordance with <xref target="IKEv2"/>, for this version of EAP-IKEv2, the
MjVer (major version) and MnVer (minor version) fields in the header MUST be 2
and 0 respectively. The value of the Exchange Type field MUST be set to 34
(IKE_SA_INIT) in messages 3 and 4, and to 35 (IKE_SA_AUTH) in messages 5 and 6
in <xref target="fullsuccess"/>. In messages 3 and 4 in <xref target="fast"/>
this value MUST be set to 36 (CREATE_CHILD_SA). </t>
<t> The Flags field of the EAP-IKEv2 header is also constructed according to Section
3.1 of <xref target="IKEv2"/>. Note that this is not the same field as the Flags
field shown in <xref target="genformat"/>. </t>
<t> The Message ID field is constructed as follows. Messages 3 and 4 in a full
protocol run MUST carry Message ID value 0. Messages 5 and 6 in a full protocol
run (see Figure 1) MUST carry Message ID value 1. Messages 3 and 4 in a fast
reconnect protocol run MUST carry Message ID value 2.</t>
</section>
<section anchor="sapayload" title="Security Association Payload">
<t> The SA payload is used for the negotiation of cryptographic algorithms between
the initiator and the responder. The rules for its construction adhere to <xref
target="IKEv2"/>, in particular sections 2.7 and 3.3. </t>
<t> In EAP-IKEv2, all Proposal Substructures in the SA payload MUST carry Protocol
ID value 1 (IKE).</t>
</section>
<section anchor="kepayload" title="Key Exchange Payload">
<t> The Key Exchange payload, denoted KEi if constructed by the initiator and KEr if
constructed by the responder, is formatted according to the rules specified in
Section 3.4 of <xref target="IKEv2"/>. </t>
</section>
<section anchor="npayload" title="Nonce Payload">
<t> The Nonce payload, denoted Ni if constructed by the initiator and Nr if
constructed by the responder, is constructed and formatted according to the
rules specified in Section 3.9 of <xref target="IKEv2"/>. </t>
</section>
<section anchor="idpayload" title="Identification Payload">
<t> The Identification payload, denoted IDi if it contains an identifier for the
initiator and IDr if it contains an identifier for the responder, is constructed
and formatted according to the rules specified in Section 3.5 of <xref
target="IKEv2"/>. </t>
</section>
<section anchor="certpayload" title="Certificate Payload">
<t> The Certificate payload, denoted CERT, is constructed and formatted according to
the rules specified in Section 3.6 of <xref target="IKEv2"/>. Note that certain
certificate encodings for the EAP server certificate, e.g., those that need to
be resolved via another network protocol, cannot be used in some typical
EAP-IKEv2 deployment scenarios. A user, for example, that authenticates himself
by means of EAP-IKEv2 in order to obtain network access, cannot resolve the
server certificate at the time of EAP-IKEv2 protocol execution. </t>
</section>
<section anchor="certreqpayload" title="Certificate Request Payload">
<t> The Certificate payload, denoted CERTREQ, is constructed and formatted according
to the rules specified in Section 3.7 of <xref target="IKEv2"/>. </t>
</section>
<section anchor="encpayload" title="Encrypted Payload">
<t> The Encrypted payload, denoted SK{...}, is constructed and formatted according
to the rules specified in Section 3.14 of <xref target="IKEv2"/>. </t>
</section>
<section anchor="authpayload" title="Authentication Payload">
<t> The Authentication payload, denoted AUTH, is constructed and formatted according
to the rules specified in Section 2.15 and Section 3.8 of <xref target="IKEv2"
/>. </t>
<t> The contents of the Authentication payload depend on which party generates this
field, the use case, and the algorithm that corresponds to the credential
(asymmetric key, symmetric key, or password) that this party uses to
authenticate itself. The Authentication payload contains either a MAC or a
signature. </t>
<t> If the party that generates the Authentication payload authenticates itself
based on a shared secret (i.e., a password or a symmetric key), then the
Authentication payload MUST contain a MAC. This MAC is calculated using a key
that is derived from the shared secret, according to Section 2.15 of <xref
target="IKEv2"/>. According to that section, the shared secret is padded
with the string "Key Pad for IKEv2" as part of this key derivation. For the
EAP-IKEv2 method, this rule is overridden, in that the padding string is
redefined as "Key Pad for EAP-IKEv2". The latter padding string MUST be used for
the derivation of the MAC key from a shared secret in the context of EAP-IKEv2.
This is done in order to avoid the same MAC key to be used for both IKEv2 and
EAP-IKEv2 in scenarios where the same shared secret is used for both. Note that
using a shared secret (e.g., a password) in the context EAP-IKEv2 that is
identical or similar to a shared secret that is used in another context
(including IKEv2) is nevertheless NOT RECOMMENDED.</t>
</section>
<section anchor="notifypayload" title="Notify Payload">
<t> The Notify payload, denoted N(...), is constructed and formatted according to
the rules specified in Section 3.10 of <xref target="IKEv2"/>. The Protocol ID
field of this payload MUST be set to 1 (IKE_SA). </t>
</section>
<section anchor="nfidpayload" title="Next Fast-ID Payload">
<t> The Next Fast-ID Payload is defined as follows. </t>
<t>
<figure anchor="nfidp" title="NFID payload format">
<artwork><![CDATA[
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Fast-Reconnect-ID (FRID) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t> The Next Fast-ID payload, denoted NFID, does not have an equivalent in IKEv2.
Nevertheless, the Next Payload, C, RESERVED, and Payload Length fields of this
payload are constructed according to Section 3.2 of <xref target="IKEv2"/>. The
payload ID is registered in <xref target="iabcs"/>. The Fast-Reconnect-ID field
contains a fast reconnect identifer that the peer can use in the next fast
reconnect protocol run, as described in <xref target="fastrec"/>. In
environments where a realm portion is required, Fast-Reconnect-ID includes both
a username portion and a realm name portion. The Fast-Reconnect-ID MUST NOT
include any terminating null characters. The encoding of the Fast-Reconnect-ID
field MUST follow the NAI format <xref target="NAI"/>. </t>
</section>
</section>
<section anchor="extensibility" title="Payload Types and Extensibility">
<t> In EAP-IKEv2, each payload is identified by means of a type field which, as
specified in <xref target="IKEv2"/>, is indicated in the "Next Payload" field of the
preceding payload. However, the identifer space from which EAP-IKEv2 payload types
are drawn is independent from the payload type space of IKEv2. This is because
EAP-IKEv2 and IKEv2 may evolve in a different way and, as such, payload types that
appear in one protocol do not necessary appear in the other. An example of this is
the "Next Fast-ID" (NFID) payload which does not exist in IKEv2.</t>
<t> The values for the payload types defined in this document are listed in <xref
target="iabcs"/>. Payload type values 13-127 are reserved to IANA for future
assignment in EAP-IKEv2. Payload type values 128-255 are for private use among
mutually consenting parties. </t>
</section>
<section anchor="sec" title="Security Considerations">
<t> As mentioned in <xref target="overview"/>, in EAP-IKEv2, the EAP server always
assumes the role of the initiator (I), and the EAP peer takes on the role of the
responder (R) of an exchange. This is in order to ensure that, in scenarios where
the peer authenticates itself based on a password (i.e., in use case 3), operations
that involve this password only take place after the server has been successfully
authenticated. In other words, this assignment of initiator and responder roles
results in protection against offline dictionary attacks on the password that is
used by the peer to authenticate itself (see <xref target="dictattack"/>). </t>
<t> In order for two EAP-IKEv2 implementations to be interoperable, they must support at
least one common set of cryptographic algorithms. In order to promote
interoperability, EAP-IKEv2 implementations MUST support the following algorithms
based on the "MUST/MUST-" recommendations given in <xref target="cryptomust"/>:</t>
<t>
<figure>
<artwork><![CDATA[
Diffie-Hellman Groups: 1024 MODP Group
IKEv2 Transform Type 1 Algorithms: ENCR_3DES
IKEv2 Transform Type 2 Algorithms: PRF_HMAC_SHA1
IKEv2 Transform Type 3 Algorithms: AUTH_HMAC_SHA1_96
]]></artwork>
</figure>
</t>
<t>All other options of <xref target="cryptomust"/> MAY be implemented.</t>
<t> The remainder of this section describes EAP-IKEv2 in terms of specific security
terminology as required by <xref target="EAP"/>. The discussion makes reference to
the use cases defined in <xref target="introduction"/>. </t>
<section toc="no" anchor="ciphersuite" title="Protected Ciphersuite Negotiation">
<t> In message 3, the EAP server provides the set of ciphersuites it is willing to
accept in an EAP-IKEv2 protocol run. Hence, the server is in control of the
ciphersuite. An EAP peer that does not support any of the indicated ciphersuites
is not able to authenticate. The local security policy of the peer MUST specify
the set of ciphersuites that the peer accepts. The server MUST verify that the
ciphersuite that is indicated as being chosen by the peer in message 4, belongs
to the set of ciphersuites that were offered in message 3. If this verification
fails, the server MUST silently discard the packet. </t>
</section>
<section toc="no" anchor="mutualauth" title="Mutual Authentication">
<t> EAP-IKEv2 supports mutual authentication. </t>
</section>
<section toc="no" anchor="intprot" title="Integrity Protection">
<t> EAP-IKEv2 provides integrity protection of EAP-IKEv2 traffic. This protection is
offered after authentication is completed and is facilitated by inclusion of two
Integrity Checksum Data fields: one at the end of the EAP packet (see <xref
target="genformat"/>), and one as part of an Encrypted payload (see <xref
target="encpayload"/>). </t>
</section>
<section toc="no" anchor="replayprot" title="Replay Protection">
<t> EAP-IKEv2 provides protection against replay attacks by a variety of means. This
includes the requirement that the Authentication payload is computed as a
function of, among other things, a server-provided nonce and a peer-provided
nonce. These nonces are required to be practically unpredictable by an
adversary. Assuming that the algorithm that is used to compute the
Authentication payload does not contain cryptographic weaknesses, the
probability that an Authentication payload that is valid in a particular
protocol run, will also be valid in a subsequent run, is therefore negligible. </t>
</section>
<section toc="no" anchor="confidentiality" title="Confidentiality">
<t> EAP-IKEv2 provides confidentiality of certain EAP-IKEv2 fields, namely those
included in Encrypted payloads. With respect to identity confidentiality, the
following claims are made. Note that identity confidentiality refers to the
EAP-IKEv2 identity of the EAP peer.</t>
<t> Identity confidentiality is provided in the face of a passive adversary, i.e.,
an adversary that does not modify traffic as it is in transit. Whenever the
optional SK{IDr} payload in message 4 of a full EAP-IKEv2 protocol (see <xref
target="fullsuccess"/>) is not included, identity confidentiality is also
provided in the face of an active adversary. This payload MUST NOT be included
in use cases 1, 2, and 3. In use case 4 this payload MUST be included.
Therefore, in use case 4, EAP-IKEv2 does not provide identity confidentiality in
the face of an active adversary.</t>
<t>Note, however, that the EAP peer provides it's identity in message 2 in <xref
target="fullsuccess"/> in cleartext. In order to provide identity
confidentiality as discussed in the previous paragraphs it is necessary to
obfuscated the username part of the identity (the realm part must stay intact to
allow correct message routing by the AAA infrastructure). The EAP server then
uses the identity information in message 4. The same mechanism is also used by
other EAP methods to provide identity confidentiality, for example EAP-TTLS
<xref target="I-D.ietf-pppext-eap-ttls"/>. </t>
</section>
<section toc="no" anchor="kstr" title="Key Strength">
<t> EAP-IKEv2 supports the establishment of session keys (MSK and EMSK) of a variety
of key strengths, with the theoretical maximum at 512 bits per key (since this
is the size of the MSK and the EMSK). However, in practice the effective key
strength is likely to be significantly lower, and depends on the authentication
credentials used, the negotiated ciphersuite (including the output size of the
pseudorandom function), the Diffie-Hellman group used, and on the extent to
which the assumptions on which the underlying cryptographic algorithms depend
really hold. Of the above mechanisms, the one that offers the lowest key
strength can be regarded as a measure of the effective key strength of the
resulting session keys. Note that this holds for other EAP methods, too.</t>
<t> Due to the large variety of possible combinations, no indication of a practical
effective key strength for MSK or EMSK is given here. However, those responsible
for the deployment of EAP-IKEv2 in a particular environment should consider the
threats this environment may be exposed to, and configure the EAP-IKEv2 server
and peer policies and authentication credentials such that the established
session keys are of a sufficiently high effective key strength.</t>
</section>
<section toc="no" anchor="dictattack" title="Dictionary Attack Resistance">
<t> EAP-IKEv2 can be used in a variety of use cases, as explained in <xref
target="introduction"/>. In some of these uses cases, namely use case 1, 2,
and 4, dictionary attacks cannot be launched since no passwords are used. In use
case 3, EAP-IKEv2 provides protection against offline dictionary attacks, since
operations that involve the password are executed only after the server has
authenticated itself (based on a credential other than a password). </t>
<t> In order to reduce exposure against online dictionary attacks, in use case 3,
the server SHOULD provide the capability to log failed peer authentication
events, and SHOULD implement a suitable policy in case of consecutive failed
peer authentication attempts within a short period of time (such as responding
with an EAP-Failure instead of message 5 for a predetermined amount of time).</t>
<t>When passwords are used with method 4 (instead of using an key with high entropy)
then dictionary attacks are possible, as described in Section 8 of <xref
target="IKEv2"/>:</t>
<t>
<list style="empty">
<t>" When using pre-shared keys, a critical consideration is how to assure
the randomness of these secrets. The strongest practice is to ensure
that any pre-shared key contain as much randomness as the strongest key
being negotiated. Deriving a shared secret from a password, name, or
other low-entropy source is not secure. These sources are subject to
dictionary and social engineering attacks, among others. " </t>
</list>
</t>
<t>Hence, the usage of passwords with mode 4 where the EAP peer and the EAP server
rely on a shared secret that was derived from a password is insecure. It is
strongly recommended to use mode 3 when passwords are used by the EAP peer. </t>
</section>
<section toc="no" anchor="fastr" title="Fast Reconnect">
<t> EAP-IKEv2 supports a "fast reconnect" mode of operation, as described in <xref
target="fastrec"/>.</t>
</section>
<section toc="no" anchor="crbinding" title="Cryptographic Binding">
<t> EAP-IKEv2 is not a tunnel EAP method. Thus, cryptographic binding does not apply
to EAP-IKEv2.</t>
</section>
<section toc="no" anchor="sessionind" title="Session Independence">
<t> EAP-IKEv2 provides session independence in a number of ways, as follows.
Firstly, knowledge of captured EAP-IKEv2 conversations (i.e., the information
that a passive adversary may obtain) does not enable the adversary to compute
the Master Session Key (MSK) and Extended Master Session Key (EMSK) that
resulted from these conversations. This holds even in the case where the
adversary later obtains access to the server and/or the peer's long-term
authentication credentials that were used in these conversations. That is,
EAP-IKEv2 provides support for "perfect forward secrecy". However, whether or
not this support is made use of in a particular EAP-IKEv2 protocol run, depends
on when the peer and the server delete the Diffie-Hellman values that they used
in that run, and on whether or not they use fresh Diffie-Hellman values in each
protocol run. The discussion in Section 2.12 of <xref target="IKEv2"/> applies. </t>
<t> Secondly, an active adversary that does not know the peer's and the server's
long-term authentication credentials cannot learn the MSK and EMSK that were
established in a particular protocol run of EAP-IKEv2, even if it obtains access
to the MSK and EMSK that were established in other protocol runs of EAP-IKEv2.
This is because the MSK and the EMSK are a function of, among other things, data
items that are assumed to be generated independently at random in each protocol
run. </t>
</section>
<section toc="no" anchor="fragmntn" title="Fragmentation">
<t> EAP-IKEv2 provides support for fragmentation, as described in <xref
target="flagsfield"/>.</t>
</section>
<section toc="no" anchor="chanbind" title="Channel Binding">
<t> Channel binding is not supported in EAP-IKEv2.</t>
</section>
<section toc="no" title="Summary">
<t> EAP security claims are defined in Section 7.2.1 of <xref target="EAP"/>. The
security claims for EAP-IKEv2 are as follows:</t>
<t>
<figure>
<artwork><![CDATA[
Ciphersuite negotiation: Yes
Mutual authentication: Yes
Integrity protection: Yes
Replay protection: Yes
Confidentiality: Yes
Key derivation: Yes; see Section 5
Key strength: Variable
Dictionary attack prot.: Yes; see Section 10.7
Fast reconnect: Yes; see Section 4
Crypt. binding: N/A
Session independence: Yes; see Section 10.10
Fragmentation: Yes; see Section 10.11
Channel binding: No
]]></artwork>
</figure>
</t>
</section>
</section>
<section anchor="iabcs" title="IANA Considerations">
<t> IANA should allocate a value for the EAP method type indicating EAP-IKEv2.</t>
<t>In addition, IANA is requested to create a new registry for EAP-IKEv2 payloads, and
populate it with the following initial entries listed below.</t>
<t>The following payload type values are used by this document. <figure>
<artwork><![CDATA[
Next Payload Type | Value
-----------------------------------+----------------------------------
No Next payload | TBD by IANA (suggested value: 0)
Security Association payload | TBD by IANA (suggested value: 1)
Key Exchange payload | TBD by IANA (suggested value: 2)
Identification payload |
(when sent by initiator, IDi) | TBD by IANA (suggested value: 3)
Identification payload |
(when sent by responder, IDr) | TBD by IANA (suggested value: 4)
Certificate payload | TBD by IANA (suggested value: 5)
Certificate Request payload | TBD by IANA (suggested value: 6)
Authentication payload | TBD by IANA (suggested value: 7)
Nonce payload | TBD by IANA (suggested value: 8)
Notification payload | TBD by IANA (suggested value: 9)
Vendor ID payload | TBD by IANA (suggested value: 10)
Encrypted payload | TBD by IANA (suggested value: 11)
Next Fast-ID payload | TBD by IANA (suggested value: 12)
RESERVED TO IANA | 13-127
PRIVATE USE | 128-255
]]></artwork>
</figure> Payload type values 13-127 are reserved to IANA for future assignment in
EAP-IKEv2. Payload type values 128-255 are for private use among mutually consenting
parties. </t>
<t>The semantic of the above-listed payloads is provided in this document and refer to
IKEv2 when necessary. </t>
<t>Following the policies outline in <xref target="RFC3575"/> new payload type values
with a description of their semantic will be assigned after Expert Review initiated
by the Security Area Directors in consultation with the EMU working group chairs or
the working group chairs of a designated successor working group. Updates can be
provided based on expert approval only. A designated expert will be appointed by the
Security Area Directors. Based on expert approval it is possible to delete entries
from the registry or to mark entries as "deprecated".</t>
<t>Each registration must include the payload type value and the semantic of the
payload.</t>
</section>
<section title="Contributors">
<t> The authors are grateful to Krzysztof Rzecki, Rafal Mijal, Piotr Marnik, and Pawel
Matejski, who, during their implementation of EAP-IKEv2 (see
http://eap-ikev2.sourceforge.net/), provided invaluable feedback and identified a
number of errors in previous versions of this draft. </t>
</section>
<section anchor="acks" title="Acknowledgements">
<t>The authors also thank Pasi Eronen for his invaluable comments as expert reviewer
assigned by the EAP working group chairs Jari Arkko and Bernard Aboba. The authors
would also like to thank Guenther Horn, Thomas Otto, Paulo Pagliusi and John
Vollbrecht for their insightful comments and suggestions. The members of the PANA
design team, in particular D. Forsberg and A. Yegin, also provided comments on the
initial version of this draft. We would like to thank Hugo Krawczyk for his feedback
regarding the usage of the password based authentication.</t>
<t> The authors are grateful to the members of the EAP keying design team for their
discussion in the area of the EAP Key Management Framework.</t>
<t>We would like to thank Jari Arkko for his support and for his comments. Finally, we
would like to thank Charlie Kaufman, Bernard Aboba, and Paul Hoffman for their
comments during IETF Last Call.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="EAP">
<front>
<title>Extensible Authentication Protocol (EAP) (RFC 3748)</title>
<author initials="B" surname="Aboba" fullname="Bernard Aboba">
<organization/>
</author>
<author initials="L.J." surname="Blunk" fullname="Larry J. Blunk">
<organization/>
</author>
<author initials="J.R." surname="Vollbrecht" fullname="John R. Vollbrecht">
<organization/>
</author>
<author initials="J" surname="Carlson" fullname="James Carlson">
<organization/>
</author>
<author initials="H" surname="Levkowetz" fullname="Henrik Levkowetz">
<organization/>
</author>
<date month="June" year="2004"/>
</front>
<seriesInfo name="Request For Comments" value="3748"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc3748.txt"/>
</reference>
<reference anchor="IKEv2">
<front>
<title>Internet Key Exchange (IKEv2) Protocol</title>
<author initials="C" surname="Kaufman" fullname="Charlie Kaufman">
<organization/>
</author>
<date month="December" day="27" year="2005"/>
</front>
<seriesInfo name="RFC" value="4306"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc4306.txt"/>
</reference>
<reference anchor="2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S" surname="Bradner" fullname="Scott Bradner">
<organization/>
</author>
<date month="March" year="1997"/>
</front>
<seriesInfo name="RFC" value="2119"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc2119.txt"/>
</reference>
<reference anchor="cryptomust">
<front>
<title> Cryptographic Algorithms for Use in the Internet Key Exchange Version 2
(IKEv2)</title>
<author initials="J" surname="Schiller" fullname=" Jeffrey I. Schiller">
<organization/>
</author>
<date month="December" year="2005"/>
</front>
<seriesInfo name="RFC" value="4307"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc4307.txt"/>
</reference>
<reference anchor="utf8">
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author initials="F" surname="Yergeau" fullname="Francois Yergeau">
<organization/>
</author>
</front>
<seriesInfo name="RFC" value="3629"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc3629.txt"/>
</reference>
<reference anchor="NAI">
<front>
<title> The Network Access Identifier</title>
<author initials="B" surname="Aboba" fullname="Bernard Aboba">
<organization/>
</author>
<author initials="M" surname="Beadles" fullname="Mark Beadles">
<organization/>
</author>
<author initials="J" surname="Arkko" fullname="Jari Arkko">
<organization/>
</author>
<author initials="P" surname="Eronen" fullname="Pasi Eronen">
<organization/>
</author>
<date month="December" year="2005"/>
</front>
<seriesInfo name="RFC" value="4282"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc4282.txt"/>
</reference>
</references>
<references title="Informative References"> &I-D.ietf-eap-keying;
&I-D.ietf-pppext-eap-ttls; &RFC3575; </references>
<section anchor="failedruns" title="EAP-IKEv2 Protocol Runs with Failed Authentication">
<t> This appendix illustrates how authentication failures are handled within EAP-IKEv2.
Note that authentication failures only occur in full EAP-IKEv2 protocol runs.</t>
<t>
<xref target="fullsauthfailed"/> shows the message flow in case the EAP peer fails
to authenticate the EAP server. </t>
<t>
<figure anchor="fullsauthfailed" title="EAP-IKEv2 with failed server authentication">
<artwork><![CDATA[
1. R<-I: EAP-Request/Identity
2. R->I: EAP-Response/Identity(Id)
3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni)
4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}])
5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH})
6. R->I: EAP-Res(HDR, SK {N(AUTHENTICATION_FAILED)})
7. R<-I: EAP-Failure
]]></artwork>
</figure>
</t>
<t> The difference to the full successful exchange described in <xref target="overview"
/> is that, in message 6, the EAP peer MUST answer the EAP server with an Encrypted
payload that contains a Notify payload with the Notify Message Type value set to 24
(AUTHENTICATION_FAILED). In that message, the Message ID field in the EAP-IKEv2
header (HDR), MUST carry Message ID value 2. In message 7, an EAP-Failure message
MUST be returned by the EAP server. </t>
<t>
<xref target="fullpauthfailed"/> shows the message flow in case the EAP server fails
to authenticate the EAP peer. </t>
<t>
<figure anchor="fullpauthfailed" title="EAP-IKEv2 with failed peer authentication">
<artwork><![CDATA[
1. R<-I: EAP-Request/Identity
2. R->I: EAP-Response/Identity(Id)
3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni)
4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}])
5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], AUTH})
6. R->I: EAP-Res (HDR, SK {IDr, [CERT], AUTH})
7. R<-I: EAP-Req (HDR, SK {N(AUTHENTICATION_FAILED)})
8. R->I: EAP-Res (HDR, SK {})
9. R<-I: EAP-Failure
]]></artwork>
</figure>
</t>
<t> Compared to the full successful exchange, one additional roundtrip is required. In
message 7 the EAP server MUST send an EAP request with Encrypted payload that
contains a Notify payload with the Notify Message Type value set to 24
(AUTHENTICATION_FAILED), instead of sending an EAP-Success message. The EAP peer,
upon receiving message 7, MUST send an empty EAP-IKEv2 (informational) message in
reply to the EAP server's error indication, as shown in message 8. In both message 7
and 8, the Message ID field in the EAP-IKEv2 header (HDR), MUST carry Message ID
value 2. Finally, by means of message 9, the EAP server answers with an EAP-Failure. </t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 13:58:14 |