Subject: [HOKEY] WGLC comments on ER

From: Charles Clancy <[email-masked]>
Date: Thu, 01 Nov 2007 11:05:45 -0400

ER Authors,

You may want to double-check usage of MAY/may, MUST/must, and 
SHOULD/should.  They seem to be used a little inconsistently.  All my 
other copious comments are inline in the attached document.

-- 
t. charles clancy, ph.d.                 eng.umd.edu/~tcc
electrical & computer engineering, university of maryland

Network Working Group                                       V. Narayanan
Internet-Draft                                                L. Dondeti
Intended status: Standards Track                          QUALCOMM, Inc.
Expires: April 6, 2008                                   October 4, 2007

         EAP Extensions for EAP Reauthentication Protocol (ERP)
                        draft-ietf-hokey-erx-05

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 6, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

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 EAP keying hierarchy to support an
   EAP method-independent protocol for efficient Re-authentication
   between the peer and the server through an authenticator.

Narayanan & Dondeti       Expires April 6, 2008                 [Page 1]

Internet-Draft                     ERP                      October 2007

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  ERP Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  ERP with a Local ER Server . . . . . . . . . . . . . . . .  6
   4.  ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Key Derivations and Properties . . . . . . . . . . . . . .  9
       4.1.1.  rRK Derivation . . . . . . . . . . . . . . . . . . . .  9
       4.1.2.  rRK Properties . . . . . . . . . . . . . . . . . . . .  9
       4.1.3.  rIK Derivation . . . . . . . . . . . . . . . . . . . . 10
       4.1.4.  rIK Properties . . . . . . . . . . . . . . . . . . . . 11
       4.1.5.  rIK usage  . . . . . . . . . . . . . . . . . . . . . . 11
       4.1.6.  rMSK Derivation  . . . . . . . . . . . . . . . . . . . 11
       4.1.7.  rMSK Properties  . . . . . . . . . . . . . . . . . . . 12
   5.  Protocol Description . . . . . . . . . . . . . . . . . . . . . 13
     5.1.  ERP Bootstrapping  . . . . . . . . . . . . . . . . . . . . 13
       5.1.1.  ERP Bootstrapping with a Local ER Server . . . . . . . 15
     5.2.  EAP Re-auth Protocol . . . . . . . . . . . . . . . . . . . 16
       5.2.1.  Failure Handling . . . . . . . . . . . . . . . . . . . 18
     5.3.  New EAP Messages . . . . . . . . . . . . . . . . . . . . . 19
       5.3.1.  EAP Initiate Re-auth Packet  . . . . . . . . . . . . . 20
       5.3.2.  EAP Finish Re-auth Packet  . . . . . . . . . . . . . . 23
       5.3.3.  EAP Initiate Re-auth-Start Packet  . . . . . . . . . . 25
       5.3.4.  TV and TLV Attributes  . . . . . . . . . . . . . . . . 26
     5.4.  Replay Protection  . . . . . . . . . . . . . . . . . . . . 27
     5.5.  Channel Binding  . . . . . . . . . . . . . . . . . . . . . 28
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 32
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 32
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 33
   Appendix A.  Example ERP Exchange  . . . . . . . . . . . . . . . . 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
   Intellectual Property and Copyright Statements . . . . . . . . . . 35

Narayanan & Dondeti       Expires April 6, 2008                 [Page 2]

Internet-Draft                     ERP                      October 2007

1.  Introduction

   The extensible authentication protocol (EAP) is a generic framework
   for transport of methods that authenticate two parties; the
   authentication is either one-way or mutual.  The primary purpose is
   network access control, and a key generating method is recommended to

** s/key generating/key-generating/

   enforce access control.  The EAP keying hierarchy defines two keys
   that are derived at the top level - the master session key (MSK) and

** s/ - /: /
** s/master session key/Master Session Key/

   the extended MSK (EMSK).  In the most common deployment scenario, a

** s/extended/Extended/

   peer and a server authenticate each other through a third party known
   as the authenticator.  The authenticator or an entity controlled by
   the authenticator enforces access control.  After successful
   authentication, the server transports the MSK to the authenticator;
   the authenticator and the peer derive transient session keys (TSK)
   using the MSK as the authentication key or a key derivation key and
   use the TSK for per-packet access enforcement.

   When a peer moves from one authenticator to another, it is desirable
   to avoid full EAP authentication.  The full EAP exchange with another

** s/avoid full/avoid a full/

   run of the EAP method takes several round trips and significant time

** s/takes/can take/

   to complete, causing delays in handoff times.  Some EAP methods

** s/handoff/handover/

   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 roundtrips in most

s/roundtrips/round trips/

   cases (e.g., [6]).  It is also important to note that many methods do
   not offer support for Re-authentication.  Thus, it is beneficial to
   have efficient Re-authentication support in EAP rather than in
   individual methods.

** (why is Re-authentication always capitalized?)

   Key sharing across authenticators is sometimes used as a practical
   solution to lower handoff times.  In that case, compromise of an

** s/handoff/handover/

   authenticator results in compromise of keying material established
   via other authenticators.

   Other solutions for fast reauthentication exist in the literature [7]
   [8].

** s/reauth/re-auth/
** Quick sentence saying how these approaches are different might be good.

   In conclusion, there is a need to design an efficient EAP Re-
   authentication mechanism that allows a fresh key to be established
   between the peer and an authenticator without having to execute the
   EAP method again.  The EAP Re-authentication problem statement is
   described in detail in [9].

   This document specifies EAP Reauthentication Extensions (ERX) for
   efficient re-authentication using EAP.  The protocol that uses these
   extensions itself is referred to as the EAP Reauthentication Protocol
   (ERP).  It supports EAP method independent Re-authentication for a
   peer that has valid, unexpired key material from a previously

Narayanan & Dondeti       Expires April 6, 2008                 [Page 3]

Internet-Draft                     ERP                      October 2007

   performed EAP authentication.  The protocol and the key hierarchy
   required for EAP Reauthentication is described in this document.

** Reauthentication vs Re-authentication vs re-authentication.  
** Need to be consistent throughout.

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 terminology defined in [2] and in [3].  In
   addition, this document uses the following terms:

** Suggestion: This document uses the basic EAP terminology [2] and 
** EMSK keying hierarchy terminology [3].  In addition...

      ER peer - An EAP peer that supports the EAP Re-authentication
      protocol

      ER Authenticator - An entity that supports the authenticator
      functionality for EAP Reauthentication 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.

      ERX: EAP Reauthentication extensions to support EAP
      reauthentication.

Sounds a bit ... redundant.

      ERP: EAP Reauthentication Protocol that use the reauthentication
      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.

3.  ERP Overview

** The sectioning seems strange here.  3 = "ERP Overview" and 3.1 = "ERP with
** a local server".  I think the tree needs rebalancing.  I suggest a brief
** intro, and then 2 subsections talking about ERP with and without a local
** server.

   Figure 1 shows the protocol exchange.  The first time the peer
   attaches to an authenticator, it performs a full EAP exchange with
   the EAP server; as a result an MSK is distributed to the
   authenticator.  The MSK is then used by the authenticator and the
   peer to generate TSKs as needed.  At the time of the initial EAP
   exchange, the peer and the server derive a Re-authentication Root Key
   (rRK).  The rRK may be derived from the EMSK or from a Domain
   Specific Root Key (DSRK).  The rRK is only available to the peer and

Narayanan & Dondeti       Expires April 6, 2008                 [Page 4]

Internet-Draft                     ERP                      October 2007

   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 uses the rIK to provide proof of possession while performing an
   ERP exchange at a later time.  The rIK is also never handed out to
   any entity and is only available to the peer and server.

** "peer" and "Server -- are these "ER Peer" and "ER Server"?
** Should specify that unqualified peers and servers are ER in the
** terminology section, like was done for authenticator.

   Peer               Authenticator                   Server
   ====               =============                   ======

    <--- EAP Request/ ------
            Identity

    ----- EAP Response/ --->
            Identity          ---EAP Response/Identity-->

    <------------ EAP Method exchange------------------->

                              <----MSK, EAP Success------

    <---EAP Success---------

        Peer               Authenticator                   Server
        ====               =============                   ======

    [<-- EAP Request/ ------
        Identity]
    [<-- EAP Initiate/ ------
        Reauth-Start]

    ---- EAP Initiate/ ----> ----EAP Initiate/ ---------->
          Reauth/                  Reauth/
         [Bootstrap]              [Bootstrap]

    <--- EAP Finish/ ------> <---rMSK,EAP Finish/---------
          Reauth/                   Reauth/
        [Bootstrap]               [Bootstrap]

** Why is there an arrow pointing to the right for the EAP Finish?
** Also, you might want to distinguish between an EAP server and an ER server.

                          Figure 1: ERP Exchange

   When the peer subsequently identifies a target authenticator that
   supports EAP Reauthentication, it performs an ERP exchange, as shown
   in Figure 1 as well; the exchange itself may happen when the peer

** Suggestion: ... it also performs an ERP exchange, as shown in Figure 1; ...

   attaches to a new authenticator supporting EAP Reauthentication, or
   prior to attachment.  The peer initiates ERP by itself; it may also

Narayanan & Dondeti       Expires April 6, 2008                 [Page 5]

Internet-Draft                     ERP                      October 2007

   do so in response to an EAP Request Identity or EAP Initiate Reauth-
   Start message from the new authenticator.  The EAP Initiate Reauth-
   Start message allows the authenticator to initiate the ERP exchange.
   It is plausible that the authenticator does not know whether the peer
   supports ERP and whether it has performed a full EAP authentication
   through another authenticator and hence the authenticator initiation
   of the ERP exchange may require the authenticator to send both the
   EAP Request Identity and EAP Initiate Reauth-Start messages.

   We introduce two new codes to EAP: EAP Initiate and EAP Finish.  The
   peer sends an EAP Initiate Re-auth message that includes peer-id or a

** s/includes peer-id/includes the peer-id/

   temporary NAI based on the rIKname, and a sequence number for replay
   protection.  The EAP Initiate Re-auth message is integrity protected
   with the rIK.  The message is routed based on the rIKname when it is
   in the form of an NAI, and if rIKname is also not present, the

** Citation for NAI.

   message is routed based on the peer-id.  The server uses the rIKname
   or the peer-id in that order to lookup 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.

   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 [10] describes another approach to key
   management and delivery aspects.

** I don't think it's necessarily "another approach", which would imply it
** replaces the one presented here.  It would, in fact, not replace 
** distribution of keying material from the HOKEY server to the 
** authenticator, rather it allows for distribution of the rRK from the 
** EAP server to the ER server.

** Suggested text: "Ongoing work in [10] 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 AAA trust
** relationship with the EAP server."

   In an ERP bootstrap exchange, the peer may request the rRK lifetime
   to be sent to it.  If so, the ER server sends the lifetime along with
   the EAP Finish Re-auth message.

   The peer verifies the replay protection and the origin 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

** s/lower layer/lower-layer/

   protocol is ready to be triggered after this point.

3.1.  ERP with a Local ER Server

   The defined ER extensions allow executing the ERP with a local ER
   server that may be topologically closer to the authenticator.  The
   local ER server may be collocated with a local AAA server.  The peer
   may learn about the presence of a local ER server in the network and
   the local domain (or ER server) name either via the lower layer or by
   means of ERP bootstrapping.  Figure 2 shows the full EAP and
   subsequent local ERP exchange with a local ER server.

Narayanan & Dondeti       Expires April 6, 2008                 [Page 6]

Internet-Draft                     ERP                      October 2007

   Peer           Authenticator       Local Server       Home Server
   ====           =============       ============       ===========

    <-- EAP Request/ -----
          Identity

    --- EAP Response/ --->
          Identity         --EAP Response/-->
                               Identity       --EAP Response/Identity->
                                             [DSRK Req, Domain Identity]

    <------------------------ EAP Method exchange------------------->

                                           <---MSK, DSRK, EAP Success--

                       <---MSK, EAP Success--

      <---EAP Success---

        Peer               Authenticator                Local Server
        ====               =============                ============

    [<-- EAP Request/ ------
        Identity]
    [<-- EAP Initiate/ ------
        Reauth-Start]

    ---- EAP Initiate/ ----> ----EAP Initiate/ ---------->
          Reauth/                  Reauth/

    <--- EAP Finish/ ------> <---rMSK,EAP Finish/---------
          Reauth/                   Reauth/

                       Figure 2: Local ERP Exchange

   As shown in Figure 2, 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

** s/AAA entities/AAA entities, such as a AAA proxy,/

   in the path between the authenticator and the home EAP server of the
   peer).  In that case, at the end of a full authentication exchange,
   the DSRK may be provided to the local ER server.  Alternatively, the
   DSRK can be obtained at the time of an ERP bootstrap exchange with
   the home server.  The local ER server then computes a DS-rRK and a
   DS-rIK (and the appropriate key names) from the DSRK as defined in

Narayanan & Dondeti       Expires April 6, 2008                 [Page 7]

Internet-Draft                     ERP                      October 2007

   Section 4.1.1 and Section 4.1.3 below.  The peer also derives the
   DSRK, followed by the DS-rRK and the DS-rIK (and the appropriate key
   names) following the EAP or ERP bootstrap exchange.

** Don't the latest versions of the EMSK doc call it a DS-RK?
** If not, then nevermind, if so, please update the terminology here.

   Subsequently, when the peer attaches to an authenticator within the
   local ER domain, it may perform an ERP exchange with the local ER
   server to obtain an rMSK for the new authenticator.

   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 visited domain.  The realm in the rIKname or the peer-id reflects
   the ER server's domain.

4.  ER Key Hierarchy

   We define a key hierarchy for ER, rooted at the rRK, and derived as a
   result of a full EAP exchange.  The rRK may be derived from an EMSK
   or DSRK as specified in this document.  For the purpose of rRK
   derivation, this document derives a Usage Specific Root Key (USRK) or
   a Domain Specific USRK (DS-USRK) in accordance with [3] for
   Reauthentication.  The USRK designated for Re-authentication is the
   Re-authentication root key (rRK).  A DS-USRK 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 are 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 a rIK and one or more rMSKs.  The figure
   below shows the key hierarchy with the rRK, rIK and rMSKs.

             rRK
              |
     +--------+--------+
     |        |        |
    rIK     rMSK1 ...rMSKn

                 Figure 3: Re-authentication Key Hierarchy

Narayanan & Dondeti       Expires April 6, 2008                 [Page 8]

Internet-Draft                     ERP                      October 2007

4.1.  Key Derivations and Properties

4.1.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 = prf+ (K, S), where,

      K = EMSK or K = DSRK and

      S = rRK Label + "\0" + NULL + length

   The rRK Label is an IANA-assigned ASCII string "EAP Re-authentication
   Root Key" assigned from the Key Label name space in accordance with
   [3].  This document specifies IANA registration for the rRK label
   above.

** Might want to specify 8-bit ASCII -- crazy people might try to use
** 7-bit ASCII.

   The prf+ operation is as defined in [3].

   Along with the rRK, a unique rRK name is derived to identify the rRK.

   The rRKname is derived as follows.

   rRKname = prf-64 (NameDerivationKey, rRK Label)

   where the prf-64 operation is as defined in [3].

   NameDerivationKey = EAP Session-ID, when K used in rRK derivation is
   the EMSK,

   NameDerivationKey = DSRK Name, when K used in rRK derivation is the
   DSRK.

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

Narayanan & Dondeti       Expires April 6, 2008                 [Page 9]

Internet-Draft                     ERP                      October 2007

   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.

** The rRK is a USRK or DS-USRK.  It is either derived from an EMSK or DSRK.
** Could it be the case that the DSRK lives at a local AAA server, and the
** local ER server is physically distinct, and the rRK might be transported
** from the AAA server to the ER server?  Or, are we requring that these
** two entities by colocated in the same device?

   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 removed
      from use at that time.

** s/expires and removed/expired and MUST be removed/

4.1.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 = prf+ (K, S ) where,

      K = rRK and

      S = rIK Label + "\0" + length

   The rIK Label is the ascii string "Re-authentication Integrity Key"
   and the length refers to the length of the rIK in octets.

   The PRF used MAY be the same as that used by the EAP method - using
   the PRF from the EAP method provides algorithm agility.  Otherwise,
   the default PRF used is HMAC-SHA-256.  The PRF is specified as part
   of the ERP message exchange.

   The rIKname is derived as follows.

   rIKname = prf-64 (rRKname, rIK Label)

   where prf-64 is the first 64 bits from the output of the PRF.  The
   PRF is the same as that used in the derivation of the rIK.

   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.

** How does a peer know whether a server used prf-64 or the original
** EAP method's PRF to generate the rIK?

Narayanan & Dondeti       Expires April 6, 2008                [Page 10]

Internet-Draft                     ERP                      October 2007

4.1.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 is expired when the EMSK expires and removed from
      use at that time.

** add normative language about deletion

4.1.5.  rIK usage

** s/usage/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
   all ERP messages protected with that key.  The peer and the server
   store the algorithm information after the first use and the same
   algorithm for all subsequent uses of that rIK.

   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 [4].  In
   case of cipher-based MAC algorithms, if the required key length is
   less than 32 octets, the rIK is hashed using HMAC-SHA-256 and the
   most significant 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 most significant k octets of the rIK are used by
   the cipher-based MAC algorithm.

** The server has no control over what MAC is used?  This seems bad.
** A server should be able to enforce policy about what MAC should be
** used in a network.  There should be a NACK message the server can
** send in response to an eap-reauth-init message indicating the MAC
** is no good, and provide a list of acceptable MACs.

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

Narayanan & Dondeti       Expires April 6, 2008                [Page 11]

Internet-Draft                     ERP                      October 2007

   The rMSK is derived as follows.

   rMSK = prf+ (K, S ) where,

      K = rRK and

      S = rMSK label + "\0" + SEQ + length

   The rMSK label is the ascii string "Re-authentication Master Session
   Key" and the length refers to the length of the rMSK in octets.

** same 7bit vs 8bit question

   The SEQ is the sequence number sent by the peer in the EAP Initiate
   Re-auth message.

   The PRF is specified as part of the ERP message exchange.  The
   default PRF used is HMAC-SHA-256.

   The rMSK name is derived as follows.

   rMSK_name = prf-64 (rRK, "rMSK Name")

   where prf-64 is the first 64 bits from the output of the PRF.  The
   PRF may be specified in the EAP Re-auth message.

** Grammar issues -- "where..." is not a complete sentence.  Perhaps
** change s/follows./follows:/

   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.

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

** s/must/MUST, s/may/MAY/

Narayanan & Dondeti       Expires April 6, 2008                [Page 12]

Internet-Draft                     ERP                      October 2007

   o  A given rMSK MUST NOT be shared by multiple authenticators.

5.  Protocol Description

   ERP allows a peer and server to verify proof of possession of keying
   material from an earlier EAP method run and establish a security
   association between the peer and an authenticator.  The authenticator
   acts as a pass-through entity for the Re-auth protocol in a manner
   similar to that described in RFC 3748 [2].  ERP is a single roundtrip

** s/roundtrip/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.

5.1.  ERP Bootstrapping

   When the peer requires the local domain identity to use ERP in the
   local domain, or when it moves to a new domain and needs to have a
   new DSRK delivered to the local ER server and wants to obtain the
   domain identity for domain specific key derivation, it can use the
   bootstrapping process with the home domain ER server.

   We identify two types of bootstrapping for ERP: explicit and implicit
   bootstrapping.  In implicit bootstrapping, the domain specific keys
   are delivered to the local ER server during the EAP exchange.  The
   peer learns the domain identity through out of band means.  When the

** s/out of band/out-of-band/

   domain identity is available to the peer during or after the full EAP
   authentication, it attempts to use ERP when it associates with a new
   authenticator.

   For explicit bootstrapping, the peer initiates the EAP Re-auth
   exchange with the bootstrapping flag turned on immediately after the
   full EAP authentication finishes.  The following steps summarize the
   process:

   o  The peer sends the EAP Initiate Re-auth message with the
      bootstrapping flag turned on.  It is RECOMMENDED that the
      authenticator hold on to the state (e.g., called station id in
      RADIUS) that allows all messages of a full EAP conversation to be

** s/RADIUS) that/ RADIUS).  This/

      routed to the same server.  The EAP Initiate Re-auth message
      contains one or more TLVs containing identification information to
      assist the authenticator further in routing the message to the
      appropriate ER server -- in this case to the ER server that holds
      the EMSK, rRK and rIK.

** s/rRK and/rRK, and/

      *  It is mandatory to send the rIKname either by itself, or as
         part of an NAI.  The authenticator may use the NAI to route the
         EAP Re-auth Bootstrap Initiate message.

** Either provide more info on embedding the rIKname in the NAI (format
** perhaps?) or a forward reference if it's defined later.

Narayanan & Dondeti       Expires April 6, 2008                [Page 13]

Internet-Draft                     ERP                      October 2007

      *  When the rIKname is not in the form of an NAI, the peer-id
         SHOULD be included.  The peer-id may be in the form of a
         pseudonym for identity privacy.

      *  If an NAI is not available as part of the peer-name or the
         rIKname, an authenticator routes the ERP packets to the default
         ER server in the network.  The default ER server may be the
         authenticator itself.  When neither an NAI nor a default ER
         server are available to an authenticator, it drops the ERP
         packets silently.

   o  In addition to the identities, the message contains a sequence
      number for replay protection, a crypto-suite, and an integrity
      checksum.  The crypto-suite indicates the authentication algorithm
      and the PRF.  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 that
      the rRK lifetime be sent to it.

   o  When an ERP capable authenticator receives EAP Initiate Re-auth
      message from a peer, it looks for local EAP forwarding state
      corresponding to the peer's lower layer address and forwards the
      message accordingly.  This forwarding is similar to that of
      messages of an EAP conversation.  It is RECOMMENDED that an ERP
      capable authenticator store that forwarding information for a

** s/ERP capable/ERP-capable/

      finite amount of time after the EAP Success message has been sent
      to the peer.

      *  In the absence of forwarding state, the authenticator parses
         the EAP Initiate Re-auth message to locate the rIKname, and if
         the rIKname is in the NAI form, uses that domain identity to
         forward the message.

      *  Otherwise, it finds the peer-id and uses the realm portion of
         the peer-id to route the EAP message to the appropriate server.

      *  In the absence of an NAI, the authenticator routes packets to
         the default ER server in the local domain.  If no such
         information is available, the authenticator drops the packets.

** silently?

   o  Upon receipt of an EAP Initiate Re-auth message, the server
      verifies whether the message is fresh or a replay by evaluating
      whether the received sequence number is equal to or greater than
      the expected sequence number for that rIK.  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

Narayanan & Dondeti       Expires April 6, 2008                [Page 14]

Internet-Draft                     ERP                      October 2007

      message with the relevant error value.  This error MUST NOT have
      any correlation to any EAP Success message that may have been
      received by the 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 is
      set to indicate that this is a bootstrapping exchange.  The
      message contains the following fields:

      *  A sequence number for replay protection.

      *  The rIKname so that the peer can correctly identify the rIK to
         verify the integrity and origin authentication of the Finish
         message.

      *  If the lifetime flag was set in the EAP Initiate Re-auth
         message, the ER server SHOULD include the rRK lifetime in the
         EAP Finish Re-auth message.

** why only SHOULD?

      *  An authentication tag to prove that the EAP Finish Re-auth
         message originates at a server that possesses the rIK
         corresponding to the rIKname.

   o  In addition, the rMSK is sent along with the EAP Finish Re-auth
      message, in a AAA attribute.

** Can we be more specific than a "AAA attribute"?  Is the MPPE format
** documented in an RFC, or is it proprietary?  Is there any other
** standard AAA attribute we could use?

   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 derived the 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 generate a TSK from the rMSK.  However, the
   bootstrapping exchange may be carried out via a new authenticator, in
   which case, the rMSK received is used by the lower layer.

** How does the peer know?  I assume that's an L2 problem?  For example,
** if an 11i authenticator wants to use the rMSK it would do another 4-way
** handshake?  But how would the peer know the new 4-way handshake uses
** the new PMK=rMSK?

** It would be nice if ERX could be used with a protocol such as 802.11,
** without having to write an IEEE document defining the 802.11 binding.
** Consequently, I think the less ambiguity, the better.

5.1.1.  ERP Bootstrapping with a Local ER Server

   When a local ER server is present, it may be in the path of the full
   EAP exchange performed by the peer.  In this case, the local ER
   server SHOULD include a request for DSRK and its domain or server

** s/for DSRK/for the DSRK/

   name along with the AAA message encapsulating the first EAP Response
   message sent by the peer.  If the EAP exchange is successful, the
   server sends a DSRK (for the local ER server) along with the EAP
   Success message.  The local ER server MUST extract the DSRK, if
   present, before forwarding the EAP Success message to the peer [11].
   Note that the MSK (also present along with the EAP Success message)
   is still extracted by the authenticator as usual.

** What are the plans for [11]?  Is the radex wg going to publish it?
** Shouldn't the reference be normative, considering tall the NORMATIVE
** text in this paragraph?  If so, then there's
** a publishing dependency -- [11] needs to be out simultaneous
** to this document.

Narayanan & Dondeti       Expires April 6, 2008                [Page 15]

Internet-Draft                     ERP                      October 2007

   If the peer performs an ERP bootstrapping exchange when a local ER
   server is present, the local ER server MUST include the DSRK request
   and its domain identity in the AAA message encapsulating the EAP
   Initiate Re-auth message sent by the peer.  If the exchange is
   successful, the home ER server MUST include a DSRK along with the EAP
   Finish Re-auth message.  The local ER server MUST extract the DSRK,
   if present, before forwarding the EAP Finish Re-auth message to the
   peer.

   When the server receives an EAP Initiate Re-auth message with the
   bootstrap flag set along with a DSRK request, it SHOULD return the
   domain identity to which the DSRK was sent, in the EAP Finish Re-auth
   message.  The other processing rules for the ERP bootstrapping
   exchange specified in Section 5.1 apply as well.

   When the peer receives an EAP Finish Re-auth message with the
   bootstrap flag set, if a local domain identity is present, it MUST
   use that to derive the appropriate DSRK, DS-rRK and DS-rIK.  If not,
   the peer SHOULD derive the domain specific keys using the domain

** s/domain specific/domain-specific/

   identity it learnt via the lower layer.  If the peer has no available

** s/learnt/learned -- are we British?

   domain identity, it must assume that there is no local ER server
   available.

   The RADIUS attributes required to carry the DSRK request, local
   domain identity and the DSRK itself along with the encapsulated EAP

** s/identity and/identity, and/

   messages are specified in [11].

5.2.  EAP Re-auth Protocol

   When a peer that has an active rRK and rIK identifies a new/target

** new/target?  I don't know what that means.

   authenticator that supports ERP, it may perform an ERP exchange with
   the new authenticator supporting ERP.  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.  When an ERP capable authenticator sends an EAP
   Request Identity the peer may in response initiate the EAP Re-

** When talking about RFC3748 messages, we shoud format their titles
** properly -- I think it's "EAP-Request/Identity"

   authentication exchange.  Additionally, an ERP capable authenticator

** s/ERP capable/ERP-capable/g
** note the "/g"... I'm not going to point this out in the rest of the doc.

   may also send an EAP Initiate/Reauth-Start message to indicate

** This message naming is inconsistent with earlier references.
** I suggest all the HOKEY messages be named and formatted
** consistently with the RFC 3748 style.

   support for ERP.  The peer may or may not wait for these messages to
   arrive to initiate the EAP Initiate Re-auth message.

** See, here it is again without the slash.

   Notes on authenticator state machine:

   If an authenticator that is waiting on an EAP Response after sending

Narayanan & Dondeti       Expires April 6, 2008                [Page 16]

Internet-Draft                     ERP                      October 2007

   an EAP Request packet to the peer receives an EAP Initiate Re-auth
   packet from the peer, it should follow the EAP Re-authentication
   exchange and determine Success or Failure of the exchange based on

** why are success and failure capitalized?

   the success or failure of the EAP Re-authentication exchange itself.
   The authenticator SHOULD also cancel any retransmission timers
   associated with the EAP Request packet.  The same behavior applies

** uh oh... we're specifying behavior in the EAP state machine...

   when the authenticator sends an EAP Initiate Reauth-Start message to
   the peer and receives an EAP Initiate Re-auth packet from the peer as
   well.

   The EAP Initiate Reauth-Start message is sent by an ERP capable
   authenticator; it is retransmitted as many times as the EAP Request
   Identity message but has a different Identifier value.  The EAP
   Initiate Re-auth message from the peer may have originated before the
   peer receives any of the two messages from the authenticator and thus
   the Identifier value in the EAP Initiate Re-auth message is
   independent of the Identifier value in the EAP Initiate Re-auth Start
   and the EAP Request Identity messages.

** most of that paragraph is one huge, unintelligble sentence.
** that paragraph needs to be rewritten much more clearly.

   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 section below looks nearly identical to the bootstrap protocol
** description.  Any comments I had for the bootstrap section would
** likely apply here as well.

      The peer sends an EAP Initiate Re-auth message including one or
      more identity TLVs: the rIKname, and optionally the peer-id; also
      included are the peer's rIK sequence number, and a crypto-suite
      indicating the cryptographic algorithms used.  The message is
      integrity protected with the rIK.  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 sets the lifetime flag
      to request the rRK lifetime from the server.  It may learn this to
      know when to trigger an EAP method exchange.

      If the rIKname is in the form of an NAI, the authenticator MUST
      use that NAI to route the message.  If the rIKname is not in the
      form of an NAI, the authenticator MUST use the NAI in the peer-id
      to forward the message via AAA.  If neither are available, the
      authenticator MUST forward the ERP messages to the local ER
      server.  If none of these rules apply, the authenticator MUST drop
      the packets silently.

      The server uses the rIKname to lookup the rIK.  It first verifies
      whether the sequence number is equal to or greater than the

Narayanan & Dondeti       Expires April 6, 2008                [Page 17]

Internet-Draft                     ERP                      October 2007

      expected sequence number.  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 the verifications fail,
      the server sends an EAP Finish Re-auth message with the Result
      flag set to '1' (Failure).  Otherwise, it computes an rMSK from
      the rRK using the sequence number as the additional input to the
      key derivation.

      The server then sends an EAP Finish Re-auth message containing the
      rIK sequence number and the rIKname.  The sequence number MUST be
      same as the received sequence number.  The local copy of the
      sequence number is incremented by 1.  The EAP Finish Re-auth
      message is also integrity protected with the rIK.  The server may
      include the server-id with this message.

      If the lifetime flag was set in the EAP Initiate Re-auth message,
      the ER server SHOULD include the rRK lifetime in the EAP Finish
      Re-auth message.

      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 a EAP Finish Re-auth message with that sequence number.
      It then looks up the rIKname and verifies the integrity of the
      message.  This also verifies the proof of possession of the rIK at
      the server.  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.  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.

   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
   replay and integrity checks are successful, the peer MUST assume

Narayanan & Dondeti       Expires April 6, 2008                [Page 18]

Internet-Draft                     ERP                      October 2007

   failure of the exchange and terminate the ER state machine.  If the
   replay and/or integrity checks fail, it may mean that the server did
   not have the rIK for the peer or that the failure message was sent by
   an attacker.  Hence, in this case, the peer SHOULD continue the ERP
   exchange per the retransmission timers before declaring a failure.

5.3.  New EAP Messages

   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 RFC3748 [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 4: EAP Packet

      Code

         5 Initiate

         6 Finish

         Two new code values are defined for the purpose of ERP.  The
         code values itself are TBD based on IANA assignment.

** s/itself/themselves/

      Identifier

         The Identifier field is one octet.  The Identifier field MUST
         be the same if a Initiate Re-auth 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 Re-auth message MUST match
         that of the currently outstanding Initiate Re-auth message.  A
         Peer or Authenticator receiving a Finish Re-auth message whose
         Identifier value does not match that of the currently
         outstanding Initiate Re-auth message MUST silently discard the
         packet.

** is this behavior different than the 3748 behavior?  if not, then
** i don't think it needs to be detailed.  if so, then indicate
** that divergence.

Narayanan & Dondeti       Expires April 6, 2008                [Page 19]

Internet-Draft                     ERP                      October 2007

         In order to avoid confusion between new EAP Initiate Re-auth
         messages and retransmissions, the peer must choose a an
         Identifier value that is different from the previous 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
         (assigned Type 1), Re-auth-Start (assigned Type 2).

** Aesthetically, I think those type assignments should be swapped.

      Type-Data

         The Type-Data field varies with the Type of Re-authentication
         packet.

5.3.1.  EAP Initiate Re-auth Packet

   The EAP Initiate Re-auth packet contains the parameters shown in
   Figure 5 :

   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                         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Crypto-Suite  |        Authentication Tag                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 5: EAP Initiate Re-auth Packet

      Type = 1.

      Flags

Narayanan & Dondeti       Expires April 6, 2008                [Page 20]

Internet-Draft                     ERP                      October 2007

         '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 rRK lifetime 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 zero every time a new rRK is
      derived.

      TVs or TLVs: In the TV payloads, there is a 1-octet type payload

** TV and TLV are undefined acronyms.

      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.

         rIKname: This is carried in a TV payload.  The Type is 1 and
         the value is a 64-bit field computed as specified in Section
         Section 4.1.3 and is used to identify the rIK with which the
         ERP messages are protected.

         rIKname as NAI: This is carried in a TLV payload.  The Type is
         2.  The NAI is variable in length, not exceeding 253 octets.
         If the rIK is derived from the EMSK, the realm part of the NAI
         is the home domain identity and if the rIK is derived from a
         DSRK, the realm part of the NAI is the domain identity used in
         the derivation of the DSRK.  The computed rIKname itself serves
         as the username part of the NAI.

         Peer-Id: This is a TLV payload.  The Type is 3.  The Peer-Id is
         the NAI of the peer, and is variable in length, not exceeding
         253 octets.

** Are these ASCII?  UTF8?  Unicode?

         Authenticator Identifier: This is a TLV payload.  The Type is
         TBD (see Section 5.5 for additional discussion).  The server
         sends the Authenticator Identifier so that the peer can verify
         the identity seen at the lower layer, if channel binding is to
         be supported.

      Crypto Suite: This field indicates the integrity and the PRF used
      for ERP.  Key lengths and output lengths are either indicated or
      are obvious from the crypto suite name.  We specify some cipher-
      suites below, in the format Integrity-algorithm_PRF-name:

Narayanan & Dondeti       Expires April 6, 2008                [Page 21]

Internet-Draft                     ERP                      October 2007

      *  0 RESERVED

      *  1 HMAC-SHA256-64_HMAC-SHA-256

      *  2 HMAC-SHA256-128_HMAC-SHA-256

      *  3 HMAC-SHA256-256_HMAC-SHA-256

** Why is suite 1 supported?  64 bits seems too small.
** Also, HMAC-SHA-256 should be HMAC-SHA256
** Which are mandatory to implement?

      Authentication Tag: This field contains the integrity checksum
      over the ERP packet.  The length of the field is indicated by the
      Crypto Suite.

5.3.1.1.  Peer Operation

   When an ER capable peer receives an EAP Request Identity message from
   an Authenticator, it checks to see if it has valid EAP state from a
   previous EAP authentication.  If the peer has state from a previous
   authentication, and if it knows that the Authenticator is ER capable,
   it sends an EAP Initiate Re-auth message instead of an EAP Response
   Identity message.  The peer may, upon attachment to an authenticator
   send an EAP Initiate Re-auth message in an unsolicited manner.

5.3.1.2.  Authenticator Operation

   If the Authenticator does not recognize the EAP Initiate Code, it
   silently discards the EAP Initiate Re-auth message.

   The Authenticator then parses the message to find the rIKname and
   peer-id TLVs.

   If the rIKname is in the form of an NAI, the authenticator MUST use
   that NAI to route the message.  If the rIKname is not in the form of
   an NAI, the authenticator MUST use the NAI in the peer-id to forward
   the message via AAA.  If neither are available, the authenticator
   MUST forward the ERP messages to the local ER server.  If none of
   these rules apply, the authenticator MUST drop the packets silently.

   The Authenticator sends the ERP messages just as it forwards other
   EAP messages to the EAP server.

5.3.1.3.  Server Operation

   The server uses the following steps in processing EAP Re-
   authentication messages:

      The server uses the rIKname to lookup the rIK.  It first verifies
      whether the sequence number is equal to or greater than the
      expected sequence number.  The server then proceeds to verify the

Narayanan & Dondeti       Expires April 6, 2008                [Page 22]

Internet-Draft                     ERP                      October 2007

      integrity of the message using the rIK, thereby verifying proof of
      possession of that key by the peer.  If the verifications fail,
      the server sends an EAP Finish Re-auth message with a Failure
      indication.  Otherwise, it computes an rMSK from the rRK using the
      sequence number.

5.3.2.  EAP Finish Re-auth Packet

   The EAP Finish Re-auth packet contains the parameters shown in
   Figure 6 :

   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                         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Crypto-Suite  |        Authentication Tag                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 6: EAP Finish Re-auth Packet

      Type = 1.

      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.

Narayanan & Dondeti       Expires April 6, 2008                [Page 23]

Internet-Draft                     ERP                      October 2007

      SEQ: A 16-bit sequence number is used for replay protection.  The
      SEQ number field is initialized to zero 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.

         rIKname: This is carried in a TV payload.  The Type is 1 and
         the value is a 64-bit field computed as specified in Section
         Section 4.1.3 and is used to identify the rIK with which the
         ERP messages are protected.

         rIKname as NAI: This is carried in a TLV payload.  The Type is
         2.  The NAI is variable in length, not exceeding 253 octets.
         If the rIK is derived from the EMSK, the realm part of the NAI
         is the home domain identity and if the rIK is derived from a
         DSRK, the realm part of the NAI is the domain identity used in
         the derivation of the DSRK.

         Peer-Id: This is a TLV payload.  The Type is 3.  The Peer-Id is
         the NAI of the peer, and is variable in length, not exceeding
         253 octets.

         Authenticator Identifier: This is a TLV payload.  The Type is
         TBD (see Section 5.5 for additional discussion).  The server
         sends the Authenticator Identifier so that the peer can verify
         the identity seen at the lower layer, if channel binding is to
         be supported.

      Crypto Suite: 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 crypto suite name.

      Authentication Tag: This field contains the integrity checksum
      over the ERP packet.  The length of the field is indicated by the
      Crypto Suite.

5.3.2.1.  Server Operation

   The server then sends an EAP Finish Re-auth message containing the
   rIK sequence number, and the rIKname; this message is also integrity
   protected with the rIK.  The server may include one or more server-
   ids with this message.  The server-id is for the peer to use to send
   future ERP messages.

Narayanan & Dondeti       Expires April 6, 2008                [Page 24]

Internet-Draft                     ERP                      October 2007

   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.

5.3.2.2.  Authenticator Operation

   The Authenticator Operation is similar to that in processing an EAP
   success message.  It extracts the rMSK just as it does an MSK from a
   AAA message containing an EAP success packet [11].

5.3.2.3.  Peer Operation

   The peer uses the following steps in processing an EAP Finish Re-auth
   message:

      The peer first checks if the identifier in the EAP Finish Re-auth
      message is the expected value.

      The peer then checks to see if the sequence number in the received
      message is the same as the sequence number in the EAP Initiate Re-
      auth message; otherwise it logs an error.

      Next, it uses the rIKname to lookup the appropriate rIK and
      verifies the integrity of the message.  If the verification
      succeeds, it proceeds to the next step; otherwise, it logs an
      error.

      The peer then uses the sequence number and the peer-id to compute
      the rMSK.

      The lower layer security association protocol can be triggered at
      this point.

5.3.3.  EAP Initiate Re-auth-Start Packet

   The EAP Initiate Re-auth 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     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Narayanan & Dondeti       Expires April 6, 2008                [Page 25]

Internet-Draft                     ERP                      October 2007

                Figure 7: EAP Initiate Re-auth-Start Packet

      Type = 2.

      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 domain identity to
      the peer.

5.3.3.1.  Authenticator Operation

   The authenticator optionally sends the EAP Initiate Reauth-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 may include the domain
   identity to allow the peer to learn it without lower layer support or
   the ERP bootstrapping exchange.

   The authenticator may re-transmit the EAP Initiate Reauth-Start
   message a few times for reliable transport.

5.3.3.2.  Peer Operation

   The peer may send the EAP Initiate Re-auth message in response to the
   EAP Initiate/Reauth-Start message from the authenticator.  If the
   peer does not recognize the Initiate code value, it silently discards
   the message.

   If the EAP Initiate Reauth-Start message contains the domain
   identity, and if the peer does not already have the domain
   information, the peer uses the domain identity to compute the DSRK
   and uses the corresponding DS-rIK to send an EAP Initiate Re-auth
   message in response.

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

Narayanan & Dondeti       Expires April 6, 2008                [Page 26]

Internet-Draft                     ERP                      October 2007

                       Figure 8: 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 9: TLV Attribute Format

   The following Types are defined in this document:

      '1' - rIKname: TV Payload

      '2' - rIKname as NAI: This is a TLV payload

      '3' - Peer-Id: This is a TLV payload

      '4' - Domain Identity: 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

         '129' - Calling-Station-Id

         '130' - NAS-Identifier

         '131' - NAS-IP-Address

         '132' - NAS-IPv6-Address

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

Narayanan & Dondeti       Expires April 6, 2008                [Page 27]

Internet-Draft                     ERP                      October 2007

   Finish Re-auth message.  It increments the expected sequence number
   by 1.

** is the peer required to also increment by 1, or can it increment
** by a number larger than 1?

   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.

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 and 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.  Other values may be
   added in future versions of this draft and the rest are IANA managed
   based on IETF Consensus [5].

6.  Security Considerations

   This section provides an analysis of the protocol in accordance with
   the AAA key management requirements specified in [12].

      Cryptographic Algorithm Independence

** These should be subsections, so they can be referenced earlier in 
** the document.

         The EAP Re-auth protocol satisfies this requirement.  The
         algorithm chosen by the peer for the PRF used in key derivation
         as well as for the MAC generation is indicated in the EAP Re-
         authentication Response message.  If the chosen algorithms are
         unacceptable, the EAP server returns an EAP Failure message in
         response.  Only when the specified algorithms 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 roundtrip 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-

Narayanan & Dondeti       Expires April 6, 2008                [Page 28]

Internet-Draft                     ERP                      October 2007

         demand when the peer requires a key with a new authenticator.
         Both the peer and the server contribute nonces that are used in
         the rMSK derivation.  Further, 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 are 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
         increments the sequence number when it receives and responds to
         the message.

      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 resulted from a previous EAP exchange in order to

** s/resulted/that resulted/

         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.

      Keying material confidentiality

         The peer and the server derive the keys independently using
         parameters known to each entity.  The rMSK is sent to the
         authenticator via the AAA protocol.  It is RECOMMENDED that the
         AAA protocol be protected using IPsec or TLS so that the key
         can be sent encrypted to the authenticator.

      Confirm ciphersuite selection

         The same ciphersuite used as a result of the EAP session to
         which a particular ERP exchange corresponds is used after the
         ERP exchange as well.  The EAP method executed during the full
         EAP exchange is responsible for confirming the ciphersuite
         selection.

** I think this is a little confusing.  ER can use the EAP method's
** ciphersuite, or its own, for the PRF.  I think when to use which and
** how needs significantly more explanation.

Narayanan & Dondeti       Expires April 6, 2008                [Page 29]

Internet-Draft                     ERP                      October 2007

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

      Bind key to its context

         All the keys derived for ERP are bound to the appropriate
         context using appropriate key labels.  Also, the rMSK is bound
         to the peer and server IDs.

   A denial of service 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 to that 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 EAP-Start capability of 802.11 and other similar

s/802.11/IEEE 802.11/

   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 and 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.  Alternately, the lower layers and AAA protocols may define
   mechanisms to allow two link layer 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.

7.  IANA Considerations

   This document requires IANA registration of two new EAP Codes:

   o  5 (Initiate)

Narayanan & Dondeti       Expires April 6, 2008                [Page 30]

Internet-Draft                     ERP                      October 2007

   o  6 (Finish)

   These values are in accordance with [2].

   This document also requires IANA registration of two new Types
   related to Initiate and one for Finish message :

   o  1 (Re-auth, applies to Initiate and Finish Codes),

   o  2 (Re-auth-Start, applies to Initiate Code only).

   Additional type values are IANA managed and assigned based on IETF
   Consensus.

   Next, a number of type values corresponding to the TLVs within EAP
   Initiate and Finish messages.  Those are as follows:

   o  rIKname: TV Payload.  The Type is 1

   o  rIKname as NAI: This is a TLV payload.  The Type is 2.

   o  Peer-Id: This is a TLV payload.  The Type is 3.

   o  Domain Identity: This is a TLV payload.  The Type is 4.

   o  The TLV type range of 128-191 is reserved to carry CB information
      in the EAP Initiate and 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

      Other values may be added in future versions of this draft and the
      rest are IANA managed based on IETF Consensus.

   o  192-255 is reserved for Experimental/Private use.

   Further, this document registers a USRK label with a value "EAP Re-
   authentication Root Key" in accordance with [3].

   We specify some cipher-suites below, in the format Integrity-

Narayanan & Dondeti       Expires April 6, 2008                [Page 31]

Internet-Draft                     ERP                      October 2007

   algorithm_PRF-name:

   o  0 RESERVED

   o  1 HMAC-SHA256-64_HMAC-SHA-256

   o  2 HMAC-SHA256-128_HMAC-SHA-256

   o  3 HMAC-SHA256-256_HMAC-SHA-256

   o  4-191 IANA managed and assigned based on IETF consensus

   o  192-255 is reserved for Experimental/Private use.

8.  Acknowledgments

   In writing this draft, 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, Dan Harkins, Yoshi Ohba, Glen Zorn 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.

9.  References

9.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., "Specification for the Derivation of Root Keys
         from an Extended Master  Session Key (EMSK)",
         draft-ietf-hokey-emsk-hierarchy-01 (work in progress),
         June 2007.

   [4]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
         for Message Authentication", RFC 2104, February 1997.

   [5]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs",

Narayanan & Dondeti       Expires April 6, 2008                [Page 32]

Internet-Draft                     ERP                      October 2007

         draft-narten-iana-considerations-rfc2434bis-07 (work in
         progress), July 2007.

9.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, "Experimental Handoff Extension to
         RADIUS", draft-irtf-aaaarch-handoff-04 (work in progress),
         November 2003.

   [9]   Clancy, C., "Handover Key Management and Re-authentication
         Problem Statement", draft-ietf-hokey-reauth-ps-04 (work in
         progress), September 2007.

   [10]  Nakhjiri, M. and Y. Ohba, "Derivation, delivery and management
         of EAP based keys for handover and  re-authentication",
         draft-ietf-hokey-key-mgm-00 (work in progress), July 2007.

   [11]  Gaonkar, K. and L. Dondeti, "RADIUS attributes for Domain-
         specific Key Request and Delivery",
         draft-gaonkar-radext-erp-attrs-00 (work in progress),
         July 2007.

   [12]  Housley, R. and B. Aboba, "Guidance for Authentication,
         Authorization, and Accounting (AAA) Key Management", BCP 132,
         RFC 4962, July 2007.

Appendix A.  Example ERP Exchange

Narayanan & Dondeti       Expires April 6, 2008                [Page 33]

Internet-Draft                     ERP                      October 2007

0. Authenticator --> Peer:  [EAP Request/Identity()]

1. Peer --> Authenticator:  EAP Initiate/Re-auth(SEQ, rIKname,[peer-Id],
                             Crypto-suite,Auth-tag*)

1a. Authenticator --> Reauth-Server: AAA-Request{Authenticator-Id,
                            EAP Initiate/Re-auth(SEQ,rIKname,[peer-Id],
                             Crypto-suite,Auth-tag*)

2. ER-Server --> Authenticator:  AAA-Response{rMSK,
                            EAP Finish/Re-auth(SEQ,rIKname,[peer-Id],
                            Crypto-suite,[CB-Info],Auth-tag*)

2b. Authenticator --> Peer : EAP Finish/Re-auth(SEQ,rIKname,[peer-Id],
                             Crypto-suite,[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.

                          Figure 10: ERP Exchange

Authors' Addresses

   Vidya Narayanan
   QUALCOMM, Inc.
   5775 Morehouse Dr
   San Diego, CA
   USA

   Phone: +1 858-845-2483
   Email: [email-masked]

   Lakshminath Dondeti
   QUALCOMM, Inc.
   5775 Morehouse Dr
   San Diego, CA
   USA

   Phone: +1 858-845-1267
   Email: [email-masked]

Narayanan & Dondeti       Expires April 6, 2008                [Page 34]

Internet-Draft                     ERP                      October 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Narayanan & Dondeti       Expires April 6, 2008                [Page 35]


_______________________________________________
HOKEY mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hokey

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 6 Nov 2007 23:45:17 -0800

Hi Charles,
Thanks for the detailed review.  We fixed most of your comments.  Here
is an attempt at responses to the ones not addressed: 

* Distinguishing between EAP and ER server in Figure 1: Figure 1 shows
an ERP exchange with the home server; if the ER and EAP servers are
different, the EMSK will need to be transported to the ER server for the
ER exchange to occur with the separate entity.  Note that the transport
of rRK in this case is insufficient, since DSRKs can't be derived from
it.  EMSK transport is not allowed.  Hence, I don't see how the EAP and
ER servers can be different in the home domain.  

* Separate local AAA and local ER servers: It may be that some future
spec defines how these can be separate and how the DS-rRK can be
transported out to the local ER server.  Such a spec will then update
this spec.  For the purpose of this document, we don't define such key
delivery and I don't think it makes sense for interoperability reasons
to relax the MUST NOT on rRK transport. 

* SHOULD vs MUST on inclusion of lifetime in EAP-Finish/Re-auth message:
The server may not always wish to hand out the lifetimes, depending on
its policy.  It may want to reserve the right to revoke the key material
any time it wants, without providing any commitments on the lifetime.
This is now explained in the revised version. 

* Section 5.1; how does the peer know the new PMK=rMSK in a 4-way
handshake: Lower layer secure association protocols should have a key id
to indicate which key is being used for the exchange; the PMK ID in
802.11i provides this. So, there is no ambiguity. 

* RADIUS and Diameter support for ERP: The appropriate references for
both have been included, although, both are informative references,
keeping inline with how RFC3748 was published (RFC3579 and the then
Diameter EAP draft were only informative references to EAP).  I am,
however, not sure if those need to be progressed in HOKEY or if the
RADEXT/DIME groups will take it up.  I think the RADIUS document will
need to be published in HOKEY (given the history of the WG), although
that document has normative dependencies on some pending RADEXT work.
The Diameter document can be taken up in either place.  I will initiate
a separate thread on this topic with the AD and all relevant chairs.  

* "Identifier" usage in section 5.3 vs. RFC3748: RFC3748 defines
detailed Identifier usage specifically for the Request and Response
codes only.  Hence, it is appropriate to do the same for the Initiate
and Finish codes that we are defining here.  There is no standalone
usage for all EAP codes, since the Identifier is for matching pairs of
messages and hence only relevant for Request/Response and
Initiate/Finish pairs so far. 

* Sub-sections in Section 6: The security considerations section largely
follows the requirements specified in RFC4962 - the requirements in
RFC4962 are not numbered.  It seems unnecessary to have 13 sub-sections
(none of those need to be referenced anywhere in the document anyway).
So, it is left as-is. 

Thanks!
Vidya

> -----Original Message-----
> From: Charles Clancy [mailto:[email-masked]] 
> Sent: Thursday, November 01, 2007 8:06 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [HOKEY] WGLC comments on ER
> 
> ER Authors,
> 
> SHOULD/should.  They seem to be used a little inconsistently. 
>  All my other copious comments are inline in the attached document.
> 
> --

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 11 Nov 2007 23:44:30 -0500

Just commenting on the first two bullets.  hokey-key-mgm-01 draft
covers the scenario where EAP server and ER server are separated and
the scenario where local AAA server (DSR-KH) and local ER server are
separated.  There is no need to transport EMSK to support the first
scenario if DSRK as well as rRK are transported.

Regards,
Yoshihiro Ohba