Handover Keying Working Group M. Vanderveen Internet-Draft Qualcomm Intended status: Informational January 8, 2007 Expires: July 12, 2007 AAA Separation for Roaming draft-vanderveen-aaa-roaming-00.txt 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 July 12, 2007. Copyright Notice Copyright (C) The Internet Society (2007). Abstract This draft proposes a framework that achieves separation of AAA functionality between the home and local domain as it arises in the roaming process. Vanderveen Expires July 12, 2007 [Page 1] Internet-Draft AAA Separation for Roaming January 2007 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Typical Existing Network Access Model . . . . . . . . . . . . 5 5. Proposed Network Access Model . . . . . . . . . . . . . . . . 6 6. Reauthentication with the Visited Domain . . . . . . . . . . . 8 7. Reauthentication with the Home Domain . . . . . . . . . . . . 8 8. Moving between two Local ISPs . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 12. Informative References . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Vanderveen Expires July 12, 2007 [Page 2] Internet-Draft AAA Separation for Roaming January 2007 1. Requirements notation 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]. This draft follows the terminology that has been defined in [RFC2194], [RFC3748] and [I-D.ietf-eap-keying]. This draft uses the term "local" (as in "Local ISP", defined in [RFC2194]), to mean visited ISP, and note that this ISP has a business relationship with the home domain or a third-party broker/settlement system. This draft also uses the term "roaming [capability]", which is defined ("loosely") in the abstract of [RFC2194] as the "ability to use any one of multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one." In addition, this draft uses the following terms: Visited-domain Master Session Key (VMSK) A key derived during the EAP exchange between the user and its home domain, which is given by the home domain to the local domain for purposes of securing access and/or services in the local domain. Access Point (AP) An entity (layer 2 and/or layer 3) located at the edge of network and responsible for providing an access link to the user. This document also uses the following abbreviations: AAAH/L Authentication, Authorization and Accounting Home/Local ISP Internet Service Provider VSP Voice Service Provider 2. Background With the advent of mobile cellular networks integration with the Internet infrastructure, a need has arisen to support roaming of mobile nodes between administrative domains. As a result, new issues have to be solved to allow the user to be authenticated and authorized by the home domain even though physical access is provided by a local (visited) domain. Recall that roaming here is used to describe the process of moving to a local operator from a home operator that has a business relationship with the user. The AAA issues associated with this type of roaming between administrative domains have been investigated only Vanderveen Expires July 12, 2007 [Page 3] Internet-Draft AAA Separation for Roaming January 2007 marginally in IETF. [RFC2194] describes a deployed roaming consortium-based system, employing distributed roaming-aware authentication servers. [RFC2477] puts forth requirements for Internet roaming protocols. [RFC2607] describes an implemented roaming system that uses RADIUS proxy chaining efficiently. More recently, [I-D.greco-sipping-roaming] proposes a solution for the case where the user has a contract with a Voice Service Provider, which provides the users with a token containing all the information that local network (access provider) needs to verify credentials and activate accounting. [draft-ietf-eap-netsel-problem-05.txt] discusses AAA routing based on the NAI of the roaming user. Finally, [I-D.dondeti-eap-vkh] comes the closest to discussing the problem at hand, i.e., efficient security for users while roaming away from their home domain. The solution therein involves a key hierarchy that the home domain supports in order to give out key material to the local domain, to aid in future authentications of the roaming user with the local domain. The key hierarchy is based on the EAP- derived EMSK, and requires that the local domain server employ the EAP-ER scheme in order to facilitate fast, EAP-method-independent re- authentication while in the local domain. This draft proposes a framework that achieves separation of AAA functionality between the home and local domain as it arises in the roaming process, by employing a roaming-aware local domain AAA server, and without requiring changes to the home domain server. 3. Motivation The scenario to be analyzed is as follows: a user has a business relationship and shares long-term credentials with a home ISP (or cellular provider, or VSP). The user roams and obtains service via physical access to a local Internet Access Provider or ISP, as in Figure 1. To this end, the home ISP authenticates/authorizes the user to receive services provided by the local ISP. o +----------+ +-----+ /|\ -------| Internet |-------|Home | / \ | Access | |ISP | user | Provider | +-----+ ^ +----------+ ^ | | \ / --------- contract ------ Vanderveen Expires July 12, 2007 [Page 4] Internet-Draft AAA Separation for Roaming January 2007 Figure 1 In the most generic way, roaming is facilitated by the user providing its Network Access Identifier (NAI), [RFC2486] to the local ISP, which uses the NAI realm for AAA routing, to identify the target AAA system (of the home ISP) and to then proxy the AAA request for the user authentication to that AAA system, potentially via a AAA broker. This AAA proxy-ing requires security associations to exist between the home and local domains (or between the broker and both the home and local domains). This draft outlines an approach to allow the following enhanced roaming capabilities: (i) the provision of a shared secret between the user and the local AAA system, and (ii) the support of temporary accounts for roaming users into the local ISP. The main motivation for this proposed roaming framework is to enable the local operator to have control over user authentication, authorization and accounting for services consumed in the local domain, without mandating any changes to the home AAA server. A secondary motivation is to shield the home AAA server from the local AAA functions. 4. Typical Existing Network Access Model Figure 2 illustrates how a home cellular/network operator can use its AAA system to authenticate a user and authorize service capabilities. If seeking access to the system, a user sends some form of 'connect' message to the access point (AP), which itself triggers an AAA- Request message to the local AAA server. The 'connect' message needs to contain the username and realm of that user in a home NAI to facilitate AAA routing. Note that an alternate means to start an EAP-based authentication is via the EAP-Request/Response-Identity transaction. The AAA-Request message may also include the access interface type (and/or access router type) so that the AAA system understands what interface-specific home AAA processing to apply to that AAA-Request (AVP check-list etc), and what specific parameters need to be returned in the AAA-Answer message (AVP response-list). The user and home AAA server share long-term credentials that are provided as part of service creation. This credential can then be used for a mutual authentication (e.g. based on EAP) between the user and the AAAH. At the end of a successful User-AAAH authentication, the AAA server returns a profile and possibly key material to the AP/Authenticator. The AP/Authenticator can then proceed to secure the User-AP link. Vanderveen Expires July 12, 2007 [Page 5] Internet-Draft AAA Separation for Roaming January 2007 User AP/Authenticator AAAH | | | +-- connect(homeNAI)--> | | | +--AAA-Req(homeNAI)---> | | | | |<========== authentication ===================> | | | | | |<-AAA-Ans(profile) -----+ | | | |<== link auth=========>| | | Typical power-up message flow while in the home ISP domain. Figure 2 5. Proposed Network Access Model The proposed access model requires changes to the AAAL behavior, but no changes in home authentication scheme or AAA messaging, and no changes to the AAAH behavior. Authenticator +----------------------------+ User | AP AAAL | AAAH | +----------------------------+ | | | | | +-- connect(homeNAI)-->| | | | +--AAA-Req(homeNAI)-->| | | | +--AAA-Req(homeNAI)-->| | | | | |<================= authentication================================>| | | | | | | |<--AAA-Ans(VMSK, | | | profile)-------+ | | +------------------------+ | | | | create temp user entry | | | | +------------------------+ | | | | | |<================= other authentication====>| | | | | | Proposed power-up message flow while roaming. Vanderveen Expires July 12, 2007 [Page 6] Internet-Draft AAA Separation for Roaming January 2007 Figure 3 Figure 3 illustrates a power-up access procedure. As an example, if the User-AAAH authentication is based on EAP, then according to the terminology of [RFC3748], the local AAA server (AAAL) and the Access Points (AP) it serves constitute the "Authenticator", while the home AAA server (AAAH) constitutes the "EAP server" for the EAP session with the home domain (Note that [RFC3748] does not preclude such embodiment of an Authenticator.) When a user finds itself in a local network, it requests access from the AP. This triggers a process in AAAL to locate the user's AAAH and forward the access request to that server. AAA routing is out of scope of this draft. The AAAH and the user engage in a (mutual) authentication task whereby the messages follow the same path through the AAAL and AP. After a successful authentication, the AAAH delivers key material, called a Visited-domain Master Session Key (VMSK), its lifetime, and (possibly) a profile for the user to the AAAL. In the exmaple of a (successful) EAP exchange, this amounts to the AAAH sending an EAP-Success message encapsulated in a AAA-Answer message to the AAAL, and containing standard or vendor-specific AVPs carrying the MSK, its lifetime, and possibly a user profile. It is essential that the VMSK be intercepted by the AAAL and not transported to the AP. This is because of two reasons: (i) the VMSK is intended to be the shared secret between the user and AAAL, so should be the only key material that is transferred; and (ii) this transported key should not be used to secure user-AP links, unlike an MSK. Once AAAL obtains the VMSK, it creates a temporary user-specific entry in its database. This entry contains the following values: Home NAI, temporary identifier, VMSK (and lifetime), and possibly user profile and accounting rules. It is not necessary, however, that a temporary identifier be generated and used for the roaming user. Note that in the case of EAP, the local Access Point MUST be able to deal with a missing MSK and expect to facilitate another authentication with the AAAL this time. The AP is expected to realize that the user is a roaming user and so the EAP messaging that just happened are directed to the AAAH, and therefore another phase might be needed for the user to authenticate to the local AAAL. The way in which the AP is informed that this user is roaming can be via the 'connect' message or some other out-of-band means. Following the end of the first authentication, the AAAL may initiate another authentication procedure with the user if session keys are Vanderveen Expires July 12, 2007 [Page 7] Internet-Draft AAA Separation for Roaming January 2007 needed for link layer security and access control. At this point the AAA issues relating to the user connecting to and obtaining services in this domain, are reduced to a known problem that has been worked on in various SDOs. The only constraint is that the security methods employed be based on a shared secret, which is the VMSK. We also note that the user may need to be informed that the first MSK is to be used as a VMSK, for example by the AP via L2 messaging. 6. Reauthentication with the Visited Domain The AAAL can enforce a new authentication or re-authentication with the user according to local policy or user profile. Any standard approach can be applied here, irrespective of the fact that the AAA server is a local one and not the home one. For example, an AP serving the user can trigger an EAP exchange by sending a AAA-Request to the AAAL containing an EAP-Response-Identity message with the temporary identifier of the Peer (user). Alternatively, the AAAL can periodically re-authenticate the user by triggering initiation of an EAP-ER phase. It is assumed that the user, as the least trusted entity, does not have an interest in initiating re-authentication with the AAAL unless required to (and enforced). 7. Reauthentication with the Home Domain The AAAL MUST keep track of the VMSK and its lifetime as given by the AAAH. When the VMSK expires, a new authentication with the AAAH MUST take place. The responsibility of this re-authentication SHOULD lie with the AAAL. That is, the AAAL should only assume that the local services provided will be paid for by the AAAH (directly or indirectly) only if they were consumed within the lifetime of the provided VMSK (and of course within the limits of the provided user profile). Upon VMSK expiration, the AAAL behavior can follow local policy, for example: Passive local policy: the AAAL MUST reject access when a new local-domain re-authentication is due: for example when the AAAL receives an AAA-Request with the User-Name set to the tempID of the Peer, the AAAL SHOULD return a message indicating rejection. Strict local policy: the AAAL triggers authentication with the AAAH immediately upon VMSK expiration. This can be done when the Vanderveen Expires July 12, 2007 [Page 8] Internet-Draft AAA Separation for Roaming January 2007 AAAL supports a AAA client, whereby gratuitous AAA messages can be sent to the AAAH (to be investigated, as it requires that the AAAL know the AP currently serving the user). In addition or as an alternate means, the AP can itself keep track of the VMSK lifetime (even though it does not have access to the VMSK itself) and request a re-authentication with the home ISP upon its expiration. VMSK lifetime expiration triggers the serving AP to send a AAA-Request to the AAAL with the home NAI as the username, signaling that re-authentication with the home, rather than the local domain, is sought. If the AP does not know the home NAI of the Peer, then the temporary ID can be placed in the AAA-Request. Regardless of the value of the AAA attribute carrying the user name, the AAAL SHOULD realize that the VMSK is expired and SHOULD forward this request to the AAAH along with the user's home NAI. Note that the user SHOULD NOT have send the home NAI in the clear and/or to the serving AP again after the power-up (for anonymity support). 8. Moving between two Local ISPs If a user moves between two local domains, it cannot be assumed that the new ISP has a business relationship with the previous ISP. That is, no key sharing of any kind can be assumed or mandated between two local administrative domains. Thus an authentication with the home ISP is necessary. That is, moving to another local ISP likely requires a power-up like procedure (see Figure 3). 9. Security Considerations The security considerations relating to the user-AAA authentication are also applicable here (for the case of EAP, these are outlined in [RFC3748]. Additional security considerations are related to the scope and transport of the VMSK, and are the same as the ones listed in [I-D.dondeti-eap-vkh]. 10. IANA Considerations This document requires no IANA action. 11. Acknowledgments Parts of this draft were based on a 2001 technical memorandum by A. O'Neil and M. Vanderveen. Thanks to Vidya Narayanan and Lakshminath Dondeti for their helpful comments. Vanderveen Expires July 12, 2007 [Page 9] Internet-Draft AAA Separation for Roaming January 2007 12. Informative References [I-D.dondeti-eap-vkh] Dondeti, L. and V. Narayanan, "EAP Keying and Re- authentication in Visited Domains", draft-dondeti-eap-vkh-00 (work in progress), October 2006. [I-D.greco-sipping-roaming] Greco, S. and H. Schulzrinne, "SIP and SAML roaming profile", draft-greco-sipping-roaming-00 (work in progress), September 2006. [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-16 (work in progress), January 2007. [I-D.ietf-eap-netsel-problem] Arkko, J., "Network Discovery and Selection Problem", draft-ietf-eap-netsel-problem-05 (work in progress), October 2006. [I-D.vidya-eap-er] Narayanan, V. and L. Dondeti, "EAP Extensions for Efficient Re-authentication", draft-vidya-eap-er-01 (work in progress), October 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997. [RFC2477] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999. [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", Vanderveen Expires July 12, 2007 [Page 10] Internet-Draft AAA Separation for Roaming January 2007 RFC 3748, June 2004. [RFC3957] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005. Author's Address Michaela Vanderveen Qualcomm Email: mvandervn@yahoo.com Vanderveen Expires July 12, 2007 [Page 11] Internet-Draft AAA Separation for Roaming January 2007 Full Copyright Statement Copyright (C) The Internet Society (2007). 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 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). Vanderveen Expires July 12, 2007 [Page 12]