| Network Working Group | Z. Cao |
| Internet-Draft | H. Deng |
| Intended status: Standards Track | China Mobile |
| Expires: April 23, 2012 | Y. Wang |
| Q. Wu | |
| Huawei Technologies Co., Ltd. | |
| G. Zorn, Ed. | |
| Network Zen | |
| October 21, 2011 |
EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK)
draft-ietf-hokey-erp-aak-06
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 23, 2012.
Copyright (c) 2011 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.
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 to not 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 peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting.
Authenticated Anticipatory Keying (AAK) [RFC5836] is a method by which cryptographic keying materials may be established prior to handover upon one or more candidate attachment points (CAPs). AAK utilizes the AAA infrastructure for key transport.
This document specifies the extensions necessary to enable AAK support in ERP.
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 [RFC2119].
The following acronyms are used in this document; see the references for more details.
+------+ +-----+ +-----+ +-----------+ | Peer | | SAP | | CAP | | EA Server | +--+---+ +--+--+ +--+--+ +-----+-----+ | | | | 1. | [EAP-Initiate/ | | | | Re-auth-start | | | | (E-flag) | | | |<---------------| | | | | | | 2. | EAP-Initiate/ | | | | Re-auth | | | | (E-flag) | | | |--------------->| | | 3. | | AAA(EAP-Initiate/Re-auth(E-flag))| | |--------------------------------->| | | | +---------+---------+ | | | | CA authorized & | 4. | | | | authenticated; | | | | | EA keying | | | | | materials derived | | | | +---------+---------+ 5. | | | | | | | AAA(pMSK) | | | |<----------------->| | | | | 6. | | AAA (EAP-Finish/Re-auth(E-flag)) | | |<---------------------------------| 7. | EAP-Finish/ | | | | Re-auth(E-flag)| | | |<---------------| | | | | | |
ERP/AAK is intended to allow the establishment of cryptographic keying materials on a single Candidate Attachment Points prior to the arrival of the MH at the Candidate Access Network (CAN).
It is assumed that the peer has previously completed full EAP authentication and the peer or SAP knows the identities of neighboring attachment points. Figure 1 shows the general protocol exchange by which the keying material is established on the CAP. This document only discusses the case of distributing the key to a single CAP.
The SAP may send the identity of a candidate attachment point to the peer in the EAP-Initiate/Re-auth-Start message. If the EAP-Initiate/Re-auth-Start packet is not supported by the peer, it is silently discarded.
The peer sends 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. 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 rIK is used to protect the message. The sequence number is used for replay protection.
The SAP encapsulates the early-authentication message into a AAA message and sends it to the peer’s ERP/AAK server in the realm indicated in the keyName-NAI field.
Upon receiving the message, the ERP/AAK server first checks its integrity and freshness, then verifies the identity of the peer by checking the username portion of the KeyName-NAI. Next, the server authenticates and authorizes the CAP specified in the CAP-Identifier TLV. If any of the checks fail, the server sends an early-authentication finish message (EAP-Finish/Re-auth with E-flag set) with the Result flag set to '1'.
The ERP/AAK server transports the pMSK to the authenticated and authorized CAP via AAA as described in Section 7.
Finally, the ERP/AAK server sends 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.
DSRK EMSK
| |
+---+---+---+---+
| | |
pRK rRK ...
pRK
|
+--------+--------+
| | |
pIK pMSK ...
As an optimization of ERP, ERP/AAK uses a key hierarchy similar to that of ERP. The EMSK is used to derive the ERP/AAK pre-established Root Key (pRK). Similarly, the ERP/AAK pre-established Integrity Key (pIK) and the pre-established Master Session Key (pMSK) are derived from the pRK. The pMSK is established for the CAP when the peer early authenticates to the network. The pIK is established for the peer to re-authenticate the network after handover. The hierarchy relationship is illustrated in Figure 2, below. [I-D.ietf-dime-local-keytran]. If the peer has previously been authenticated by means of ERP or ERP/AAK, the DSRK SHOULD be directly re-used.
This section describes the packet and TLV extensions for the ERP/AAK exchange.
Figure 4 shows the changed parameters contained in the EAP-Initiate/Re-auth-Start packet defined in RFC 5296 [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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags
‘E’ – The E flag is used to indicate early-authentication.
Reserved: MUST be set to 0.
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.
If the EAP-Initiate/Re-auth-Start packet is not supported by the peer, it is discarded silently.
Figure 5 illustrates the changed parameters contained in the EAP-Initiate/Re-auth packet defined in RFC 5296 [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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags
'x' – The x flag is reserved. It MUST be set to 0.
'E’ – The E flag is used to indicate early-authentication.
The rest of the 4 bits (Resved) MUST be set to 0 and ignored on reception.
SEQ
A 16-bit sequence number is used for replay protection.
TVs and TLVs
keyName-NAI: As defined in RFC 5296 [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 or the domain to which the peer is currently attached. Exactly one keyName-NAI attribute SHALL be present in an EAP-Initiate/Re-auth packet.
CAP-Identifier: Carried in a TLV payload. It is used to indicate the FQDN of a CAP.
Sequence number: Carried in a TV payload. The Type is TBD (less than 128). It is used in the derivation of the pMSK for each CAP. Each CAP-Identifier in the packet MUST be associated with a unique sequence number.
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. We specify some cryptosuites below:
HMAC-SHA256-128 is mandatory to implement and should be enabled in the default configuration.
Authentication Tag
This field contains the integrity checksum over the ERP/AAK packet, excluding the authentication tag field itself. The length of the field is indicated by the Cryptosuite.
If the EAP-Initiate/Re-auth packet is not supported by the SAP, it is discarded silently.
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 shows the changed parameters contained in the EAP-Finish/Re-auth packet defined in [RFC5296].
Flags
'x' – The x flag is reserved. It MUST be set to 0.
‘E’ – The E flag is used to indicate early-authentication.
The rest of the 4 bits (Resved) MUST be set to 0 and ignored on reception.
SEQ
A 16-bit sequence number is used for replay protection.
TVs and TLVs
keyName-NAI: As defined in RFC 5296 [RFC5296], this is carried in a TLV payload. The Type is 1. The NAI is variable in length, not exceeding 253 octets. The realm part of the NAI is the home domain name. Exactly one keyName-NAI attribute 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 }
ERP/AAK-Key: Carried in a TLV payload for the key container. The type is TBD. Exactly one ERP/AAK-key SHALL be present in an EAP-Finish/Re-auth packet.
Cryptosuite
This field indicates the integrity algorithm and PRF used for ERP/AAK. 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, excluding the authentication tag field itself. The length of the field is indicated by the Cryptosuite.
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 which may be present in the EAP-Initiate and EAP-Finish messages are defined as below:
Similar to ERP, some lower layer specifications may need to be revised to support ERP/AAK; refer to of Section 6 [RFC5296] for additional guidance.
AAA transport of ERP/AAK messages is the same as AAA transport of the ERP message [RFC5296]. In addition, the document requires AAA transport of the ERP/AAK keying materials delivered by the ERP/AAK server to the CAP. Hence, a new Diameter ERP/AAK application message should be specified to transport the keying materials.
This section provides an analysis of the protocol in accordance with the AAA key management requirements specified in RFC 4962 [RFC4962].
IANA is requested to assign four TLV type values from the registry of EAP Initiate and Finish Attributes maintained at http://www.iana.org/assignments/eap-numbers/eap-numbers.xml.
New TLV types:
In writing this document, we have received reviews from many experts in the IETF, including Tom Taylor, Tena Zou, Tim Polk, Tan Zhang and Semyon Mizikovsky. We apologize if we miss some of those who have helped us.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5296] | Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-authentication Protocol (ERP)", RFC 5296, August 2008. |
| [RFC5836] | Ohba, Y., Wu, Q. and G. Zorn, "Extensible Authentication Protocol (EAP) Early Authentication Problem Statement", RFC 5836, April 2010. |
| [I-D.ietf-dime-local-keytran] | Zorn, G, Wu, W and V Cakulev, "Diameter Attribute-Value Pairs for Cryptographic Key Transport", Internet-Draft draft-ietf-dime-local-keytran-14, August 2011. |
| [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. |
| [RFC4962] | Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007. |