--- 1/draft-ietf-hokey-erp-aak-05.txt 2011-10-21 10:14:05.134671421 +0200 +++ 2/draft-ietf-hokey-erp-aak-06.txt 2011-10-21 10:14:05.166671870 +0200 @@ -1,58 +1,58 @@ Network Working Group Z. Cao Internet-Draft H. Deng Intended status: Standards Track China Mobile -Expires: March 17, 2012 Y. Wang +Expires: April 20, 2012 Y. Wang Q. Wu Huawei Technologies Co., Ltd. - G. Zorn + G. Zorn, Ed. Network Zen - September 14, 2011 + October 18, 2011 EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK) - draft-ietf-hokey-erp-aak-05 + draft-ietf-hokey-erp-aak-06 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 prior to handover - upon one or more candidate attachment points (CAPs). AAK uses the + 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 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 March 17, 2012. + This Internet-Draft will expire on April 20, 2012. Copyright Notice 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 @@ -66,26 +66,26 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 3 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. ERP/AAK Overview . . . . . . . . . . . . . . . . . . . . . . . 4 4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 5 5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 6 5.1. EAP-Initiate/Re-auth-Start Packet Extension . . . . . . . 6 5.2. EAP-Initiate/Re-auth Packet Extension . . . . . . . . . . 7 - 5.3. EAP-Finish/Re-auth extension . . . . . . . . . . . . . . . 9 - 5.4. TV/TLV and sub-TLV Attributes . . . . . . . . . . . . . . 10 + 5.3. EAP-Finish/Re-auth extension . . . . . . . . . . . . . . . 8 + 5.4. TV and TLV Attributes . . . . . . . . . . . . . . . . . . 10 6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 11 7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 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 to not @@ -125,29 +125,28 @@ EA Abbreviation for "ERP/AAK"; used in figures MH Mobile Host SAP Serving Attachment Point [RFC5836] 3. ERP/AAK Overview 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). The - document also specifies a method by which the SAP may send the - identities of neighboring attachment points to the peer in the EAP- - Initiate/Re-auth-Start message. + arrival of the MH at the Candidate Access Network (CAN). It is assumed that the peer has previously completed full EAP - authentication. 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. + 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. +------+ +-----+ +-----+ +-----------+ | Peer | | SAP | | CAP | | EA Server | +--+---+ +--+--+ +--+--+ +-----+-----+ | | | | 1. | [EAP-Initiate/ | | | | Re-auth-start | | | | (E-flag) | | | |<---------------| | | | | | | @@ -173,84 +172,91 @@ | Re-auth(E-flag)| | | |<---------------| | | | | | | Figure 1: ERP/AAK Operation ERP/AAK re-uses 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 itself, or does so in response to an EAP-Initiate/Re-Auth-Start message from the SAP. In - this document, it is required that the SAP should support ERP/AAK. - If either the peer or the SAP does not support ERP/AAK, it should - fall back to full EAP authentication. + this document, SAP support for ERP/AAK is assumed. If either the + peer or the SAP does not support ERP/AAK, it should fall back to full + EAP authentication. + + 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 NAS- + 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 NAS- + 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 authorizes the CAP presented in the - NAS-Identifier TLV(s) via the NAS-Identifier. After the CAP is - authenticated and authorized successfully, the ERP/AAK server derives - the pRK and the subsequent pMSK for the CAP. + 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(s) via AAA as described in Section 7. + 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 - determined CAP to the peer via the SAP. + message (EAP-Finish/Re-auth with E-flag set) containing the identity + of the authorized CAP to the peer via the SAP. 4. ERP/AAK Key Hierarchy - As an optimization of ERP, ERP/AAK uses 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 + 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(s) when the peer + 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. DSRK EMSK | | +---+---+---+---+ | | | pRK rRK ... Figure 2 The EMSK and DSRK both can be used to derive the pRK. In general, the pRK is derived from the EMSK in case of the peer moving in the home AAA realm and derived from the DRSK in case of the peer moving - in the visited AAA realm. The DSRK is delivered from the EAP server - to the ERP/AAK server as specified in [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. + in a visited realm. The DSRK is delivered from the EAP server to the + ERP/AAK server as specified in [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. pRK | +--------+--------+ | | | pIK pMSK ... Figure 3 - The pRK is used to derive the pIK and pMSK for the CAP(s). + The pRK is used to derive the pIK and pMSK for the CAP. 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 Extension Figure 4 shows the changed parameters contained in the EAP-Initiate/ Re-auth-Start packet defined in RFC 5296 [RFC5296]. @@ -265,25 +271,25 @@ Figure 4 Flags 'E' - The E flag is used to indicate early-authentication. Reserved: MUST be set to 0. TVs and TLVs - NAS-Identifier: As defined in [RFC5296], it is carried in a TLV - payload. It is used by the SAP to advertise the identifier(s) of - CAP(s) to the peer. One or more NAS-Identifier TLVs MAY be included - in the EAP-Initiate/Re-auth-Start packet if the SAP has performed CAP - discovery. + 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. 5.2. EAP-Initiate/Re-auth Packet Extension Figure 5 illustrates the changed parameters contained in the EAP- Initiate/Re-auth packet defined in RFC 5296 [RFC5296]. 0 1 2 3 @@ -315,30 +321,27 @@ 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. - NAS-Identifier: As defined in RFC 5296 [RFC5296], it is carried in a - TLV payload. It is used to indicate the identifier of a CAP. Though - this document only introduces the case of a single CAP, two or more - NAS-Identifier may be included in the EAP-Initiate/Re-auth packet to - identify multiple CAPs. + CAP-Identifier: Carried in a TLV payload. It is used to indicate the + FQDN of a CAP. - Sequence number: It is carried in a TV payload. The Type is TBD - (which is lower than 128). It is used in the derivation of the pMSK - for each CAP. Each NAS-Identifier in the packet MUST be associated - with a unique sequence number. + 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: 0 RESERVED 1 HMAC-SHA256-64 @@ -386,138 +389,129 @@ 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[RFC5296], this is carried in a TLV - payload. The Type is 1. The NAI is variable in length, not + 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: It is carried in a TLV payload for the key container. - The type is TBD. One or more than one ERP/AAK-key may be present in - an EAP-Finish/Re-auth packet. + 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. ERP/AAK-Key ::= - { sub-TLV: NAS-Identifier } + { sub-TLV: CAP-Identifier } { sub-TLV: pMSK-lifetime } { sub-TLV: pRK-lifetime } { sub-TLV: Cryptosuites } - NAS-Identifier: It is carried in a sub-TLV payload. It is used to - indicate the identifier of candidate authenticator. There exactly - one instance of the NAS-Identifier TLV MUST be present in the ERP/ + CAP-Identifier + Carried in a sub-TLV payload. It is used to indicate the + identifier of the candidate authenticator. There exactly one + instance of the CAP-Identifier TLV MUST be present in the ERP/ AAK-Key TLV. - pMSK-lifetime: It is carried in a sub-TLV payload. The Type is - TBD. The value field is a 32-bit field and contains the lifetime - of the pMSK in seconds. If the 'L' flag is set, the pMSK Lifetime - attribute SHOULD be present. + pMSK-lifetime + Carried in a sub-TLV payload. The Type is TBD. The value field + is a 32-bit field and contains the lifetime of the pMSK in + seconds. If the 'L' flag is set, the pMSK Lifetime attribute + SHOULD be present. - pRK-lifetime: It is carried in a sub-TLV payload. The Type is - TBD. The value field is a 32-bit field and contains the lifetime - of the pRK in seconds. If the 'L' flag is set, the pRK Lifetime - attribute SHOULD be present. + pRK-lifetime + Carried in a sub-TLV payload. The Type is TBD. The value field + is a 32-bit field and contains the lifetime of the pRK in seconds. + If the 'L' flag is set, the pRK Lifetime attribute SHOULD be + present. - List of Cryptosuites: This is a sub-TLV payload. The Type is TBD. - The value field contains a list of cryptosuites, each 1 octet in - length. The allowed cryptosuite values are as specified in - Section 5.2, above. The server SHOULD include this attribute if - the cryptosuite used in the EAP-Initiate/Re-auth message was not + List of Cryptosuites + Carried in a sub-TLV payload. The Type is 5 [RFC5296]. The value + field contains a list of cryptosuites, each 1 octet in length. + The allowed cryptosuite values are as specified in Section 5.2, + above. The server SHOULD include this attribute if the + cryptosuite used in the EAP-Initiate/Re-auth message was not acceptable and the message is being rejected. The server MAY include this attribute in other cases. The server MAY use this attribute to signal to the peer about its cryptographic algorithm capabilities. 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. -5.4. TV/TLV and sub-TLV Attributes - - The TV and TLV attributes are the same specified as section 5.3.4 of - [RFC5296]. In this document, some new TLV(s) which may be present in - the EAP-Initiate or EAP-Finish messages are defined as below: - - Sequence number - This is a TV payload. The type is TBD. - - ERP/AAK-Key - This is a TLV payload. The type is TBD. +5.4. TV and TLV Attributes - The format of sub-TLV attributes that may be present in the EAP- - Initiate or EAP-Finish messages is: + 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: - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Value ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + o Sequence number: This is a TV payload. The type is TBD. - The following types are defined in this document: + o ERP/AAK-Key: This is a TLV payload. The type is TBD. - pRK Lifetime: This is a TV payload. The type of this sub-TLV is - TBD. + o pRK Lifetime: This is a TV payload. The type is TBD. - pMSK Lifetime: This is a TV payload. The type of this sub-TLV is - TBD. + o pMSK Lifetime: This is a TV payload. The type is TBD. - List of Cryptosuites: This is a TLV payload. The type of this - sub-TLV is TBD. + o List of Cryptosuites: This is a TLV payload. The type is TBD. 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 + revised to support ERP/AAK; refer to of Section 6 [RFC5296] for additional guidance. 7. AAA Transport Considerations 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. 8. Security Considerations This section provides an analysis of the protocol in accordance with - the AAA key management requirements specified in [RFC4962] + the AAA key management requirements specified in RFC 4962 [RFC4962]. o Cryptographic algorithm independence: ERP-AAK satisfies this requirement. The algorithm chosen by the peer is indicated in the EAP-Initiate/Re-auth message. If the chosen algorithm is unacceptable, the EAP server returns an EAP- Finish/Re-auth - message with Failure indication + message with Failure indication. o Strong, fresh session keys: ERP-AAK results in the derivation of strong, fresh keys that are unique for the given CAP. An 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 pIK and pMSK for the CAP. Different sequence numbers for each CAP MUST be used to - derive the unique pMSK. + derive a unique pMSK. o Replay detection mechanism: For replay protection of ERP-AAK messages, a sequence number associated with the pMSK is used. o Authenticate all parties: The EAP Re-auth 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 @@ -527,52 +521,54 @@ 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 the compromise of one pMSK does not hurt any other CAP. - o Bind key to its context: the pMSK are binded to the context where - the sequence numbers are transmitted. + o Bind key to its context: the pMSK are bound to the context in + which the sequence numbers are transmitted. - o Confidentiality of identity: this is the same with ERP protocol as - analyzed in [RFC5296]. + o Confidentiality of identity: this is the same as with the ERP + protocol [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 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: - Sequence number - - ERP/AAK-Key + o Sequence number - New sub-TLV types: + o ERP/AAK-Key - pRK Lifetime + o pRK Lifetime - pMSK Lifetime + o pMSK Lifetime 10. Acknowledgement In writing this document, we have received reviews from many experts - in IETF, including Tom Taylor, Tena Zou, Tim Polk. We apologize if - we miss some names that have helped us. + 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. 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. [RFC5296] Narayanan, V. and L. Dondeti, "EAP @@ -627,27 +623,27 @@ EMail: denghui02@gmail.com Yungui Wang Huawei Technologies Co., Ltd. Floor 10, HuiHong Mansion, No.91 BaiXia Rd. Nanjing, Jiangsu 210001 P.R. China Phone: +86 25 84565893 EMail: w52006@huawei.com + Qin Wu Huawei Technologies Co., Ltd. Floor 12, HuiHong Mansion, No.91 BaiXia Rd. Nanjing, Jiangsu 210001 P.R. China Phone: +86 25 84565892 EMail: bill.wu@huawei.com - - Glen Zorn + Glen Zorn (editor) Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand Phone: +66 (0) 87-040-4617 - EMail: gwz@net-zen.net + EMail: glenzorn@gmail.com