Network Working Group Y. Ohba Internet-Draft Toshiba Expires: August 25, 2008 R. Lopez University of Murcia February 22, 2008 An EAP Method for Key Distribution Exchange for Handover Re- authentication draft-ohba-eap-kde-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 25, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document describes an EAP method used for carrying KDE (Key Distribution Exchange) protocol for handover re-authentication. This method carries HOKEY KDE messages. This EAP method is designed to work with stand-alone authenticators. Ohba & Lopez Expires August 25, 2008 [Page 1] Internet-Draft EAP-KDE February 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Protocol Operation . . . . . . . . . . . . . . . . . . . . 4 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Bootstrapping EAP-KDE . . . . . . . . . . . . . . . . . . . . 5 5. Per-Authenticator Key, IK and CK . . . . . . . . . . . . . . . 6 6. EAP Method Attributes . . . . . . . . . . . . . . . . . . . . 7 6.1. MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. Server ID . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.2. Informative references . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Ohba & Lopez Expires August 25, 2008 [Page 2] Internet-Draft EAP-KDE February 2008 1. Introduction KDE (Key Distribution Exchange) is a three-party key distribution protocol designed for handover keying [I-D.ietf-hokey-key-mgm]. EAP-KDE is an EAP method designed for carrying KDE over EAP. This EAP method is designed to work with stand-alone authenticators. EAP- KDE has the following characteristics that may achieve the goals in designing the EAP re-authentication and key management protocol [I-D.ietf-hokey-reauth-ps]. No modification to lower layer Since the KDE messages are encapsulated in an EAP method, no modification to existing EAP lower layer is required. No modification to EAP Since the KDE messages encapsulated in an EAP method, no modification to EAP [RFC3748] is required. Minimum modification to AAA protocols For this EAP method to work, some KDE messages need be exchanged outside this EAP method between an authenticator and a KDE server. Such KDE messages are carried over AAA protocols. Specifically, one new AAA attribute is needed to carry KDE messages over existing AAA protocols between an authenticator and a KDE server. One roundtrip beyond access network EAP-KDE requires one AAA roundtrip between authenticator and AAA server. Channel Binding Since KDE cryptographically binds a session key and associated attributes to the identity of an authenticator, EAP-KDE provides Channel Binding property. As observed, EAP-KDE provides the same number of roundtrips (1) as ERP [I-D.ietf-hokey-erx] between an authenticator and an a re- authentication server without modifying EAP. EAP-KDE creates a new usage of KDE to distribute a per-authenticator key from a HOKEY server to an authenticator. Therefore, EAP-KDE can be also considered as an alternative to ERP [I-D.ietf-hokey-erx]. Ohba & Lopez Expires August 25, 2008 [Page 3] Internet-Draft EAP-KDE February 2008 This EAP method is intended to be used for intra-domain handover optimization in a AAA domain. A full EAP authentication with any EAP method is still needed for initial entry of the domain. It should be noted that a similar method-based mechanism with use of stand-alone authenticator may be applicable to carry other authentication and key management protocols such as Kerberos to achieve the same goals. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2.1. Protocol Operation EAP-KDE works with a stand-alone EAP authenticator that is an EAP authenticator co-located with an EAP server supporting this EAP method. In this protocol, an EAP peer is a KDE peer, and an EAP authenticator is a KDE third party. The KDE server may reside in the home AAA domain or visited AAA domain. It is assumed that a Kps (a shared key between the peer and KDE server) has been established using the bootstrapping mechanism described in Section 4. The authenticator that supports EAP-KDE method starts with the EAP- KDE method when a peer attaches to it by sending an EAP-Request/KDE carrying a KDE message 0 (KDE0). If the peer does not support the method or it needs to go through a complete EAP authentication sends a EAP-NAK. Then the authenticator can start the EAP Request/Identity to the peer to perform a full EAP authentication using other EAP method. On the contrary, if the peer supports EAP-KDE and wishes to run it, it answers with EAP-Response/KDE containing a KDE message 1 (KDE1). Once the authenticator receives KDE1, it sends a KDE message 2 (KDE2) to the KDE server over a AAA protocol and waits for a KDE message 3 (KDE3) from the KDE server, and send an EAP-Request/KDE with a KDE message 4 (KDE4) after receiving the KDE3. The AAA message carrying the KDE3 also carries authorization data used for network access. The peer returns an EAP-Request/KDE with an empty Payload in response to the KDE3. The authenticator returns an EAP-Success. (NOTE: Failure case is TBD.) Ohba & Lopez Expires August 25, 2008 [Page 4] Internet-Draft EAP-KDE February 2008 Peer Authenticator/Server KDE Server/AAA Server <-- EAP-Request/KDE{KDE0} --> EAP-Response/KDE{KDE1} --> AAA{KDE2} <-- EAP-Request/KDE{KDE4} <-- AAA{KDE3, authorization data} --> EAP-Response/KDE{} <-- EAP-Success Figure 1: EAP-KDE Call Flow 3. Message Format The Code, Identifier, Length, and Type fields are described in [RFC3748]. The EAP Type for this EAP method is [to be assigned by IANA]. The Payload-Type field contains the type of Payload. The optional Payload field contains data specific to Payload-Type 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 | Payload-Type | Payload (optional) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 2: Message Format Payload-Type Payload Data 0 Empty 1 KDE message 4. Bootstrapping EAP-KDE EAP-KDE requires that the following parameters are bootstrapped from a full EAP authentication with any EAP method that generates EMSK. o The identity of the KDE server (KDE-SERVER-ID) o Kps, the secret key shared between peer and the KDE server (KDE- SERVER-KEY) KDE-SERVER-ID is statically or dynamically configured on the peer. DNS or DHCP may be used for dynamically discovering the KDE-SERVER-ID. Kps (KDE-SERVER-KEY) is derived from EMSK (EAP Master Session Key) as Ohba & Lopez Expires August 25, 2008 [Page 5] Internet-Draft EAP-KDE February 2008 a USRK (Usage Specific Root Key) [I-D.ietf-hokey-emsk-hierarchy] as follows, where USRK denotes the USRK key derivation function defined in [I-D.ietf-hokey-emsk-hierarchy] where the key label, optional data and key length are specified in the first, second and third parameter, respectively. Kps = USRK(key-label="kde-boot-key@ietf.org", op-data=KDE-SERVER-ID, length). The name of the Kps (Kps-Name) is the USRK name of this key. The KDE server may reside in the home domain or visited domain. If the KDE server resides in the home domain, it is assumed that the KDE server is implemented on the same node as the EAP server for the initial EAP authentication. Hence, no protocol is needed for distributing the KDE-SERVER-KEY. If the KDE server resides in the visited domain, it is implemented on a AAA proxy server in the visited domain. The KDE-SERVER-KEY is distributed from the home domain using HOKEY KDE over UDP. Also, the AAA proxy is expected to store the authorization data obtained from the home AAA server during the full EAP authentication performed at the time of initial entry of the visited domain so that the authorization data is associated with the KDE-SERVER-KEY and subsequent EAP-KDE runs once EAP-KDE is bootstrapped in the visited domain. 5. Per-Authenticator Key, IK and CK Kpt, the session key established between the peer and authenticator is derived from Kps as follows, where KDF denotes a key derivation function defined in [I-D.ietf-hokey-emsk-hierarchy] and length denotes the length of the derived key. The default PRF is used for derivation of Kpt. The key-label is "kde-per-authenticator-key@ietf.org". The op-data is SEQps of KDE in network byte order. Kpt = KDF(Kps, key-label + "\0" + op-data + length). key-label: "kde-per-authenticator-key@ietf.org" op-data: SEQps The name of the Kpt (Kpt-Name) is defined as SHA-1-64(Kps-Name + key- label + op-data) where where SHA-1-64 is the first 64-octet of SHA-1. IK and CK, the integrity key and encryption key to protect KDE1 and KDE4 between the peer and KDE server, respectively, are derived using the Kps as the KDRK. Ohba & Lopez Expires August 25, 2008 [Page 6] Internet-Draft EAP-KDE February 2008 6. EAP Method Attributes 6.1. MSK and EMSK A set of 64-octet MSK and 64-octet EMSK to be exported from EAP-KDE is derived from Kpt, the KDE session key established between the peer and stand-alone authenticator as follows. MSK is the first 64-octet of Kpt. EMSK is the next 64-octet of Kpt. The length of Kpt MUST be at least 128-octet. 6.2. Server ID TID (Third party identifier) of KDE is used as the Server ID of this EAP method. 7. Security Considerations The EAP-KDE method transports KDE protocol describe in [I-D.ietf-hokey-key-mgm]. The KDE protocol is a 3-party key distribution protocol. The security of EAP-KDE mainly depends on the security of KDE protocol. Security Claims for this EAP method is provided below. Auth. mechanism: Pre-shared keys. Ciphersuite negotiation: No Mutual authentication: Yes Integrity protection: Yes Replay protection: Yes Confidentiality: No Key derivation: Yes Key strength: min(128, Kpt strength) Dictionary attack prot.: N/A Fast reconnect: Yes Crypt. binding: N/A Session independence: Yes Fragmentation: TBD Channel binding: Yes Protected ciphersuite negotiation EAP-KDE does not support ciphercuite negotiation. Mutual authentication EAP-KDE transports KDE protocol which provides peer authentication in KDE0 message and server authentication in message KDE4. Ohba & Lopez Expires August 25, 2008 [Page 7] Internet-Draft EAP-KDE February 2008 Integrity protection EAP-KDE is a mere carrier of KDE protocol, which is integrity protected. Therefore, this property is applied to the Payload field but not to the whole EAP message. Replay protection KDE protocol transported by EAP-KDE provides replay protection. Additionally, peer receives a success result indication when receiving KDE4 message. Confidentiality EAP-KDE does not provide confidentiality. Key derivation EAP-KDE derives a MSK (64 bytes) and EMSK (64 bytes) from session key Kpt distributed by KDE. Key strength The distributed key Kpt shall have at least 128 octets. From that key, EAP-KDE derives 64 bytes MSK and 64 bytes EMSK. (see Section 6.1). The key strength of exported keying material depends on the strength of Kpt. Dictionary attack resistance No password authentication is used. Fast reconnect EAP-KDE use KDE protocol that provides a fast reconnect feature by itself. In fact, KDE uses the cryptographic material exported from a previous full EAP authentication. Cryptographic binding Since EAP-KDE does not tunnel another EAP method, it does not implement cryptographic binding. Session independence Each time EAP-KDE is performed a new fresh per-authenticator key (Kpt) is derived. Since MSK and EMSK are derived from the new Kpt, they shall be also fresh keys. Ohba & Lopez Expires August 25, 2008 [Page 8] Internet-Draft EAP-KDE February 2008 Fragmentation TBD. Channel binding Since KDE is a three-party key distribution protocol it cryptographically binds a session key and associated attributes to the identity of an authenticator, EAP-KDE provides this property. 8. IANA consideration EAP-KDE requires a new EAP Type value assigned by IANA. EAP-KDE requires a new namespace for EAP-KDE Payload-Type field managed by IANA. This document uses two Payload-Type values 0 (Empty) and 1 (KDE message). EAP-KDE requires a new KDE Key Type values 3 (EAP-KDE KDE Server Key) and 4 (EAP-KDE Per-Authenticator Key) assigned by IANA. EAP-KDE requires two new USRK key label values "kde-boot-key@ietf.org" and "kde-per-authenticator-key@ietf.org" assigned by IANA. 9. Acknowledgements TBD. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [I-D.ietf-hokey-key-mgm] Nakhjiri, M. and Y. Ohba, "Derivation, delivery and management of EAP based keys for handover and re- authentication", draft-ietf-hokey-key-mgm-02 (work in progress), January 2008. Ohba & Lopez Expires August 25, 2008 [Page 9] Internet-Draft EAP-KDE February 2008 [I-D.ietf-hokey-emsk-hierarchy] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", draft-ietf-hokey-emsk-hierarchy-03 (work in progress), January 2008. [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 10.2. Informative references [I-D.ietf-eap-keying] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-22 (work in progress), November 2007. [I-D.ietf-hokey-reauth-ps] Clancy, C., Nakhjiri, M., Narayanan, V., and L. Dondeti, "Handover Key Management and Re-authentication Problem Statement", draft-ietf-hokey-reauth-ps-08 (work in progress), February 2008. [I-D.ietf-hokey-erx] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- authentication Protocol (ERP)", draft-ietf-hokey-erx-11 (work in progress), February 2008. Authors' Addresses Yoshihiro Ohba Toshiba Email: yohba@tari.toshiba.com Rafael Marin Lopez University of Murcia Email: rafa@um.es Ohba & Lopez Expires August 25, 2008 [Page 10] Internet-Draft EAP-KDE February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Ohba & Lopez Expires August 25, 2008 [Page 11]