Network Working Group M. Nakhjiri Internet-Draft Huawei USA Intended status: Informational Y. Ohba Expires: March 19, 2007 Toshiba September 15, 2006 Pre-Authentication AAA requirements draft-nakhjiri-preauth-aaa-req-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 March 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Nakhjiri & Ohba Expires March 19, 2007 [Page 1] Internet-Draft Preauth-AAA requirements September 2006 Abstract Pre-authentication as a solution for providing expedited authenticataion service as part of handover is being considered within a potentially new working group. This draft intends to describe the requirements set forth by Pre-authentication procedure on AAA protocols and attributes. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Assumptions . . . . . . . . . . . . . . . . . . 3 3. Problem Description . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.2. Informative references . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Nakhjiri & Ohba Expires March 19, 2007 [Page 2] Internet-Draft Preauth-AAA requirements September 2006 1. Introduction When the mobile changes attaches to the network, it is often required that the mobile authenticates to the network and receives authorization for the services it is requesting. During handover, i.e. when the mobile changes its point of attachment to the network, it is typically required of the mobile to perform the authentication and authorization process through the new point of attachment. It is becoming more and more common that the authentication and authorization process includes an EAP authentication process [RFC3748], which is typically both delay and message intensive. Pre- authentication is defined as a handover optimization technique that is based on executing EAP between a mobile node and a target authenticator via the serving authenticator before the mobile node handovers to the target authenticator, so that the delay involved in performing EAP signaling is eliminated from the handover critical path to the extent possible. The motivation and problem statement for pre-authentication is described in details in [I-D.ohba-hokeyp-preauth-ps]. However, both the authentication and the authorization process is typically performed between a mobile entity (peer) and a central AAA server, it is important to describe the functionality required from the AAA protocols and servers to support the pre-authentication process. This document intends to tackle the latter problem beyond what is described in the documentations describing encapsulation of EAP messaging inside AAA protocol messages (RADIUS [RFC3579] or Diameter [RFC4072]). 2. Terminology and Assumptions 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]. Most of the terminology found in this document uses the EAP keying document [I-D.ietf-eap-keying]. AAA server: The entity that is the main point of trust and authorization (AAA) in the administrative domain, and maintains peer information and possibly keying information. The AAA server relies on EAP server for execution of EAP-method authentications. EAP server: The EAP server in pre-authentication has the same functionality of a backend EAP server in [RFC3748] and [I-D.ietf-eap-keying], i.e, the EAP server terminates the EAP authentication method with peer through a pass-through authenticator and can perform keying functions. Nakhjiri & Ohba Expires March 19, 2007 [Page 3] Internet-Draft Preauth-AAA requirements September 2006 EAP pass-through authenticator: The pass-through authenticator is the entity between a peer and a backend EAP server that is passing through EAP Request and Response messages ([RFC3748]) without understanding their data content. It can understand EAP success and failure messages. The role of pass-through authenticator during EAP authentication is defined in [RFC3748]. 3. Problem Description Most of the AAA documentations today do not distinguish between a full authentication and a pre-authentication and this creates a set of open issues: Pre-authentication authorization: Many users may not be allowed to have more than one logon session at the time. This means, when such users actively engage in an active session (as a result of a previously valid authentication), they will not be able to perform pre-authentication. The AAA server currently has no way of distinguishing between a full authentication request and a pre- authentication request. Pre-authentication life time : Currently AAA protocols define attributes (AVPs) carrying life time information for a full authentication session. Even when a user profile and the AAA server support pre-authentication function, after the pre- authentication of a peer is complete, since the pre-authentication may be accompanied with a pre-authorization, the pre- authentication is typically valid only for a short amount of time. It is currently not possible for a AAA server to indicate to the AAA client/ NAS or a peer what the life time of the pre- authenticated session is. In other words, it is not clear to the peer or the NAS, when the pre-authentication will expire. Pre-authentication retries: It is typically expected that shortly following the pre-authentication process, the mobile entity moves to the new point of attachment and converts the pre-authentication state to a full authentication state (the procedure for which is not the topic of this particular subsection). However, if the peer has yet not moved to the new location and realizes that the pre-authentication is expiring, it may perform another pre- authentication. In order to avoid unlimited number of pre- authentication tries, it is quite possible that the network policy sets a limit on the maximum number of pre-authentication attempts. Nakhjiri & Ohba Expires March 19, 2007 [Page 4] Internet-Draft Preauth-AAA requirements September 2006 Completion of network attachment: Once the peer has successfully attached to the new point of attachment, it needs to convert its authentication state from pre-authenticated to fully attached and authenticated. There may need to be a mechanism within the AAA protocol to provide this indication to the AAA server. Session Resumption In case the peer ping pongs between a network N1 with which it has a full authentication state to another network N2 and then back to N1, it should possible to simply convert the full authentication state to a pre-authenticated state. The problems around handling session life time and keying material caching needs to be dealt with. multiple candidate authenticators: There may be situations where the mobile node may need to make a selection between a number of candidate attachment points. In such cases it is desirable for the mobile to perform pre-authentication with multiple authenticators. In such cases the AAA server may need to be aware of the situation. roaming support In case the pre-authentication is being performed through a serving network that is foreign to the MN's home AAA server, the AAA server needs to obtain information about the serving network, so that the AAA server can make authorization decisions accordingly (Madjid: I am not sure I understand what this is all about?? need more details). Inter-technology support Current specifications on pre- authentication mostly deal with homogeneous 802.11 networks. The AAA attributes such as Calling-Station-ID [I-D.aboba-radext-wlan] may need to be expanded to cover other access technologies. Furthermore, heterogeneous handovers may require change of the MN identifier as part of the handover. Investigation on the best type of identifiers for multi-access technology MNs is required. Network controlled handovers It is becoming quite common for the network operators to maintain the control over the handovers for among other thing load balancing and performance reasons. Hence the network may need to direct the MN to perform pre- authentication to one a set of candidate authenticators in an anticipation for a handover. The AAA protocol extensions for carrying out such procedures needs to be provided. Nakhjiri & Ohba Expires March 19, 2007 [Page 5] Internet-Draft Preauth-AAA requirements September 2006 4. Security Considerations This document discusses the requirements of the pre-authentication solution for a AAA protocol. Signaling of pre-authentication specific data carried over AAA messages through AAA attributes will have security implications and will place specific requirements on the AAA entities and the AAA protocol, which may or may not be natively met by the AAA protocol, depending on what protocol is chosen. Therefore, the choice of the AAA protocol will effect the security considerations. Some examples are as follows Key Management: Guidance on parameters required, caching, storage and deletion procedures for the keying material to ensure adequate security and authorization provisioning may need to be defined in a solution document or in this document. AAA proxies: One important issue arises from the way the authorization decisions might be handled at the AAA server during network access authentication. For example, if AAA proxies are involved, they may also influence in the authorization decision. Channel Binding TBD More details are TBD. 5. IANA consideration This document may later on require allocation of specific RADIUS attributes or Diameter AVPs, which require IANA assignments. The specifics are currently TBD. 6. Acknowledgements The authors would like to thank Alper Yegin for initiation of this work. 7. References 7.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)", Nakhjiri & Ohba Expires March 19, 2007 [Page 6] Internet-Draft Preauth-AAA requirements September 2006 RFC 3748, June 2004. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-14 (work in progress), June 2006. [I-D.ohba-hokeyp-preauth-ps] Ohba, Y., "Pre-authentication Problem Statement", draft-ohba-hokeyp-preauth-ps-00 (work in progress), April 2006. [I-D.aboba-radext-wlan] Aboba, B., "RADIUS Attributes for WLAN", draft-aboba-radext-wlan-03 (work in progress), June 2006. 7.2. Informative references [802.11r] Institute of Electrical and Electronics Engineer, "Draft Amendment to STANDARD FOR Information Technology - Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements. Part 11:Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Amendment 8: Fast BSS Transition", IEEE std. 802.11r/D2.0. [I-D.housley-aaa-key-mgmt] Housley, R. and B. Aboba, "Guidance for AAA Key Management", draft-housley-aaa-key-mgmt-03 (work in progress), July 2006. [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005. Nakhjiri & Ohba Expires March 19, 2007 [Page 7] Internet-Draft Preauth-AAA requirements September 2006 Authors' Addresses Madjid Nakhjiri Huawei USA 12040 98th AVE NE, Suite 200B Kirkland, WA 98034 USA Email: mnakhjiri@Huawei.com Yoshihiro Ohba Toshiba America Research,Inc 1 Telcordia Dr. Piscataway, NJ 08854 USA Email: yohba@tari.toshiba.com Nakhjiri & Ohba Expires March 19, 2007 [Page 8] Internet-Draft Preauth-AAA requirements September 2006 Full 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. 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). Nakhjiri & Ohba Expires March 19, 2007 [Page 9]