doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc6630.txt b/doc/rfc/rfc6630.txt
new file mode 100644
index 0000000..a40c1ac
--- /dev/null
+++ b/doc/rfc/rfc6630.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+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]
+