Network Working Group K. Chowdhury Internet-Draft Starent Networks Expires: August 9, 2006 J. Bournelle GET/INT M. Nakhjiri Motorola February 5, 2006 Problem Statement for the AMSK draft-chowdhury-hoakey-amsk-ps-00 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 9, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Network operators offer multiple services ranging from basic network access level service to application level service. Each of these services require independent authentication and authorization steps. Depending on the number of services and the scale of these networks, the need for multiple levels of authentication and authorization Chowdhury, et al. Expires August 9, 2006 [Page 1] Internet-Draft AMSK PS February 2006 phases not only makes the operation complex, but it increases network load and session setup latency. This document summarizes the related problem scenarios. The goal is to address these problem scenarios with a solution based on the EAP keying framework. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. EAP Keying Framework . . . . . . . . . . . . . . . . . . . . . 4 4. The Application Master Session Key . . . . . . . . . . . . . . 4 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 6. Example Deployment Scenarios . . . . . . . . . . . . . . . . . 5 6.1 The Scenario Without a Key Holder . . . . . . . . . . . . 5 6.2 The Scenario Withh a Key Holder . . . . . . . . . . . . . 6 7. Security considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 10. Informative References . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 10 Chowdhury, et al. Expires August 9, 2006 [Page 2] Internet-Draft AMSK PS February 2006 1. Terminology The keywords "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]. Most of the terms used in this document are extracted from the EAP Keying Framework Document [I-D.ietf-eap-keying] and the AAA-Key based keying for Wireless Handover Problem Statement Document [I-D.nakhjiri-aaa-hokey-ps]. The terms used in this document are (re-)stated below for better readability: AAA server: The entity that is the main point of trust and authorization in the user's administrative domain. It maintains peer information and possibly keying information. The AAA server relies on the EAP server to authenticate its clients and to obtain keying materials. EAP server: The EAP server terminates the EAP authentication method with the EAP client through a pass-through authenticator and can derive Master Session Key (MSK, EMSK, AMSK) as defined in [I-D.ietf-eap-keying]. Key Holder: This entity is the one that holds root key/s for key derivation process. This entity may need to have AAA client functionality if it receives keying material form a AAA server. Mobile Node (MN) (peer): The entity that queries for network access and for IP-based services. It acts as an EAP peer functionality as described in [RFC3748] and [I-D.ietf-eap-keying]. 2. Introduction EAP is being adopted as a generic authentication framework by different SDOs like 3GPP2 and WiMAX. In general EAP is used to authenticate the device and the user for network access service. Beyond that, EAP may also be used to setup security associations for various services ranging from mobility services to application level services. Often this involves multiple EAP transactions with different EAP authenticators. The goal of this document is to define the problem with the need to run EAP several times to obtain services. The intent is also to show that the EAP keying framework may be leveraged to standardize a key derivation and distribution scheme for multiple service agents in a network. Chowdhury, et al. Expires August 9, 2006 [Page 3] Internet-Draft AMSK PS February 2006 3. EAP Keying Framework The EAP server authenticates the EAP peer based on long term credentials. Some of the EAP authentication methods are able to derive some keying materials from these credentials. The document [I-D.ietf-eap-keying] explains the EAP keying management framework. It details the generation, the transport and the usage of the keying materials generated by EAP methods. Specifically, the EAP method used at EAP peer and server derives the Master Session Key (MSK) and the Extended Master Session Key (EMSK). Please refer to [I-D.ietf-eap-keying] for more details. 4. The Application Master Session Key The current EAP Key management framework does not explain the purpose of the EMSK. However, the document [aboba-keying-exts] proposes to use it to derive Application Master Session Keys (AMSKs). These AMSKs could be used for extended use. The idea behind AMSK is that the AAA server requests the EAP AMSK key derivation function (KDF) to derive an AMSK per specific application. An AMSK is then derived from the EMSK, an application data label, optional application data and output length. This key is then exported to the AAA layer. AMSK = KDF(EMSK, key label, optional application data, length) This root AMSK is thus available both at the EAP peer and at the EAP/ AAA server. 5. Problem Statement In a typical IP network, the users may access various services offered by the operator. Each of these services normally require authentication and authorization steps. Hence multiple runs of EAP is very likely in today's networks. In most of the cases, the EAP is run between the same peer and EAP server via the same AAA server. Even same root key is be used often times for these EAP transactions. This increases network load unnecessarily and it also increases session setup delay. The EAP-keying framework could be enhanced to derive shared secrets (keys) for the service access based on a single EAP transaction during the network access authentication and authorization. Here is an example scenario with network, mobility and service access (via SIP) as an illustration of the problem: Chowdhury, et al. Expires August 9, 2006 [Page 4] Internet-Draft AMSK PS February 2006 +------+ +------+ +------+ +------+ +------+ | MN/ | | AN | | HA | | SIP- | | AAA/ | | EAPP | | | | | |Server| | EAPS | +------+ +------+ +------+ +------+ +------+ | | | | | |<---net-access------------------------------------------------>| EAP-1 | | | | | | | | | | | | | | | |<----mobility access/IKE----->|<------------------------------>| EAP-2 | | | | | | | | | | | | | | | |<--------Service Registration/IPsec-SA------->|<-------------->| EAP-3 Figure 1: Example Service Access Scenario As seen in (cf. Figure 1), the MN (EAPP: EAP Peer) has to perform multiple EAP transactions with the EAPS: EAP Server to establish SA between it and the various authenticators in the IP network. In a large network, these authenticators may all be located in the same administrative domain. However, there is no mechanism defined today that will allow integration of these authentication steps via a single EAP exchange. Considering this example, the first EAP authentication (EAP-1) could be used to derive some keying materials for the others services. For example, EAP-1 could be used to derive and distribute a master session key: (x)MSK to a Key Holder in the network [I-D.nakhjiri-aaa- hokey-ps] and later used to establish SAs for various applications/ services the MN wants to access. 6. Example Deployment Scenarios Operators deploy networks to offer multiple services. However, there is no framework in place that will allow the operators to offer single-sign-on type of access to their users for the services based on user profile. The need for multiple EAP transactions to authenticate and authorize each service access one-by-one not only slows down the service access process, but also increase signaling overhead on the network and degrade user experience. 6.1 The Scenario Without a Key Holder A possible scenario would be that the AAA server (collocated with the EAP server), based on the user's profiles, determines the services to which the MN may access (e.g. Mobile IPv6, NEMO, SIP, Chowdhury, et al. Expires August 9, 2006 [Page 5] Internet-Draft AMSK PS February 2006 etc). From this, it may proactively or reactively derive and distributes keys to the service nodes. These keys being derivated from AMSKs. This model is shown below: +------------+ | EAPS/ | | AAA | +------------+ ^ ^ ^ / | \ key-1 / key-2| \key-3 / | \ V V V Service Service Service Node-1 Node-2 Node-3 Figure 2: Service Key Provisioning without a Key Holder In the proactive case, the AAA/EAP server derives and distributes keys to Service Nodes in the access network. These Services Nodes provide various services to the user. When a Service Node receives service (or registration) request from the MN, it can process the request without having to fetch the associated key(s) from the AAA/ EAP server. In the reactive case, upon receiving service requests from the MN the Service Node contact the AAA/EAP server in order to get the key to be used to process the service request from the MN. For this, it sends a message containing its identity, the service requested and an identifier for the MN. Others information may also be needed. In either case, the MN must derive and hold the same key(s) corresponding to each Service. 6.2 The Scenario Withh a Key Holder An EAP pass-through authenticator is typically an edge device that may not be trusted enough for caching master keys for a lot of network applications that may have agents in both the visited network (including authenticator) and the home network (including AAA server). The authenticator may not be allowed to cache keys either (per EAP-keying requirements). For this reason, the document [I-D.nakhjiri-aaa-hokey-ps] introduces the entity Key Holder (KH) that will have proper trust relationship and secure channels running Chowdhury, et al. Expires August 9, 2006 [Page 6] Internet-Draft AMSK PS February 2006 into and out of it for transport, caching, and management of keys. In this section, we show how this entity could be used instead of direct interaction with the AAA/EAP server. The key holder holds the AMSKs received during the network access by the user. These AMSKs are sent by the AAA server to the Key Holder. The key holder can either distribute the (derived) keys to the appropriate service nodes or it can wait for the service nodes to request for the specific keys. This possible model is shown below: +-------+ | EAPS/ | | AAA | +-------+ | | (SID1-AMSK1, | SID2-AMSK2, | SID3-AMSK3) | V +-------------+ | KH | +-------------+ ^ ^ ^ / | \ key-1 / key-2| \key-3 / | \ V V V Service Service Service Node-1 Node-2 Node-3 Figure 3: scenario-1: Service Key Provisioning using a Key Holder In the Proactive scenario, the Key Holder receives keys to be used with corresponding services (SID1-AMSK1, SID2-AMSK2 and SID3-AMSK3) from the AAA /EAP server. In this example the KH distributes these three keys (or keys derived from the AMSKs) to the service nodes corresponding to the services all at the same time. In the reactive scenario, the user attempts to access (e.g. Mobile IP registration) a service. The Service node makes a request for a shared secret from the Key Holder. In the request, the service node Chowdhury, et al. Expires August 9, 2006 [Page 7] Internet-Draft AMSK PS February 2006 includes the Service Identifier (SID) and other relevant information (TBD). The KH returns the appropriate key(s) to the service node. Note that unlike in the proactive mode, these transactions take place at different times based on the service initiation by the user. 7. Security considerations The solution framework must address all the security issues related to: 1. Transportation of the keys and/or keying material between the required entities must be secure (confidentiality, integrity protection, authentication). 2. The distributed keys and keying materials must have associated lifetimes. The lifetime of key-0 must be longer than that of the derived keys (key-x). 3. The solution must include provisions for re-keying the derived keys. The solution must also address transport issues after re- keying. 8. IANA Considerations None 9. Acknowledgements TBD 10. Informative References [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-09 (work in progress), January 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.nakhjiri-aaa-hokey-ps] Nakhjiri, M., "AAA based Keying for Wireless Handovers: Problem Statement", draft-nakhjiri-aaa-hokey-ps-01 (work in progress), January 2006. [aboba-keying-exts] Chowdhury, et al. Expires August 9, 2006 [Page 8] Internet-Draft AMSK PS February 2006 Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Extensions", draft-aboba-eap-keying-extns-00.txt (expired), April 2005. Authors' Addresses Kuntal Chowdhury Starent Networks 30 International Place Tewksbury MA 01876 US Email: kchowdhury@starentnetworks.com Julien Bournelle GET/INT 9 rue Charles Fourier Evry 91011 France Email: julien.bournelle@int-evry.fr Madjid Nakhjiri Motorola Email: Madjid.nakhjiri@motorola.com Chowdhury, et al. Expires August 9, 2006 [Page 9] Internet-Draft AMSK PS February 2006 Intellectual Property Statement 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. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Chowdhury, et al. Expires August 9, 2006 [Page 10] Internet-Draft AMSK PS February 2006 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Chowdhury, et al. Expires August 9, 2006 [Page 11]