GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5296

Network Working Group V. Narayanan Request for Comments: 5296 L. Dondeti Category: Standards Track Qualcomm, Inc.

                                                           August 2008
      EAP Extensions for EAP Re-authentication Protocol (ERP)

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Abstract

 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.

Narayanan & Dondeti Standards Track [Page 1] RFC 5296 ERP August 2008

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
 2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
 3.  ERP Description  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.1.  ERP With the Home ER Server  . . . . . . . . . . . . . . .  6
   3.2.  ERP with a Local ER Server . . . . . . . . . . . . . . . .  8
 4.  ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 10
   4.1.  rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 11
   4.2.  rRK Properties . . . . . . . . . . . . . . . . . . . . . . 12
   4.3.  rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 12
   4.4.  rIK Properties . . . . . . . . . . . . . . . . . . . . . . 13
   4.5.  rIK Usage  . . . . . . . . . . . . . . . . . . . . . . . . 13
   4.6.  rMSK Derivation  . . . . . . . . . . . . . . . . . . . . . 14
   4.7.  rMSK Properties  . . . . . . . . . . . . . . . . . . . . . 15
 5.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 15
   5.1.  ERP Bootstrapping  . . . . . . . . . . . . . . . . . . . . 15
   5.2.  Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 18
     5.2.1.  Multiple Simultaneous Runs of ERP  . . . . . . . . . . 20
     5.2.2.  ERP Failure Handling . . . . . . . . . . . . . . . . . 21
   5.3.  New EAP Packets  . . . . . . . . . . . . . . . . . . . . . 22
     5.3.1.  EAP-Initiate/Re-auth-Start Packet  . . . . . . . . . . 23
     5.3.2.  EAP-Initiate/Re-auth Packet  . . . . . . . . . . . . . 25
     5.3.3.  EAP-Finish/Re-auth Packet  . . . . . . . . . . . . . . 26
     5.3.4.  TV and TLV Attributes  . . . . . . . . . . . . . . . . 29
   5.4.  Replay Protection  . . . . . . . . . . . . . . . . . . . . 30
   5.5.  Channel Binding  . . . . . . . . . . . . . . . . . . . . . 30
 6.  Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 31
 7.  Transport of ERP Messages  . . . . . . . . . . . . . . . . . . 32
 8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
 9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 37
 10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 39
 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
   11.1. Normative References . . . . . . . . . . . . . . . . . . . 39
   11.2. Informative References . . . . . . . . . . . . . . . . . . 40
 Appendix A.  Example ERP Exchange  . . . . . . . . . . . . . . . . 42

Narayanan & Dondeti Standards Track [Page 2] RFC 5296 ERP August 2008

1. Introduction

 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.
 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., [6]).  It is also important to note that several methods do
 not offer support for re-authentication.
 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 [7] [8].
 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 [9].
 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.

Narayanan & Dondeti Standards Track [Page 3] RFC 5296 ERP August 2008

 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.

2. Terminology

 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 [1].
 This document uses the basic EAP terminology [2] and EMSK keying
 hierarchy terminology [3].  In addition, this document uses the
 following terms:
    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.
    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.
    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.
    ERX - EAP re-authentication extensions.
    ERP - EAP Re-authentication Protocol that uses the
    re-authentication extensions.
    rRK - re-authentication Root Key, derived from the EMSK or DSRK.
    rIK - re-authentication Integrity Key, derived from the rRK.
    rMSK - re-authentication MSK.  This is a per-authenticator key,
    derived from the rRK.

Narayanan & Dondeti Standards Track [Page 4] RFC 5296 ERP August 2008

    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 [3]; 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.
    Domain - Refers to a "key management domain" as defined in [3].
    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.

3. ERP Description

 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 [2].  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.
 Figure 2 shows the protocol exchange.  The first time the peer
 attaches to any network, it performs a full EAP exchange (shown in
 Figure 1) 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.
 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.

Narayanan & Dondeti Standards Track [Page 5] RFC 5296 ERP August 2008

3.1. ERP With the Home ER Server

 EAP Peer           EAP Authenticator                 EAP Server
 ========           =================                 ==========
  <--- EAP-Request/ ------
          Identity
  1. —- EAP Response/ —>

Identity —AAA(EAP Response/Identity)–>

  <--- EAP Method ------->  <------ AAA(EAP Method -------->
         exchange                    exchange)
                            <----AAA(MSK, EAP-Success)------
  <---EAP-Success---------
                     Figure 1: EAP Authentication
 Peer               Authenticator                      Server
 ====               =============                      ======
  [<-- EAP-Initiate/ -----
      Re-auth-Start]
  [<-- EAP-Request/ ------
      Identity]
  1. — 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.
                        Figure 2: ERP Exchange
 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 Figure 2;
 the exchange itself may happen when the peer attaches to a new
 authenticator supporting EAP re-authentication, or prior to

Narayanan & Dondeti Standards Track [Page 6] RFC 5296 ERP August 2008

 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.
 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 [2].  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 Section 6), 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.
 If the authenticator does not support ERP, it drops EAP-Initiate/
 Re-auth messages [2] 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
 [10].
 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 [4] field to send

Narayanan & Dondeti Standards Track [Page 7] RFC 5296 ERP August 2008

 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.
 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 [11] 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.
 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.
 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.
 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.

3.2. ERP with a Local ER Server

 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.  Figure 3 shows the full EAP and subsequent
 local ERP exchange; Figure 4 shows it with a local ER server.

Narayanan & Dondeti Standards Track [Page 8] RFC 5296 ERP August 2008

 Peer        EAP Authenticator     Local ER Server     Home EAP Server
 ====        =================     ===============     ===============
 <-- EAP-Request/ --
      Identity
  1. - 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-----
          Figure 3: Local ERP Exchange, Initial EAP Exchange
 Peer                ER Authenticator            Local ER Server
 ====                ================            ===============
 [<-- EAP-Initiate/ --------
      Re-auth-Start]
 [<-- EAP-Request/ ---------
      Identity]
  1. — EAP-Initiate/ ——→ —-AAA(EAP-Initiate/ ——–>

Re-auth Re-auth)

  <--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/-------
        Re-auth                        Re-auth)
                     Figure 4: Local ERP Exchange

Narayanan & Dondeti Standards Track [Page 9] RFC 5296 ERP August 2008

 As shown in Figure 4, 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 [3] 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.
 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.
 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 4.1 and 4.3 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.
 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.

4. ER Key Hierarchy

 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.
 The rRK is derived from either the EMSK or a DSRK as specified in
 Section 4.1.  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 [3] 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-

Narayanan & Dondeti Standards Track [Page 10] RFC 5296 ERP August 2008

 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.
 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.
                          rRK
                           |
                  +--------+--------+
                  |        |        |
                 rIK     rMSK1 ...rMSKn
               Figure 5: Re-authentication Key Hierarchy
 The derivations in this document are according to [3].  Key
 derivations and field encodings, where unspecified, default to that
 document.

4.1. rRK Derivation

 The rRK may be derived from the EMSK or DSRK.  This section provides
 the relevant key derivations for that purpose.
 The rRK is derived as specified in [3].
 rRK = KDF (K, S), where
    K = EMSK or K = DSRK and
    S = rRK Label | "\0" | length
 The rRK Label is an IANA-assigned 8-bit ASCII string:
    EAP Re-authentication Root Key@ietf.org
 assigned from the "USRK key labels" name space in accordance with
 [3].
 The KDF and algorithm agility for the KDF are as defined in [3].

Narayanan & Dondeti Standards Track [Page 11] RFC 5296 ERP August 2008

 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.

4.2. rRK Properties

 The rRK has the following properties.  These properties apply to the
 rRK regardless of the parent key used to derive it.
 o  The length of the rRK MUST be equal to the length of the parent
    key used to derive it.
 o  The rRK is to be used only as a root key for re-authentication and
    never used to directly protect any data.
 o  The rRK is only used for derivation of rIK and rMSK as specified
    in this document.
 o  The rRK MUST remain on the peer and the server that derived it and
    MUST NOT be transported to any other entity.
 o  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.

4.3. rIK Derivation

 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.
 The rIK is derived as follows.
 rIK = KDF (K, S), where
    K = rRK and
    S = rIK Label | "\0" | cryptosuite | length
 The rIK Label is the 8-bit ASCII string:
    Re-authentication Integrity Key@ietf.org
 The length field refers to the length of the rIK in octets encoded as
 specified in [3].

Narayanan & Dondeti Standards Track [Page 12] RFC 5296 ERP August 2008

 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 Section 5.3.2 for
 the cryptosuite specification.
 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.
 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.

4.4. rIK Properties

 The rIK has the following properties.
 o  The length of the rIK MUST be equal to the length of the rRK.
 o  The rIK is only used for authentication of the ERP exchange as
    specified in this document.
 o  The rIK MUST NOT be used to derive any other keys.
 o  The rIK must remain on the peer and the server and MUST NOT be
    transported to any other entity.
 o  The rIK is cryptographically separate from any other keys derived
    from the rRK.
 o  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.

4.5. rIK Usage

 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

Narayanan & Dondeti Standards Track [Page 13] RFC 5296 ERP August 2008

 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.
 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.
 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 [5].  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.

4.6. rMSK Derivation

 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.
 The rMSK is derived as follows.
 rMSK = KDF (K, S), where
    K = rRK and
    S = rMSK label | "\0" | SEQ | length
 The rMSK label is the 8-bit ASCII string:
    Re-authentication Master Session Key@ietf.org
 The length field refers to the length of the rMSK in octets.  The
 length field is encoded as specified in [3].
 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 Section 5.3.2).
 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.

Narayanan & Dondeti Standards Track [Page 14] RFC 5296 ERP August 2008

4.7. rMSK Properties

 The rMSK has the following properties:
 o  The length of the rMSK MUST be equal to the length of the rRK.
 o  The rMSK is delivered to the authenticator and is used for the
    same purposes that an MSK is used at an authenticator.
 o  The rMSK is cryptographically separate from any other keys derived
    from the rRK.
 o  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.
 o  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.
 o  A given rMSK MUST NOT be shared by multiple authenticators.

5. Protocol Details

5.1. ERP Bootstrapping

 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 [3]), 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 [12].  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.
 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

Narayanan & Dondeti Standards Track [Page 15] RFC 5296 ERP August 2008

 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.
 The following steps describe the ERP explicit bootstrapping process:
 o  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.
 o  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.
 o  The peer MAY additionally set the lifetime flag to request the key
    lifetimes.
 o  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 [13].  The rest
    of the process is similar to that described in [14] and [12].
 o  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.
 o  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 Section 5.2.2 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:

Narayanan & Dondeti Standards Track [Page 16] RFC 5296 ERP August 2008

  • A sequence number for replay protection.
  • The same keyName-NAI as in the EAP-Initiate/Re-auth message.
  • 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.
  • 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.
  • 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.
  • 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.
 o  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 [3]), EMSKname, and DSRK lifetime along with the EAP-
    Finish/Re-auth message.
 o  In addition, the rMSK is sent along with the EAP-Finish/Re-auth
    message, in a AAA attribute [12].
 o  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 [12].
 o  The authenticator receives the rMSK.
 o  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.

Narayanan & Dondeti Standards Track [Page 17] RFC 5296 ERP August 2008

 o  The peer MAY also verify the Authorization Indication TLV.
 o  The procedures for encapsulating the ERP and obtaining relevant
    keys using RADIUS and Diameter are specified in [12] and [15],
    respectively.
 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.

5.2. Steps in ERP

 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.
 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.
 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.

Narayanan & Dondeti Standards Track [Page 18] RFC 5296 ERP August 2008

 Operational Considerations at the Peer:
 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.
 The EAP Re-auth Protocol has the following steps:
    The peer sends an EAP-Initiate/Re-auth message.  At a minimum, the
    message SHALL include the following fields:
       a 16-bit sequence number for replay protection
       keyName-NAI as a TLV attribute to identify the rIK used to
       integrity protect the message.
       cryptosuite to indicate the authentication algorithm used to
       compute the integrity checksum.
       authentication tag over the message.
    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.
    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.
    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 Section 5.2.2 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.

Narayanan & Dondeti Standards Track [Page 19] RFC 5296 ERP August 2008

    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:
       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.
       keyName-NAI as a TLV attribute to identify the rIK used to
       integrity protect the message.
       cryptosuite to indicate the authentication algorithm used to
       compute the integrity checksum.
       authentication tag over the message.
       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.
    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.
    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.
    The peer uses the sequence number to compute the rMSK.
    The lower-layer security association protocol can be triggered at
    this point.

5.2.1. Multiple Simultaneous Runs of ERP

 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.

Narayanan & Dondeti Standards Track [Page 20] RFC 5296 ERP August 2008

 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.

5.2.2. ERP Failure Handling

 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
 Section 4.3 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.
 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
 Section 4.3.  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.
 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.
 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.

Narayanan & Dondeti Standards Track [Page 21] RFC 5296 ERP August 2008

 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.

5.3. New EAP Packets

 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 [2].
 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 ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
                         Figure 6: EAP Packet
    Code
       5 Initiate
       6 Finish
       Two new code values are defined for the purpose of ERP.
    Identifier
       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.
       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.

Narayanan & Dondeti Standards Track [Page 22] RFC 5296 ERP August 2008

       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.
    Type
       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).
    Type-Data
       The Type-Data field varies with the Type of re-authentication
       packet.

5.3.1. EAP-Initiate/Re-auth-Start Packet

 The EAP-Initiate/Re-auth-Start packet contains the parameters shown
 in Figure 7.
 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     ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 7: EAP-Initiate/Re-auth-Start Packet
    Type = 1.
    Reserved, MUST be zero.  Set to zero on transmission and ignored
    on reception.
    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.
    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.

Narayanan & Dondeti Standards Track [Page 23] RFC 5296 ERP August 2008

       Domain-Name: This is a TLV payload.  The Type is 4.  The domain
       name is to be used as the realm in an NAI [4].  The Domain-Name
       attribute SHOULD be present in an EAP-Initiate/Re-auth-Start
       message.
       In addition, channel binding information MAY be included; see
       Section 5.5 for discussion.  See Figure 11 for parameter
       specification.

5.3.1.1. Authenticator Operation

 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.
 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.
 The authenticator MAY re-transmit the EAP-Initiate/Re-auth-Start
 message a few times for reliable transport.

5.3.1.2. Peer Operation

 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.
 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.

Narayanan & Dondeti Standards Track [Page 24] RFC 5296 ERP August 2008

5.3.2. EAP-Initiate/Re-auth Packet

 The EAP-Initiate/Re-auth packet contains the parameters shown in
 Figure 8.
 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                     ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Figure 8: EAP-Initiate/Re-auth Packet
    Type = 2.
    Flags
       'R' - The R flag is set to 0 and ignored upon reception.
       'B' - The B flag is used as the bootstrapping flag.  If the
       flag is turned on, the message is a bootstrap message.
       'L' - The L flag is used to request the key lifetimes from the
       server.
       The rest of the 5 bits are set to 0 and ignored on reception.
    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.
    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.
       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

Narayanan & Dondeti Standards Track [Page 25] RFC 5296 ERP August 2008

       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 [4].  Exactly one keyName-NAI
       attribute SHALL be present in an EAP-Initiate/Re-auth packet.
       In addition, channel binding information MAY be included; see
       Section 5.5 for discussion.  See Figure 11 for parameter
       specification.
    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:
  • 0 RESERVED
  • 1 HMAC-SHA256-64
  • 2 HMAC-SHA256-128
  • 3 HMAC-SHA256-256
    HMAC-SHA256-128 is mandatory to implement and should be enabled in
    the default configuration.
    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.

5.3.3. EAP-Finish/Re-auth Packet

 The EAP-Finish/Re-auth packet contains the parameters shown in
 Figure 9.
 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                     ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 9: EAP-Finish/Re-auth Packet

Narayanan & Dondeti Standards Track [Page 26] RFC 5296 ERP August 2008

    Type = 2.
    Flags
       '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.
       'B' - The B flag is used as the bootstrapping flag.  If the
       flag is turned on, the message is a bootstrap message.
       'L' - The L flag is used to indicate the presence of the rRK
       lifetime TLV.
       The rest of the 5 bits are set to 0 and ignored on reception.
    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.
    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.
       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 [4].  Exactly one instance of the
       keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth
       message.
       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.
       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.

Narayanan & Dondeti Standards Track [Page 27] RFC 5296 ERP August 2008

       Domain-Name: This is a TLV payload.  The Type is 4.  The domain
       name is to be used as the realm in an NAI [4].  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.
       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 Figure 8.
       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.
       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.
       In addition, channel binding information MAY be included: see
       Section 5.5 for discussion.  See Figure 11 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.
    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.
    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.

Narayanan & Dondeti Standards Track [Page 28] RFC 5296 ERP August 2008

5.3.4. TV and TLV Attributes

 The TV attributes that may be present in the EAP-Initiate or EAP-
 Finish messages are of the following format:
 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 ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Figure 10: TV Attribute Format
 The TLV attributes that may be present in the EAP-Initiate or EAP-
 Finish messages are of the following format:
 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 ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Figure 11: TLV Attribute Format
 The following Types are defined in this document:
    '1' - keyName-NAI: This is a TLV payload.
    '2' - rRK Lifetime: This is a TV payload.
    '3' - rMSK Lifetime: This is a TV payload.
    '4' - domain name: This is a TLV payload.
    '5' - cryptosuite list: This is a TLV payload.
    '6' - Authorization Indication: This is a TLV payload.
    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):
       '128' - Called-Station-Id [13]
       '129' - Calling-Station-Id [13]
       '130' - NAS-Identifier [13]

Narayanan & Dondeti Standards Track [Page 29] RFC 5296 ERP August 2008

       '131' - NAS-IP-Address [13]
       '132' - NAS-IPv6-Address [16]
 The length field indicates the length of the value part of the
 attribute in octets.

5.4. Replay Protection

 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.
 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.

5.5. Channel Binding

 ERP provides a protected facility to carry channel binding (CB)
 information, according to the guidelines in Section 7.15 of [2].  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 [17].
 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.

Narayanan & Dondeti Standards Track [Page 30] RFC 5296 ERP August 2008

 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.

6. Lower-Layer Considerations

 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.
 The Identifier value in the EAP-Initiate/Re-auth packet is
 independent of the Identifier value in the EAP-Initiate/Re-auth-Start
 packet.
 The peer is responsible for retransmission of EAP-Initiate/Re-auth
 messages.
 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 [2]).  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 [2] for additional guidance on setting timers.
 The Identifier value in the EAP-Finish/Re-auth packet is the same as
 the Identifier value in the EAP-Initiate/Re-auth packet.
 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.

Narayanan & Dondeti Standards Track [Page 31] RFC 5296 ERP August 2008

 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
 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.
 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.
 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.

7. Transport of ERP Messages

 AAA Transport of ERP messages is specified in [11] and [12].

Narayanan & Dondeti Standards Track [Page 32] RFC 5296 ERP August 2008

8. Security Considerations

 This section provides an analysis of the protocol in accordance with
 the AAA key management requirements specified in [18].
    Cryptographic algorithm independence
       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 [3].  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.
    Strong, fresh session keys
       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.
    Limit key scope
       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.
    Replay detection mechanism
       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.

Narayanan & Dondeti Standards Track [Page 33] RFC 5296 ERP August 2008

    Authenticate all parties
       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.
    Peer and authenticator authorization
       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.
    Keying material confidentiality
       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.
       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.
       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.
       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

Narayanan & Dondeti Standards Track [Page 34] RFC 5296 ERP August 2008

       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.
    Confirm cryptosuite selection
       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.
    Uniquely named keys
       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.
    Prevent the domino effect
       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.
       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.

Narayanan & Dondeti Standards Track [Page 35] RFC 5296 ERP August 2008

    Bind key to its context
       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 [18].  The key usage, lifetime and the parties that
       have access to the keys are specified.
    Confidentiality of identity
       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.
    Authorization restriction
       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.
 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.
 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

Narayanan & Dondeti Standards Track [Page 36] RFC 5296 ERP August 2008

 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.
 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.

9. IANA Considerations

 This document specifies IANA registration of two new 'Packet Codes'
 from the EAP registry:
 o  5 (Initiate)
 o  6 (Finish)
 These values are in accordance with [2].
 This document also specifies creation of a new table, Message Types,
 in the EAP registry with the following assigned numbers:
 o  0 Reserved
 o  1 (Re-auth-Start, applies to Initiate Code only)
 o  2 (Re-auth, applies to Initiate and Finish Codes)
 o  3-191 IANA managed and assigned based on IETF Consensus [17]
 o  192-255 Private use
 Next, we specify creation of a new table, EAP Initiate and Finish
 Attributes, associated with EAP Initiate and Finish messages in the
 EAP registry with the following assigned numbers.

Narayanan & Dondeti Standards Track [Page 37] RFC 5296 ERP August 2008

 o  0: Reserved
 o  keyName-NAI: This is a TLV payload.  The Type is 1.
 o  rRK Lifetime: This is a TV payload.  The Type is 2.
 o  rMSK Lifetime: This is a TV payload.  The Type is 3.
 o  Domain name: This is a TLV payload.  The Type is 4.
 o  Cryptosuite list: This is a TLV payload.  The Type is 5.
 o  Authorization Indication: This is a TLV payload.  The Type is 6.
 o  7-127: Used to carry other non-channel-binding-related attributes.
    IANA managed and assigned based on IETF Consensus [17].
 o  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.
    Below are the current assignments (all of them are TLVs):
  • Called-Station-Id: 128
  • Calling-Station-Id: 129
  • NAS-Identifier: 130
  • NAS-IP-Address: 131
  • NAS-IPv6-Address: 132
    133-191: Used to carry other channel-binding-related attributes.
    IANA managed and assigned based on IETF Consensus [17].
 o  192-255: Reserved for Private use.
 We specify creation of another registry, 'Re-authentication
 Cryptosuites', with the following assigned numbers:
 o  0: Reserved
 o  1: HMAC-SHA256-64
 o  2: HMAC-SHA256-128
 o  3: HMAC-SHA256-256
 o  4-191: IANA managed and assigned based on IETF consensus [17]

Narayanan & Dondeti Standards Track [Page 38] RFC 5296 ERP August 2008

 o  192-255: Reserved for Private use.
 Further, this document registers a Re-auth usage label from the "USRK
 Key Labels" name space with a value
    EAP Re-authentication Root Key@ietf.org
 and DSRK-authorized delivery key from the "USRK Key Labels" name
 space
    DSRK Delivery Authorized Key@ietf.org
 in accordance with [3].

10. Acknowledgments

 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.

11. References

11.1. Normative References

 [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.
 [2]   Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
       Levkowetz, "Extensible Authentication Protocol (EAP)",
       RFC 3748, June 2004.
 [3]   Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
       "Specification for the Derivation of Root Keys from an Extended
       Master Session Key (EMSK)", RFC 5295, August 2008.

Narayanan & Dondeti Standards Track [Page 39] RFC 5296 ERP August 2008

 [4]   Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
       Access Identifier", RFC 4282, December 2005.
 [5]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
       for Message Authentication", RFC 2104, February 1997.

11.2. Informative References

 [6]   Arkko, J. and H. Haverinen, "Extensible Authentication Protocol
       Method for 3rd Generation Authentication and Key Agreement
       (EAP-AKA)", RFC 4187, January 2006.
 [7]   Lopez, R., Skarmeta, A., Bournelle, J., Laurent-Maknavicus, M.,
       and J. Combes, "Improved EAP keying framework for a secure
       mobility access service", IWCMC '06, Proceedings of the 2006
       International Conference on Wireless Communications and Mobile
       Computing, New York, NY, USA, 2006.
 [8]   Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", Work
       in Progress, October 2003.
 [9]   Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti,
       "Handover Key Management and Re-Authentication Problem
       Statement", RFC 5169, March 2008.
 [10]  Institute of Electrical and Electronics Engineers, "IEEE
       Standards for Local and Metropolitan Area Networks: Port based
       Network Access Control, IEEE Std 802.1X-2004", December 2004.
 [11]  Nakhjiri, M. and Y. Ohba, "Derivation, delivery and management
       of EAP based keys for handover and re-authentication", Work
       in Progress, February 2008.
 [12]  Gaonkar, K., Dondeti, L., Narayanan, V., and G. Zorn, "RADIUS
       Support for EAP Re-authentication Protocol", Work in Progress,
       February 2008.
 [13]  Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
       Authentication Dial In User Service (RADIUS)", RFC 2865,
       June 2000.
 [14]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
       In User Service) Support For Extensible Authentication Protocol
       (EAP)", RFC 3579, September 2003.
 [15]  Dondeti, L. and H. Tschofenig, "Diameter Support for EAP Re-
       authentication Protocol", Work in Progress, November 2007.

Narayanan & Dondeti Standards Track [Page 40] RFC 5296 ERP August 2008

 [16]  Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
       RFC 3162, August 2001.
 [17]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
       Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
 [18]  Housley, R. and B. Aboba, "Guidance for Authentication,
       Authorization, and Accounting (AAA) Key Management", BCP 132,
       RFC 4962, July 2007.

Narayanan & Dondeti Standards Track [Page 41] RFC 5296 ERP August 2008

Appendix A. Example ERP Exchange

 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.

Authors' Addresses

 Vidya Narayanan
 Qualcomm, Inc.
 5775 Morehouse Dr.
 San Diego, CA  92121
 USA
 Phone: +1 858-845-2483
 EMail: vidyan@qualcomm.com
 Lakshminath Dondeti
 Qualcomm, Inc.
 5775 Morehouse Dr.
 San Diego, CA  92121
 USA
 Phone: +1 858-845-1267
 EMail: ldondeti@qualcomm.com

Narayanan & Dondeti Standards Track [Page 42] RFC 5296 ERP August 2008

Full Copyright Statement

 Copyright (C) The IETF Trust (2008).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Narayanan & Dondeti Standards Track [Page 43]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5296.txt · Last modified: 2008/08/26 23:47 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki