GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6630

Internet Engineering Task Force (IETF) Z. Cao Request for Comments: 6630 H. Deng Category: Standards Track China Mobile ISSN: 2070-1721 Q. Wu

                                                                Huawei
                                                          G. Zorn, Ed.
                                                           Network Zen
                                                             June 2012
             EAP Re-authentication Protocol Extensions
          for Authenticated Anticipatory Keying (ERP/AAK)

Abstract

 The Extensible Authentication Protocol (EAP) is a generic framework
 supporting multiple types of authentication methods.
 The EAP Re-authentication Protocol (ERP) 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.
 Authenticated Anticipatory Keying (AAK) is a method by which
 cryptographic keying material may be established upon one or more
 Candidate Attachment Points (CAPs) prior to handover.  AAK uses the
 AAA infrastructure for key transport.
 This document specifies the extensions necessary to enable AAK
 support in ERP.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6630.

Cao, et al. Standards Track [Page 1] RFC 6630 ERP/AAK June 2012

Copyright Notice

 Copyright (c) 2012 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
 2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.2.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . .  3
 3.  ERP/AAK Description  . . . . . . . . . . . . . . . . . . . . .  4
 4.  ERP/AAK Key Hierarchy  . . . . . . . . . . . . . . . . . . . .  7
   4.1.  Derivation of the pRK and pMSK . . . . . . . . . . . . . .  8
 5.  Packet and TLV Extension . . . . . . . . . . . . . . . . . . .  9
   5.1.  EAP-Initiate/Re-auth-Start Packet and TLV Extension  . . .  9
   5.2.  EAP-Initiate/Re-auth Packet and TLV Extension  . . . . . . 10
   5.3.  EAP-Finish/Re-auth Packet and TLV Extension  . . . . . . . 12
   5.4.  TV and TLV Attributes  . . . . . . . . . . . . . . . . . . 14
 6.  Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 15
 7.  AAA Transport Considerations . . . . . . . . . . . . . . . . . 15
 8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
 9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
   11.2. Informative References . . . . . . . . . . . . . . . . . . 19

Cao, et al. Standards Track [Page 2] RFC 6630 ERP/AAK June 2012

1. Introduction

 The Extensible Authentication Protocol (EAP) [RFC3748] is a generic
 framework supporting multiple types of authentication methods.  In
 systems where EAP is used for authentication, it is desirable not to
 repeat the entire EAP exchange with another authenticator.  The EAP
 Re-authentication Protocol (ERP) [RFC5296] specifies extensions to
 EAP and the EAP keying hierarchy to support an EAP method-independent
 protocol for efficient re-authentication between the EAP
 re-authentication 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 mobile host (i.e., the
 EAP re-authentication peer) is connecting.
 Authenticated Anticipatory Keying (AAK) [RFC5836] is a method by
 which cryptographic keying material may be established upon one or
 more Candidate Attachment Points (CAPs) prior to handover.  AAK
 utilizes the AAA infrastructure for key transport.
 This document specifies the extensions necessary to enable AAK
 support in ERP.

2. Terminology

2.1. Requirements Language

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

2.2. Acronyms

 The following acronyms are used in this document; see the references
 for more details.
 AAA
     Authentication, Authorization, and Accounting [RFC3588]
 CAP
     Candidate Attachment Point [RFC5836]
 DSRK
       Domain-Specific Root Key [RFC5295]
 EA
     Abbreviation for "ERP/AAK"

Cao, et al. Standards Track [Page 3] RFC 6630 ERP/AAK June 2012

 EA Peer
          An EAP peer that supports the ERP/AAK.  Note that all
          references to "peer" in this document imply an EA peer,
          unless specifically noted otherwise.
 NAI
     Network Access Identifier [RFC4282]
 pMSK
       pre-established Master Session Key
 pRK
     pre-established Root Key
 rIK
     re-authentication Integrity Key [RFC5296]
 rRK
     re-authentication Root Key [RFC5296]
 SAP
     Serving Attachment Point [RFC5836]

3. ERP/AAK Description

 ERP/AAK is intended to allow (upon request by the peer) the
 establishment of cryptographic keying materials on a single Candidate
 Attachment Point prior to the arrival of the peer at the Candidate
 Access Network (CAN).
 In this document, ERP/AAK support by the peer is assumed.  Also, it
 is assumed that the peer has previously completed full EAP
 authentication and that either the peer or the SAP knows the
 identities of neighboring attachment points.  Note that the behavior
 of a peer that does not support the ERP-AAK scheme defined in this
 specification is out of the scope of this document.  Figure 1 shows
 the general protocol exchange by which the keying material is
 established on the CAP.

Cao, et al. Standards Track [Page 4] RFC 6630 ERP/AAK June 2012

   +------+         +-----+        +-----+          +-----------+
   | Peer |         | SAP |        | CAP |          | EA Server |
   +--+---+         +--+--+        +--+--+          +-----+-----+
      |                |              |                   |
   a. | [EAP-Initiate/ |              |                   |
      | Re-auth-start  |              |                   |
      | (E flag)]      |              |                   |
      |<---------------|              |                   |
      |                |              |                   |
   b. | EAP-Initiate/  |              |                   |
      | Re-auth        |              |                   |
      | (E flag)       |              |                   |
      |--------------->|              |                   |
   c. |                | AAA(EAP-Initiate/Re-auth(E flag))|
      |                |--------------------------------->|
      |                |              |         +---------+---------+
      |                |              |         | CA authorized &   |
   d. |                |              |         |  and EA Keying    |
      |                |              |         |   Distribution    |
      |                |              |         +---------+---------+
      |                |              |                   |
      |                |              |                   |
   f. |                | AAA (EAP-Finish/Re-auth(E flag)) |
      |                |<---------------------------------|
   g. | EAP-Finish/    |              |                   |
      | Re-auth(E flag)|              |                   |
      |<---------------|              |                   |
      |                |              |                   |
                      Figure 1: ERP/AAK Exchange

Cao, et al. Standards Track [Page 5] RFC 6630 ERP/AAK June 2012

                +-----------+               +---------+
                |           |               |         |
                | EA Server |               |   CAP   |
                |           |               |         |
                +-----|-----+               +----|----+
                      |                          |
                      |                          |
                      |    AAA Request (pMSK)    |
                   e.1|------------------------->|
                      |                          |
                      |                          |
                      |                          |
                      |  AAA Response (Success)  |
                   e.2|<-------------------------|
                      |                          |
                      |                          |
                      |                          |
                Figure 2: Key Distribution for ERP/AAK
 ERP/AAK reuses the packet format defined by ERP, but specifies a new
 flag to differentiate EAP early authentication from EAP
 re-authentication.  The peer initiates ERP/AAK without an external
 trigger, or initiates ERP/AAK in response to an EAP-Initiate/
 Re-Auth-Start message from the SAP.
 In the latter case, the SAP MAY send the identity of one or more
 Candidate Attachment Points to which the SAP is adjacent to the peer
 in the EAP-Initiate/Re-auth-Start message (see step a in Figure 1).
 The peer SHOULD override the identity of CAP(s) carried in the
 EAP-Initiate/Re-auth-Start message by sending EAP-Initiate/Re-auth
 with the E flag set if it knows to which CAP it will move.  If the
 EAP-Initiate/Re-auth-Start packet is not supported by the peer, it
 MUST be silently discarded.
 If the peer initiates ERP/AAK, the peer MAY send an early-
 authentication request message (EAP-Initiate/Re-auth with the E flag
 set) containing the keyName-NAI, the CAP-Identifier, rIK, and
 sequence number (see step b in Figure 1).  The realm in the keyName-
 NAI field is used to locate the peer's ERP/AAK server.  The CAP-
 Identifier is used to identify the CAP.  The re-authentication
 Integrity Key (rIK) is defined by Narayanan & Dondeti in [RFC5296]
 and is used to protect the integrity of the message.  The sequence
 number is used for replay protection.
 The SAP SHOULD verify the integrity of this message at step b.  If
 this verification fails, the SAP MUST send an EAP-Finish/Re-auth
 message with the Result flag set to '1' (Failure).  If the

Cao, et al. Standards Track [Page 6] RFC 6630 ERP/AAK June 2012

 verification succeeds, the SAP SHOULD encapsulate the early-
 authentication message into a AAA message and send it to the peer's
 ERP/AAK server in the realm indicated in the keyName-NAI field (see
 step c in Figure 1).
 Upon receiving the message, the ERP/AAK server MUST first use the
 keyName indicated in the keyName-NAI to look up the rIK and check the
 integrity and freshness of the message.  Then, the ERP/AAK server
 MUST verify the identity of the peer by checking the username portion
 of the KeyName-NAI.  If any of the checks fail, the server MUST send
 an early-authentication finish message (EAP-Finish/Re-auth with E
 flag set) with the Result flag set to '1'.  Next, the server MUST
 authorize the CAP specified in the CAP-Identifier TLV.  In the
 success case, the server MUST derive a pMSK from the pRK for the CAP
 carried in the CAP-Identifier field using the sequence number
 associated with CAP-Identifier as an input to the key derivation.
 (see step d in Figure 1).
 Then, the ERP/AAK server MUST transport the pMSK to the authorized
 CAP via AAA (see Section 7) as illustrated above (see steps e.1 and
 e.2 in Figure 2).  Note that key distribution in Figure 2 is one part
 of step d in Figure 1.
 Finally, in response to the EAP-Initiate/Re-auth message, the ERP/AAK
 server SHOULD send the early-authentication finish message (EAP--
 -Finish/Re-auth with E flag set) containing the identity of the
 authorized CAP to the peer via the SAP along with the lifetime of the
 pMSK.  If the peer also requests the rRK Lifetime, the ERP/AAK server
 SHOULD send the rRK Lifetime in the EAP-Finish/Re-auth message (see
 steps f and g in Figure 1).

4. ERP/AAK Key Hierarchy

 ERP/AAK uses a key hierarchy similar to that of ERP.  The ERP/AAK
 pre-established Root Key (pRK) is derived from either the EMSK or the
 DSRK as specified below (see Section 4.1).  In general, the pRK is
 derived from the EMSK if the peer is located in the home AAA realm
 and derived from the DSRK if the peer is in a visited realm.  The
 DSRK is delivered from the EAP server to the ERP/AAK server as
 specified in [KEYTRAN].  If the peer has previously been
 authenticated by means of ERP or ERP/AAK, the DSRK SHOULD be directly
 reused.

Cao, et al. Standards Track [Page 7] RFC 6630 ERP/AAK June 2012

                               DSRK    EMSK
                                |       |
                            +---+---+---+---+
                            |
                           pRK            ...
                 Figure 3: ERP/AAK Root Key Derivation
 Similarly, the pre-established Master Session Key (pMSK) is derived
 from the pRK.  The pMSK is established for the CAP when the peer
 early authenticates to the network.  The hierarchy relationship is
 illustrated Figure 4, below.
                                  pRK
                                   |
                          +--------+--------+
                          |
                          pMSK             ...
                    Figure 4: ERP/AAK Key Hierarchy

4.1. Derivation of the pRK and pMSK

 The rRK is derived as specified in [RFC5295].
 pRK = KDF (K, S), where
    K = EMSK or K = DSRK and
    S = pRK Label | "\0" | length
 The pRK Label is an IANA-assigned 8-bit ASCII string:
    EAP Early-Authentication Root Key@ietf.org
 assigned from the "User Specific Root Keys (USRK) Key Labels" name
 space in accordance with Salowey, et al. [RFC5295].  The KDF and
 algorithm agility for the KDF are also defined in RFC 5295.  The KDF
 algorithm is indicated in the cryptosuite field or list of
 cryptosuites TLV payload as specified in Sections 5.2 and 5.3.
 The pMSK uses the same KDF as pRK and is derived as follows:
 pMSK = KDF (K, S), where
    K = pRK and
    S = pMSK label | "\0" | SEQ | length

Cao, et al. Standards Track [Page 8] RFC 6630 ERP/AAK June 2012

 The pMSK label is the 8-bit ASCII string:
    EAP Early-Authentication Master Session Key@ietf.org
 The length field refers to the length of the pMSK in octets encoded
 as specified in RFC 5295.  SEQ is sent by either the peer or the
 server in the ERP/AAK message using the SEQ field or the Sequence
 number TLV.  It is encoded as a 16-bit number as specified in
 Sections 5.2 and 5.3.

5. Packet and TLV Extension

 This section describes the packet and TLV extensions for the ERP/AAK
 exchange.

5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension

 Figure 5 shows the new parameters contained in the EAP-Initiate/
 Re-auth-Start packet defined in [RFC5296].
    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      |E| Reserved    |     1 or more TVs or TLVs     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Figure 5: EAP-Initiate/Re-auth-Start Extension
 Flags
 'E' - The E flag is used to indicate early authentication.  This
 field MUST be set to '1' if early authentication is in use, and it
 MUST be set to '0' otherwise.
 The rest of the 7 bits (Reserved) MUST be set to 0 and ignored on
 reception.
 Type/Values (TVs) and TLVs
 CAP-Identifier: Carried in a TLV payload.  The format is identical to
 that of a DiameterIdentity [RFC3588].  It is used by the SAP to
 advertise the identity of the CAP to the peer.  Exactly one
 CAP-Identifier TLV MAY be included in the EAP-Initiate/Re-auth-Start
 packet if the SAP has performed CAP discovery.

Cao, et al. Standards Track [Page 9] RFC 6630 ERP/AAK June 2012

 If the EAP-Initiate/Re-auth-Start packet is not supported by the
 peer, it SHOULD be discarded silently.

5.2. EAP-Initiate/Re-auth Packet and TLV Extension

 Figure 6 illustrates the new parameters contained in the
 EAP-Initiate/Re-auth packet defined in [RFC5296].
    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|x|L|E|Resved |             SEQ               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 1 or more TVs or TLVs                         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Cryptosuite  |         Authentication Tag                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Figure 6: EAP-Initiate/Re-auth Extension
 Flags
 'x' - The x flag is reserved.  It MUST be ignored on receipt.
 'L' - As defined in Section 5.3.2 of [RFC5296], this bit is used to
 request the key lifetimes from the server.
 'E' - The E flag is used to indicate early authentication.
 The first bit(R) and final 4 bits (Resved) MUST be set to 0 and
 ignored on reception.
 SEQ
 As defined in Section 5.3.2 of [RFC5296], this field is 16-bit
 sequence number and used for replay protection.
 TVs and TLVs
 keyName-NAI: As defined in [RFC5296], this is carried in a TLV
 payload.  The Type is 1.  The NAI is variable in length, not
 exceeding 253 octets.  The username part of the NAI is the EMSKname
 used to identify the peer.  The realm part of the NAI is the peer's
 home domain name if the peer communicates with the home EA server or
 the domain to which the peer is currently attached (i.e., local
 domain name) if the peer communicates with a local EA server.  The

Cao, et al. Standards Track [Page 10] RFC 6630 ERP/AAK June 2012

 SAP knows whether the KeyName-NAI carries the local domain name by
 comparing the domain name carried in the KeyName-NAI with the local
 domain name that is associated with the SAP.  Exactly one keyName-NAI
 attribute SHALL be present in an EAP-Initiate/Re-auth packet and the
 realm part of it SHOULD follow the use of internationalized domain
 names defined in [RFC5890].
 CAP-Identifier: Carried in a TLV payload.  The Type is 11.  This
 field is used to indicate the Fully Qualified Domain Name (FQDN) of a
 CAP.  The value field MUST be encoded as specified in Section 8 of
 [RFC3315].  Exactly one instance of the CAP-Identifier TLV MUST be
 present in the ERP/AAK-Key TLV.
 Sequence number: The Type is 7.  The value field is a 16-bit field
 and used in the derivation of the pMSK for a CAP.
 Cryptosuite
 This field indicates the integrity algorithm used for ERP/AAK.  Key
 lengths and output lengths are either indicated or obvious from the
 cryptosuite name, e.g., HMAC-SHA256-128 denotes Hashed Message
 Authentication Code (HMAC) computed using the SHA-256 function
 [RFC4868] with 256-bit key length and the output truncated to 128
 bits [RFC2104].  We specify some cryptosuites below:
 0-1  RESERVED
 2    HMAC-SHA256-128
 3    HMAC-SHA256-256
 HMAC-SHA256-128 is REQUIRED to implement, and it SHOULD be enabled in
 the default configuration.
 Authentication Tag
 This field contains an integrity checksum over the ERP/AAK packet
 from the first bit of the Code field to the last bit of the
 Cryptosuite field, excluding the Authentication Tag field itself.
 The value field is calculated using the integrity algorithm indicated
 in the Cryptosuite field and rIK specified in [RFC5296] as the secret
 key.  The length of the field is indicated by the Cryptosuite.
 The peer uses the Authentication Tag to determine the validity of the
 EAP-Finish/Re-auth message from the server.

Cao, et al. Standards Track [Page 11] RFC 6630 ERP/AAK June 2012

 If the message doesn't pass verification or the Authentication Tag is
 not included in the message, the message SHOULD be discarded
 silently.
 If the EAP-Initiate/Re-auth packet is not supported by the SAP, it
 SHOULD be discarded silently.  The peer MUST maintain retransmission
 timers for reliable transport of the EAP-Initiate/Re-auth message.
 If there is no response to the EAP-Initiate/Re-auth message from the
 server after the necessary number of retransmissions (see Section 6),
 the peer MUST assume that ERP/AAK is not supported by the SAP.

5.3. EAP-Finish/Re-auth Packet and TLV Extension

 Figure 7 shows the new parameters contained in the EAP-Finish/Re-auth
 packet defined in [RFC5296].
    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|x|L|E|Resved |             SEQ               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 1 or more TVs or TLVs                         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Cryptosuite  |         Authentication Tag                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 7: EAP-Finish/Re-auth Extension
 Flags
 'R' - As defined in Section 5.3.3 of [RFC5296], this bit is used as
 the Result flag.  This field MUST be set to '1' to indicate success,
 and it MUST be set to '0' otherwise.
 'x' - The x flag is reserved.  It MUST be ignored on receipt.
 'L' - As defined in Section 5.3.3 of [RFC5296], this bit is used to
 request the key lifetimes from the server.
 'E' - The E flag is used to indicate early authentication.
 The final 4 bits (Resved) MUST be set to 0 and ignored on reception.

Cao, et al. Standards Track [Page 12] RFC 6630 ERP/AAK June 2012

 SEQ
 As defined in Section 5.3.3 of [RFC5296], this field is a 16-bit
 sequence number and is used for replay protection.
 TVs and TLVs
 keyName-NAI: As defined in [RFC5296], this is carried in a TLV
 payload.  The Type is 1.  The NAI is variable in length, not
 exceeding 253 octets.  Exactly one keyName-NAI attribute SHALL be
 present in an EAP-Finish/Re-auth packet.
 ERP/AAK-Key: Carried in a TLV payload for the key container.  The
 Type is 8.  Exactly one ERP/AAK-key SHALL be present in an
 EAP-Finish/Re-auth packet.
 ERP/AAK-Key ::=
      { sub-TLV: CAP-Identifier }
      { sub-TLV: pMSK Lifetime }
      { sub-TLV: pRK Lifetime }
      { sub-TLV: Cryptosuites }
 CAP-Identifier
    Carried in a sub-TLV payload.  The Type is 11 (less than 128).
    This field is used to indicate the identifier of the candidate
    authenticator.  The value field MUST be encoded as specified in
    Section 8 of [RFC3315].  At least one instance of the CAP-
    Identifier TLV MUST be present in the ERP/AAK-Key TLV.
 pMSK Lifetime
    Carried in a sub-TLV payload of the EAP-Finish/Re-auth message.
    The Type is 10.  The value field is an unsigned 32-bit field and
    contains the lifetime of the pMSK in seconds.  This value is
    calculated by the server after performing the pRK Lifetime
    computation upon receiving the EAP-Initiate/Re-auth message.  The
    rIK SHOULD share the same lifetime as the pMSK.  If the 'L' flag
    is set, the pMSK Lifetime attribute MUST be present.
 pRK Lifetime
    Carried in a sub-TLV payload of EAP-Finish/Re-auth message.  The
    Type is 9.  The value field is an unsigned 32-bit field and
    contains the lifetime of the pRK in seconds.  This value is
    calculated by the server before performing the pMSK Lifetime
    computation upon receiving a EAP-Initiate/Re-auth message.  If the
    'L' flag is set, the pRK Lifetime attribute MUST be present.

Cao, et al. Standards Track [Page 13] RFC 6630 ERP/AAK June 2012

 List of Cryptosuites
    Carried in a sub-TLV payload.  The Type is 5 [RFC5296].  The value
    field contains a list of cryptosuites (at least one cryptosuite
    SHOULD be included), each 1 octet in length.  The allowed
    cryptosuite values are as specified in Section 5.2.  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 its
    cryptographic algorithm capabilities to the peer.
 Cryptosuite
 This field indicates the integrity algorithm and PRF used for ERP/
 AAK.  HMAC-SHA256-128 is REQUIRED to implement, and it SHOULD be
 enabled in the default configuration.  Key lengths and output lengths
 are either indicated or obvious from the cryptosuite name.
 Authentication Tag
 This field contains the integrity checksum over the ERP/AAK packet
 from the first bit of the Code field to the last bit of the
 Cryptosuite field, excluding the Authentication Tag field itself.
 The value field is calculated using the integrity algorithm indicated
 in the Cryptosuite field and the rIK [RFC5296] as the integrity key.
 The length of the field is indicated by the corresponding
 Cryptosuite.
 The peer uses the authentication tag to determine the validity of the
 EAP-Finish/Re-auth message from a server.
 If the message doesn't pass verification or the authentication tag is
 not included in the message, the message SHOULD be discarded
 silently.
 If the EAP-Initiate/Re-auth packet is not supported by the SAP, it is
 discarded silently.  The peer MUST maintain retransmission timers for
 reliable transport of the EAP-Initiate/Re-auth message.  If there is
 no response to the EAP-Initiate/Re-auth message from the server after
 the necessary number of retransmissions (see Section 6), the peer
 MUST assume that ERP/AAK is not supported by the SAP.

5.4. TV and TLV Attributes

 With the exception of the rRK Lifetime and rMSK Lifetime TV payloads,
 the attributes specified in Section 5.3.4 of [RFC5296] also apply to
 this document.  In this document, new attributes that may be present
 in the EAP-Initiate and EAP-Finish messages are defined as below:

Cao, et al. Standards Track [Page 14] RFC 6630 ERP/AAK June 2012

 o  Sequence number: This is a TV payload.  The Type is 7.
 o  ERP/AAK-Key: This is a TLV payload.  The Type is 8.
 o  pRK Lifetime: This is a TV payload.  The Type is 9.
 o  pMSK Lifetime: This is a TV payload.  The Type is 10.
 o  CAP-Identifier: This is a TLV payload.  The Type is 11.

6. Lower-Layer Considerations

 Similar to ERP, some lower-layer specifications may need to be
 revised to support ERP/AAK; refer to Section 6 of [RFC5296] for
 additional guidance.

7. AAA Transport Considerations

 The AAA transport of ERP/AAK messages is the same as that of the ERP
 message [RFC5296].  In addition, this document requires AAA transport
 of the ERP/AAK keying materials delivered by the ERP/AAK server to
 the CAP.  Hence, a new AAA message for the ERP/AAK application should
 be specified to transport the keying materials.

8. Security Considerations

 This section provides an analysis of the protocol in accordance with
 the AAA key management requirements specified in [RFC4962].
 o  Cryptographic algorithm independence: ERP-AAK satisfies this
    requirement.  The algorithm chosen by the peer for calculating the
    authentication tag 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 a Failure indication.
 o  Strong, fresh session keys: ERP-AAK results in the derivation of
    strong, fresh keys that are unique for the given CAP.  A pMSK is
    always derived on demand when the peer requires a key with a new
    CAP.  The derivation ensures that the compromise of one pMSK does
    not result in the compromise of a different pMSK at any time.
 o  Limit key scope: The scope of all the keys derived by ERP-AAK is
    well defined.  The pRK is used to derive the pMSK for the CAP.
    Different sequence numbers for each CAP MUST be used to derive a
    unique pMSK.

Cao, et al. Standards Track [Page 15] RFC 6630 ERP/AAK June 2012

 o  Replay detection mechanism: For replay protection, a sequence
    number associated with the pMSK is used.  The peer increments the
    sequence number by one after it sends an ERP/AAK message.  The
    server sets the expected sequence number to the received sequence
    number plus one after verifying the validity of the received
    message, and it responds to the message.
 o  Authenticate all parties: The EAP Re-authentication Protocol
    provides mutual authentication of the peer and the server.  The
    peer and SAP are authenticated via ERP.  The CAP is authenticated
    and trusted by the SAP.
 o  Peer and authenticator authorization: The peer and authenticator
    demonstrate possession of the same keying material without
    disclosing it, as part of the lower-layer secure authentication
    protocol.
 o  Keying material confidentiality: The peer and the server derive
    the keys independently using parameters known to each entity.
 o  Uniquely named keys: All keys produced within the ERP context can
    be referred to uniquely as specified in this document.
 o  Prevent the domino effect: Different sequence numbers for each CAP
    MUST be used to derive the unique pMSK so that the compromise of
    one pMSK does not hurt any other CAP.
 o  Bind key to its context: The pMSKs are bound to the context in
    which the sequence numbers are transmitted.
 o  Confidentiality of identity: This is the same as with ERP
    [RFC5296].
 o  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 to be used only in the
    domain for which the keys are derived.  Any other restrictions of
    session keys may be imposed by the specific lower layer and are
    out of scope for this specification.

9. IANA Considerations

 IANA has assigned five TLVs from the registry of EAP Initiate and
 Finish Attributes maintained at
 http://www.iana.org/assignments/eap-numbers/ with the following
 numbers:

Cao, et al. Standards Track [Page 16] RFC 6630 ERP/AAK June 2012

 o  Sequence number: This is a TV payload.  The Type is 7.
 o  ERP/AAK-Key: This is a TLV payload.  The Type is 8.
 o  pRK Lifetime: This is a TLV payload.  The Type is 9.
 o  pMSK Lifetime: This is a TLV payload.  The Type is 10.
 o  CAP-Identifier: This is a TLV payload.  The Type is 11.
 This document reuses the cryptosuites that were created for
 "Re-authentication Cryptosuites" in [RFC5296].
 Further, IANA has added a new label in the "User Specific Root Keys
 (USRK) Key Labels" sub-registry of the "Extended Master Session Key
 (EMSK) Parameters" registry, as follows:
    EAP Early-Authentication Root Key@ietf.org
 A new registry for the flags in the EAP Initiate/Re-auth-Start
 message called the "EAP Initiate/Re-auth-Start Flags" has been
 created and a new flag (E) has been assigned as follows:
    (E) 0x80
 The rest of the values in the 8-bit field are reserved.  New values
 can be assigned by Standards Action or IESG Approval [RFC5226].
 A new registry for the flags in the EAP Initiate/Re-auth message
 called the "EAP Initiate/Re-auth Flags" has also been created.  The
 following flags are reserved:
    (R) 0x80 [RFC5296]
    (B) 0x40 [RFC5296]
    (L) 0x20 [RFC5296]
 This document assigns a new flag (E) as follows:
    (E) 0x10
 The rest of the values in the 8-bit field are reserved.  New values
 can be assigned by Standards Action or IESG Approval.
 Further, this document creates a new registry for the flags in the
 EAP Finish/Re-auth message called the "EAP Finish/Re-auth Flags".
 The following values are assigned.

Cao, et al. Standards Track [Page 17] RFC 6630 ERP/AAK June 2012

    (R) 0x80 [RFC5296]
    (B) 0x40 [RFC5296]
    (L) 0x20 [RFC5296]
 This document assigns a new flag (E) as follows:
    (E) 0x10
 The rest of the values in the 8-bit field are reserved.  New values
 can be assigned by Standards Action or IESG approval.

10. Acknowledgements

 In writing this document, Yungui Wang contributed to early versions
 of this document and we have received reviews from many experts in
 the IETF, including Tom Taylor, Tena Zou, Tim Polk, Tan Zhang, Semyon
 Mizikovsky, Stephen Farrell, Radia Perlman, Miguel A. Garcia, and
 Sujing Zhou.  We apologize if we miss some of those who have helped
 us.

11. References

11.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
            and M. Carney, "Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6)", RFC 3315, July 2003.
 [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
            Network Access Identifier", RFC 4282, December 2005.
 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008.
 [RFC5295]  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.
 [RFC5296]  Narayanan, V. and L. Dondeti, "EAP Extensions for EAP
            Re-authentication Protocol (ERP)", RFC 5296, August 2008.

Cao, et al. Standards Track [Page 18] RFC 6630 ERP/AAK June 2012

11.2. Informative References

 [KEYTRAN]  Zorn, G., Wu, W., and V. Cakulev, "Diameter Attribute-
            Value Pairs for Cryptographic Key Transport", Work
            in Progress, August 2011.
 [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
            Hashing for Message Authentication", RFC 2104,
            February 1997.
 [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
            Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
 [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
            Levkowetz, "Extensible Authentication Protocol (EAP)",
            RFC 3748, June 2004.
 [RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
            384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
 [RFC4962]  Housley, R. and B. Aboba, "Guidance for Authentication,
            Authorization, and Accounting (AAA) Key Management",
            BCP 132, RFC 4962, July 2007.
 [RFC5836]  Ohba, Y., Wu, Q., and G. Zorn, "Extensible Authentication
            Protocol (EAP) Early Authentication Problem Statement",
            RFC 5836, April 2010.
 [RFC5890]  Klensin, J., "Internationalized Domain Names for
            Applications (IDNA): Definitions and Document Framework",
            RFC 5890, August 2010.

Cao, et al. Standards Track [Page 19] RFC 6630 ERP/AAK June 2012

Authors' Addresses

 Zhen Cao
 China Mobile
 53A Xibianmennei Ave., Xuanwu District
 Beijing, Beijing  100053
 P.R. China
 EMail: zehn.cao@gmail.com
 Hui Deng
 China Mobile
 53A Xibianmennei Ave., Xuanwu District
 Beijing, Beijing  100053
 P.R. China
 EMail: denghui02@gmail.com
 Qin Wu
 Huawei
 Floor 12, HuiHong Mansion, No. 91 BaiXia Rd.
 Nanjing, Jiangsu  210001
 P.R. China
 Phone: +86 25 56623633
 EMail: sunseawq@huawei.com
 Glen Zorn (editor)
 Network Zen
 227/358 Thanon Sanphawut
 Bang Na, Bangkok  10260
 Thailand
 Phone: +66 (0) 87-040-4617
 EMail: glenzorn@gmail.com

Cao, et al. Standards Track [Page 20]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6630.txt · Last modified: 2012/06/02 01:38 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki