Network Working Group D. Forsberg Internet-Draft Nokia Expires: April 22, 2006 J. Bournelle GET/INT R. Marin Lopez University of Murcia October 19, 2005 PANA Mobility Optimizations with Session Keys Context (SKC) draft-forsberg-pana-skc-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 April 22, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This specification describes an extension to the PANA protocol that enables usage of a AAA Proxy acting as a Key Distribution Center (KDC) for multiple local PANA Authentication Agents. The AAA Proxy acts as the contact point towards the AAA home server (single SA) and a AAA server and KDC towards the PAAs. This document assumes that Forsberg, et al. Expires April 22, 2006 [Page 1] Internet-Draft PANA MobOpts with SKC October 2005 the local network has multiple PAAs. To avoid signalling between PAAs and the KDC, a Session Key Context is also defined which permits to the KDC to proactively provide a set of keys to a PAA. Session Keys can then be fetched using CXTP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7 5. Session Keys Context . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1 Normative References . . . . . . . . . . . . . . . . . . . 11 7.2 Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 13 Forsberg, et al. Expires April 22, 2006 [Page 2] Internet-Draft PANA MobOpts with SKC October 2005 1. Introduction A PaC using PANA [I-D.ietf-pana-pana] MUST execute full EAP/PANA upon inter-subnet (inter-PAA) movement. In case seamless mobility is desirable, having to execute full EAP authentication with a AAA server would incur undesirable latency. This document outlines the required extensions to the base PANA specification and architecture to eliminate the need to execute EAP each time the PaC performs an inter-PAA handover. The solution described in this document is based on a key derivation scheme where the AAA-Key is used as the root key to derive PAA specific session keys, namely PAA-Keys. The key derivation procedure happens in a AAA Proxy acting as a Key Distribution Center (KDC) for the PAAs. The KDC must have a separate security association (SA) with every PAA it is deriving keys for. These SAs are used to encrypt the derived PAA-Keys. A set of PAA-Keys (named SKC) can then be sent to the current PAA. Forsberg, et al. Expires April 22, 2006 [Page 3] Internet-Draft PANA MobOpts with SKC October 2005 2. 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]. Forsberg, et al. Expires April 22, 2006 [Page 4] Internet-Draft PANA MobOpts with SKC October 2005 3. Framework The proposed architecture with KDC is depicted below (Figure 1). +-------+ PaC |prePAA +--------------+ | +-------+ | | +-+-+ +----+ | |KDC+-----|AAAH| | +-+-+ +----+ | +-------+ | v |newPAA +--------------+ +-------+ Figure 1: PANA with KDC The PaC is authenticated by the prePAA which forwards AAA traffic to its KDC. The KDC acts as a AAA proxy during the authentication phase and thus relays traffic to the AAAH. When KDC has received the authentication result and in case of successful authentication the AAA-Key, it derives PAA-Keys. Having a SA per PAA, it encrypts PAA- Keys with corresponding SAs and sends the whole set of keys to prePAA. This set of keys is called Session Key Context. The key framework is shown on the figure below (Figure 2). In this figure, one assume that EAP server is colocated in the AAA. PaC PAA KDC AAA --- --- --- --- MSK, EMSK MSK, EMSK AAA-Key AAA-Key <---- AAA-Key PAA-Key PAA-Key <--- PAA-Key Figure 2: Keying Framework with KDC The message flow chart depicting mobility-optimized PANA execution is shown below (Figure 3). Forsberg, et al. Expires April 22, 2006 [Page 5] Internet-Draft PANA MobOpts with SKC October 2005 PaC newPAA prePAA | | | 1 |<---------- live PANA session ----------->| | | | 2 x move from subnet1 | | | to subnet2 | | | | | | PDI | | 3 |---------------------->| | | PSR | | 4 |<----------------------| | | PSA | | 5 |---------------------->| CT-req | 6 | |----------------->| | | CT-resp | 7 | PBR |<-----------------| 8 |<----------------------| | | PBA | | 9 |---------------------->| | Figure 3: Mobility optimized PANA call flow. In this flow, the PaC is already authorized and connected to PAA (prePAA) (step 1). Later, the PaC performs a handover from prePAA to newPAA (step 2). Following the movement, PANA discovery and handshake phases are executed (steps 3-5). In response to the parameters included in the PSA, PANA session context is transferred from the prePAA to the new PAA (newPAA) (steps 6,7). Finally, PANA- Bind exchange signals the successful PANA authorization (steps 8,9). In this flow, EAP authentication does not take place. Forsberg, et al. Expires April 22, 2006 [Page 6] Internet-Draft PANA MobOpts with SKC October 2005 4. Protocol Details The AAA Proxy has single SA to the AAA home servers, which realizes more efficient SA management in cases where the local AAA Proxy is managed by different entity than the AAA home server(s). Using a local AAA Proxy it is possible to localize inter-PAA movements and thus not burden the AAA home server unnecessarily (possible multiple hops away from the AAA proxy). PAA-Key derivation is based on multiple identities for channel binding and authentication purposes. AAA-Key (PANA Key-Id AVP) and NAP/ISP (PANA Provider-Identifier AVP) identifiers are used in the key derivation process. To bind the PAA-Key to a specific PAA, the DiameterIdentity of the PAA is used. In this document we assume that the NAP/ISP owns the AAA Proxy and that the AAA home server provides subscriber authentication service for the NAP/ISP. The extensions described in this document provide also mutual authentication between the PAAs and the PaCs, based on the AAA-Key. The KDC derives keys for one or multiple PAAs at a time, encrypts the keys and PAA DiameterIdentifiers with corresponding SAs. There are multiple possibilities for the PAA to get it's corresponding key from the KDC. Upon a mobility event the PAA could ask a key for the PaC from the KDC. This method is called key-request. On the other hand the KDC could pre-distribute the keys to some number of PAAs. This method is called (pre-emptive) pre-distribution. In this document we describe a mechanism that uses pre-distribution as the basis but bundles the PAA keys into a single PaC specific context. This context is called Session Keys Context (SKC) and is transferred between PAAs as is described in the PANA context-transfer document [I-D.bournelle-pana-ctp]. The mechanisms of how the KDC selects the PAAs to be included into the SKC are out of the scope of this document and for further study. For all the different key distribution mechanisms, the PaC must know the AAA-Key and use it with the additional PAA identifier information for the PAA-Key derivation. This provides mutual authentication between PaC and PAA (based on the PAA-Key). During initial authentication phase PaC gets the AAA Key-Id and Provider-Identifier AVPs. In addition to these, a serving PAA needs to send its PAA- Identifier AVP to the PaC. When PaC is moving from one PAA to another, this AVP must be transferred to the PaC before the PaC is able to derive corresponding PAA-Key and authenticate the PAA. The optimizations described in this document require a AAA Proxy acting also as a KDC that knows the the PAA identifiers and its own Provider-Identifier. However, in smaller deployments and where the singaling between PAAs and AAA home server (including also the EAP Forsberg, et al. Expires April 22, 2006 [Page 7] Internet-Draft PANA MobOpts with SKC October 2005 Server) is localized, this kind of KDC is not needed. A mobile PaC's network access authentication performance can be enhanced by deploying a context transfer based mechanism like described in the [I-D.bournelle-pana-ctp], where some session attributes are transferred from the prevPAA to the newPAA in order to avoid performing a full EAP authentication (reactive approach). Additional mechanisms that are based on the proactive AAA state establishment at one or more candidate PAAs may be developed in the future (see for example [I-D.irtf-aaaarch-handoff]). In case the current PAA can retrieve the on-going PANA session attributes from the previous PAA, the PANA session continues with a PANA-Bind exchange. PAA-Key is calculated in the KDC and PaC with the following formula: PAA-Key = The first N bits of HMAC-SHA1(AAA-Key, Provider-Identifier, DiameterIdentity) The value of N depends on the integrity protection algorithm in use, i.e., N=160 for HMAC-SHA1. DiameterIdentity is the identifier of the current (new) PAA. New PANA_MAC_KEY is computed based on the algorithm described in [I-D.ietf-pana-pana], by using the new PAA-Key. The MAC AVP contained in the PANA-Bind-Request and PANA-Bind-Answer messages MUST be generated and verified by using the new PANA_MAC_KEY. Forsberg, et al. Expires April 22, 2006 [Page 8] Internet-Draft PANA MobOpts with SKC October 2005 5. Session Keys Context The SKC contains one or multiple entries. SKC is PaC specific and identified with a Session-Id. Every entry in the SKC contains PAA DiameterIdentity and a PAA-Key encrypted with the shared secret between PAA and the KDC. The whole entry is integrity protected with the shared secret between PAA and KDC. Forsberg, et al. Expires April 22, 2006 [Page 9] Internet-Draft PANA MobOpts with SKC October 2005 6. Security Considerations Only KDC and PaC can derive PAA-Keys. Only PaC and PAA can derive PANA_MAC_KEYs, but also the KDC if it can intercept the nonce exchange between PaC and PAA. These ensure that a single PAA-Key, AAA-Key, or PANA_MAC_KEY is not be used in multiple PAAs at any given time. The nonce exchange provides fresh keys, even if the PaC revisits the same PAA during the lifetime of a AAA-Key. Forsberg, et al. Expires April 22, 2006 [Page 10] Internet-Draft PANA MobOpts with SKC October 2005 7. References 7.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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2 Informative References [I-D.bournelle-pana-ctp] Bournelle, J., "Use of Context Transfer Protocol (CxTP) for PANA", draft-bournelle-pana-ctp-03 (work in progress), June 2005. [I-D.irtf-aaaarch-handoff] Arbaugh, W. and B. Aboba, "Experimental Handoff Extension to RADIUS", draft-irtf-aaaarch-handoff-04 (work in progress), November 2003. Authors' Addresses Dan Forsberg Nokia Research Center P.O. Box 407 FIN-00045 NOKIA GROUP Finland Phone: +358 50 4839470 Email: dan.forsberg@nokia.com Julien Bournelle GET/INT 9 rue Charles Fourier Evry 91011 France Email: julien.bournelle@int-evry.fr Forsberg, et al. Expires April 22, 2006 [Page 11] Internet-Draft PANA MobOpts with SKC October 2005 Rafa Marin Lopez University of Murcia Murcia 30071 Spain Email: rafa@dif.um.es Forsberg, et al. Expires April 22, 2006 [Page 12] Internet-Draft PANA MobOpts with SKC October 2005 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 (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. Forsberg, et al. Expires April 22, 2006 [Page 13]