<?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 rfc3579 PUBLIC '' 
		'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3579.xml'>
	<!ENTITY I-D.ietf-dime-erp PUBLIC "" 		
		"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dime-erp.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" obsoletes="5296" docName="draft-wu-hokey-rfc5296bis-01" ipr="noDerivativesTrust200902">
	<front>
		<title abbrev="ERP">EAP Extensions for EAP Re-authentication Protocol (ERP)</title>

		<author role="editor" fullname="Glen Zorn" initials="G." surname="Zorn">
			<organization abbrev="Network Zen">Network Zen</organization>
			<address>
				<postal>
					<street>1463 East Republican Street</street>
					<street>#358</street>
					<city>Seattle</city>
					<region>Washington</region>
					<code>98112</code>
					<country>US</country>
				</postal>
				<email>gwz@net-zen.net</email>
			</address>
		</author>
		
		<author fullname="Qin Wu" initials="Q." surname="Wu">
			<organization abbrev="Huawei">Huawei Technologies Co., Ltd.</organization>
			<address>
				<postal>
					<street>Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd.</street>
					<city>Nanjing</city>
					<region>JiangSu</region>
					<code>210001</code>
					<country>China</country>
				</postal>
				<phone>+86-25-84565892</phone>
				<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>

		<date year="2010"/>

        <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 not repeat
                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.</t>
        </abstract>
    </front>
    <middle>
        <section title="Introduction" anchor="intro">
            <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 delays in handover times. Some EAP methods specify
                the use of state from the initial authentication to optimize re-authentications by reducing the
                computational overhead, but method-specific re-authentication takes at least 2 round trips with the
                original EAP server in most cases (e.g., <xref target="RFC4187"/>). 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, compromise of an authenticator results in compromise of keying material established via other
                authenticators. Other solutions for fast re-authentication exist in the literature <xref
                    target="MSKHierarchy"/>.</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.
                The EAP re-authentication problem statement is described in detail in <xref
                    target="RFC5169"/>.</t>
            <t> This document specifies EAP Re-authentication Extensions (ERXs) for efficient re-authentication using
                EAP. The protocol that uses these extensions itself is 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 IEEE802.1x specification must be revised and RFC 4306 must be updated
                to carry ERP messages.</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"/>. </t>
            <t> This document uses the basic EAP terminology <xref target="RFC3748"/> and EMSK keying hierarchy
                terminology <xref target="RFC5295"/>. 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; the home ER server is located on
                        the same backend authentication server as the EAP server in the home domain. The local ER server
                        may not necessarily be 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"/>; 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"/>. 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 title="ERP Description" anchor="overview">
            <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"/>. 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. </t>

            <t>
                <xref target="erp_fig"/> 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"/>) 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 itself is 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>When the ER server is in the home domain, the peer and the server use the rIK and rRK derived from the
                EMSK; and when the ER server is not in the home 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>
                    <figure title="EAP Authentication" anchor="eap_fig">
                        <artwork><![CDATA[
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 title="ERP Exchange" anchor="erp_fig">
                        <artwork><![CDATA[

Peer               Authenticator                      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"/>; 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.</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, it will send the EAP-Request/Identity message. Note that this avoids having two EAP messages in
                    flight at the same time <xref target="RFC3748"/>. The authenticator may send the
                    EAP-Initiate/Re-auth-Start message and wait for a short, locally configured amount of time. If the
                    peer does not already know, 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
                    retransmissions (see <xref target="lowerlayer"/>),
                    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 drops EAP-Initiate/Re-auth messages <xref
                        target="RFC3748"/> as the EAP code of those
                        packets is greater than 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 stage onwards, 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 in the IEEE 802.1X specification <xref
                        target="IEEE_802.1X"/>.</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"/> 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 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. Ongoing work in <xref
                        target="RFC5749"/> describes 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 server for the rMSK lifetime. 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 request 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 replay protection 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>
            </section>

            <section title="ERP with a Local ER Server" anchor="local_er">
                <t>The defined ER extensions allow executing the ERP with an ER server in the local domain (access
                    network). 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
                    the lower layer or by means of ERP bootstrapping. 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"/>
                    shows the full EAP and subsequent local ERP
                    exchange; <xref target="local_erp_fig"/> shows it with a local ER
                    server. </t>
                <t>
                    <figure title="Local ERP Exchange, Initial EAP Exchange" anchor="local_erp_fig_init">
                        <artwork><![CDATA[
Peer         EAP Authenticator     Local ER Server     Home EAP Server
====         =================     ===============     ===============

<-- EAP-Request/ --
     Identity

-- EAP Response/-->
     Identity      --AAA(EAP Response/-->
                         Identity)       --AAA(EAP Response/ -->
                                                   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 title="Local ERP Exchange" anchor="local_erp_fig">
                        <artwork><![CDATA[

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"/>, 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 authenticator and the home EAP server of the peer). In that case, the ER server requests
                    the DSRK by sending the domain name to the EAP server. In response, the EAP server computes the DSRK
                    by following the procedure specified in <xref target="RFC5295"/> and sends the
                    DSRK and the key name, EMSKname, to the ER server in the claimed domain. The local domain is
                    responsible for announcing that same domain name via the lower layer to the peer. </t>
                <t> If the peer does not know the domain name (did not receive the domain name via the lower-layer
                    announcement, due to a missed announcement or lack of support for domain name announcements in a
                    specific lower layer), it SHOULD initiate ERP bootstrap exchange with the home ER server to obtain
                    the domain name. The local ER server SHALL request the home AAA server for the DSRK by sending the
                    domain name in the AAA message that carries the EAP-Initiate/Re-auth bootstrap message. The local ER
                    server MUST be in the path from the peer to the home ER server. If it is not, it cannot request the
                    DSRK.</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 target="rRKderv" format="counter"/> and
                    <xref target="rIKderv" format="counter"/> 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>Subsequently, when the peer attaches to an authenticator within the local domain, it may perform an
                    ERP exchange with the local ER server to obtain an rMSK for the new authenticator. </t>

            </section>

        </section>

        <section title="ER Key Hierarchy" anchor="eap_er_kh">
            <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"/>. For the
                purpose of rRK derivation, this document specifies derivation of a Usage-Specific Root Key (USRK) or a
                Domain-Specific USRK (DSUSRK) in accordance with <xref target="RFC5295"/> 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 they are derived for,
                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 title="Re-authentication Key Hierarchy" anchor="rRK_fig">
                    <artwork><![CDATA[
                         rRK
                          |
                 +--------+--------+
                 |        |        |
                rIK     rMSK1 ...rMSKn]]>
                    </artwork>
                </figure>
            </t>

            <t> The derivations in this document are according to <xref target="RFC5295"/>. Key
                derivations and field encodings, where unspecified, default to that document. </t>
            <section title="rRK Derivation" anchor="rRKderv">
                <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 <xref target="RFC5295"/>. </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 <xref
                        target="RFC5295"/>.</t>
                <t> The KDF and algorithm agility for the KDF are as defined in <xref
                        target="RFC5295"/>.</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 derivation of 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 title="rIK Derivation" anchor="rIKderv">
                <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 <xref
                        target="RFC5295"/>. </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 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"/> for the cryptosuite specification.</t>
                <t>The rIK is referred to by 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>An rIK derived from a DS-rRK is referred to as a DS-rIK in the rest of the document. All 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 whose possession 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 as specified in <xref
                        target="RFC2104"/>. 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 <xref target="RFC5295"/>.</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"/>).</t>
                <t>An rMSK derived from a DS-rRK is referred to as a DS-rIK in the rest of the document. All 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 title="ERP Bootstrapping" anchor="ERP-boot">
                <t> We identify two types of bootstrapping for ERP: explicit and implicit bootstrapping. In implicit
                    bootstrapping, the local ER server SHOULD include
                    its domain name and SHOULD request the DSRK from the home
                    AAA server during the initial EAP exchange, in the AAA message encapsulating the first EAP Response
                    message sent by the peer. If the EAP exchange is successful, the server sends the DSRK for the local
                    ER server (derived using the EMSK and the domain name as specified in <xref
                        target="RFC5295"/>), EMSKname, and DSRK lifetime along with the EAP-Success
                    message. The local ER server MUST extract the DSRK, EMSKname, and DSRK lifetime (if present) before
                    forwarding the EAP-Success message to the peer, as specified in <xref
                        target="I-D.ietf-dime-erp"/>. Note that the MSK (also present along 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 via lower-layer announcements. 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 does not know the domain name (did not receive the domain name via the lower-layer
                    announcement, due to a missed announcement or lack of support for domain name announcements in a
                    specific lower layer), it SHOULD initiate ERP bootstrap exchange (ERP exchange with the bootstrap
                    flag turned on) with the home ER server to obtain the domain name. The local ER server behavior is
                    the same as described above. 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 turned on. The
                            bootstrap message is always sent to the home AAA 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>When an ERP-capable authenticator receives
                            the EAP-Initiate/Re-auth message from a peer, it
                            copies the contents of the keyName-NAI into the User-Name attribute of RADIUS <xref
                                target="RFC2865"/>. The rest of the process is similar to that described in <xref
                                target="RFC3579"/>.</t>
                        <t>If a local ER server is present, the local ER server MUST include the DSRK request and 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 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 server then verifies to ensure that the
                            cryptosuite used by the peer is acceptable. Next, it verifies the origin authentication of
                            the message by looking up the rIK. If any of the checks fail, the server sends an
                            EAP-Finish/Re-auth message with the Result flag set to '1'. Please refer to <xref
                                target="fail"/> 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 and a DSRK request is received, the server MUST include
                                    the domain name to which the DSRK is being sent.</t>
                                <t>If the home ER server verifies the authorization of a local domain 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 ERP exchange is successful, and the local ER server sent a DSRK request, the home ER
                            server MUST include the DSRK for the local ER server (derived using the EMSK and the domain
                            name as specified in <xref target="RFC5295"/>), EMSKname, and DSRK
                            lifetime along with 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
                                <xref target="I-D.ietf-dime-erp"/>. </t>
                        <t> The local ER server MUST extract the DSRK, EMSKname, and DSRK lifetime (if present), before
                            forwarding the EAP-Finish/Re-auth message to the peer, as specified in <xref
                                target="I-D.ietf-dime-erp"/>. </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 the ERP and obtaining relevant keys using Diameter
                            are specified in <xref target="I-D.ietf-dime-erp"/>.</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 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 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 the
                            User-Name RADIUS attribute in the AAA message to the ER server.</t>
                        <t>The 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 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 server MUST then verify to ensure
                            that the cryptosuite used by the peer is acceptable. The 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 server MUST send an EAP-Finish/Re-auth
                            message with the Result flag set to '1' (Failure). Please refer to <xref target="fail"/> 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 server MUST send an
                            EAP-Finish/Re-auth message with the following considerations: <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 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 server transports the rMSK along with this message to the authenticator. The rMSK is
                            transported in a manner similar to the MSK transport along with 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 title="Multiple Simultaneous Runs of ERP" anchor="window">
                    <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 title="ERP Failure Handling" anchor="fail">
                    <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"/> 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 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"/>. 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 TLV of Type 5, 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 imply 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 RFC 3748 <xref target="RFC3748"/>. 

                    <figure title="EAP Packet" anchor="ReauthPkt">
                        <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      |  Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-                                ]]>
                        </artwork>
                    </figure>
                </t>
                <t>
                    <list style="empty">
                        <t> Code <list style="empty">
                                <t>5 Initiate</t>
                                <t>6 Finish</t>
                                <t> Two new code values are defined for the purpose of ERP.</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 Finish
                                    message. Any new (non-retransmission) Initiate message MUST use a new Identifier
                                    field. </t>
                                <t> The Identifier field of the Finish message MUST match that of the currently
                                    outstanding Initiate message. A peer or authenticator receiving a Finish message
                                    whose Identifier value does not match that of the currently outstanding 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 (assigned Type 1) and Re-auth (assigned
                                    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 title="EAP-Initiate/Re-auth-Start Packet" anchor="Re-auth-Start">
                    <t>The EAP-Initiate/Re-auth-Start packet contains the parameters shown in <xref
                            target="Re-auth-StartPkt"/>. 

                        <figure title="EAP-Initiate/Re-auth-Start Packet" anchor="Re-auth-StartPkt">
                            <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      |   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"/>. The Domain-Name attribute 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"/>
                                        for discussion. See <xref target="TLV"/> for parameter specification.
                                    </t>
                                </list>
                            </t>
                        </list>
                    </t>

                    <section title="Authenticator Operation">
                        <t>The authenticator MAY 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 lower-layer support or the ERP bootstrapping exchange.</t>
                        <t>The authenticator MAY include channel binding information so that the peer can send the
                            information to the server in the EAP-Initiate/Re-auth message 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 Initiate code value, it silently discards the message. If the peer has already sent the
                            EAP-Initiate/Re-auth message to begin the ERP exchange, it silently discards the 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 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 the
                            peer has already initiated an ERP exchange with the
                            home ER server, it MAY choose to not start an ERP exchange with the local ER server.</t>
                    </section>
                </section>

                <section title="EAP-Initiate/Re-auth Packet" anchor="ReauthInit">
                    <t>The EAP-Initiate/Re-auth packet contains the parameters shown in <xref target="ReauthInitPkt"/>.

                        <figure title="EAP-Initiate/Re-auth Packet" anchor="ReauthInitPkt">
                            <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      |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 rest of the 5 bits are set to 0 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 128 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"/>. 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"/>
                                        for discussion. See <xref target="TLV"/> 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 title="EAP-Finish/Re-auth Packet" anchor="ReauthFin">
                    <t> The EAP-Finish/Re-auth packet contains the parameters shown in <xref target="ReauthInfPkt"/>.

                        <figure title="EAP-Finish/Re-auth Packet" anchor="ReauthInfPkt">
                            <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      |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 rest of the 5 bits are set to 0 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"/>. 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"/>. 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"/>. 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 ER 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"/>
                                        for discussion. See <xref target="TLV"/> 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 title="TV Attribute Format" anchor="TV">
                            <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     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 title="TLV Attribute Format" anchor="TLV">
                            <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     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"/></t>
                                    <t>'129' - Calling-Station-Id <xref target="RFC2865"/></t>
                                    <t>'130' - NAS-Identifier <xref target="RFC2865"/></t>
                                    <t>'131' - NAS-IP-Address <xref target="RFC2865"/></t>
                                    <t>'132' - NAS-IPv6-Address <xref target="RFC3162"/></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 per rIK and is
                    initialized to zero in both directions. In the first EAP-Initiate/Re-auth message, the peer uses the
                    sequence number zero or higher. Note that the when the sequence number rotates, the rIK MUST be
                    changed by running 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 accepts 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 it 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. When the sequence number rotates, the peer
                    MUST run full EAP authentication.</t>
            </section>

            <section title="Channel Binding" anchor="CB">
                <t>ERP provides a protected facility to carry channel binding (CB) information, according to the
                    guidelines in Section 7.15 of <xref target="RFC3748"/>. 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"/>.</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 title="Lower-Layer Considerations" anchor="lowerlayer">

            <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 may not know whether the peer supports ERP; in those cases, the
                peer may be silently dropping 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
                (this is based on the recommendation of <xref target="RFC3748"/>). 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 <xref target="RFC3748"/> 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, the
                IEEE802.1x specification must be revised to allow carrying EAP messages of the new codes defined in this
                document in order to support ERP.  Similarly, RFC 4306 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, 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 an 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 title="Transport of ERP Messages" anchor="AAA">
            <t>AAA Transport of ERP messages is specified in <xref target="RFC5749"/> and <xref
                    target="I-D.ietf-dime-erp"/>. </t>
        </section>
        <section title="Security Considerations" anchor="SecCons">
            <t> This section provides an analysis of the protocol in accordance with the AAA key management requirements
                specified in <xref target="RFC4962"/>. </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"/>. Only when the algorithms used are
                                acceptable, the server proceeds with derivation of keys and verification of the proof of
                                possession of relevant keying material 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 a different 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 ER 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 ER 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 ER 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,
                                i.e., 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"/>. 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. Any other restrictions of session keys may be imposed by the specific lower
                                layer and are out of scope for this specification. </t>
                        </list>
                    </t>
                </list>
            </t>
            <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
                RADIUS-Access-Request to the server; in response, the server may send an EAP-Finish/Re-auth with
                Failure indication in a RADIUS Access-Reject message. Note that such attacks may be plausible 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 RADIUS Access-Reject 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 the bogus EAP-Initiate/Re-auth message. </t>
            <t> When a DSRK is sent from a home ER 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>
        </section>
        <section title="IANA Considerations" anchor="ianaCons">
			<t>
				This document has no IANA actions; 
				all values referenced in this document were previously assigned in RFC 5296 <xref target="RFC5296"/>.
			</t>
        </section>
    </middle>
    <back>
        <references title="Normative References"> &rfc2119; &rfc3748;  &rfc2104;
            &rfc4282; &rfc5295;

</references>
        <references title="Informative References"> &rfc4962;
	  &rfc4187; &rfc5296;

<!-- &eapERps; is ietf-hokey-reauth-ps, which became RFC 5169 -->
&rfc5169;

&I-D.ietf-dime-erp;


<!-- &hokekeymgm; is ietf-hokey-key-mgm -->


&rfc5749;




&rfc5226; &rfc2865; &rfc3162;
            &rfc3579; 

<reference anchor="MSKHierarchy">
                <front>
                    <title>Improved EAP keying framework for a secure mobility access service</title>
                    <author fullname="Rafa Marin Lopez" surname="Lopez" initials="R. M.">
                        <organization/>
                    </author>
                    <author fullname="Antonio Gomez Skarmeta" surname="Skarmeta" initials="A. G.">
                        <organization/>
                    </author>
                    <author fullname="Julien Bournelle" surname="Bournelle" initials="J">
                        <organization/>
                    </author>
                    <author fullname="Maryline Laurent-Maknavicus" surname="Laurent-Maknavicus" initials="M">
                        <organization/>
                    </author>
                    <author fullname="Jean Michel Combes" surname="Combes" initials="J. M.">
                        <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>
        </references>
        <section title="Acknowledgments" anchor="ack">
			<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>
					TBC
				</t>
            </section>
        </section>
        <section title="Example ERP Exchange">
            <t>
                    <figure><artwork><![CDATA[
0. Authenticator --> Peer:  [EAP-Initiate/Re-auth-Start]

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>
