EAP WG Internet Draft Mayumi Yanagiya Document: draft-yanagiya-apl-boot-00.txt NTT Expires: August 14 2005 February 14, 2005 Security Association for application bootstrapping Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 14, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract In [ID-yanagiya-eap-saa-00], [ID-ohba-mip6-boot-arch-dhcp-01], and [ID-yegin-eap-boot-rfc3118-01], it is assumed that a peer and service authenticator execute the authentication or authorization process with a key derived from EAP Keying materials. However, [EAP-Key-04] does not assume that a network element that does not support EAP, such as a DHCP server or Mobile IP home agent, uses the EAP key to authenticate/authorize the user. Thus, it is M.Yanagiya Expires - August 14 2005 [Page 1] draft-yanagiya-apl-boot-00.txt 14 Feb.2004 necessary to define a new security association and key for the application authenticator. Conventions used in this document 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 [i]. Table of Contents 1. Introduction..................................................2 2. Terminology...................................................2 3. Assumed network architecture..................................3 4. Application security association.............................3 4.1. Need for AP-SA..........................................3 4.2. Key for AP-SA...........................................4 4.3. Lifetime of TSK for AP-SA...............................5 4.4. Derivation of TSK for AP-SA.............................5 4.5. Lifetime of AP-SA.......................................5 5. Security considerations......................................5 6. IANA considerations..........................................5 [TBD]............................................................5 7. Informative references.......................................5 Author's Addresses...............................................6 1. Introduction In [ID-yanagiya-eap-saa-00], [ID-ohba-mip6-boot-arch-dhcp-01], and [ID-yegin-eap-boot-rfc3118-01], it is assumed that a peer and service authenticator execute the authentication or authorization process with a key derived from EAP (Extensible Authentication Protocol) Keying materials. However, [EAP-Key-04] does not assume that a network element that does not support EAP, such as a DHCP server or Mobile IP home agent, uses EAP key to authenticate/authorize the user. Thus, it is necessary to define a new security association and key for the application authenticator. 2. Terminology Application authenticator A network element that provides application service such as DHCP and Mobile IP. This node does not support the EAP-based authentication/authorization method. User node A user terminal that acts as an EAP peer and application client such as a DHCP client or mobile node. M.Yanagiya Expires - August 14 2005 [Page 2] draft-yanagiya-apl-boot-00.txt 14 Feb.2004 3. Assumed network architecture Figure 1 shows the network architecture assumed in this document. Between the user node (as an EAP peer function) and EAP authenticator, the access authentication process that uses the EAP method is executed. Between the user node (as an application client) and application authenticator, service authentication/authorization that does not use the EAP method is executed. +------+ +----------------+ +-----+ | User | EAP | EAP | EAP over AAA | | | node |--------| authenticator |----------------| AAA | | | | (e.g., WLAN AP)| | | +------+ +----------------+ +-----+ | | | +-----------------+ | | non-EAP | Application | RADIUS, etc. | +------------| authenticator |------------------+ | (e.g., DHCPS,HA)| +-----------------+ Figure 1: Assumed network architecture. In this document, we assume the following. o During the access authentication process, AAA (Authentication, Authorization, and Accounting server) and the user node can derive the EAP key. o In order to authenticate/authorize the user node, the application authenticator uses a key calculated from the EAP key derived during access authentication. The application authenticator can get the key from AAA. o The user node calculates the key for service authentication/authorization from the EAP key derived during access authentication. 4. Application security association 4.1. Need for AP-SA In [EAP-Key-04], 4 types of security association are specified: Service-SA, AAA-SA, EAP-key-SA, and EAP-Method SA. But they are specified for EAP peer, EAP authenticator, and AAA. When we apply the EAP key framework to authentication between a peer and the application authenticator, we need to introduce a new security association. Thus we introduce a new security association that we call "application security association (AP-SA)" between the application authenticator and peer. M.Yanagiya Expires - August 14 2005 [Page 3] draft-yanagiya-apl-boot-00.txt 14 Feb.2004 EAP Application authenticator authenticator + + |\ AP-SA ->/| | \ / | | \ / | | \ / | Service-SA->| \ / |<-AAA-SA | / \ | | / \ | | / \ | | / <-AAA-SA \ | |/ \| +-------------------+ Peer AAA EAP-key-SA EAP-Method-SA Figure 2. Application SA. 4.2. Key for AP-SA In [EAP-Key-04], it is assumed that AAA sends an AAA-key to the EAP authenticator when EAP authentication has been completed successfully, and the EAP authenticator and EAP peer can establish a security association with a TSK (Transient Session Key) derived from the AAA-key. In [EAP-Key-04], the rules for key expiration are described as follows. "When keying material exported by EAP methods expires, all keying material derived from the exported keying material, (including the AAA-key, AMSKs, and TSKs) also expires." "Note that deletion of the AAA-Key does not necessarily imply deletion of the corresponding TSKs." The EAP authenticator can terminate or pass-through EAP messages, AAA can update the AAA-key on the EAP authenticator during the access re-authentication process. On the other hand, the application authenticator does not treat the EAP message and cannot know when re-authentication is being executed. If AAA sends an AAA- key to the application authenticator, then AAA will have to update the AAA-key on the application authenticator when access re- authentication has been completed successfully. We think that this is not scalable. M.Yanagiya Expires - August 14 2005 [Page 4] draft-yanagiya-apl-boot-00.txt 14 Feb.2004 Thus, we propose that AAA calculates a TSK from the AAA-key and sends it to the application authenticator, which treats the TSK as a pre-shared key. 4.3. Lifetime of TSK for AP-SA Because the TSK for AP-SA is treated as a pre-shared key, the application authenticator does not manage the lifetime of TSK. The TSK for AP-SA does not change whenever access re-authentication is executed. When a user node wants to establish a security association with a new application authenticator or re-establish a security association with the current application authenticator after access re-authentication has been executed, a TSK may be derived from the new AAA-key. 4.4. Derivation of TSK for AP-SA TSK is derived from AAA-key, MSK, EMSK or AMSK on AAA server and user node. Thus, parameters which are used to derive TSK have to be able to share dynamically during service authentication/authorization process. The derivation method is TBD. 4.5. Lifetime of AP-SA The lifetime of the AP-SA will follow the application-specific rules (e.g., When IKE (Internet key exchange) is used to establish the security association, the lifetime of AP-SA is negotiated by IKE. When we apply this architecture to [DHCPv6], the DHCP server and client change the key only when the DHCP session is started by sending a Solicit message.). 5. Security considerations [TBD] 6. IANA considerations [TBD] 7. Informative references [ID-yanagiya-eap-saa-00] M.Yanagiya, H.Ohinishi, "Service Authentication Architecture using EAP key framework", draft- yanagiya-eap-saa-00.txt, February 14, 2005 [ID-ohba-mip6-boot-arch-dhcp-01] Y.Ohba, R.Lopez, M.Yanagiya, H.Ohinishi, K.Chowdhury, "Mobile IPv6 Bootstrapping Architecture Using DHCP", draft-ohba-mip6-boot-arch-dhcp-00.txt, October 17,2004 [ID-yegin-eap-boot-rfc3118-01] A.Yegin, H.Tschofenig, D.Forsberg, "Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based M.Yanagiya Expires - August 14 2005 [Page 5] draft-yanagiya-apl-boot-00.txt 14 Feb.2004 NetworkAccess Authentication", draft-yegin-eap-boot-rfc3118-01, January 25, 2005 [EAP-Key-04] B.Aboba, D. Simon, J.Arkko, P,Eronen, H,Kevkowetz, "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-04.txt, November 14, 2004 Author's Addresses Mayumi Yanagiya NTT Network Service Systems Laboratories 3-9-11 Midori-cho, Musashino-shi Tokyo, Japan Phone: 81-422-5967893 Email: yanagiya.mayumi@lab.ntt.co.jp 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 IETF's procedures with respect to rights in IETF 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. 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. M.Yanagiya Expires - August 14 2005 [Page 6] draft-yanagiya-apl-boot-00.txt 14 Feb.2004 Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. M.Yanagiya Expires - August 14 2005 [Page 7]