PANA Working Group Y. Ohba Internet-Draft Toshiba Expires: September 4, 2006 March 3, 2006 Pre-authentication Support for PANA draft-ietf-pana-preauth-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 September 4, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines an extension to the PANA protocol used for proactively establishing a PANA SA (Security Association) between a PaC in an access network and a PAA in another access network to which the PaC may move. The proposed method operates across multiple administrative domains. Ohba Expires September 4, 2006 [Page 1] Internet-Draft Pre-authentication Support for PANA March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 2. Terminogy . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Pre-authentication Procedure . . . . . . . . . . . . . . . . . 7 4. PANA Extensions . . . . . . . . . . . . . . . . . . . . . . . 11 5. Authorization and Accounting Considerations . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Ohba Expires September 4, 2006 [Page 2] Internet-Draft Pre-authentication Support for PANA March 2006 1. Introduction The PANA protocol [I-D.ietf-pana-pana] carries EAP messages between a PaC (PANA Client) and a PAA (PANA Authentication Agent) in the access network. If the PaC is a mobile device and is capable of moving one access network to another while running its applications, it is critical for the PaC to perform a handover seamlessly without degrading the performance of the applications during the handover period. When the handover requires the PaC to establish a PANA session with the PAA in the new access network, the signaling to establish the PANA session should be completed as fast as possible. There is an optimization method based on Context Transfer Protocol (CTP) [RFC4067] to reduce the signaling delay for establishing a PANA session with a new PAA upon a handover [I-D.ietf-pana-mobopts][I- D.ietf-pana-cxtp]. The CTP-based method have the following issues. First, it is not readily applicable to handovers across multiple administrative domains since having a security association between PAAs in different administrative domains is practically difficult. Second, even within a single administrative domain, the CTP-based method is difficult to work when the previous and new access networks have different authorization characteristics, e.g., on use of NAP and ISP separate authentication. Third, the CTP-based method relies on deriving the PANA_MAC_Key used between the PaC and the PAA in the new access network from the AAA-Key used between the PaC and the PAA in the previous access network, which does not provide perfect cryptographic separation between the PAAs. To address the issues on the CTP-based method, this document defines an extension to the PANA protocol [I-D.ietf-pana-pana] used for proactively executing EAP authentication and establishing a PANA SA (Security Association) between a PaC in an access network and a PAA in another access network to which the PaC may move. The proposed method operates across multiple administrative domains. Although the proposed method covers the case that is also covered by the CTP-based method (i.e., homogeneous authorization characteristics in a single administrative domain), the purpose of this document is not to replace the CTP-based method. Instead, the purpose of this document is to provide a way to cover the cases that are not covered by the other method. For the case covered by the CTP-based method, the CTP-based method may be used. 1.1. Specification of Requirements In this document, several words are used to signify the requirements Ohba Expires September 4, 2006 [Page 3] Internet-Draft Pre-authentication Support for PANA March 2006 of the specification. These words are often capitalized. 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]. Ohba Expires September 4, 2006 [Page 4] Internet-Draft Pre-authentication Support for PANA March 2006 2. Terminogy The following terms are used in this document in addition to the terms defined in [I-D.ietf-pana-pana]. Access Network: A network through which a PaC can access to the Internet via one or more EPs controlled by one or more PAAs. An access network may consist of multiple IP links. Local PAA: A PAA that resides in the access network where the PaC is connected. The term "local" is relative to the location of a particular PaC. Remote PAA: A PAA that is not a local PAA for the PaC. The term "remote" is relative to the location of a particular PaC. A PAA that is a remote PAA for one PaC may be a local PAA for another PaC. Local PaC: A PaC that resides in the same access network as a particular PAA. The term "local" is relative to the location of a specific PaC. Remote PaC: A PaC that is not a local PaC for a particular PAA. The term "remote" is relative to the location of a particular PAA. A PaC that is a remote PaC for one PAA may be a local PaC for another PAA. Active PAA: A local PAA for which the PaC has a PANA session. Preparing PAA: A remote PAA which performs pre-authentication with the PaC. A PAA that is serving as a preparing PAA for one PaC may be serving as an active PAA for another PaC. Ohba Expires September 4, 2006 [Page 5] Internet-Draft Pre-authentication Support for PANA March 2006 Pre-authentication: Authentication performed between the PaC and a preparing PAA. Pre-authentication SA: A PANA SA that is established between the PaC and a preparing PAA as a result of successful pre-authentication. Active SA: A PANA SA that is established between the PaC and an active PAA. Pre-authorization: An authorization that is made for the PaC by a preparing PAA as a result of successful pre-authentication. Post-authorization: An authorization that was made for the PaC by a PAA that was acting as a preparing PAA and has become the active PAA. Ohba Expires September 4, 2006 [Page 6] Internet-Draft Pre-authentication Support for PANA March 2006 3. Pre-authentication Procedure A PaC that supports pre-authentication may have one or more PANA sessions for preparing PAAs in addition to the PANA session for one of local PAAs. There may be a number of ways to discover a remote PAA, however, remote PAA discovery and remote PaC discovery is out of the scope of this proposal. There may be a number of criteria as to when and with which remote PAA pre-authentication is performed. Such criteria can be implementation specific and thus are outside the scope of this document. Pre-authentication may be initiated by both a PaC and a preparing PAA. A new flag P-flag is defined in the PANA header. When pre- authentication is performed, the P-flag of PANA messages are set in order to indicate whether this PANA run is for establishing a pre- authentication SA. Pre-authentication is negotiated in the PANA discovery and handshake phase as follows. o When a PaC initiates pre-authentication, it sends a PANA-PAA- Discover message with the P-flag set. The PANA-PAA-Discover message MUST be unicast. The PAA responds with a PANA-Start- Request message with the P-flag set only when it supports pre- authentication. Otherwise, it MUST silently discard the message. o When a preparing PAA initiates pre-authentication, it sends a PANA-Start-Request message with the P-flag set. The PaC responds with a PANA-Start-Answer message with the P-flag set only when it supports pre-authentication. Otherwise, it MUST silently discard the message. o Once the PaC and preparing PAA have agreed on performing pre- authentication during the discovery and handshake phase, the subsequent PANA messages exchanged between them MUST have the P-flag set. When the preparing PAA becomes an active PAA due to movement of the PaC, the PaC performs an IP address update procedure using PANA- Update exchange in order to update the PAA with the PaC's new address obtained from the remote network where the PAA resides. The completion of the PANA-Update procedure will change the pre- authentication SA to the active SA. The P-flag is not set in the PANA-Update messages and subsequent PANA messages. When the PaC having an active SA with an active PAA as well as a pre- Ohba Expires September 4, 2006 [Page 7] Internet-Draft Pre-authentication Support for PANA March 2006 authentication SA with a preparing PAA changes its active PAA but without changing the preparing PAA, the PaC performs an IP address update procedure using PANA-Update exchange in order to update the PAA of the PaC's new address obtained from the remote network where the new active PAA resides. The completion of the PANA-Update procedure will not change the pre-authentication SA to the active SA. The P-flag is set in the PANA-Update messages and subsequent PANA messages. The pre-authentication SA and corresponding PANA session between the PaC and the pre-authenticated PAA can be deleted by entering the termination phase of the PANA protocol and performing the required procedure for that phase. An example call flow for PaC-initiated pre-authentication is shown in Figure 1. A PaC in an access network establishes a PANA session with a local PAA (l-PAA). At some point, it receives a trigger for pre- authenticating to a remote PAA (r-PAA) in another access network. The PaC then initiates a pre-authentication procedure by sending a PANA-PAA-Discover message with the P-bit set. PANA messages are exchanged between the PaC and r-PAA, with the P-bit set for all messages. On successful completion of the PANA exchanges for pre- authentication and pre-authorization, a pre-authentication SA will be established between the PaC and l-PAA. On the other hand, the active SA established between the PaC and l-PAA stays active. At some point after establishing the pre-authentication SA, the PaC moves to the access network of the r-PAA. The r-PAA may be found by running PAA discovery over a newly created session or immediately when the PaC attaches a link-layer device that is acting as an EP whose device identifier was contained in the list of EP device identifiers advertised by the r-PAA in the pre-authentication procedure. If the r-PAA is found, the PaC initiates a PANA-Update exchange over the session in which the pre-authentication SA has been maintained to inform the PAA of the IP address change. In this PANA- Update exchange, the P-bit is unset. On successful completion of the PANA-Update exchange and post-authorization procedure, the pre- authentication SA becomes the active SA. The active SA between the PaC and l-PAA may stay active for a while to deal with the case in which the PaC immediately switches back to the previous access network. If no such an r-PAA is found but other PAA(s) in the new access network, a full PANA authentication or PANA mobility optimization may be performed between the PaC and one of those PAA(s) based on the procedures described in [I-D.ietf-pana-pana] and [I-D.ietf-pana- Ohba Expires September 4, 2006 [Page 8] Internet-Draft Pre-authentication Support for PANA March 2006 cxtp]. PaC l-PAA r-PAA | | | | PANA w/o P-bit set | | |<---------------------->| | | | | . . . . . . +------------------+ | | |Pre-authentication| | | |trigger | | | +------------------+ | | | PDI w/P-bit set | |------------------------------------------------>| | PSR w/P-bit set | |<------------------------------------------------| | PSA w/P-bit set | |------------------------------------------------>| | PAR-PAN exchange w/P-bit set | |<----------------------------------------------->| | | +------------------+ | | |pre-authorization | | | +------------------+ | PBR-PBA exchange w/P-bit set | |<----------------------------------------------->| . . . . . . +----------+ | | | Movement | | | +----------+ | | | PUR w/o P-bit set | |------------------------------------------------>| | | +------------------+ | | |post-authorization| | | +------------------+ | PUA w/o P-bit set | |<------------------------------------------------| | | | Figure 1: PaC-initiated Pre-authentication Call Flow An example call flow for PAA-initiated pre-authentication is shown in Figure 2. Ohba Expires September 4, 2006 [Page 9] Internet-Draft Pre-authentication Support for PANA March 2006 PaC l-PAA r-PAA | | | | PANA w/o P-bit set | | |<---------------------->| | | | | . . . . . . | | +------------------+ | | |Pre-authentication| | | |trigger | | | +------------------+ | PSR w/P-bit set | |<------------------------------------------------| | PSA w/P-bit set | |------------------------------------------------>| | PAR-PAN exchange w/P-bit set | |<----------------------------------------------->| | | +------------------+ | | |pre-authorization | | | +------------------+ | PBR-PBA exchange w/P-bit set | |<----------------------------------------------->| . . . . . . +----------+ | | | Movement | | | +----------+ | | | PUR w/o P-bit set | |------------------------------------------------>| | | +------------------+ | | |post-authorization| | | +------------------+ | PUA w/o P-bit set | |<------------------------------------------------| | | | Figure 2: PAA-initiated Pre-authentication Call Flow Ohba Expires September 4, 2006 [Page 10] Internet-Draft Pre-authentication Support for PANA March 2006 4. PANA Extensions A new P-flag is defined in Flags field of PANA header as follows. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R S N P r r r r r r r r r r r r| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P(re-authentication) When pre-authentication is performed, the P-flag of PANA messages are set in order to indicate whether this PANA run is for establishing a pre-authentication SA. The exact usage of this flag is described in Section 3. This flag is to be assigned by IANA. Ohba Expires September 4, 2006 [Page 11] Internet-Draft Pre-authentication Support for PANA March 2006 5. Authorization and Accounting Considerations A pre-authorization and a post-authorization for the PaC may have different authorization policies. For example, the pre-authorization policy may not allow the PaC to sent or receive packets through the EP(s) under control of the preparing PAA, while both the pre- authorization and post-authorization policies may allow installing credentials to the EP(s), where the credentials are used for establishing a security association for per-packet cryptographic filtering. In an access network where accounting is performed, accounting starts when the pre-authentication SA becomes the active SA by default. Depending on the pre-authorization policy, accounting may start immediately after the pre-authentication SA is established. Ohba Expires September 4, 2006 [Page 12] Internet-Draft Pre-authentication Support for PANA March 2006 6. Security Considerations Since the mechanism described in this document is designed to work across multiple access networks, each EP (Enforcement Point) SHOULD be configured to allow PANA messages to be forwarded between a PaC and a preparing PAA in a different access network only if the PaC has an active SA with a local PAA in order to avoid an unauthorized PaC to initiate pre-authentication. Also, each access network that supports pre-authentication SHOULD block pre-authentication attempts from networks from which a handover is not likely to occur. When pre-authentication is initiated by a remote PAA, it is possible that the PaC simultaneously communicates with multiple remote PAAs initiating pre-authentication. In order to avoid possible resource consumption attacks on the PaC caused by a blind attacker initiating pre-authentication for the PaC by changing source addresses, the PaC SHOULD limit the maximum number of PAAs allowed to communicate. Ohba Expires September 4, 2006 [Page 13] Internet-Draft Pre-authentication Support for PANA March 2006 7. IANA Considerations As described in Section 4, a new flag in the Flags field of PANA Header needs to be assigned by IANA. The new flag is bit 3 ('P're- authentication). Ohba Expires September 4, 2006 [Page 14] Internet-Draft Pre-authentication Support for PANA March 2006 8. Acknowledgments The author would like to thank Alper Yegin, Ashutosh Dutta, Julien Bournelle and Sasikanth Bharadwaj for their valuable comments. Ohba Expires September 4, 2006 [Page 15] Internet-Draft Pre-authentication Support for PANA March 2006 9. References 9.1. Normative References [I-D.ietf-pana-pana] Forsberg, D., "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-10 (work in progress), July 2005. 9.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. [I-D.ietf-pana-mobopts] Forsberg, D., "PANA Mobility Optimizations", draft-ietf-pana-mobopts-01 (work in progress), October 2005. [I-D.ietf-pana-cxtp] Bournelle, J., "Use of Context Transfer Protocol (CXTP) for PANA", draft-ietf-pana-cxtp-00 (work in progress), October 2005. Ohba Expires September 4, 2006 [Page 16] Internet-Draft Pre-authentication Support for PANA March 2006 Author's Address Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscateway, NJ 08854 USA Phone: +1 732 699 5365 Email: yohba@tari.toshiba.com Ohba Expires September 4, 2006 [Page 17] Internet-Draft Pre-authentication Support for PANA March 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ohba Expires September 4, 2006 [Page 18]