Network Working Group J. Bournelle Internet-Draft M. Laurent-Maknavicius Expires: novembre 30, 2004 GET/INT H. Tschofenig Siemens Y. El Mghazli Alcatel G. Giaretta TILab June 2004 Context Transfer for PANA draft-bournelle-pana-ctp-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 novembre 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The PANA protocol offers a way to authenticate clients in IP based access networks. It carries EAP over UDP which permits ISPs to use multiple authentication methods. However, in roaming environments IP clients might change of gateways and new EAP authentication from scratch may occur. This can considerably degrade performance. Bournelle, et al. Expires novembre 30, 2004 [Page 1] Internet-Draft Context Transfer for PANA June 2004 To enhance IP handover in mobile environments, we propose to use the Context Transfer Protocol. The aim is to recover from previous PANA Authentication Agent the PANA security context previously established. For this, we define some ways to trigger the transfer and the content of what we called a PANA context. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1 PANA overview . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2 IPsec based access control . . . . . . . . . . . . . . . . . 5 3.2 Re-authentication of PaC . . . . . . . . . . . . . . . . . . 5 3.2.1 Re-authentication based on EAP . . . . . . . . . . . . . . . 5 3.2.2 Re-authentication based on PANA . . . . . . . . . . . . . . 6 3.2.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Context Transfer for PANA . . . . . . . . . . . . . . . . . 8 4.1 CTP overview . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2 Extensions to PANA and CTP . . . . . . . . . . . . . . . . . 9 4.3 Conditions to Perform the Transfer . . . . . . . . . . . . . 9 4.4 Transfer of AAA-Key . . . . . . . . . . . . . . . . . . . . 9 4.5 The PANA Session Attributes . . . . . . . . . . . . . . . . 11 4.6 Contacting the AAA server . . . . . . . . . . . . . . . . . 13 4.7 Operations . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.7.1 Operations in the Non-predictive mode . . . . . . . . . . . 14 4.7.2 Operations in the Predictive mode . . . . . . . . . . . . . 16 5. General Issues . . . . . . . . . . . . . . . . . . . . . . . 18 6. Security considerations . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 Normative References . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . 23 Bournelle, et al. Expires novembre 30, 2004 [Page 2] Internet-Draft Context Transfer for PANA June 2004 1. Introduction In IP based access network, PANA [I-D.ietf-pana-pana] may be used as a front-end to a AAA architecture in order to authenticate users before granting them access to the resources. For this purpose, it uses EAP which offers a variety of authentication methods. In a shared medium this is typically accomplished with help of cryptographic mechanisms. Note that this type of cryptographic mechanism prevents a malicious node from sending packet to the network and thereby authenticating each data packet. In addition, encryption is often enabled to prevent eavesdropping. While roaming, the PANA client might change its access router. Without extensions to PANA the PaC has to restart a new PANA protocol exchange to authenticate itself to the network. In some cases it is necessary to execute the EAP exchange from scratch whereas in other cases it might be possible to benefit from state stored at the visited networks AAA server. This procedure is known as fast resume. In this document, we propose a mechanism to avoid re-authentication from scratch by using the framework defined in [I-D.ietf-seamoby-ctp]. State established during the initial authentication and the key establishment procedure (using PANA) is transferred between the old and new points of attachment. Bournelle, et al. Expires novembre 30, 2004 [Page 3] Internet-Draft Context Transfer for PANA June 2004 2. Terminology This document uses the following terms or abbreviations: PANA: Protocol for CArrying Network Authentication for Network Access PANA Client (PaC): A mobile node (MN) using a PANA protocol implementation to authenticate itself to the network. New Access Router (nAR): The router to which the PaC attaches after the handover. Previous Access Router (pAR): The router to which the PaC was attached before the handover. New PANA Authentication Agent (nPAA): The PAA in charge of the subnet to which the PaC was attached before the handover. Previous PANA Authentication Agent (pPAA): The PaC's default PAA prior to handover. EP: Enforcement Point. Context Transfer Protocol (CTP). Context Transfer Data (CTD) Context Transfer Activate Request (CTAR) Context Transfer Activate Acknowledge (CTAA) Feature Profile Type (FPT) Bournelle, et al. Expires novembre 30, 2004 [Page 4] Internet-Draft Context Transfer for PANA June 2004 3. Motivations 3.1 Background 3.1.1 PANA overview PANA is a protocol that carries EAP over IP/UDP to authenticate users. The PAA (PANA Authentication Agent) is the endpoint of the PANA protocol at the access network. The PAA itself might not be able to authenticate the user by terminating the EAP protocol. Instead the PAA might forward the EAP payloads to the backend AAA infrastructure. The Enforcement Point (EP) is an entity which enforces the result of the PANA protocol exchange. The EP might be co-located with the PAA or separated as a stand-alone device. In the latter case, the SNMPv3 protocol [I-D.ietf-pana-snmp] is used to communicate between PAA and EP. A successful EAP authentication exchange results in a PANA security association (PANA SA) if the EAP method was able to derive session keys. In this case, all further PANA messages between PaC and PAA will be authenticated, replay and integrity protected thanks to the MAC AVP. 3.1.2 IPsec based access control [I-D.ietf-pana-ipsec] describes how PANA could enable IPsec between PaC and the EP. An IKE pre-shared key is distributed to PaC and EP. Then, IKE is used to setup an ESP tunnel. Figure 1 describes a possible architecture, AR/EP is the default router of the PaC and all its traffic is protected by the ESP tunnel. +----- PAA | | PaC ================= AR/EP (ESP tunnel) Figure 1: PANA IPsec based access control 3.2 Re-authentication of PaC PANA offers two types of re-authentication. 3.2.1 Re-authentication based on EAP If the current session lifetime expires, the PAA or the AAA server Bournelle, et al. Expires novembre 30, 2004 [Page 5] Internet-Draft Context Transfer for PANA June 2004 may initiate a new EAP authentication. In this case, the PaC enters in a new authentication phase and should provide credentials. The PaC may also re-authenticate the access network. 3.2.2 Re-authentication based on PANA PANA also offers a way to do a re-authentication. The PaC or the PAA may trigger it by sending a PRAR message (PANA-Reauth-Request) with a MAC AVP. Thus the responder needs the PANA_MAC_Key to respond. This mechanism is a very efficient means to detect the aliveness of both the PaC and the PAA. Figure 2 shows the message exchange which can be triggered by both nodes. PaC PAA Message(tseq,rseq)[AVPs] -------------------------------------------- <----- PANA-Reauth-Request(q,p)[MAC] -----> PANA-Reauth-Answer(p+1,q)[MAC] Figure 2: PANA re-authentication 3.2.3 Limitations PaC ------------ pEP ---- pPAA | | | | | +------ pAR (roaming) | | v PaC ------------ nEP ---- nPAA | | +------ nAR Figure 3: Example Scenario Figure 3 shows an example scenario with a roaming PaC which has been previously authenticated. The PAA must be at one IP hop away from PaC; this means that a specific PANA module on a PAA is in charge of one IP network. After a PaC's IP handover, the PaC changes of IP subnet and of PAA accordingly. The new PAA (nPAA) does not share any context with the PaC. The new EP (nEP) will detect the PaC and will trigger a new PANA authentication phase from scratch. A new authentication phase involving the AAA infrastructure will then Bournelle, et al. Expires novembre 30, 2004 [Page 6] Internet-Draft Context Transfer for PANA June 2004 occur. Such a signaling can seriously degrades handover performance in term of latency. Bournelle, et al. Expires novembre 30, 2004 [Page 7] Internet-Draft Context Transfer for PANA June 2004 4. Context Transfer for PANA A PaC connected to an access network shares a context with its access router like e.g. compression type, Quality of service parameters and security state. As motivated in the previous sections, the goal of this document is to reduce the overhead of establishing state between the PaC and the nPAA. CTP [I-D.ietf-seamoby-ctp] permits to avoid signaling overhead during roaming by enabling authorized context transfer between access routers However, CTP only offers a framework and does not define a particular context. In particular, it appears that PANA is likely to use this protocol to enhance mobility handling. In CTP, a context is identified by a context type which is a 32-bit number. As specified in [I-D.ietf-seamoby-ctp], the meaning of each context type is determined by a specification document. This is precisely the purpose of this document: defining a PANA context type and the PANA-specific context, which comes together. 4.1 CTP overview Context Transfer Protocol (CTP) [I-D.ietf-seamoby-ctp] enables context transfers between access routers (ARs). The context transfer can be either initiated by a request from the mobile node ("mobile initiated") or at the initiative of either the new or the previous access router ("network initiated"). Furthermore it can be performed prior to handover ("predictive mode") or after the handover ("non-predictive mode"). In non-predictive mode, the MN sends a CT Activate Request (CTAR) to the new AR (nAR). In this message the MN includes an authorization token: this token is calculated based on a secret shared between the MN and the previous AR (pAR) and it is used in order to authorize the transfer. This means that the MN and the AR must share a secret. The definition of this secret is out of scope of CTP. As soon as the nAR receives a CTAR message, it generates a CT-Request message which includes the authorization token and the context to be transferred (i.e. Feature Profile Types). This message is received by the pAR that verifies the authorization token and sends a Context Transfer Data (CTD) message including the context requested. In the predictive case, the pAR receives a CTAR message from the MN whose feature contexts are to be transferred. This message provides the IP address of the nAR and an authorization token. The pAR predictively transmits to the nAR a Context Transfer Data (CTD) that contains feature contexts. This message contains also parameters for the nAR to compute an authorization token in order to verify the MN's Bournelle, et al. Expires novembre 30, 2004 [Page 8] Internet-Draft Context Transfer for PANA June 2004 token. Regardless the MN sent the CTAR to the pAR, it sends another CTAR message to the nAR in order to ascertain that the context transfer reliably took place. Furthermore in this CTAR the MN includes tha authorization token so that the nAR verifies it. CTP messages use Feature Profile Types (FPTs) to identify the way data is organized for a particular feature context. The FTPs are registered in a number space that allows a node to unambiguously determine the type of context and the context parameters present in the protocol messages. 4.2 Extensions to PANA and CTP We introduce the PANA Feature Profile Types to handle transfer of PANA context in CTP. (To be assigned by IANA). New states are needed in PaC and PAA state machine to handle CTP. For this we introduce the PANA-CTP-WAITING state for PAA. [TBD: do we need to introduce a new state for the PaC.] In addition, a new key is also introduced to compute a token used in CTP, namely the PANA-CTP-Key. This key could be derived from the AAA-Key. Finally a new AVP is needed in PANA to carry the CTP CTAR message. 4.3 Conditions to Perform the Transfer In this section, we list conditions and recommandations to perform a PANA context transfer between two PAAs. This list is mostly inherited from [I-D.aboba-802-context] o Homogeneous PAA's device deployment within a single administrative domain. o Trust between devices engaged in the context transfer. CTP indicates that IPsec ESP must be used. o The nPAA should not obtain keys used to encrypt traffic between PaC and pEP. 4.4 Transfer of AAA-Key According to EAP [I-D.ietf-eap-keying], the figure below illustrates the keys hierarchy in the PANA case: Bournelle, et al. Expires novembre 30, 2004 [Page 9] Internet-Draft Context Transfer for PANA June 2004 PaC pPAA AAA/EAP --- ---- ------- MSK MSK MSK EMSK EMSK AAA-Key AAA-Key <---------- AAA-Key PANA_MAC_Key PANA_MAC_Key For security reasons, after the IP handover, the PaC and nPAA should derive a new PANA_MAC_Key cryptographically separated from the previous one. This can be accomplished by deriving a new AAA-Key cryptographically separated from the previous AAA-Key. The problem is that this key depends on MSK and EMSK, but EMSK must not be sent to PAA. The only solution to have a new PANA_MAC_Key cryptographically separated from the old one should be to obtained a new one from the AAA/EAP server. We propose to use the same solutions as proposed in [I-D.ietf-pana-pana]. For this, the pPAA provides to nPAA an intermediate AAA-Key: AAA-Key-int = The first N bits of HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) If there are two AAA-Keys generated by a NAP/ISP authentication. pPAA provides the following key: AAA-Key-int = The first N bits of HMAC-SHA1(AAA-Key1 | AAA-Key2, DiameterIdentity | Session-ID) DiameterIdentity is the identifier of the pPAA and Session-ID is the identifier of the Session between the pPAA and PaC. During the PBR/PBA exchange, PaC and nPAA must provide nonces that are used to derive a new AAA-Key: AAA-Key-new = The first N bits of HMAC-SHA1(AAA-Key-int, PaC_nonce | PAA_nonce) The new PANA_MAC_Key used to compute AVP MAC will be calculated from this key. A new PANA_CTP_Key should also be derived from this key. Bournelle, et al. Expires novembre 30, 2004 [Page 10] Internet-Draft Context Transfer for PANA June 2004 4.5 The PANA Session Attributes The PANA Context is what should be transferred between the two PAAs to avoid re-authentication from scratch. The attributes described in [I-D.ietf-pana-pana] list elements that could constitute the PANA context at PAA. However some of these datas are PAA's specific and as such does not need to be transferred. The PANA session attributes are listed below: Session-Id: The Session-Id is of type UTF8String and is used to identify a specific session between a PaC and PAA. Length is not fixed. (type: UTF8String Length: variable) Device-Id: The first octet (8 bits) of the Device-Id contains the device type. The rest of the payload contains the device information. The length depends on the device type (32 bits for IPv4 address, 128 bits for IPv6 address). (type: UTF8string Length: 8 + 32 || 64) Sequence numbers: Note: tseq and rseq are 32-bit sequence number used in the PANA header. tseq starts from initial sequence number (ISN) and is monotonically increased by 1. * ISN_pac: Initial tseq value of PaC. (type: Unsigned32, Length: 4) * ISN_paa: Initial tseq value of PAA. (type: Unsigned32, Length: 4) * Last transmitted tseq/rseq. (type: Unsigned32, Length: 4) Retransmission Interval: PANA layer messages that require an answer from a communicating peer are retransmitted based on a timer at PANA-layer until a response is received. This timer should be calculated as described in [RFC2988] to provide congestion control. (type: Unsigned32, Length: 4) Session-Lifetime: The authentication phase also determines the PANA session lifetime when authorization succeeds. This value is included in Session-Lifetime AVP. In Diameter [RFC3588], this AVP (Session-Timeout) is of type Unsigned32 and contains the maximum number of seconds of service to be provided to the user before session termination. Note that the value forwarded to the new PAA needs to reflect the already 'consumed' session lifetime. This helps to avoid problems where roaming is used to reset the lifetime when re-attaching at a new PAA. It must be assured that the sum of the individual session lifetimes is never greater than Bournelle, et al. Expires novembre 30, 2004 [Page 11] Internet-Draft Context Transfer for PANA June 2004 the initially communicated lifetime(type: Unsigned32, length: 4) Protection Capability: This attribute is sent by the PAA in PANA-Bind-Request. It indicates protection capability of the network access (L2 protection or IPsec). (type: Unsigned32, length: 4) PANA SA Attributes: AAA-Key: Keying material (64 octets) that is derived from the MSK (Master Session Key) and EMSK by the EAP server. This key is distributed to the PAA. (type: xx, Length: 64) PANA_MAC_Key: Key used to integrity protect PANA messages and derived from the AAA-Key in the following way: PANA_MAC_Key = The first N-bit of HMAC_xxx(AAA-Key, ISN_pac | ISN_paa |Session_Id) The value of N depends on the integrity algorithm in use (N=128 for HMAC_MD5 and N=160 for HMAC_SHA1). As noted above, we do not need to transfer all of these fields. Indeed, it appears that we do not need to transfer the following: o Session-Id: nPAA will allocate a new one. o Device-Id: nPAA does need the previous Device-Id of PaC. o Protection-Capability: transfer occurs in homogeneous environment. This means that the protection capability must be the same. o AAA-Key and PANA_MAC_Key are not sent for security reasons. However, as noted below, a AAA-Key-int is transferred. Finally, the figure Figure 5 summarizes the PANA Context: Bournelle, et al. Expires novembre 30, 2004 [Page 12] Internet-Draft Context Transfer for PANA June 2004 +------------------+------------+----------------------------+ | Data | Type | Length | +------------------+------------+----------------------------+ | ISN_pac | Unsigned32 | Fixed | +------------------+------------+----------------------------+ | ISN_paa | Unsigned32 | Fixed | +------------------+------------+----------------------------+ | Last tseq sent | Unsigned32 | Fixed | +------------------+------------+----------------------------+ | Last rseq sent | Unsigned32 | Fixed | +------------------+------------+----------------------------+ | Retransmission | | | | Interval | Unsigned32 | Fixed | +------------------+------------+----------------------------+ | Session-Lifetime | Unsigned32 | Fixed | | Elapsed | | | +------------------+------------+----------------------------+ | AAA-Key-int | UTF8String | Fixed (64 octets) | +------------------+------------+----------------------------+ Figure 5: The PANA Context 4.6 Contacting the AAA server To handle re-authentication, the AAA server should know new location of PaC. This means that the nPAA or pPAA must notify new location of PaC. The AAA protocol may be used for this purpose. 4.7 Operations The transfer may occur either after or before the handover. From this standpoint, we define two operating transfer modes: Non-predictive mode: the PaC has already performed the handover. We assume that it has already acquired an address. Predictive mode: the transfer occurs before the handover. The following section deals successively with both modes: Bournelle, et al. Expires novembre 30, 2004 [Page 13] Internet-Draft Context Transfer for PANA June 2004 4.7.1 Operations in the Non-predictive mode PaC nPAA pPAA ---------------------------------------- PSR <--------------- PSA(CTAR) ---------------> CT-Request --------------> CTD <-------------- PBR <------------- PBA -------------> Figure 6: After the IP handover 4.7.1.1 Trigger the transfer The transfer occurs between PAAs while the handover concerns PaC and AR. Thus it is necessary to have a way to trigger this transfer. We consider two variations: 1. the mobile is in charge of alerting the network 2. in the second one, an equipment in the access network triggers the context transfer. However, in this case the nPAA should send information that only PaC can know. For this reason, the network can not initiate the transfer. While entering in the new network, the PaC will be detected and the nPAA will send a PSR message. To trigger the transfer we propose to answer by a PSA message containing a CTAR message in an AVP. The PSA message should contain the previous allocated Session-Id as proposed in [I-D.ietf-pana-pana] and a AVP PaC_Nonce. This CTAR message should contain the following data: o The previous PaC's address. o The previous PAA's address. o An authorization token computed over this message using a shared key between PaC and pPAA. We propose to introduce a new key for Bournelle, et al. Expires novembre 30, 2004 [Page 14] Internet-Draft Context Transfer for PANA June 2004 this purpose: PANA-CTP-Key derive from the AAA-Key. [TBD: how do we derive this key ?] 4.7.1.2 Exchange between PAA After receiving the PSA-CTAR message from the PaC, the PANA module delivers the CTAR message to the PANA-CTP module. We introduce a new state for this case: PANA-CTP-WAITING. The PAA sends a CT-Request to request the transfer. As noted in Section 4.3, this message must be protected by ESP [I-D.ietf-ipsec-esp-v3] as specified in [I-D.ietf-seamoby-ctp]. The pPAA verifies the authorization token before sending the CTD message. (If this token is not valid: [TBD: what do we do ? not specified in CTP draft].) The CTD message contains: o The Elapsed Time in milliseconds. This value reflects the already 'consumed' session lifetime. o The PaC previous Care-of address. o The PANA Context block. This message must also be protected by ESP. The CTD message is described in the following figure (ABNF notation): CTD-PANA ::= < CTD-Header> < Context Data Block, Ctx-Type: PANA-Context-Transfer, FPT> { ISN-pac } { ISN-paa } { Last tseq sent } { Last rseq sent } { Retransmission Interval } { Session-Lifetime-Elapsed } { AAA-Key-int } Figure 7: CTD-PANA message where FPT (Feature Profile Type) identifies the way the particular feature context is organized. 4.7.1.3 After the Context Transfer After receiving the CTD message, nPAA processes the following task: o Parses the CTD message. Bournelle, et al. Expires novembre 30, 2004 [Page 15] Internet-Draft Context Transfer for PANA June 2004 o Changes state for this PaC: PANA-CTP-WAITING -> WAIT_SUCC_BIND o Generates the PAA_Nonce o Computes the AAA-Key-new (from PaC_Nonce, AAA-Key-int and PAA_Nonce o Derives the new PANA_MAC_Key o Sends a PANA-Bind-Request containing: * The newly allocated Session-ID in a AVP Session-ID. * The PAA_Nonce. * An AVP MAC signed with the new PANA_MAC_Key o Waits a PANA-Bind-Answer from the PaC 4.7.2 Operations in the Predictive mode 4.7.2.1 Triggering the transfer 4.7.2.1.1 Mobile Controlled To trigger the transfer, PaC/MN sends a CTAR message to pPAA. In this message, it includes data which permit the pPAA to recover the nPAA's address. The nAR's address should be this value. An authorization token is also computed using PANA-CTP-Key. 4.7.2.1.2 Network Controlled The document [I-D.irtf-aaaarch-handoff] describes an approach where NAS/AR are able to anticipate movement of the PaC. 4.7.2.2 Exchange between PAA The pPAA sends the CTD message to the nPAA/AR indicated in the CTAR message. In this case, it is a predictive CTD message and thus it must also contain: o Algorithm, Key length and PANA-CTP-Key: allows the nAR to compute a token locally and verify against the token present in the CTAR message. o The PANA context as described above in Section 4.5 Bournelle, et al. Expires novembre 30, 2004 [Page 16] Internet-Draft Context Transfer for PANA June 2004 pPAA may set the A flag (see [I-D.ietf-seamoby-ctp])in order to have a acknowledgment of this message. Some data in the PANA Context may change before the handover really take place: the last tseq/rseq and the Session-Lifetime. [TBD: how do we handle this ?] 4.7.2.3 After the Context Transfer The nPAA creates an entry for this PaC (state PAA-CTP-WAITING). PaC performs the handover and sends a PSA-CTAR message. nPAA verifies it and if it is correct it realizes a PBR/PBA to assign a new session-id and exchanges Nonces. Then it configures the EP. Bournelle, et al. Expires novembre 30, 2004 [Page 17] Internet-Draft Context Transfer for PANA June 2004 5. General Issues o How do we compute the PANA-CTP-Key ? o If Session-Lifetime is near its expiration, is it necessary to perform the transfer ? If yes, how do we manage this ? o How informs the AAA system of the new PaC's location ? o new state in the PaC state machine ? Bournelle, et al. Expires novembre 30, 2004 [Page 18] Internet-Draft Context Transfer for PANA June 2004 6. Security considerations This document defines a mechanism to apply the Seamoby Context Transfer Protocol between PAAs when a PaC changes PAA following up an IP handover. Therefore, all security considerations described in [I-D.ietf-seamoby-ctp] and in [I-D.ietf-pana-pana] apply also here. The approach described in this document considers only the intra-domain scenario. This means that the PAAs involved in the context transfer belong to the same administrative domain. Therefore, at this stage the inter-domain scenario is out of scope. As described in [I-D.ietf-seamoby-ctp] IPsec ESP must be used to protect CTP messages between PAAs. In order to avoid the introduction of additional latency due to the need for establishment of a secure channel between the context transfer peers, the two PAAs should establish such a secure channel in advance. The mechanism used by the PAAs to establish such a channel is out of the scope of this draft: for example, IKE [RFC2409] with pre-shared key authentication might be used. Furthermore, CTP requires that the PaC and the PAA possess a shared secret to calculate the authorization token: for this purpose, this document defines a new key (PANA-CTP-Key) that is derived from the AAA-key. The mechanism used by the nPAA to derivea new AAA-key and consequently a new PANA-CTP-key is specified in [I-D.ietf-pana-pana]. Bournelle, et al. Expires novembre 30, 2004 [Page 19] Internet-Draft Context Transfer for PANA June 2004 7. Acknowledgements The authors would like to thank Jean-Jacques Puig for his valuable comments Bournelle, et al. Expires novembre 30, 2004 [Page 20] Internet-Draft Context Transfer for PANA June 2004 Normative References [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. [I-D.ietf-pana-pana] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-04 (work in progress), May 2004. [I-D.ietf-pana-ipsec] Parthasarathy, M., "PANA enabling IPsec based Access Control", draft-ietf-pana-ipsec-03 (work in progress), May 2004. [I-D.ietf-pana-snmp] Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for PAA-2-EP interface", draft-ietf-pana-snmp-00 (work in progress), April 2004. [I-D.ietf-seamoby-ctp] Loughney, J., "Context Transfer Protocol", draft-ietf-seamoby-ctp-10 (work in progress), June 2004. [I-D.ietf-ipsec-esp-v3] Kent, S., "IP Encapsulating Security Payload (ESP)", draft-ietf-ipsec-esp-v3-08 (work in progress), March 2004. [I-D.aboba-802-context] Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE 802", draft-aboba-802-context-02 (work in progress), April 2002. [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [I-D.ietf-eap-keying] Aboba, B., "EAP Key Management Framework", draft-ietf-eap-keying-01 (work in progress), October 2003. Bournelle, et al. Expires novembre 30, 2004 [Page 21] Internet-Draft Context Transfer for PANA June 2004 Authors' Addresses Julien Bournelle GET/INT 9 rue Charles Fourier Evry 91011 France EMail: julien.bournelle@int-evry.fr Maryline Laurent-Maknavicius GET/INT 9 rue Charles Fourier Evry 91011 France EMail: maryline.maknavicius@int-evry.fr Hannes Tschofenig Siemens Corporate Technology Otto-Hahn-Ring 6 81739 Munich Germany EMail: Hannes.Tschofenig@siemens.com Yacine El Mghzali Alcatel Route de Nozay Marcoussis 91460 France EMail: yacine.el_mghazli@alcatel.fr Gerardo Giaretta TILab via G. Reiss Romoli, 274 TORINO 10148 Italy EMail: gerardo.giaretta@telecomitalia.it Bournelle, et al. Expires novembre 30, 2004 [Page 22] Internet-Draft Context Transfer for PANA June 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Bournelle, et al. Expires novembre 30, 2004 [Page 23] Internet-Draft Context Transfer for PANA June 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bournelle, et al. Expires novembre 30, 2004 [Page 24]