Network Working Group J. Bournelle (Ed.) Internet-Draft M. Laurent-Maknavicius Expires: april 1, 2005 GET/INT H. Tschofenig Siemens Y. El Mghazli Alcatel G. Giaretta TILab October 2004 Use of Context Transfer Protocol (CTP) for PANA draft-bournelle-pana-ctp-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 1, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract The PANA protocol offers a way to authenticate clients in IP based Bournelle (Ed.), et al. Expires april 1, 2005 [Page 1] Internet-Draft CTP for PANA October 2004 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. To enhance IP handover in mobile environments, the Context Transfer Protocol (CTP) could be used. This protocol could recover from previous PANA Authentication Agent the PANA security context previously established. However the interaction between CTP and PANA raises some questions and issues. It appears that it is difficult to apply CTP for PANA. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 PANA overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1 IPsec based access control . . . . . . . . . . . . . . 5 3.1.2 Limitations . . . . . . . . . . . . . . . . . . . . . 6 3.2 CTP overview . . . . . . . . . . . . . . . . . . . . . . . 6 4. General considerations in the use of CTP for PANA . . . . . . 8 4.1 Conditions to Perform the Transfer . . . . . . . . . . . . 8 4.2 Transfer of AAA-Key . . . . . . . . . . . . . . . . . . . 8 4.3 Interaction with the AAA infrastructure . . . . . . . . . 9 4.4 The PANA Context . . . . . . . . . . . . . . . . . . . . . 11 5. Possible approaches to perform the transfer . . . . . . . . . 14 5.1 PANA solution . . . . . . . . . . . . . . . . . . . . . . 14 5.2 CTP friendly approach . . . . . . . . . . . . . . . . . . 15 5.2.1 Operations in non-predictive mode . . . . . . . . . . 15 5.2.2 Operations in predictive mode . . . . . . . . . . . . 17 5.3 Optimized approach . . . . . . . . . . . . . . . . . . . . 18 5.3.1 Operations in the Non-predictive mode . . . . . . . . 18 5.3.2 Operations in the Predictive mode . . . . . . . . . . 20 6. PANA CTP interactions . . . . . . . . . . . . . . . . . . . . 21 7. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Security considerations . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . 27 Bournelle (Ed.), et al. Expires april 1, 2005 [Page 2] Internet-Draft CTP for PANA October 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 the 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 analyse the interaction between the framework defined in [I-D.ietf-seamoby-ctp] and PANA. In particular, we define what should be transferred (i.e. the PANA context) and the interactions with the AAA infrastructure. Three possible solutions are also given. The first one is the solution given in the PANA specification [I-D.ietf-pana-pana]. In the second approach, we try to strictly apply CTP. Finally, the last approach proposed an optimized version of the previous one. Bournelle (Ed.), et al. Expires april 1, 2005 [Page 3] Internet-Draft CTP for PANA October 2004 2. Terminology This document uses the following terms or abbreviations: PANA Protocol for Carrying Network Authentication for Network Access PaC PANA Client. A mobile node (MN) using a PANA protocol implementation to authenticate itself to the network. nAR New Access Router. The router to which the PaC attaches after the handover. pAR Previous Access Router. The router to which the PaC was attached before the handover. nPAA New PANA Authentication Agent. The PAA in charge of the subnet to which the PaC was attached before the handover. pPAA Previous PANA Authentication Agent. The PaC's default PAA prior to handover. EP Enforcement Point. CTP Context Transfer Protocol. CTD Context Transfer Data. CTAR Context Transfer Activate Request. CTAA Context Transfer Activate Acknowledge. FPT Feature Profile Type. Bournelle (Ed.), et al. Expires april 1, 2005 [Page 4] Internet-Draft CTP for PANA October 2004 3. Background 3.1 PANA overview PANA is a protocol that carries EAP over IP/UDP to authenticate users. The PANA Authentication Agent (PAA) 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.1 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 Bournelle (Ed.), et al. Expires april 1, 2005 [Page 5] Internet-Draft CTP for PANA October 2004 3.1.2 Limitations PaC ------------ pEP ---- pPAA | | | | | +------ pAR (roaming) | | v PaC ------------ nEP ---- nPAA | | +------ nAR Figure 2: Example Scenario Figure 2 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 occur. Such a signaling can seriously degrades handover performance in term of latency. For this reason, we propose to use the Context Transfer Protocol (CTP) to transfer PANA context established with the PaC from pPAA to the nPAA. 3.2 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 Bournelle (Ed.), et al. Expires april 1, 2005 [Page 6] Internet-Draft CTP for PANA October 2004 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 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 the 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 FPTs 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. Bournelle (Ed.), et al. Expires april 1, 2005 [Page 7] Internet-Draft CTP for PANA October 2004 4. General considerations in the use of CTP 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. The aim of this section is to give general considerations on the use of CTP for PANA. 4.1 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.2 Transfer of AAA-Key According to EAP [I-D.ietf-eap-keying], the figure below illustrates the keys hierarchy in the PANA case: PaC pPAA AAA/EAP --- ---- ------- MSK MSK MSK EMSK EMSK AAA-Key AAA-Key <---------- AAA-Key PANA_MAC_Key PANA_MAC_Key MSK and EMSK are derived from the EAP method used between the PaC and Bournelle (Ed.), et al. Expires april 1, 2005 [Page 8] Internet-Draft CTP for PANA October 2004 the AAA/EAP server. Those keys must not be exported from the EAP module. The AAA-Key is computed from MSK and EMSK. This key is exported to the pPAA. The PANA_MAC_KEY, used to protect PANA messages, is derived from the AAA-Key using the following way: PANA_MAC_KEY = The first N bits of HMAC_SHA1(AAA-Key, PaC_nonce | PAA_nonce | Session-ID) 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 only solution to have a new PANA_MAC_Key cryptographically separated from the old one should be to obtain 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) DiameterIdentity is the identifier of the pPAA and Session-ID is the identifier of the Session between the pPAA and PaC. 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) During the PSR/PSA 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. 4.3 Interaction with the AAA infrastructure PAAs use AAA infrastructure to authenticate PaC. This means that the PAA contacts a (local) AAA server and relay the EAP messages in order Bournelle (Ed.), et al. Expires april 1, 2005 [Page 9] Internet-Draft CTP for PANA October 2004 to authenticate a PaC. We have two possible situations depending on roaming situation. We only consider use of RADIUS [RFC2865] or Diameter EAP application [I-D.ietf-aaa-eap]. +-----+ +-----+ +-----+ | PaC |<------->| PAA |<----->| AAA | +-----+ +-----+ +-----+ Figure 4: Local authentication In Figure 4, the PaC is authenticated in its home domain. The PAA contacts its local AAA server. +-----+ +-----+ +------+ | PaC |<------->| PAA |<----->| AAAL | +-----+ +-----+ +--+---+ ^ | v +--+---+ | AAAH | +------+ Figure 5: PaC in a visited domain In Figure 5, the PaC is in a visited domain. It can not be authenticated by the local AAA server (AAAL). In this case, the PAA contacts a local AAA entity. In the first situation, the PAA shares a session with only one AAA server. This server keeps information on the PaC authenticated such as session-lifetime, PAA's identity, authorized services...In some cases, the AAA server may have to contact the PaC and thus if the PaC changes of PAAs, it seems necessary to contact the AAA server to inform it of the new PAA in charge of the PaC. The second situation is a little bit more complex since the PAA does not know the AAAH's identity. We can however state that it is necessary for the PAA to inform its local AAA entity of PaC's new location. Depending on policy, the AAAL server should inform the AAAH server. Bournelle (Ed.), et al. Expires april 1, 2005 [Page 10] Internet-Draft CTP for PANA October 2004 +----------+ | AAA(L/H) | +----------+ ^ | nPAA's identity | | +---+--+ +------+ | pPAA |----------------->| nPAA | +------+ +------+ AAA's identity Figure 6: The pPAA contacts the AAA infrastructure To inform the AAA server of PaC's new location, we have two solutions. In the first one (cf. Figure 6), the pPAA is in charge of contacting the AAA server to inform it of the nPAA. +----------+ | AAA(L/H) +<-----------------+ +----------+ | I'm in | charge of PaC | | | +------+ +--+---+ | pPAA |----------------->| nPAA | +------+ +------+ AAA's identity Figure 7: The nPAA contacts AAA infrastructure In the second one (cf. Figure 7), the nPAA informs the AAA server. It also seems necessary to inform the nPAA of the AAA server's identity. 4.4 The PANA Context 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 data are PAA specific and as such does not need to be transferred. Bournelle (Ed.), et al. Expires april 1, 2005 [Page 11] Internet-Draft CTP for PANA October 2004 Figure 8 summarizes the PANA Context. +------------------+------------+----------------------------+ | Data | Type | Length | +------------------+------------+----------------------------+ | Session-Lifetime | Unsigned32 | Fixed | | Elapsed | | | +------------------+------------+----------------------------+ | AAA-Key-int | UTF8String | Fixed (64 octets) | +------------------+------------+----------------------------+ | AAA server | UTF8String | Variable | | Identity | | | +------------------+------------+----------------------------+ | ISP-Identifier | Unsigned32 | Fixed | +------------------+------------+----------------------------+ | ISP-Name | UTF8String | Variable | +------------------+------------+----------------------------+ | NAP/ISP Separate | Unsigned32 | Fixed | | Authentication | | | +------------------+------------+----------------------------+ Figure 8: The PANA Context Data have the following meanings: 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 the initially communicated lifetime(type: Unsigned32, length: 4) AAA-Key-int: cf. above. AAA server identify: Identity of the AAA server used to authenticate the PaC. ISP-Identifier IANA assigned "SMI Network Management Private Enterprise Codes" of the provider. Bournelle (Ed.), et al. Expires april 1, 2005 [Page 12] Internet-Draft CTP for PANA October 2004 ISP-Name UTF8-encoded name of the provider. Separate NAP/ISP authentication This variable indicates if a separate NAP/ISP authentication has been performed at pPAA. Bournelle (Ed.), et al. Expires april 1, 2005 [Page 13] Internet-Draft CTP for PANA October 2004 5. Possible approaches to perform the transfer 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. Different approaches exist to perform PANA context transfer using CTP. The aim of this section is to describe three of them and to discuss interaction between CTP specification and PANA. In each of those 3 solutions, the transfer occurs between PAAs and they use a CTD message containing the PANA context. The CTD message is described in the following figure (ABNF notation): CTD-PANA ::= < CTD-Header> < Context Data Block, Ctx-Type: PANA-Context-Transfer, FPT> { Session-Lifetime-Elapsed } { AAA-Key-int } { AAA server's identity } { ISP-Identifier } { ISP-Name } { Double Authentication NAP/ISP information } Figure 9: CTD-PANA message where FPT (Feature Profile Type) identifies the way the particular feature context is organized. 5.1 PANA solution In the solution proposed by PANA [I-D.ietf-pana-pana], the PaC does not use CTAR message to request and activate the context. Instead, it replies to PSR message with a PSA message containing the unexpired previous PANA session identifier and a MAC AVP (cf. Figure 10). This AVP is computed using the PANA_MAC_KEY shared between the PaC and its pPAA. Bournelle (Ed.), et al. Expires april 1, 2005 [Page 14] Internet-Draft CTP for PANA October 2004 PaC nPAA pPAA --- ---- ---- PSR[PAA_Nonce] <------------ PSA[oSession-ID][PaC_Nonce][MAC] --------------> CT-Request [PSA] ----------------> CTD-PANA <---------------- PBR[nSession-Id][MAC] <-------------- PBA [MAC] ---------------> Figure 10: The PANA approach The nPAA receives this PSA message and it deduces that it must perform CTP (because of the Session-Id AVP). It determines the identity of pPAA by looking at the DiameterIdentity part of the PANA session identifier. It sends a CT-Request to the pPAA containing the PSA message. The pPAA checks the validity of the PSA message and transfers the PANA context in the CTD message. Then the PANA session continues with a PANA-Bind exchange. This procedure has the following issues: o It does not support predictive mode since we do not have a CTAR message. o CTP does not define a way to carry PSA message in CT-Request. o The CTP module can not validate the transfer since the CT-Request does not provide any authorization token. 5.2 CTP friendly approach 5.2.1 Operations in non-predictive mode As described in the previous paragraph, in order to handle PaC mobility in the reactive case, the approach based on [I-D.ietf-pana-pana] has some unsolved issues: these issues concern the usage of CTP to perform the context transfer between PAAs. A possible alternative approach is to perform the context transfer relying completely on CTP as specified in [I-D.ietf-seamoby-ctp]. Bournelle (Ed.), et al. Expires april 1, 2005 [Page 15] Internet-Draft CTP for PANA October 2004 Figure 11 shows the message flow if this CTP-friendly approach is used. PaC nPAA pPAA --- ---- ---- PSR [PAA_Nonce] (handoff) <-------------- CTAR ---------------> CT-Request ---------------> CTD-PANA <---------------- CTAA <--------------- PSA[(old Session-ID,) PaC_Nonce] ---------------> PBR[nSession-Id] <------------- PBA -------------> Figure 11: CTP friendly approach: non predictive mode When the PaC performs a change of the point of attachment to the network, it receives a trigger indicating that a handoff has occured and consequently a context transfer should be performed. This trigger might be a PSR message sent by the nPAA (as depicted in Figure 11) or an internal DNA trigger (e.g. L2 "link-up" trigger). Based on this event notification, the PaC begins the CTP procedure sending to the nPAA a CTAR message to trigger the context transfer. Based on [I-D.ietf-seamoby-ctp] this message MUST include the previous address of the PaC, the address of the pPAA and an authorization token needed to authorize the transfer. This authorization token is computed using a key that we called PANA_CTP_KEY. The nPAA sends a CT-Request to the pPAA including the previous address of the PaC and the authorization token. These data are needed to the pPAA in order to identify the PaC and to retrieve Bournelle (Ed.), et al. Expires april 1, 2005 [Page 16] Internet-Draft CTP for PANA October 2004 the associated PANA state. If the authorization token is verified successfully, the pPAA sends to the nPAA the PANA context of the PaC through a CTD-PANA message. Finally the nPAA sends a CTAA message to the PaC as a confirm that the context transfer has been accomplished. Upon the receipt of the CTAA, the PaC sends to the nPAA a PSA message: the protocol operation continues as specified in section 4.11 of [I-D.ietf-pana-pana]. Even if it is compliant to CTP specification, this approach has several open issues: o [I-D.ietf-seamoby-ctp] specifies that the context transfer is performed between Access Routers, while in this scenario it is performed between PAAs; o in CTP the transfer is authorized through the authorization token: it should be defined the key (called PANA_CTP_KEY in this document) needed to calculate this authorization token; o if CTP operations are triggered by a PSR message (i.e. it is not provided by layer 2 or by a DNA solution), the nPAA keeps on sending PSR messages waiting to receive a PSA message; indeed the PaC sends the PSA message only once the context transfer is accomplished. This implies an inefficiency in PANA protocol operations. o in order to send a CTAR message, the PaC must know the nPAA IP address. This could be an issue if CTP is triggered by DNA, since a DNA solution might not provide the IP address of the nPAA. For this reason, the PaC might be forced to perform a new discovery phase to get the nPAA's address. 5.2.2 Operations in predictive mode 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. 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 nPAA to compute a token locally and verify against the token present in the CTAR message. Bournelle (Ed.), et al. Expires april 1, 2005 [Page 17] Internet-Draft CTP for PANA October 2004 o The PANA context as described above in Section 4.4 o The (previous) IP address of PaC. pPAA may set the A flag (see [I-D.ietf-seamoby-ctp]) in order to have an acknowledgment of this message. The nPAA creates an entry for this PaC. PaC performs the handover and sends CTAR message (after receiving a PSR message). nPAA recovers the context using PaC's address indicated in the CTAR message. It verifies the authorization token and if it is correct it activates the context. Then they perform a PBR/PBA exchange. Thus the nPAA can allocate a new session-id. This predictive mode raises the following issue: o After receiving the CTD message from pPAA, the nPAA creates an entry for the PaC. But in which state is it for this PaC ? Do we need to introduce a new state ? 5.3 Optimized approach In this approach, we embed the CTAR message in the PSA message. Thus, we reduce the number of messages. 5.3.1 Operations in the Non-predictive mode PaC nPAA pPAA --- ---- ---- PSR [PAA_Nonce] <--------------- PSA [CTAR][PaC_Nonce] ---------------> CT-Request --------------> CTD <-------------- PBR[nSession-Id] <------------- PBA -------------> 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 an AVP PaC_Nonce. Bournelle (Ed.), et al. Expires april 1, 2005 [Page 18] Internet-Draft CTP for PANA October 2004 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 (the PANA_CTP_KEY). After receiving the PSA-CTAR message from the PaC, the PANA module delivers the CTAR message to the PANA-CTP module. The PAA sends a CT-Request to request the transfer. As noted in Section 4.1, 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. The CTD message contains: o The Elapsed Time in milliseconds. This value reflects the already 'consumed' session lifetime. o The PaC's previous address. o The PANA Context block. This message must also be protected by ESP. After receiving the CTD message, nPAA processes the following task: o Parses the CTD message. o (Changes state for this PaC ?) 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 Session-ID AVP. * The PAA_Nonce. Bournelle (Ed.), et al. Expires april 1, 2005 [Page 19] Internet-Draft CTP for PANA October 2004 * An AVP MAC signed with the new PANA_MAC_Key. o Waits a PANA-Bind-Answer from the PaC. Issues: o Do we need to introduce a new state to handle the period of time where the nPAA is waiting the PaC's context from pPAA ? o how do we generate the PANA-CTP-Key ? o Piggyback of a CTP message in PANA. 5.3.2 Operations in the Predictive mode The operations here are quite similar than in Section 5.2.2. The difference is that the PaC embeds the CTAR message in the PSA after the IP handover. Bournelle (Ed.), et al. Expires april 1, 2005 [Page 20] Internet-Draft CTP for PANA October 2004 6. PANA CTP interactions The table below summarizes issues in using CTP to carry PANA context. +----------+------------+-------------+ | PANA | CTP | Optimized | +------------------+----------+------------+-------------+ | Transfer | no | no | no | | between ARs | | | | +------------------+----------+------------+-------------+ | CTAR message | no | yes | yes | +------------------+----------+------------+-------------+ | predictive mode | no | yes | yes | | supported | | | | +------------------+----------+------------+-------------+ | Transfer | | | | | authorized by | PANA | CTP | CTP | +------------------+----------+------------+-------------+ | Trigger | PSR | PSR/DNA | PSR | +------------------+----------+------------+-------------+ | State Machine | ? | yes | yes | | Issue | | | | +------------------+----------+------------+-------------+ Figure 13: PANA-CTP interactions Bournelle (Ed.), et al. Expires april 1, 2005 [Page 21] Internet-Draft CTP for PANA October 2004 7. Issues This section lists the different issues raised in previous section. o PAAs are not Access Routers. CTP states that context transfer occurs between ARs. o CT-request does not define a way to carry PSA message. o Which protocol can be used to inform the AAA server of the nPAA in charge of the PaC ? A AAA extension ? o Who informs the local AAA entity of the new PAA in charge of the PaC ? (pPAA or nPAA ?) 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 State machine modification in PaC and PAA ? Bournelle (Ed.), et al. Expires april 1, 2005 [Page 22] Internet-Draft CTP for PANA October 2004 8. Security considerations This document deals with interaction between the Seamoby Context Transfer Protocol and PANA. 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 probably derived from the AAA-Key. The mechanism used by the nPAA to derive a new AAA-key and consequently a new PANA-CTP-key is specified in [I-D.ietf-pana-pana]. Bournelle (Ed.), et al. Expires april 1, 2005 [Page 23] Internet-Draft CTP for PANA October 2004 9. Acknowledgements The authors would like to thank Rafael Marin Lopez, Yoshihiro Ohba, Jean-Jacques Puig, Ren?? Soltwitsch and Alper Yegin for their valuable comments. 10 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-06 (work in progress), October 2004. [I-D.ietf-pana-ipsec] Parthasarathy, M., "PANA enabling IPsec based Access Control", draft-ietf-pana-ipsec-04 (work in progress), September 2004. [I-D.ietf-pana-snmp] Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for PAA-2-EP interface", draft-ietf-pana-snmp-01 (work in progress), July 2004. [I-D.ietf-seamoby-ctp] Loughney, J., "Context Transfer Protocol", draft-ietf-seamoby-ctp-11 (work in progress), August 2004. [I-D.ietf-ipsec-esp-v3] Kent, S., "IP Encapsulating Security Payload (ESP)", draft-ietf-ipsec-esp-v3-09 (work in progress), October 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. Bournelle (Ed.), et al. Expires april 1, 2005 [Page 24] Internet-Draft CTP for PANA October 2004 [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., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-03 (work in progress), July 2004. [I-D.ietf-aaa-eap] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", draft-ietf-aaa-eap-09 (work in progress), August 2004. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 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 Bournelle (Ed.), et al. Expires april 1, 2005 [Page 25] Internet-Draft CTP for PANA October 2004 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 (Ed.), et al. Expires april 1, 2005 [Page 26] Internet-Draft CTP for PANA October 2004 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. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 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 (2004). 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. Bournelle (Ed.), et al. Expires april 1, 2005 [Page 27] Internet-Draft CTP for PANA October 2004 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bournelle (Ed.), et al. Expires april 1, 2005 [Page 28]