One document matched: draft-ietf-hokey-rfc5296bis-06.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3748 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
<!ENTITY rfc5295 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5295.xml">
<!ENTITY rfc4282 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4282.xml">
<!ENTITY rfc2104 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2104.xml">
<!ENTITY rfc4187 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4187.xml">
<!ENTITY rfc5169 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5169.xml">
<!ENTITY rfc5749 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5749.xml">
<!ENTITY rfc2865 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY I-D.ietf-dime-erp PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dime-erp.xml">
<!ENTITY I-D.nir-ipsecme-erx PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.nir-ipsecme-erx.xml">
<!ENTITY I-D.ietf-hokey-ldn-discovery PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hokey-ldn-discovery.xml">
<!ENTITY rfc3162 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3162.xml">
<!ENTITY rfc5226 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY rfc4962 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4962.xml">
<!ENTITY rfc5296 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml">
]>
<rfc category="std" docName="draft-ietf-hokey-rfc5296bis-06" ipr="trust200902"
obsoletes="5296">
<front>
<title abbrev="ERP">EAP Extensions for EAP Re-authentication Protocol
(ERP)</title>
<author fullname="Qin Wu" initials="Q." role="editor" surname="Wu">
<organization abbrev="Huawei">Huawei Technologies Co.,
Ltd.</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>JiangSu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>Sunseawq@huawei.com</email>
</address>
</author>
<author fullname="Zhen Cao" initials="Z." surname="Cao">
<organization>China Mobile</organization>
<address>
<postal>
<street>53A Xibianmennei Ave., Xuanwu District</street>
<city>Beijing</city>
<region>Beijing</region>
<code>100053</code>
<country>P.R. China</country>
</postal>
<email>caozhen@chinamobile.com</email>
</address>
</author>
<author fullname="Glen Zorn" initials="G." role="editor" surname="Zorn">
<organization abbrev="Network Zen">Network Zen</organization>
<address>
<postal>
<street>227/358 Thanon Sanphawut</street>
<city>Bang Na</city>
<region>Bangkok</region>
<code>10260</code>
<country>Thailand</country>
</postal>
<phone>+66 (0) 87-0404617</phone>
<email>glenzorn@gmail.com</email>
</address>
</author>
<author fullname="Yang Shi" initials="Y." surname="Shi">
<organization abbrev="H3C">H3C Tech. Co., Ltd</organization>
<address>
<postal>
<street>Digital Technology Plaza, NO.9 Shangdi 9th Street,Haidian
District</street>
<city>Beijing</city>
<code>100085</code>
<country>China</country>
</postal>
<email>young@h3c.com</email>
</address>
</author>
<author fullname="Baohong He" initials="B." surname="He">
<organization abbrev="CATR"></organization>
<address>
<postal>
<street></street>
<country>China</country>
</postal>
<email>hebaohong@catr.cn</email>
</address>
</author>
<date year="2011" />
<keyword>EAP keying</keyword>
<keyword>EMSK</keyword>
<keyword>re-authentication</keyword>
<keyword>inter-authenticator roaming</keyword>
<abstract>
<t>The Extensible Authentication Protocol (EAP) is a generic framework
supporting multiple types of authentication methods. In systems where
EAP is used for authentication, it is desirable to avoid repeating the entire
EAP exchange with another authenticator. This document specifies
extensions to EAP and the EAP keying hierarchy to support an EAP
method-independent protocol for efficient re-authentication between the
peer and an EAP re-authentication server through any authenticator. The
re-authentication server may be in the home network or in the local
network to which the peer is connecting.
<vspace blankLines="1"/>
This memo obsoletes RFC 5296.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Extensible Authentication Protocol (EAP) is a an authentication
framework that supports multiple authentication methods. The primary
purpose is network access authentication, and a key-generating method is
used when the lower layer wants to enforce access control. The EAP
keying hierarchy defines two keys to be derived by all key-generating
EAP methods: the Master Session Key (MSK) and the Extended MSK (EMSK).
In the most common deployment scenario, an EAP peer and an EAP server
authenticate each other through a third party known as the EAP
authenticator. The EAP authenticator or an entity controlled by the EAP
authenticator enforces access control. After successful authentication,
the EAP server transports the MSK to the EAP authenticator; the EAP
authenticator and the EAP peer establish transient session keys (TSKs)
using the MSK as the authentication key, key derivation key, or a key
transport key, and use the TSK for per-packet access enforcement.</t>
<t>When a peer moves from one authenticator to another, it is desirable
to avoid a full EAP authentication to support fast handovers. The full
EAP exchange with another run of the EAP method can take several round
trips and significant time to complete, causing increased handover
times. Some EAP methods specify the use of state from the initial
authentication to optimize re-authentications by reducing the
computational overhead (e.g., EAP-AKA <xref target="RFC4187"></xref>), but
method-specific re-authentication takes at
least 2 round trips with the original EAP server in most cases. It is also important to note that
several methods do not offer support for re-authentication.</t>
<t>Key sharing across authenticators is sometimes used as a practical
solution to lower handover times. In that case, however, the compromise of one
authenticator results in the compromise of keying material established via
other authenticators. Other solutions for fast re-authentication exist
in the literature: for example, see Lopez, et al. <xref target="MSKHierarchy"></xref>;
Clancy, et al. have described the EAP
re-authentication problem statement in detail
<xref target="RFC5169"></xref>.
</t>
<t>In conclusion, to achieve low latency handovers, there is a need for
a method-independent re-authentication protocol that completes in less
than 2 round trips, preferably with a local server.
</t>
<t>This document specifies EAP Re-authentication Extensions (ERXs) for
efficient re-authentication using EAP. The protocol that uses these
extensions is itself referred to as the EAP Re-authentication Protocol
(ERP). It supports EAP method-independent re-authentication for a peer
that has valid, unexpired key material from a previously performed EAP
authentication. The protocol and the key hierarchy required for EAP
re-authentication are described in this document.</t>
<t>
Note that to support ERP, lower-layer specifications may need to be
revised to allow carrying EAP messages that have a code value higher
than 4 and to accommodate the peer-initiated nature of ERP.
Specifically, the Internet Key Exchange (IKE) protocol <xref target="RFC5996"></xref>
must be updated to carry ERP messages;
work is in progress on this project
<xref target="I-D.nir-ipsecme-erx"/>.
</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 <xref
target="RFC2119"></xref>.</t>
<t>This document uses the basic EAP terminology <xref
target="RFC3748"></xref> and EMSK keying hierarchy terminology <xref
target="RFC5295"></xref>. In addition, this document uses the following
terms:</t>
<t><list style="hanging">
<t>ER Peer - An EAP peer that supports the EAP Re-authentication
Protocol. All references to "peer" in this document imply an ER
peer, unless specifically noted otherwise.</t>
<t>ER Authenticator - An entity that supports the authenticator
functionality for EAP re-authentication described in this document.
All references to "authenticator" in this document imply an ER
authenticator, unless specifically noted otherwise.</t>
<t>ER Server - An entity that performs the server portion of ERP
described here. This entity may or may not be an EAP server. All
references to "server" in this document imply an ER server, unless
specifically noted otherwise. An ER server is a logical entity; it
may not necessarily be co-located with, or physically part of, a
full EAP server.</t>
<t>ERX - EAP re-authentication extensions.</t>
<t>ERP - EAP Re-authentication Protocol that uses the
re-authentication extensions.</t>
<t>rRK - re-authentication Root Key, derived from the EMSK or
DSRK.</t>
<t>rIK - re-authentication Integrity Key, derived from the rRK.</t>
<t>rMSK - re-authentication MSK. This is a per-authenticator key,
derived from the rRK.</t>
<t>keyName-NAI - ERP messages are integrity protected with the rIK
or the DS-rIK. The use of rIK or DS-rIK for integrity protection of
ERP messages is indicated by the EMSKname <xref
target="RFC5295"></xref>; the protocol, which is ERP; and the realm,
which indicates the domain name of the ER server. The EMSKname is
copied into the username part of the NAI.</t>
<t>Domain - Refers to a "key management domain" as defined in <xref
target="RFC5295"></xref>. For simplicity, it is referred to as
"domain" in this document. The terms "home domain" and "local
domain" are used to differentiate between the originating key
management domain that performs the full EAP exchange with the peer
and the local domain to which a peer may be attached at a given
time.</t>
</list></t>
</section>
<section anchor="overview" title="ERP Description">
<t>ERP allows a peer and server to mutually verify proof of possession
of keying material from an earlier EAP method run and to establish a
security association between the peer and the authenticator. The
authenticator acts as a pass-through entity for the Re-authentication
Protocol in a manner similar to that of an EAP authenticator described
in RFC 3748 <xref target="RFC3748"></xref>. ERP is a single round-trip
exchange between the peer and the server; it is independent of the lower
layer and the EAP method used during the full EAP exchange. The ER
server may be in the home domain or in the same (visited) domain as the
peer and the authenticator (i.e., the local domain).</t>
<t><xref target="erp_fig"></xref> shows the protocol exchange. The first
time the peer attaches to any network, it performs a full EAP exchange
(shown in <xref target="eap_fig"></xref>) with the EAP server; as a
result, an MSK is distributed to the EAP authenticator. The MSK is then
used by the authenticator and the peer to establish TSKs as needed. At
the time of the initial EAP exchange, the peer and the server also
derive an EMSK, which is used to derive a re-authentication Root Key
(rRK). More precisely, a re-authentication Root Key is derived from the
EMSK or from a Domain-Specific Root Key (DSRK), which is itself derived
from the EMSK. The rRK is only available to the peer and the ER server
and is never handed out to any other entity. Further, a
re-authentication Integrity Key (rIK) is derived from the rRK; the peer
and the ER server use the rIK to provide proof of possession while
performing an ERP exchange. The rIK is also never handed out to any
entity and is only available to the peer and server.</t>
<t><figure anchor="eap_fig" title="EAP Authentication">
<artwork>
EAP Peer EAP Authenticator EAP Server
======== ================= ==========
<--- EAP-Request/ ------
Identity
----- EAP Response/ --->
Identity ---AAA(EAP Response/Identity)-->
<--- EAP Method -------> <------ AAA(EAP Method -------->
exchange exchange)
<----AAA(MSK, EAP-Success)------
<---EAP-Success---------
</artwork>
</figure></t>
<t><figure anchor="erp_fig" title="ERP Exchange">
<artwork>
Peer ER Authenticator ER Server
==== ============= ======
<-- EAP-Initiate/ -----
Re-auth-Start
[<-- EAP-Request/ ------
Identity]
---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ---------->
Re-auth/ Re-auth/
[Bootstrap] [Bootstrap])
<--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/---------
Re-auth/ Re-auth/
[Bootstrap] [Bootstrap])
Note: [] brackets indicate optionality.
</artwork>
</figure></t>
<t>Two new EAP codes, EAP-Initiate and EAP-Finish, are specified in this
document for the purpose of EAP re-authentication. When the peer
identifies a target authenticator that supports EAP re-authentication,
it performs an ERP exchange, as shown in <xref target="erp_fig"></xref>;
the exchange itself may happen when the peer attaches to a new
authenticator supporting EAP re-authentication, or prior to attachment.
The peer initiates ERP by itself; it may also do so in response to an
EAP-Initiate/Re-auth-Start message from the new authenticator. The
EAP-Initiate/Re-auth-Start message allows the authenticator to trigger
the ERP exchange. The EAP-Finish message also can be used by the
authenticator to announce the local domain name.</t>
<t>It is plausible that the authenticator does not know whether the peer
supports ERP and whether the peer has performed a full EAP
authentication through another authenticator. The authenticator MAY
initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start
message, and if there is no response, send the
EAP-Request/Identity message. Note that this avoids having two EAP
messages in flight at the same time <xref target="RFC3748"></xref>. The
authenticator may send the EAP-Initiate/Re-auth-Start message and wait
for a short, locally configured amount of time. This message indicates to the peer that the authenticator
supports ERP. In response to this trigger from the authenticator, the
peer can initiate the ERP exchange by sending an EAP-Initiate/Re-auth
message. If there is no response from the peer after the necessary number of
retransmissions (see <xref target="lowerlayer"></xref>), the
authenticator MUST initiate EAP by sending an EAP-Request message,
typically the EAP-Request/Identity message. Note that the authenticator
may receive an EAP-Initiate/Re-auth message after it has sent an
EAP-Request/Identity message. If the authenticator supports ERP, it MUST
proceed with the ERP exchange. When the EAP-Request/Identity times out,
the authenticator MUST NOT close the connection if an ERP exchange is in
progress or has already succeeded in establishing a re-authentication
MSK.</t>
<t>If the authenticator does not support ERP, it will silently discard
EAP-Initiate/Re-auth messages (<xref target="ReauthInit"></xref>) since the EAP
code of those packets is greater than 4 (<xref target="RFC3748"/>, Section 4).
An ERP-capable peer will
exhaust the EAP-Initiate/Re-auth message retransmissions and fall back
to EAP authentication by responding to EAP Request/Identity messages
from the authenticator.
If the peer does not support ERP or if it does
not have unexpired key material from a previous EAP authentication, it
drops EAP-Initiate/Re-auth-Start messages. If there is no response to
the EAP-Initiate/Re-auth-Start message, the authenticator SHALL send an
EAP Request message (typically EAP Request/Identity) to start EAP
authentication. From this point onward, RFC 3748 rules apply. Note that
this may introduce some delay in starting EAP. In some lower layers, the
delay can be minimized or even avoided by the peer initiating EAP by
sending messages such as EAPoL-Start
<xref target="IEEE_802.1X"></xref>.</t>
<t>The peer sends an EAP-Initiate/Re-auth message that contains the
keyName-NAI to identify the ER server's domain and the rIK used to
protect the message, and a sequence number for replay protection. The
EAP-Initiate/Re-auth message is integrity protected with the rIK. The
authenticator uses the realm in the keyName-NAI <xref
target="RFC4282"></xref> field to send the message to the appropriate ER
server. The server uses the keyName to look up the rIK. The server,
after verifying proof of possession of the rIK, and freshness of the
message, derives a re-authentication MSK (rMSK) from the rRK using the
sequence number as an input to the key derivation. The server then updates
the expected sequence number to the received sequence number plus
one.</t>
<t>In response to the EAP-Initiate/Re-auth message, the server sends an
EAP-Finish/Re-auth message; this message is integrity protected with the
rIK. The server transports the rMSK along with this message to the
authenticator. The rMSK is transported in a manner similar to that of
the MSK along with the EAP-Success message in a full EAP exchange.
Hoeper, et al.<xref target="RFC5749"></xref> discuss an additional
key distribution protocol that can be used to transport the rRK from an
EAP server to one of many different ER servers that share a trust
relationship with the EAP server.</t>
<t>The peer MAY request the rMSK lifetime from the server. If so, the ER
server sends the rMSK lifetime in the EAP-Finish/Re-auth message.</t>
<t>In an ERP bootstrap exchange, the peer MAY ask the server for the
rRK lifetime. If so, the ER server sends the rRK lifetime in the
EAP-Finish/Re-auth message.</t>
<t>The peer verifies the sequence number and the integrity of the
message. It then uses the sequence number in the EAP-Finish/Re-auth
message to compute the rMSK. The lower-layer security association
protocol is ready to be triggered after this point.</t>
<t>The ER server is located either in the home domain or in the visited
domain. When the ER server is in the home domain and there is no local
ER server in the visited domain, the peer and the server use the rIK and
rRK derived from the EMSK; and when the ER server is in the local
domain, they use the DS-rIK and DS-rRK corresponding to the local
domain. The domain of the ER server is identified by the realm portion
of the keyname-NAI in ERP messages. </t>
<section title="ERP With the Home ER Server">
<t>If the peer is in the home domain or there is no local server
in the same domain as the peer, it SHOULD initiate an ERP bootstrap
exchange with the home ER server to obtain the domain name. </t>
<t>The defined ER extensions allow executing the ERP with an ER server
in the home domain. The home ER server may be co-located with a home
AAA server.
ERP with the Home ER Server is similar to the ERP
exchange described in <xref target="erp_fig"></xref>.</t>
<t><figure anchor="home_erp_fig"
title="ER Explicit Bootstrapping Exchange/ERP with the Home ER Sever">
<artwork>
Peer ER Authenticator Home ER Server
==== ============= ======
<-- EAP-Initiate/ -----
Re-auth-Start
[<-- EAP-Request/ ------
Identity]
---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ---------->
Re-auth/ Re-auth/
Bootstrap Bootstrap)
<--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/---------
Re-auth/ Re-auth/
Bootstrap Bootstrap)
</artwork>
</figure></t>
</section>
<section anchor="local_er" title="ERP with a Local ER Server">
<t>The defined ER extensions allow the execution of ERP with an ER server
in the local domain (access network) if the peer moves out of home
domain and a local ER server is present in the visited domain. The
local ER server may be co-located with a local AAA server. The peer
may learn about the presence of a local ER server in the network and
the local domain name (or ER server name) either via a lower layer advertisement
or by means of ERP exchange. The peer uses the domain name and the
EMSK to compute the DSRK and from that key, the DS-rRK; the peer also
uses the domain name in the realm portion of the keyName-NAI for using
ERP in the local domain. <xref target="local_erp_fig_init"></xref>
shows the ER Implicit bootstrapping exchange through local ER
Server;<xref target="local_erp_fig"></xref>shows ERP with a local ER
server.</t>
<t><figure anchor="local_erp_fig_init"
title="Implicit Bootstrapping ERP Exchange, Initial EAP Exchange">
<artwork>
Peer EAP Authenticator Local AAA Agent Home EAP Server
/ER Authenticator /Local ER Server
==== ================= =============== ===============
<-- EAP-Request/ --
Identity
-- EAP Response/-->
Identity --AAA(EAP Response/-->
Identity, --AAA(EAP Response/ -->
[domain name]) Identity,
[DSRK Request,
domain name])
<------------------------ EAP Method exchange------------------>
<---AAA(MSK, DSRK, ----
EMSKname,
EAP-Success)
<--- AAA(MSK, -----
EAP-Success)
<---EAP-Success-----
</artwork>
</figure></t>
<t><figure anchor="local_erp_fig" title="Local ERP Exchange">
<artwork>
Peer ER Authenticator Local ER Server
==== ================ ===============
<-- EAP-Initiate/ --------
Re-auth-Start
[<-- EAP-Request/ ---------
Identity]
---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ -------->
Re-auth Re-auth)
<--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/-------
Re-auth Re-auth)
</artwork>
</figure></t>
<t>As shown in <xref target="local_erp_fig_init"></xref>, the local ER
server may be present in the path of the full EAP exchange (e.g., this
may be one of the AAA entities, such as AAA proxies, in the path
between the EAP authenticator and the home EAP server of the peer). In
that case, the local ER server requests the DSRK by sending the domain
name to the home EAP server by means of an AAA message. In response, the home
EAP server computes the DSRK by following the procedure specified in
<xref target="RFC5295"></xref> and sends the DSRK and the key name,
EMSKname, to the ER server in the claimed domain (i.e., the local ER
Server). The local domain is responsible for announcing that same
domain name to the peer via a lower layer (for example, through DHCP-based local
domain name discovery <xref target="I-D.ietf-hokey-ldn-discovery"></xref>, or through the
EAP-Initiate/Re-auth-Start message with the local ER
server.</t>
<t>After receiving the DSRK and the EMSKname, the local ER server
computes the DS-rRK and the DS-rIK from the DSRK as defined in
Sections <xref format="counter" target="rRKderv"></xref> and <xref
format="counter" target="rIKderv"></xref> below. After receiving the
domain name, the peer also derives the DSRK, the DS-rRK, and the
DS-rIK. These keys are referred to by a keyName-NAI formed as follows:
the username part of the NAI is the EMSKname, the realm portion of the
NAI is the domain name. Both parties also maintain a sequence number
(initialized to zero) corresponding to the specific keyName-NAI.</t>
<t>If the peer subsequently attaches to an authenticator within the
local domain, it may perform an ERP exchange with the local ER server
to obtain a rMSK for the new authenticator. The ERP with the local ER
Server is similar to ERP exchange illustrated in <xref
target="erp_fig"></xref>.</t>
</section>
</section>
<section anchor="eap_er_kh" title="ER Key Hierarchy">
<t>Each time the peer re-authenticates to the network, the peer and the
authenticator establish an rMSK. The rMSK serves the same purposes that
an MSK, which is the result of full EAP authentication, serves. To prove
possession of the rRK, we specify the derivation of another key, the
rIK. These keys are derived from the rRK. Together they constitute the
ER key hierarchy.</t>
<t>The rRK is derived from either the EMSK or a DSRK as specified in
<xref target="rRKderv"></xref>. For the purpose of rRK derivation, this
document specifies derivation of a Usage-Specific Root Key (USRK) or a
Domain-Specific USRK (DSUSRK) <xref target="RFC5295"></xref>
for re-authentication. The USRK designated for
re-authentication is the re-authentication root key (rRK). A DSUSRK
designated for re-authentication is the DS-rRK available to a local ER
server in a particular domain. For simplicity, the keys are referred to
without the DS label in the rest of the document. However, the scope of
the various keys is limited to just the respective domains for which they are
derived, in the case of the domain specific keys. Based on the ER
server with which the peer performs the ERP exchange, it knows the
corresponding keys that must be used.</t>
<t>The rRK is used to derive an rIK, and rMSKs for one or more
authenticators. The figure below shows the key hierarchy with the rRK,
rIK, and rMSKs. <figure anchor="rRK_fig"
title="Re-authentication Key Hierarchy">
<artwork>
rRK
|
+--------+--------+
| | |
rIK rMSK1 ...rMSKn
</artwork>
</figure></t>
<t>The derivations in this document are from RFC 5295. Key derivations and field encodings, where
unspecified, default to that document.</t>
<section anchor="rRKderv" title="rRK Derivation">
<t>The rRK may be derived from the EMSK or DSRK. This section provides
the relevant key derivations for that purpose.</t>
<t>The rRK is derived as specified in RFC 5295.</t>
<t>rRK = KDF (K, S), where<list style="empty">
<t>K = EMSK or K = DSRK and</t>
<t>S = rRK Label | "\0" | length</t>
</list></t>
<t>The rRK Label is an IANA-assigned 8-bit ASCII string: <list>
<t>EAP Re-authentication Root Key@ietf.org</t>
</list> assigned from the "USRK key labels" name space in accordance
with the policy stated in RFC 5295.</t>
<t>The KDF and algorithm agility for the KDF are as defined in RFC 5295.</t>
<t>An rRK derived from the DSRK is referred to as a DS-rRK in the rest
of the document. All the key derivation and properties specified in
this section remain the same.</t>
</section>
<section title="rRK Properties">
<t>The rRK has the following properties. These properties apply to the
rRK regardless of the parent key used to derive it. <list
style="symbols">
<t>The length of the rRK MUST be equal to the length of the parent
key used to derive it.</t>
<t>The rRK is to be used only as a root key for re-authentication
and never used to directly protect any data.</t>
<t>The rRK is only used for the derivation of the rIK and rMSK as
specified in this document.</t>
<t>The rRK MUST remain on the peer and the server that derived it
and MUST NOT be transported to any other entity.</t>
<t>The lifetime of the rRK is never greater than that of its
parent key. The rRK is expired when the parent key expires and
MUST be removed from use at that time.</t>
</list></t>
</section>
<section anchor="rIKderv" title="rIK Derivation">
<t>The re-authentication Integrity Key (rIK) is used for integrity
protecting the ERP exchange. This serves as the proof of possession of
valid keying material from a previous full EAP exchange by the peer to
the server.</t>
<t>The rIK is derived as follows.</t>
<t>rIK = KDF (K, S), where<list style="empty">
<t>K = rRK and</t>
<t>S = rIK Label | "\0" | cryptosuite | length</t>
</list></t>
<t>The rIK Label is the 8-bit ASCII string: <list>
<t>Re-authentication Integrity Key@ietf.org</t>
</list> The length field refers to the length of the rIK in octets
encoded as specified in RFC 5295.</t>
<t>The cryptosuite and length of the rIK are part of the input to the
key derivation function to ensure cryptographic separation of keys if
different rIKs of different lengths (for example, for use with different Message
Authentication Code (MAC) algorithms) are derived from the same rRK.
The cryptosuite is encoded as an 8-bit number; see <xref
target="ReauthInit"></xref> for the cryptosuite specification.</t>
<t>The rIK is referred to by the EMSKname-NAI within the context of ERP
messages. The username part of EMSKname-NAI is the EMSKname; the realm
is the domain name of the ER server. In case of ERP with the home ER
server, the peer uses the realm from its original NAI; in case of a
local ER server, the peer uses the domain name received at the lower
layer or through an ERP bootstrapping exchange.</t>
<t>A rIK derived from a DS-rRK is referred to as a DS-rIK in the rest
of the document. All of the key derivation and properties specified in
this section remain the same.</t>
</section>
<section title="rIK Properties">
<t>The rIK has the following properties. <list style="symbols">
<t>The length of the rIK MUST be equal to the length of the
rRK.</t>
<t>The rIK is only used for authentication of the ERP exchange as
specified in this document.</t>
<t>The rIK MUST NOT be used to derive any other keys.</t>
<t>The rIK must remain on the peer and the server and MUST NOT be
transported to any other entity.</t>
<t>The rIK is cryptographically separate from any other keys
derived from the rRK.</t>
<t>The lifetime of the rIK is never greater than that of its
parent key. The rIK MUST be expired when the EMSK expires and MUST
be removed from use at that time.</t>
</list></t>
</section>
<section title="rIK Usage">
<t>The rIK is the key the possession of which is demonstrated by the peer and
the ERP server to the other party. The peer demonstrates possession of
the rIK by computing the integrity checksum over the
EAP-Initiate/Re-auth message. When the peer uses the rIK for the first
time, it can choose the integrity algorithm to use with the rIK. The
peer and the server MUST use the same integrity algorithm with a given
rIK for all ERP messages protected with that key. The peer and the
server store the algorithm information after the first use, and they
employ the same algorithm for all subsequent uses of that rIK.</t>
<t>If the server's policy does not allow the use of the cryptosuite
selected by the peer, the server SHALL reject the EAP-Initiate/Re-auth
message and SHOULD send a list of acceptable cryptosuites in the
EAP-Finish/Re-auth message.</t>
<t>The rIK length may be different from the key length required by an
integrity algorithm. In case of hash-based MAC algorithms, the key is
first hashed to the required key length using the HMAC algorithm <xref
target="RFC2104">RFC 2104</xref>. In case of cipher-based MAC algorithms, if
the required key length is less than 32 octets, the rIK is hashed
using HMAC-SHA256 and the first k octets of the output are used, where
k is the key length required by the algorithm. If the required key
length is more than 32 octets, the first k octets of the rIK are used
by the cipher-based MAC algorithm.</t>
</section>
<section title="rMSK Derivation">
<t>The rMSK is derived at the peer and server and delivered to the
authenticator. The rMSK is derived following an EAP Re-auth Protocol
exchange.</t>
<t>The rMSK is derived as follows.</t>
<t>rMSK = KDF (K, S), where<list style="empty">
<t>K = rRK and</t>
<t>S = rMSK label | "\0" | SEQ | length</t>
</list></t>
<t>The rMSK label is the 8-bit ASCII string: <list>
<t>Re-authentication Master Session Key@ietf.org</t>
</list> The length field refers to the length of the rMSK in octets.
The length field is encoded as specified in RFC 5295.</t>
<t>SEQ is the sequence number sent by the peer in the
EAP-Initiate/Re-auth message. This field is encoded as a 16-bit number
in network byte order (see <xref target="ReauthInit"></xref>).</t>
<t>An rMSK derived from a DS-rRK is referred to as a DS-rIK in the
rest of the document. The key derivation and properties specified
in this section remain the same.</t>
</section>
<section title="rMSK Properties">
<t>The rMSK has the following properties: <list style="symbols">
<t>The length of the rMSK MUST be equal to the length of the
rRK.</t>
<t>The rMSK is delivered to the authenticator and is used for the
same purposes that an MSK is used at an authenticator.</t>
<t>The rMSK is cryptographically separate from any other keys
derived from the rRK.</t>
<t>The lifetime of the rMSK is less than or equal to that of the
rRK. It MUST NOT be greater than the lifetime of the rRK.</t>
<t>If a new rRK is derived, subsequent rMSKs MUST be derived from
the new rRK. Previously delivered rMSKs MAY still be used until
the expiry of the lifetime.</t>
<t>A given rMSK MUST NOT be shared by multiple authenticators.</t>
</list></t>
</section>
</section>
<section title="Protocol Details">
<section anchor="ERP-boot" title="ERP Bootstrapping">
<t>We identify two types of bootstrapping for ERP: explicit and
implicit. In implicit bootstrapping, the ER-capable
authenticator or local ER server MUST verify whether it has valid rMSK
or rRK corresponding to the peer. If ER capable authenticator or the
local ER server has the key materials corresponding to the peer, it
MUST be able to respond directly in the same way as the home AAA
server does without forwarding the DSRK request to the home domain; if
not, the ER-capable authenticator or local ER server SHOULD include
its domain name in the AAA message encapsulating the first EAP
Response message sent by the peer and request the DSRK from the home
EAP server during the initial EAP exchange.
If such EAP exchange is
successful, the home EAP server sends the DSRK for the specified local
AAA client or agent (derived using the EMSK and the domain name as
specified in RFC 5295), EMSKname, and DSRK
lifetime along with the EAP-Success message. The local AAA client or
agent MUST extract the DSRK, EMSKname, and DSRK lifetime (if present)
before forwarding the EAP-Success message to the peer. Note that the MSK (also
present with the EAP Success message) is extracted by the EAP
authenticator as usual. The peer learns the domain name through the
EAP-Initiate/Re-auth-Start message or by means of lower-layer announcement (for example, DHCP <xref
target="I-D.ietf-hokey-ldn-discovery"></xref>). When the domain name
is available to the peer during or after the full EAP authentication,
it attempts to use ERP when it associates with a new authenticator.
</t>
<t>If the peer knows there is no local ER server presented in the
visited domain, it SHOULD initiate Explicit ERP bootstrapping (ERP
exchange with the bootstrap flag turned on) with the home ER server to
obtain the rRK. The peer MAY also initiate bootstrapping to fetch
information such as the rRK lifetime from the AAA server. </t>
<t>The following steps describe the ERP Explicit Bootstrapping
process: <list style="symbols">
<t>The peer sends the EAP-Initiate/Re-auth message with the
bootstrapping flag set (1). The bootstrap message is always sent
to the home ER server, and the keyname-NAI attribute in the
bootstrap message is constructed as follows: the username portion
of the NAI contains the EMSKname, and the realm portion contains
the home domain name. </t>
<t>In addition, the message MUST contain a sequence number for
replay protection, a cryptosuite, and an integrity checksum. The
cryptosuite indicates the authentication algorithm. The integrity
checksum indicates that the message originated at the claimed
entity, the peer indicated by the Peer-ID, or the rIKname.</t>
<t>The peer MAY additionally set the lifetime flag to request the
key lifetimes.</t>
<t>Upon receipt of the EAP-Initiate/Re-auth message from a peer,
the ERP-capable authenticator verifies whether it has the local domain
name and valid key materials corresponding to the peer. If it
knows the local domain name and has valid key material corresponding to
the peer, it MUST be able to respond directly in the same way as
the home ER does with local domain name included. If not, it
copies the contents of the keyName-NAI into the appropriate AAA
attribute and may include
its domain name in the AAA message encapsulating the
EAP-Initiate/Re-auth message sent by the peer. </t>
<t>Upon receipt of an EAP-Initiate/Re-auth message, the home ER
server verifies whether the message is fresh or is a replay by
evaluating whether the received sequence number is equal to or
greater than the expected sequence number for that rIK. The home
ER server then verifies that the cryptosuite used by the
peer is acceptable. Next, it verifies the integrity of
the message by looking up the rIK and checking integrity checksum contained in the Authentication Tag field.
If any of the checks fail, the
home ER server sends an EAP-Finish/Re-auth message with the Result
flag set to '1'. Please refer to <xref target="fail"></xref> for
details on failure handling. This error MUST NOT have any
correlation to any EAP-Success message that may have been received
by the EAP authenticator and the peer earlier. If the
EAP-Initiate/Re-auth message is well-formed and valid, the server
prepares the EAP-Finish/Re-auth message. The bootstrap flag MUST
be set to indicate that this is a bootstrapping exchange. The
message contains the following fields: <list style="symbols">
<t>A sequence number for replay protection.</t>
<t>The same keyName-NAI as in the EAP-Initiate/Re-auth
message.</t>
<t>If the lifetime flag was set in the EAP-Initiate/Re-auth
message, the ER server SHOULD include the rRK lifetime and the
rMSK lifetime in the EAP-Finish/Re-auth message. The server
may have a local policy for the network to maintain and
enforce lifetime unilaterally. In such cases, the server need
not respond to the peer's request for the lifetime.</t>
<t>If the bootstrap flag is set, the ER server MUST include
the domain name to which the DSRK is being sent along with the
EAP-Finish/Re-auth message.</t>
<t>If the ER server verifies the authorization of a local ER
server, it MAY include the Authorization Indication TLV to
indicate to the peer that the server that received the DSRK
and that is advertising the domain included in the domain name
TLV is authorized.</t>
<t>An authentication tag MUST be included to prove that the
EAP-Finish/Re-auth message originates at a server that
possesses the rIK corresponding to the EMSKname-NAI.</t>
</list></t>
<t> If the home ER server gets involved in ERP exchange and the
ERP exchange is successful, the home ER server SHOULD request the
DSRK from the home EAP server; the home EAP server
MUST provide the DSRK for the home ER server (derived using the
EMSK and the domain name as specified in RFC 5295), EMSKname, and DSRK lifetime for inclusion in
the AAA message. The home ER server SHOULD obtain them before
sending the EAP-Finish/Re-auth message. </t>
<t>In addition, the rMSK is sent along with the EAP-Finish/Re-auth
message in a AAA attribute (for an example, see Bournelle, et al.<xref
target="I-D.ietf-dime-erp"></xref>.</t>
<t>The authenticator receives the rMSK.</t>
<t>When the peer receives an EAP-Finish/Re-auth message with the
bootstrap flag set, if a local domain name is present, it MUST use
that to derive the appropriate DSRK, DS-rRK, DS-rIK, and
keyName-NAI, and initialize the replay counter for the DS-rIK. If
not, the peer SHOULD derive the domain-specific keys using the
domain name it learned via the lower layer or from the
EAP-Initiate/Re-auth-Start message. If the peer does not know the
domain name, it must assume that there is no local ER server
available.</t>
<t>The peer MAY also verify the Authorization Indication TLV.</t>
<t>The procedures for encapsulating ERP and obtaining relevant
keys using Diameter are specified in <xref
target="I-D.ietf-dime-erp"></xref>.</t>
</list></t>
<t>Since the ER bootstrapping exchange is typically done immediately
following the full EAP exchange, it is feasible that the process is
completed through the same entity that served as the EAP authenticator
for the full EAP exchange. In this case, the lower layer may already
have established TSKs based on the MSK received earlier. The lower
layer may then choose to ignore the rMSK that was received with the ER
bootstrapping exchange. Alternatively, the lower layer may choose to
establish a new TSK using the rMSK. In either case, the authenticator
and the peer know which key is used based on whether or not a TSK
establishment exchange is initiated. The bootstrapping exchange may
also be carried out via a new authenticator, in which case, the rMSK
received SHOULD trigger a lower layer TSK establishment exchange.</t>
</section>
<section title="Steps in ERP">
<t>When a peer that has an active rRK and rIK associates with a new
authenticator that supports ERP, it may perform an ERP exchange with
that authenticator. ERP is typically a peer-initiated exchange,
consisting of an EAP-Initiate/Re-auth and an EAP-Finish/Re-auth
message. The ERP exchange may be performed with a local ER server
(when one is present) or with the original EAP server.</t>
<t>It is plausible for the network to trigger the EAP
re-authentication process, however. An ERP-capable authenticator
SHOULD send an EAP-Initiate/Re-auth-Start message to indicate support
for ERP. The peer may or may not wait for these messages to arrive to
initiate the EAP-Initiate/Re-auth message.</t>
<t>The EAP-Initiate/Re-auth-Start message SHOULD be sent by an
ERP-capable authenticator. The authenticator may retransmit it a few
times until it receives an EAP-Initiate/Re-auth message in response
from the peer. The EAP-Initiate/Re-auth message from the peer may have
originated before the peer receives either an EAP-Request/Identity or
an EAP-Initiate/Re-auth-Start message from the authenticator. Hence,
the Identifier value in the EAP-Initiate/Re-auth message is
independent of the Identifier value in the EAP-Initiate/Re-auth-Start
or the EAP-Request/Identity messages.</t>
<t>Operational Considerations at the Peer:</t>
<t>ERP requires that the peer maintain retransmission timers for
reliable transport of EAP re-authentication messages. The reliability
considerations of Section 4.3 of RFC 3748 apply with the peer as the
retransmitting entity.</t>
<t>The EAP Re-auth Protocol has the following steps:<list>
<t>The ERP-capable authenticator sends the
EAP-Initiate/Re-auth-Start message to trigger the ERP
exchange.</t>
<t>The peer sends an EAP-Initiate/Re-auth message. At a minimum,
the message SHALL include the following fields: <list>
<t>a 16-bit sequence number for replay protection</t>
<t>keyName-NAI as a TLV attribute to identify the rIK used to
integrity protect the message.</t>
<t>cryptosuite to indicate the authentication algorithm used
to compute the integrity checksum.</t>
<t>Authentication Tag computed over the message.</t>
</list></t>
<t>When the peer is performing ERP with a local ER server, it MUST
use the corresponding DS-rIK it shares with the local ER server.
The peer SHOULD set the lifetime flag to request the key lifetimes
from the server. The peer can use the rRK lifetime to know when to
trigger an EAP method exchange and the rMSK lifetime to know when
to trigger another ERP exchange.</t>
<t>The authenticator copies the contents of the value field of the
keyName-NAI TLV into an appropriate attribute (e.g, User-Name <xref target="RFC2865"/>)
in the AAA
message to the ER server.</t>
<t>The ER server uses the keyName-NAI to look up the rIK. It MUST
first verify whether the sequence number is equal to or greater
than the expected sequence number. If the ER server supports a
sequence number window size greater than 1, it MUST verify whether
the sequence number falls within the window and has not been
received before. The ER server MUST then verify that the
cryptosuite used by the peer is acceptable. The ER server then
proceeds to verify the integrity of the message using the rIK,
thereby verifying proof of possession of that key by the peer. If
any of these verifications fail, the ER server MUST send an
EAP-Finish/Re-auth message with the Result flag set to '1'
(Failure). Please refer to <xref target="fail"></xref> for details
on failure handling. Otherwise, it MUST compute an rMSK from the
rRK using the sequence number as the additional input to the key
derivation.</t>
<t>In response to a well-formed EAP Re-auth/Initiate message, the
ER server MUST send an EAP-Finish/Re-auth message with the
following contents: <list>
<t>a 16-bit sequence number for replay protection, which MUST
be the same as the received sequence number. The local copy of
the sequence number MUST be incremented by 1. If the ER server
supports multiple simultaneous ERP exchanges, it MUST instead
update the sequence number window.</t>
<t>keyName-NAI as a TLV attribute to identify the rIK used to
integrity protect the message.</t>
<t>cryptosuite to indicate the authentication algorithm used
to compute the integrity checksum.</t>
<t>Authentication Tag over the message.</t>
<t>If the lifetime flag was set in the EAP-Initiate/Re-auth
message, the ER server SHOULD include the rRK lifetime and the
rMSK lifetime.</t>
</list></t>
<t>The ER server causes the rMSK along with this message to to be transported to
the authenticator. The rMSK is transported in a manner similar to
the MSK and the EAP-Success message in a regular
EAP exchange.</t>
<t>The peer looks up the sequence number to verify whether it is
expecting an EAP-Finish/Re-auth message with that sequence number
protected by the keyName-NAI. It then verifies the integrity of
the message. If the verifications fail, the peer logs an error and
stops the process; otherwise, it proceeds to the next step.</t>
<t>The peer uses the sequence number to compute the rMSK.</t>
<t>The lower-layer security association protocol can be triggered
at this point.</t>
</list></t>
<section anchor="window" title="Multiple Simultaneous Runs of ERP">
<t>When a peer is within the range of multiple authenticators, it
may choose to run ERP via all of them simultaneously to the same ER
server. In that case, it is plausible that the ERP messages may
arrive out of order, resulting in the ER server rejecting legitimate
EAP-Initiate/Re-auth messages.</t>
<t>To facilitate such operation, an ER server MAY allow multiple
simultaneous ERP exchanges by accepting all EAP-Initiate/Re-auth
messages with SEQ number values within a window of allowed values.
Recall that the SEQ number allows replay protection. Replay window
maintenance mechanisms are a local matter.</t>
</section>
<section anchor="fail" title="ERP Failure Handling">
<t>If the processing of the EAP-Initiate/Re-auth message results in
a failure, the ER server MUST send an EAP-Finish Re-auth message
with the Result flag set to '1'. If the server has a valid rIK for
the peer, it MUST integrity protect the EAP-Finish/Re-auth failure
message. If the failure is due to an unacceptable cryptosuite, the
server SHOULD send a list of acceptable cryptosuites (in a TLV of
Type 5) along with the EAP-Finish/Re-auth message. In this case, the
server MUST indicate the cryptosuite used to protect the
EAP-Finish/Re-auth message in the cryptosuite. The rIK used with the
EAP-Finish/Re-auth message in this case MUST be computed as
specified in <xref target="rIKderv"></xref> using the new
cryptosuite. If the server does not have a valid rIK for the peer,
the EAP-Finish/Re-auth message indicating a failure will be
unauthenticated; the server MAY include a list of acceptable
cryptosuites in the message.</t>
<t>The peer, upon receiving an EAP-Finish/Re-auth message with the
Result flag set to '1', MUST verify the sequence number and, if possible, the
Authentication Tag to determine the validity of the message. If the
peer supports the cryptosuite, it MUST verify the integrity of the
received EAP-Finish/Re-auth message. If the EAP-Finish message
contains a TLV of Type 5, the peer SHOULD retry the ERP exchange
with a cryptosuite picked from the list included by the server. The
peer MUST use the appropriate rIK for the subsequent ERP exchange,
by computing it with the corresponding cryptosuite, as specified in
<xref target="rIKderv"></xref>. If the PRF in the chosen cryptosuite
is different from the PRF originally used by the peer, it MUST
derive a new DSRK (if required), rRK, and rIK before proceeding with
the subsequent ERP exchange.</t>
<t>If the peer cannot verify the integrity of the received message,
it MAY choose to retry the ERP exchange with one of the cryptosuites
in the List of cryptosuites TLV, after a failure has been clearly determined
following the procedure in the next paragraph.</t>
<t>If the replay or integrity checks fail, the failure message may
have been sent by an attacker. It may also mean that the server and
peer do not support the same cryptosuites; however, the peer cannot
determine if that is the case. Hence, the peer SHOULD continue the
ERP exchange per the retransmission timers before declaring a
failure.</t>
<t>When the peer runs explicit bootstrapping (ERP with the
bootstrapping flag on), there may not be a local ER server available
to send a DSRK Request and the domain name. In that case, the server
cannot send the DSRK and MUST NOT include the domain name TLV. When
the peer receives a response in the bootstrapping exchange without a
domain name TLV, it assumes that there is no local ER server. The
home ER server sends an rMSK to the ER authenticator, however, and
the peer SHALL run the TSK establishment protocol as usual.</t>
</section>
</section>
<section title="New EAP Packets">
<t>Two new EAP Codes are defined for the purpose of ERP: EAP-Initiate
and EAP-Finish. The packet format for these messages follows the EAP
packet format defined in Aboba. et al. <xref target="RFC3748"></xref>.
<figure anchor="ReauthPkt" title="EAP Packet">
<artwork>
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 | Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
</artwork>
</figure></t>
<t><list style="empty">
<t>Code <list style="empty">
<t>Two new code values are defined for the purpose of ERP:</t>
<t>5 Initiate</t>
<t>6 Finish</t>
</list></t>
<t>Identifier <list style="empty">
<t>The Identifier field is one octet. The Identifier field
MUST be the same if an EAP-Initiate packet is retransmitted
due to a timeout while waiting for a EAP-Finish message. Any new
(non-retransmission) EAP-Initiate message MUST use a new
Identifier field.</t>
<t>The Identifier field of the EAP-Finish message MUST match that
of the currently outstanding EAP-Initiate message. A peer or
authenticator receiving a EAP-Finish message whose Identifier
value does not match that of the currently outstanding
EAP-Initiate message MUST silently discard the packet.</t>
<t>In order to avoid confusion between new EAP-Initiate
messages and retransmissions, the peer must choose an
Identifier value that is different from the previous
EAP-Initiate message, especially if that exchange has not
finished. It is RECOMMENDED that the authenticator clear EAP
Re-auth state after 300 seconds.</t>
</list></t>
<t>Type <list style="empty">
<t>This field indicates that this is an ERP exchange. Two type
values are defined in this document for this purpose --
Re-auth-Start (Type 1) and Re-auth (Type
2).</t>
</list></t>
<t>Type-Data <list style="empty">
<t>The Type-Data field varies with the Type of
re-authentication packet.</t>
</list></t>
</list></t>
<section anchor="Re-auth-Start"
title="EAP-Initiate/Re-auth-Start Packet">
<t>The EAP-Initiate/Re-auth-Start packet contains the fields
shown in <xref target="Re-auth-StartPkt"></xref>. <figure
anchor="Re-auth-StartPkt"
title="EAP-Initiate/Re-auth-Start Packet">
<artwork>
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 | Reserved | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
<t><list style="hanging">
<t>Type = 1.</t>
<t>Reserved, MUST be zero. Set to zero on transmission and
ignored on reception.</t>
<t>One or more TVs or TLVs are used to convey information to the
peer; for instance, the authenticator may send the domain name
to the peer.</t>
<t>TVs or TLVs: In the TV payloads, there is a 1-octet type
payload and a value with type-specific length. In the TLV
payloads, there is a 1-octet type payload and a 1-octet length
payload. The length field indicates the length of the value
expressed in number of octets. <list style="hanging">
<t>Domain-Name: This is a TLV payload. The Type is 4. The
domain name is to be used as the realm in an NAI <xref
target="RFC4282"></xref>. The Domain-Name TLV SHOULD
be present in an EAP-Initiate/Re-auth-Start message.</t>
<t>In addition, channel binding information MAY be included;
see <xref target="CB"></xref> for discussion. See <xref
target="TLV"></xref> for parameter specification.</t>
</list></t>
</list></t>
<section title="Authenticator Operation">
<t>In order to minimize ERP failure times, the authenticator
SHOULD send the EAP-Initiate/Re-auth-Start message to indicate
support for ERP to the peer and to initiate ERP if the peer has
already performed full EAP authentication and has unexpired key
material. The authenticator SHOULD include the Domain-Name TLV to
allow the peer to learn it without requiring either lower-layer support or the ERP
bootstrapping exchange.</t>
<t>The authenticator MAY include channel binding information so
so that the server can verify whether
the authenticator is claiming the same identity to both
parties.</t>
<t>The authenticator MAY re-transmit the
EAP-Initiate/Re-auth-Start message a few times for reliable
transport.</t>
</section>
<section title="Peer Operation">
<t>The peer SHOULD send the EAP-Initiate/Re-auth message in
response to the EAP-Initiate/Re-auth-Start message from the
authenticator. If the peer does not recognize the EAP-Initiate code
value or if the peer has already sent the EAP-Initiate/Re-auth message to
begin the ERP exchange, it MUST silently discard the EAP-Initiate/Re-auth-Start message.
</t>
<t>If the EAP-Initiate/Re-auth-Start message contains the domain
name, and if the peer does not already have the domain
information, the peer SHOULD use the domain name contained in the message to compute the
DSRK and use the corresponding DS-rIK to send an
EAP-Initiate/Re-auth message to start an ERP exchange with the
local ER server. If there is a local ER server between the peer
and the home ER server and the peer has already initiated an ERP
exchange with the local ER server, it SHOULD NOT start
an ERP exchange with the home ER server.</t>
</section>
</section>
<section anchor="ReauthInit" title="EAP-Initiate/Re-auth Packet">
<t>The EAP-Initiate/Re-auth packet contains the parameters shown in
<xref target="ReauthInitPkt"></xref>. <figure anchor="ReauthInitPkt"
title="EAP-Initiate/Re-auth Packet">
<artwork>
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 |R|B|L| Reserved| SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
<t><list style="hanging">
<t>Type = 2.</t>
<t>Flags <list style="hanging">
<t>'R' - The R flag is set to 0 and ignored upon
reception.</t>
<t>'B' - The B flag is used as the bootstrapping flag. If
the flag is turned on, the message is a bootstrap
message.</t>
<t>'L' - The L flag is used to request the key lifetimes
from the server.</t>
<t>The remaining 5 bits are set to 0 on transmission and ignored on
reception.</t>
</list></t>
<t>SEQ: A 16-bit sequence number is used for replay protection.
The SEQ number field is initialized to 0 every time a new rRK is
derived.</t>
<t>TVs or TLVs: In the TV payloads, there is a 1-octet type
payload and a value with type-specific length. In the TLV
payloads, there is a 1-octet type payload and a 1-octet length
payload. The length field indicates the length of the value
expressed in number of octets. <list style="hanging">
<t>keyName-NAI: This is carried in a TLV payload. The Type
is 1. The NAI is variable in length, not exceeding 253
octets. The EMSKname is in the username part of the NAI and
is encoded in hexadecimal values. The EMSKname is 64 bits in
length and so the username portion takes up 16 octets. If
the rIK is derived from the EMSK, the realm part of the NAI
is the home domain name, and if the rIK is derived from a
DSRK, the realm part of the NAI is the domain name used in
the derivation of the DSRK. The NAI syntax follows <xref
target="RFC4282"></xref>. Exactly one keyName-NAI attribute
SHALL be present in an EAP-Initiate/Re-auth packet.</t>
</list> <list style="hanging">
<t>In addition, channel binding information MAY be included;
see <xref target="CB"></xref> for discussion. See <xref
target="TLV"></xref> for parameter specification.</t>
</list></t>
<t>Cryptosuite: This field indicates the integrity algorithm
used for ERP. Key lengths and output lengths are either
indicated or are obvious from the cryptosuite name. We specify
some cryptosuites below: <list style="symbols">
<t>0 RESERVED</t>
<t>1 HMAC-SHA256-64</t>
<t>2 HMAC-SHA256-128</t>
<t>3 HMAC-SHA256-256</t>
</list> HMAC-SHA256-128 is mandatory to implement and SHOULD
be enabled in the default configuration.</t>
<t>Authentication Tag: This field contains the integrity
checksum over the ERP packet, excluding the authentication tag
field itself. The length of the field is indicated by the
Cryptosuite.</t>
</list></t>
</section>
<section anchor="ReauthFin" title="EAP-Finish/Re-auth Packet">
<t>The EAP-Finish/Re-auth packet contains the parameters shown in
<xref target="ReauthInfPkt"></xref>. <figure anchor="ReauthInfPkt"
title="EAP-Finish/Re-auth Packet">
<artwork>
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 |R|B|L| Reserved | SEQ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
<t><list style="hanging">
<t>Type = 2.</t>
<t>Flags <list style="hanging">
<t>'R' - The R flag is used as the Result flag. When set to
0, it indicates success, and when set to '1', it indicates a
failure.</t>
<t>'B' - The B flag is used as the bootstrapping flag. If
the flag is turned on, the message is a bootstrap
message.</t>
<t>'L' - The L flag is used to indicate the presence of the
rRK lifetime TLV.</t>
<t>The remaining 5 bits are set to 0 on transmission and ignored on
reception.</t>
</list></t>
<t>SEQ: A 16-bit sequence number is used for replay protection.
The SEQ number field is initialized to 0 every time a new rRK is
derived.</t>
<t>TVs or TLVs: In the TV payloads, there is a 1-octet type
payload and a value with type-specific length. In the TLV
payloads, there is a 1-octet type payload and a 1-octet length
payload. The length field indicates the length of the value
expressed in number of octets. <list style="hanging">
<t>keyName-NAI: This is carried in a TLV payload. The Type
is 1. The NAI is variable in length, not exceeding 253
octets. EMSKname is in the username part of the NAI and is
encoded in hexadecimal values. The EMSKname is 64 bits in
length and so the username portion takes up 16 octets. If
the rIK is derived from the EMSK, the realm part of the NAI
is the home domain name, and if the rIK is derived from a
DSRK, the realm part of the NAI is the domain name used in
the derivation of the DSRK. The NAI syntax follows <xref
target="RFC4282"></xref>. Exactly one instance of the
keyName-NAI attribute SHALL be present in an
EAP-Finish/Re-auth message.</t>
<t>rRK Lifetime: This is a TV payload. The Type is 2. The
value field is a 32-bit field and contains the lifetime of
the rRK in seconds. If the 'L' flag is set, the rRK Lifetime
attribute SHOULD be present.</t>
<t>rMSK Lifetime: This is a TV payload. The Type is 3. The
value field is a 32-bit field and contains the lifetime of
the rMSK in seconds. If the 'L' flag is set, the rMSK
Lifetime attribute SHOULD be present.</t>
<t>Domain-Name: This is a TLV payload. The Type is 4. The
domain name is to be used as the realm in an NAI <xref
target="RFC4282"></xref>. Domain-Name attribute MUST be
present in an EAP-Finish/Re-auth message if the
bootstrapping flag is set and if the local ER server sent a
DSRK request.</t>
<t>List of cryptosuites: This is a TLV payload. The Type is
5. The value field contains a list of cryptosuites, each of
size 1 octet. The cryptosuite values are as specified in
<xref target="ReauthInitPkt"></xref>. The server SHOULD
include this attribute if the cryptosuite used in the
EAP-Initiate/Re-auth message was not acceptable and the
message is being rejected. The server MAY include this
attribute in other cases. The server MAY use this attribute
to signal to the peer about its cryptographic algorithm
capabilities.</t>
<t>Authorization Indication: This is a TLV payload. The Type
is 6. This attribute MAY be included in the
EAP-Finish/Re-auth message when a DSRK is delivered to a
local ER server and if the home EAP server can verify the
authorization of the local ER server to advertise the domain
name included in the domain TLV in the same message. The
value field in the TLV contains an authentication tag
computed over the entire packet, starting from the first bit
of the code field to the last bit of the cryptosuite field,
with the value field of the Authorization Indication TLV
filled with all 0s for the computation. The key used for the
computation MUST be derived from the EMSK with key label
"DSRK Delivery Authorized Key@ietf.org" and optional data
containing an ASCII string representing the key management
domain that the DSRK is being derived for.</t>
</list> <list style="hanging">
<t>In addition, channel binding information MAY be included:
see <xref target="CB"></xref> for discussion. See <xref
target="TLV"></xref> for parameter specification. The server
sends this information so that the peer can verify the
information seen at the lower layer, if channel binding is
to be supported.</t>
</list></t>
<t>Cryptosuite: This field indicates the integrity algorithm and
the PRF used for ERP. Key lengths and output lengths are either
indicated or are obvious from the cryptosuite name.</t>
<t>Authentication Tag: This field contains the integrity
checksum over the ERP packet, excluding the authentication tag
field itself. The length of the field is indicated by the
Cryptosuite.</t>
</list></t>
</section>
<section title="TV and TLV Attributes">
<t>The TV attributes that may be present in the EAP-Initiate or
EAP-Finish messages are of the following format: <figure anchor="TV"
title="TV Attribute Format">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
<t>The TLV attributes that may be present in the EAP-Initiate or
EAP-Finish messages are of the following format: <figure
anchor="TLV" title="TLV Attribute Format">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
<t>The following Types are defined in this document:</t>
<t><list style="hanging">
<t>'1' - keyName-NAI: This is a TLV payload.</t>
<t>'2' - rRK Lifetime: This is a TV payload.</t>
<t>'3' - rMSK Lifetime: This is a TV payload.</t>
<t>'4' - domain name: This is a TLV payload.</t>
<t>'5' - cryptosuite list: This is a TLV payload.</t>
<t>'6' - Authorization Indication: This is a TLV payload.</t>
<t>The TLV type range of 128-191 is reserved to carry channel
binding information in the EAP-Initiate and Finish/Re-auth
messages. Below are the current assignments (all of them are
TLVs): <list>
<t>'128' - Called-Station-Id <xref
target="RFC2865"></xref></t>
<t>'129' - Calling-Station-Id <xref
target="RFC2865"></xref></t>
<t>'130' - NAS-Identifier <xref target="RFC2865"></xref></t>
<t>'131' - NAS-IP-Address <xref target="RFC2865"></xref></t>
<t>'132' - NAS-IPv6-Address <xref
target="RFC3162"></xref></t>
</list></t>
</list></t>
<t>The length field indicates the length of the value part of the
attribute in octets.</t>
</section>
</section>
<section title="Replay Protection">
<t>For replay protection, ERP uses sequence numbers. The sequence
number is maintained on a per rIK basis and is initialized to zero in both
directions. In the first EAP-Initiate/Re-auth message, the peer uses
a sequence number value of zero or higher. Note that the when the sequence
number wraps back to zero, the rIK MUST be changed by running a full EAP authentication.
The server expects a sequence number of zero or higher. When the
server receives an EAP-Initiate/Re-auth message, it uses the same
sequence number in the EAP-Finish/Re-auth message. The server then
sets the expected sequence number to the received sequence number plus
1. The server MUST accept sequence numbers greater than or equal to the
expected sequence number.</t>
<t>If the peer sends an EAP-Initiate/Re-auth message, but does not
receive a response, it retransmits the request (with no changes to the
message itself) a pre-configured number of times before giving up.
However, it is plausible that the server itself may have responded to
the message and the response was lost in transit. Thus, the peer MUST increment
the sequence number and use the new sequence number to send subsequent
EAP re-authentication messages. The peer SHOULD increment the sequence
number by 1; however, it may choose to increment by a larger number.
If the sequence number wraps back to zero, the peer MUST run full EAP
authentication.</t>
</section>
<section anchor="CB" title="Channel Binding">
<t>ERP provides a protected facility to carry channel binding (CB)
information, according to the guidelines provided by Aboba, et al. (see Section 7.15 of <xref
target="RFC3748"></xref>). The TLV type range of 128-191 is reserved to
carry CB information in the EAP-Initiate/Re-auth and
EAP-Finish/Re-auth messages. Called-Station-Id, Calling-Station-Id,
NAS-Identifier, NAS-IP-Address, and NAS-IPv6-Address are some examples
of channel binding information listed in RFC 3748, and they are
assigned values 128-132. Additional values are IANA managed based on
IETF Consensus <xref target="RFC5226"></xref>.</t>
<t>The authenticator MAY provide CB information to the peer via the
EAP-Initiate/Re-auth-Start message. The peer sends the information to
the server in the EAP-Initiate/Re-auth message; the server verifies
whether the authenticator identity available via AAA attributes is the
same as the identity provided to the peer.</t>
<t>If the peer does not include the CB information in the
EAP-Initiate/Re-auth message, and if the local ER server's policy
requires channel binding support, it SHALL send the CB attributes for
the peer's verification. The peer attempts to verify the CB
information if the authenticator has sent the CB parameters, and it
proceeds with the lower-layer security association establishment if
the attributes match. Otherwise, the peer SHALL NOT proceed with the
lower-layer security association establishment.</t>
</section>
</section>
<section anchor="lowerlayer" title="Lower-Layer Considerations">
<t>The authenticator is responsible for retransmission of
EAP-Initiate/Re-auth-Start messages. The authenticator MAY retransmit
the message a few times or until it receives an EAP-Initiate/Re-auth
message from the peer.
The authenticator might not know if the peer
supports ERP; in those cases, the peer could be silently discarding the
EAP-Initiate/Re-auth-Start packets. Thus, retransmission of these
packets should be kept to a minimum. The exact number is up to each
lower layer.</t>
<t>The Identifier value in the EAP-Initiate/Re-auth packet is
independent of the Identifier value in the EAP-Initiate/Re-auth-Start
packet.</t>
<t>The peer is responsible for retransmission of EAP-Initiate/Re-auth
messages.</t>
<t>Retransmitted packets MUST be sent with the same Identifier value in
order to distinguish them from new packets. By default, where the
EAP-Initiate message is sent over an unreliable lower layer, the
retransmission timer SHOULD be dynamically estimated. A maximum of 3-5
retransmissions is suggested
<xref target="RFC3748"></xref>.
Where the EAP-Initiate message is sent
over a reliable lower layer, the retransmission timer SHOULD be set to
an infinite value, so that retransmissions do not occur at the EAP
layer. Please refer to RFC 3748 for
additional guidance on setting timers.</t>
<t>The Identifier value in the EAP-Finish/Re-auth packet is the same as
the Identifier value in the EAP-Initiate/Re-auth packet.</t>
<t>If an authenticator receives a valid duplicate EAP-Initiate/Re-auth
message for which it has already sent an EAP-Finish/Re-auth message, it
MUST resend the EAP-Finish/Re-auth message without reprocessing the
EAP-Initiate/Re-auth message. To facilitate this, the authenticator
SHALL store a copy of the EAP-Finish/Re-auth message for a finite amount
of time. The actual value of time is a local matter; this specification
recommends a value of 100 milliseconds.</t>
<t>The lower layer may provide facilities for exchanging information
between the peer and the authenticator about support for ERP, for the
authenticator to send the domain name information and channel binding
information to the peer</t>
<t>Note that to support ERP, lower-layer specifications may need to be
revised. Specifically, RFC 5996 must be updated to include EAP
code values higher than 4 in order to use ERP with Internet Key Exchange
Protocol version 2 (IKEv2). IKEv2 may also be updated to support
peer-initiated ERP for optimized operation. Other lower layers may need
similar revisions.</t>
<t>Our analysis indicates that some EAP implementations are not RFC 3748
compliant in that instead of silently dropping EAP packets with code
values higher than 4, they may consider it an error. To accommodate such
non-compliant EAP implementations, additional guidance has been provided
below. Furthermore, it may not be easy to upgrade all the peers in some
cases. In such cases, authenticators may be configured to not send
EAP-Initiate/Re-auth-Start; peers may learn whether an authenticator
supports ERP via configuration or from advertisements at the lower
layer.</t>
<t>In order to accommodate implementations that are not compliant to RFC
3748, such lower layers SHOULD ensure that both parties support ERP;
this is trivial for instance when using a lower layer that is known
to always support ERP. For lower layers where ERP support is not
guaranteed, ERP support may be indicated through signaling (e.g.,
piggy-backed on a beacon) or through negotiation. Alternatively, clients
may recognize environments where ERP is available based on
pre-configuration. Other similar mechanisms may also be used. When ERP
support cannot be verified, lower layers may mandate falling back to
full EAP authentication to accommodate EAP implementations that are not
compliant to RFC 3748.</t>
</section>
<section anchor="AAA" title="AAA Transport of ERP Messages">
<t>AAA Transport of ERP messages is specified by <xref target="RFC5749">Hoeper, et al.</xref>
and <xref target="I-D.ietf-dime-erp">Bournelle, et al.</xref>.</t>
</section>
<section anchor="SecCons" title="Security Considerations">
<t>This section provides an analysis of the protocol in accordance with
the AAA key management guidelines described by
<xref target="RFC4962">Housley & Aboba</xref>.</t>
<t><list style="empty">
<t>Cryptographic algorithm independence <list style="empty">
<t>The EAP Re-auth Protocol satisfies this requirement. The
algorithm chosen by the peer for the MAC generation is indicated
in the EAP-Initiate/Re-auth message. If the chosen algorithm is
unacceptable, the EAP server returns an EAP-Finish/Re-auth
message with Failure indication. Algorithm agility for the KDF
is specified in <xref target="RFC5295">Salowey, et al.</xref>. Only when the
algorithms used are deemed acceptable does the server proceed with the
derivation of keys and verification of the proof of possession
of relevant keying material presented by the peer. A full-blown
negotiation of algorithms cannot be provided in a single round
trip protocol. Hence, while the protocol provides algorithm
agility, it does not provide true negotiation.</t>
</list></t>
<t>Strong, fresh session keys <list style="empty">
<t>ERP results in the derivation of strong, fresh keys that are
unique for the given session. An rMSK is always derived
on-demand when the peer requires a key with a new authenticator.
The derivation ensures that the compromise of one rMSK does not
result in the compromise of another rMSK at any time.</t>
</list></t>
<t>Limit key scope <list style="empty">
<t>The scope of all the keys derived by ERP is well defined. The
rRK and rIK are never shared with any entity and always remain
on the peer and the server. The rMSK is provided only to the
authenticator through which the peer performs the ERP exchange.
No other authenticator is authorized to use that rMSK.</t>
</list></t>
<t>Replay detection mechanism <list style="empty">
<t>For replay protection of ERP messages, a sequence number
associated with the rIK is used. The sequence number is
maintained by the peer and the server, and initialized to zero
when the rIK is generated. The peer increments the sequence
number by one after it sends an ERP message. The server sets the
expected sequence number to the received sequence number plus
one after verifying the validity of the received message and
responds to the message.</t>
</list></t>
<t>Authenticate all parties <list style="empty">
<t>The EAP Re-auth Protocol provides mutual authentication of
the peer and the server. Both parties need to possess the keying
material that resulted from a previous EAP exchange in order to
successfully derive the required keys. Also, both the EAP
re-authentication Response and the EAP re-authentication
Information messages are integrity protected so that the peer
and the server can verify each other. When the ERP exchange is
executed with a local ER server, the peer and the local server
mutually authenticate each other via that exchange in the same
manner. The peer and the authenticator authenticate each other
in the secure association protocol executed by the lower layer,
just as in the case of a regular EAP exchange.</t>
</list></t>
<t>Peer and authenticator authorization <list style="empty">
<t>The peer and authenticator demonstrate possession of the same
key material without disclosing it, as part of the lower-layer
secure association protocol. Channel binding with ERP may be
used to verify consistency of the identities exchanged, when the
identities used in the lower layer differ from that exchanged
within the AAA protocol.</t>
</list></t>
<t>Keying material confidentiality <list style="empty">
<t>The peer and the server derive the keys independently using
parameters known to each entity. The AAA server sends the DSRK
of a domain to the corresponding local ER server via the AAA
protocol. Likewise, the ER server sends the rMSK to the
authenticator via the AAA protocol.</t>
<t>Note that compromise of the DSRK results in compromise of all
keys derived from it. Moreover, there is no forward secrecy
within ERP. Thus, compromise of an DSRK retroactively
compromises all ERP keys.</t>
<t>It is RECOMMENDED that the AAA protocol be protected using
IPsec or TLS so that the keys are protected in transit. Note,
however, that keys may be exposed to AAA proxies along the way
and compromise of any of those proxies may result in compromise
of keys being transported through them.</t>
<t>The home EAP server MUST NOT hand out a given DSRK to a local
domain server more than once, unless it can verify that the
entity receiving the DSRK after the first time is the same as
that received the DSRK originally. If the home EAP server
verifies authorization of a local domain server, it MAY hand out
the DSRK to that domain more than once. In this case, the home
EAP server includes the Authorization Indication TLV to assure
the peer that DSRK delivery is secure.</t>
</list></t>
<t>Confirm cryptosuite selection <list style="empty">
<t>Crypto algorithms for integrity and key derivation in the
context of ERP MAY be the same as that used by the EAP method.
In that case, the EAP method is responsible for confirming the
cryptosuite selection. Furthermore, the cryptosuite is included
in the ERP exchange by the peer and confirmed by the server. The
protocol allows the server to reject the cryptosuite selected by
the peer and provide alternatives. When a suitable rIK is not
available for the peer, the alternatives may be sent in an
unprotected fashion. The peer is allowed to retry the exchange
using one of the allowed cryptosuites. However, in this case,
any en route modifications to the list sent by the server will
go undetected. If the server does have an rIK available for the
peer, the list will be provided in a protected manner and this
issue does not apply.</t>
</list></t>
<t>Uniquely named keys <list style="empty">
<t>All keys produced within the ERP context can be referred to
uniquely as specified in this document. Also, the key names do
not reveal any part of the keying material.</t>
</list></t>
<t>Prevent the domino effect <list style="empty">
<t>The compromise of one peer does not result in the compromise
of keying material held by any other peer in the system. Also,
the rMSK is meant for a single authenticator and is not shared
with any other authenticator. Hence, the compromise of one
authenticator does not lead to the compromise of sessions or
keys held by any other authenticator in the system. Hence, the
EAP Re-auth Protocol allows prevention of the domino effect by
appropriately defining key scope.</t>
<t>However, if keys are transported using hop-by-hop protection,
compromise of a proxy may result in compromise of key material,
e.g., the DSRK being sent to a local ER server.</t>
</list></t>
<t>Bind key to its context <list style="empty">
<t>All the keys derived for ERP are bound to the appropriate
context using appropriate key labels. Lifetime of a child key is
less than or equal to that of its parent key as specified in RFC
4962 <xref target="RFC4962"></xref>. The key usage, lifetime and
the parties that have access to the keys are specified.</t>
</list></t>
<t>Confidentiality of identity <list style="empty">
<t>Deployments where privacy is a concern may find the use of
rIKname-NAI to route ERP messages serves their privacy
requirements. Note that it is plausible to associate multiple
runs of ERP messages since the rIKname is not changed as part of
the ERP protocol. There was no consensus for that requirement at
the time of development of this specification. If the rIKname is
not used and the Peer-ID is used instead, the ERP exchange will
reveal the Peer-ID over the wire.</t>
</list></t>
<t>Authorization restriction <list style="empty">
<t>All the keys derived are limited in lifetime by that of the
parent key or by server policy. Any domain-specific keys are
further restricted for use only in the domain for which the keys
are derived. All the keys specified in this document are meant
for use in ERP only.
Other restrictions on the use of session keys may
be imposed by the specific lower layer but are out of scope for
this specification.</t>
</list></t>
<t>Prevent DoS attack<list style="empty">
<t>A denial-of-service (DoS) attack on the peer may be possible
when using the EAP Initiate/Re-auth message. An attacker may
send a bogus EAP-Initiate/Re-auth message, which may be carried
by the authenticator in a AAA request to the server;
in response, the server may send an EAP-Finish/Re-auth with
Failure indication in a AAA reply. Note that
such attacks may be possible with the EAPoL-Start capability of
IEEE 802.11 and other similar facilities in other link layers
and where the peer can initiate EAP authentication. An attacker
may use such messages to start an EAP method run, which fails
and may result in the server sending a rejection
message, thus resulting in the link-layer connections being
terminated.</t>
<t>To prevent such DoS attacks, an ERP failure should not result
in deletion of any authorization state established by a full EAP
exchange. Alternatively, the lower layers and AAA protocols may
define mechanisms to allow two link-layer security associations
(SAs) derived from different EAP keying materials for the same
peer to exist so that smooth migration from the current link
layer SA to the new one is possible during rekey. These
mechanisms prevent the link layer connections from being
terminated when a re-authentication procedure fails due to a
bogus EAP-Initiate/Re-auth message.</t>
</list></t>
<t>Keying materials Transport<list style="empty">
<t>When a DSRK is sent from the home EAP server to a local domain
server or when a rMSK is sent from an ER server to an
authenticator, in the absence of end-to-end security between the
entity that is sending the key and the entity receiving the key,
it is plausible for other entities to get access to keys being
sent to an ER server in another domain. This mode of key
transport is similar to that of MSK transport in the context of
EAP authentication. We further observe that ERP is for access
authentication and does not support end-to-end data security. In
typical implementations, the traffic is in the clear beyond the
access control enforcement point (the authenticator or an entity
delegated by the authenticator for access control enforcement).
The model works as long as entities in the middle of the network
do not use keys intended for other parties to steal service from
an access network. If that is not achievable, key delivery must
be protected in an end-to-end manner.</t>
</list></t>
</list></t>
</section>
<section anchor="ianaCons" title="IANA Considerations">
<t>This document has no IANA actions.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3748;
&rfc2104;
&rfc4282;
&rfc5295;
</references>
<references title="Informative References">
&rfc4962;
&rfc4187;
&rfc5169;
&I-D.ietf-dime-erp;
&I-D.ietf-hokey-ldn-discovery;
&I-D.nir-ipsecme-erx;
&rfc5749;
&rfc5226;
&rfc2865;
&rfc3162;
<reference anchor="MSKHierarchy">
<front>
<title>Improved EAP keying framework for a secure mobility access
service</title>
<author fullname="Rafa Marin Lopez" initials="R. M." surname="Lopez">
<organization></organization>
</author>
<author fullname="Antonio Gomez Skarmeta" initials="A. G."
surname="Skarmeta">
<organization></organization>
</author>
<author fullname="Julien Bournelle" initials="J" surname="Bournelle">
<organization></organization>
</author>
<author fullname="Maryline Laurent-Maknavicus" initials="M"
surname="Laurent-Maknavicus">
<organization></organization>
</author>
<author fullname="Jean Michel Combes" initials="J. M."
surname="Combes">
<organization></organization>
</author>
<date year="2006" />
</front>
<seriesInfo name="IWCMC" value="'06" />
<seriesInfo name="Proceedings"
value="of the 2006 International Conference on Wireless Communications and Mobile Computing, New York, NY, USA" />
</reference>
<reference anchor="IEEE_802.1X">
<front>
<title>IEEE Standards for Local and Metropolitan Area Networks: Port
based Network Access Control, IEEE Std 802.1X-2004</title>
<author>
<organization>Institute of Electrical and Electronics
Engineers</organization>
</author>
<date month="December" year="2004" />
</front>
</reference>
<reference anchor="RFC5996">
<front>
<title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
<author fullname="C. Kaufman " initials="C." surname="Kaufman">
<organization></organization>
</author>
<author fullname="P. Hoffman " initials="P." surname="Hoffman ">
<organization></organization>
</author>
<author fullname="Y. Nir" initials="Y." surname="Nir">
<organization></organization>
</author>
<author fullname="P. Eronen" initials="P." surname="Eronen">
<organization></organization>
</author>
<date month="September" year="2010" />
<abstract>
<t>This document describes version 2 of the Internet Key Exchange
(IKE) protocol. IKE is a component of IPsec used for performing
mutual authentication and establishing and maintaining Security
Associations (SAs). This document replaces and updates RFC 4306,
and includes all of the clarifications from RFC 4718.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5996" />
<format target="http://www.rfc-editor.org/rfc/rfc5996.txt" type="TXT" />
</reference>
</references>
<section anchor="ack" title="Acknowledgments">
<section title="RFC 5296">
<t>In writing this document, we benefited from discussing the problem
space and the protocol itself with a number of folks including Bernard
Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey, Jesse
Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar, Parag
Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins, Yoshi Ohba, Glen
Zorn, Alan DeKok, Katrin Hoeper, and other participants of the HOKEY
working group. The credit for the idea to use
EAP-Initiate/Re-auth-Start goes to Charles Clancy, and the multiple
link-layer SAs idea to mitigate the DoS attack goes to Yoshi Ohba.
Katrin Hoeper suggested the use of the windowing technique to handle
multiple simultaneous ER exchanges. Many thanks to Pasi Eronen for the
suggestion to use hexadecimal encoding for rIKname when sent as part
of keyName-NAI field. Thanks to Bernard Aboba for suggestions in
clarifying the EAP lock-step operation, and Joe Salowey and Glen Zorn
for help in specifying AAA transport of ERP messages. Thanks to Sam
Hartman for the DSRK Authorization Indication mechanism.</t>
</section>
<section title="RFC 5296bis">
<t>
Thanks to Yaron Sheffer and Yoav Nir for useful comments.
</t>
</section>
</section>
<section title="Sample ERP Exchange">
<t>
<figure> <artwork>
0. Authenticator --> Peer:
EAP-Initiate/Re-auth-Start [Optional]
1. Peer --> Authenticator:
EAP Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite,
Auth-tag*)
1a. Authenticator --> Re-auth-Server:
AAA-Request
{
Authenticator-Id,
EAP Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite,
Auth-tag*)
}
2. ER-Server --> Authenticator:
AAA-Response
{
rMSK,
EAP-Finish/Re-auth(SEQ, keyName-NAI, cryptosuite, [CB-Info],
Auth-tag*)
}
2b. Authenticator --> Peer:
EAP-Finish/Re-auth(SEQ, keyName-NAI, cryptosuite, [CB-Info],
Auth-tag*)
* Auth-tag computation is over the entire EAP Initiate/Finish message;
the code values for Initiate and Finish are different and thus
reflection attacks are mitigated.
</artwork> </figure>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 16:32:36 |