idnits 2.17.1 draft-ietf-pana-cxtp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 25. -- Found old boilerplate from RFC 3978, Section 5.5 on line 690. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 667. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 680. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 6, 2006) is 6182 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'AUTH' is mentioned on line 310, but not defined == Missing Reference: 'PSA' is mentioned on line 304, but not defined == Outdated reference: draft-ietf-pana-pana has been published as RFC 5191 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-pana-mobopts' ** Downref: Normative reference to an Experimental RFC: RFC 4067 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) == Outdated reference: A later version (-06) exists of draft-ietf-pana-snmp-05 -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group J. Bournelle (Ed.) 3 Internet-Draft M. Laurent-Maknavicius 4 Expires: September 7, 2006 GET/INT 5 H. Tschofenig 6 Siemens 7 Y. El Mghazli 8 Alcatel 9 G. Giaretta 10 TILab 11 R. Lopez 12 Univ. of Murcia 13 Y. Ohba 14 Toshiba 15 March 6, 2006 17 Use of Context Transfer Protocol (CXTP) for PANA 18 draft-ietf-pana-cxtp-01 20 Status of this Memo 22 By submitting this Internet-Draft, each author represents that any 23 applicable patent or other IPR claims of which he or she is aware 24 have been or will be disclosed, and any of which he or she becomes 25 aware will be disclosed, in accordance with Section 6 of BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 7, 2006. 45 Copyright Notice 47 Copyright (C) The Internet Society (2006). 49 Abstract 51 The PANA protocol offers a way to authenticate clients in IP based 52 access networks. However, in roaming environments, IP clients might 53 change of gateways and new EAP authentication from scratch may occur. 54 The present document describes a solution based on the Context 55 Transfer Protocol (CXTP) to enhance IP handover in mobile 56 environments. Note that only the intra-domain case is considered. 57 This protocol can recover the previously established PANA security 58 context from previous PANA Authentication Agent. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Conventions Used in This Document . . . . . . . . . . . . 3 65 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.4. Applicability Statement . . . . . . . . . . . . . . . . . 4 67 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. PANA framework . . . . . . . . . . . . . . . . . . . . . . 5 69 2.2. Performance limitations in mobile environments . . . . . . 5 70 2.3. CXTP protocol overview . . . . . . . . . . . . . . . . . . 6 71 3. CXTP usage in the PANA framework . . . . . . . . . . . . . . . 8 72 3.1. The Context Transfer Request Message . . . . . . . . . . . 9 73 3.2. The Context Transfer Data Message . . . . . . . . . . . . 10 74 4. Conditions to Perform the Transfer . . . . . . . . . . . . . . 13 75 5. Security considerations . . . . . . . . . . . . . . . . . . . 14 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 78 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 8.1. Changes from 00 to 01 . . . . . . . . . . . . . . . . . . 17 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 84 Intellectual Property and Copyright Statements . . . . . . . . . . 21 86 1. Introduction 88 1.1. Problem Statement 90 In IP based access network, PANA [I-D.ietf-pana-pana] may be used as 91 a front-end to a AAA architecture in order to authenticate users 92 before granting them access to the resources. For this purpose, it 93 uses EAP which offers a variety of authentication methods. In a 94 shared medium, this is typically accomplished with the help of 95 cryptographic mechanisms. Note that this type of cryptographic 96 mechanism prevents a malicious node from sending packet to the 97 network and thereby authenticating each data packet. In addition, 98 encryption is often enabled to prevent eavesdropping. 100 While roaming, the PANA client might change its access router. In 101 some cases and without extensions to PANA, the PaC has to restart a 102 new PANA protocol exchange to authenticate itself to the network. 103 This authentication may need to execute the EAP exchange from 104 scratch. 106 In this document, we analyse the interaction between the framework 107 defined in [RFC4067] and PANA. In particular, we define what should 108 be transferred (i.e. the PANA context). 110 Rough consensus in the PANA working group leaded to the solution 111 where the transfer occurs between authentication agents, according to 112 the recommendations in [I-D.ietf-pana-mobopts]. 114 1.2. Conventions Used in This Document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 1.3. Terminology 122 Most of the terms are defined in the PANA [I-D.ietf-pana-pana] and 123 CXTP [RFC4067] specifications: 125 nAR New Access Router. The router to which the PaC attaches after 126 the handover. 128 pAR Previous Access Router. The router to which the PaC was attached 129 before the handover. 131 CTAA Context Transfer Activate Acknowledge. 133 CTAR Context Transfer Activate Request. 135 CTD Context Transfer Data. 137 CXTP Context Transfer Protocol. 139 EP Enforcement Point. (PANA term) 141 FPT Feature Profile Type (CXTP term). 143 PaC PANA Client. A mobile node (MN) using a PANA protocol 144 implementation to authenticate itself to the network. 146 PAA PANA Authentication Agent. The access network (server) side 147 entity of the PANA protocol. A PAA is in charge of interfacing 148 with the PaCs for authenticating and authorizing them for the 149 network access service. 151 nPAA New PANA Authentication Agent. The PAA in charge of the subnet 152 to which the PaC is attached after the handover. 154 pPAA Previous PANA Authentication Agent. The PaC's default PAA prior 155 to handover. 157 PANA Protocol for Carrying Network Authentication for Network Access 159 1.4. Applicability Statement 161 This document defines use of CXTP for the PANA protocol. However, 162 the specification is not fully compliant with CXTP. For this reason, 163 this proposal MUST only be used to transfer PANA context. 165 2. Background 167 This section gives basic information on PANA framework and CXTP 168 protocol. The intent here is to further explain the context being 169 referred to and the terminology used in the remaining of the 170 document. 172 2.1. PANA framework 174 PANA is a protocol that carries EAP over IP/UDP to authenticate 175 users. The PANA Authentication Agent (PAA) is the endpoint of the 176 PANA protocol at the access network. The PAA itself might not be 177 able to authenticate the user by terminating the EAP protocol. 178 Instead the PAA might forward the EAP payloads to the backend AAA 179 infrastructure. 181 The Enforcement Point (EP) is an entity which enforces the result of 182 the PANA protocol exchange. The EP might be co-located with the PAA 183 or separated as a stand-alone device. In the latter case, the SNMPv3 184 protocol [I-D.ietf-pana-snmp] is used to communicate between PAA and 185 EP. 187 A successful EAP authentication exchange results in a PANA security 188 association (PANA SA) if the EAP method was able to derive session 189 keys. In this case, all further PANA messages between PaC and PAA 190 will be authenticated, replay and integrity protected thanks to the 191 AUTH AVP. 193 2.2. Performance limitations in mobile environments 195 PaC ------------ pEP ---- pPAA 196 | | 197 | | 198 | +------ pAR 199 (IP handover) | 200 | 201 v 202 PaC------------ nEP ---- nPAA 203 | 204 | 205 +------ nAR 207 Figure 1: Example Scenario 209 Figure 1 shows an example scenario with a roaming PaC which has been 210 previously authenticated. The PAA is at one IP hop away from PaC; 211 this means that a specific PANA module on a PAA is in charge of one 212 IP network. After a PaC's IP handover, the PaC changes of IP subnet 213 and of PAA accordingly. The new PAA (nPAA) does not share any 214 context with the PaC. The new EP (nEP) will detect the PaC and will 215 trigger a new PANA authentication phase from scratch. A new 216 authentication phase involving the AAA infrastructure will then 217 occur. Such a signaling can seriously degrade handover performance 218 in term of latency. 220 For this reason, we propose to use the Context Transfer Protocol 221 (CXTP) to transfer the PANA context established between the PaC and 222 pPAA to the nPAA. 224 2.3. CXTP protocol overview 226 Context Transfer Protocol (CXTP) [RFC4067] enables context transfers 227 between access routers (ARs). The context transfer can be either 228 initiated by a request from the mobile node ("mobile initiated") or 229 at the initiative of either the new or the previous access router 230 ("network initiated"). Furthermore it can be performed prior to 231 handover ("predictive mode") or after the handover ("reactive mode"). 233 In reactive mode, the MN sends a CT Activate Request (CTAR) to the 234 new AR (nAR) (cf. Figure 2). In this message the MN includes an 235 authorization token: this token is calculated based on a secret 236 shared between the MN and the previous AR (pAR) and it is used in 237 order to authorize the transfer. This means that the MN and the pAR 238 must share a secret. The definition of this secret is out of scope 239 of CXTP. As soon as the nAR receives a CTAR message, it generates a 240 CT-Request message which includes the authorization token and the 241 context to be transferred (i.e. Feature Profile Types). This 242 message is received by the pAR that verifies the authorization token 243 and sends a Context Transfer Data (CTD) message including the 244 requested context. 246 MN nAR pAR 247 -- --- --- 248 | | | 249 | CTAR | | 250 +------------->| | 251 | | CT-Request | 252 | +------------->| 253 | | | 254 | | CTD | 255 | |<-------------+ 256 | CTAA | | 257 |<-------------+ | 259 Figure 2: CXTP in reactive mode 261 In the predictive case, the pAR receives a CTAR message from the MN 262 whose feature contexts are to be transferred. This message provides 263 the IP address of the nAR and an authorization token. The pAR 264 predictively transmits to the nAR a Context Transfer Data (CTD) that 265 contains feature contexts. This message contains also parameters for 266 the nAR to compute an authorization token in order to verify the MN's 267 token. Regardless the MN sent the CTAR to the pAR, it sends another 268 CTAR message to the nAR in order to ascertain that the context 269 transfer reliably took place. Furthermore in this CTAR the MN 270 includes the authorization token so that the nAR verifies it. 272 CXTP messages use Feature Profile Types (FPTs) to identify the way 273 data is organized for a particular feature context. The FPTs are 274 registered in a number space that allows a node to unambiguously 275 determine the type of context and the context parameters present in 276 the protocol messages. 278 3. CXTP usage in the PANA framework 280 The transfer may occur either after or before the handover. From 281 this standpoint, we only consider the reactive mode. This means that 282 the PaC has already performed the handover. Predictive mode is left 283 for further study. 285 The solution described here is based on [I-D.ietf-pana-mobopts]: the 286 transfer is triggered using the PANA signalling and CTD message is 287 used to carry the PANA context. 289 In the solution proposed by PANA [I-D.ietf-pana-mobopts], the PaC 290 does not use CTAR message to request and activate the context. 291 Instead, it replies to PSR message with a PSA message containing the 292 unexpired previous PANA session identifier and a AUTH AVP (cf. 293 Figure 3). This AVP is computed using the PANA_AUTH_KEY shared 294 between the PaC and its pPAA. 296 PaC nPAA pPAA 297 --- ---- ---- 298 PSR[PAA_Nonce] 299 <------------ 301 PSA[oSession-ID][PaC_Nonce][AUTH] 302 --------------> 304 CT-Request [PSA] 305 ----------------> 306 CTD-PANA 307 <---------------- 308 PBR[nSession-Id][AUTH] 309 <-------------- 310 PBA [AUTH] 311 ---------------> 313 Figure 3: The PANA approach 315 The nPAA receives this PSA message and it deduces that it must 316 perform CXTP (because of the Session-Id AVP). It determines the 317 identity of pPAA by looking at the DiameterIdentity part of the PANA 318 session identifier. It sends a CT-Request to the pPAA containing the 319 PSA message and its identity encapsulated in TLVs. The pPAA checks 320 the validity of the PSA message and transfers the PANA context in the 321 CTD message. Then the PANA session continues with a PANA-Bind 322 exchange 324 3.1. The Context Transfer Request Message 326 While receiving the PSA message containg the old Session-Id, the 327 PaC_Nonce and the AUTH AVP, the nPAA deduces that it must perform a 328 context transfer. For this, it sends a CT-Request message containing 329 its identity and the PSA message. 331 The CT-Request message has the following header (cf. 332 Figure 4)[RFC4067]: 334 0 1 2 3 335 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 |Vers.| Type |V| Reserved | Length | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 ~ Mobile Node's Previous IP Address ~ 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Sequence Number | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | MN Authorization Token | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 ~ Next Requested Context Data Block (if present) ~ 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 ~ ........ ~ 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Figure 4: CT-Request Header 352 The 'V' flag is normally used to indicate if the packet contains an 353 IPv4 or an IPv6 address in the Mobile Node's Previous IP Address 354 field. In this specification, the PANA Client is identified by the 355 previous PANA Session-ID that it shared with the previous PAA. This 356 information is sent in the PSA message used to trigger the transfer. 357 For this reason, the 'V' flag is not used and MUST be set to '0'. 359 However, in order to match response to request, the nPAA uses the 360 Mobile Node's Previous IP Address as an identifier field. This field 361 MUST have a length of 32 bits. 363 In CXTP, the authorization of the transfer is done through the use of 364 the MN Authorization Token. In this specification, the pPAA 365 authorizes the transfer using the PSA message sent by the nPAA. For 366 this reason, this field is no longer present. 368 As explained above, the nPAA sends its identity and the PSA message. 369 These data are sent in a Context Data Block (CDB). 371 The Context Data Block header is represented Figure 5) [RFC4067]: 373 0 1 2 3 374 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Feature Profile Type (FPT) | Length |P| Reserved | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Presence Vector (if P = 1) | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 ~ Data ~ 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Figure 5: Context Data Block 385 The FPT indicates the type of data in the data field. The FPT in the 386 case of PANA is TBD. The length field indicates the length of the 387 CDB in 8 octets words, including the first 4 octets starting from 388 FPT. The Presence Vector is not used in this specification. 390 In the CT-Request message, the nPAA gives both its identity 391 (DiameterIdentity) and the PSA message received from the PaC. For 392 this reason, one use Type-Length-Value (TLV) packets format to carry 393 these two informations. 395 The TLV packet header format is shown in Figure 6 397 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Type | Length | Value 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Figure 6: TLV header 404 The field Type indicates either nPAA's identity (Type=0x01) or the 405 PSA message (Type=0x02). The field Length indicates the length of 406 the Value without padding in TBD octets. The field Value contains 407 nPAA's identity (if Type=Ox01) or the PSA message (if Type=0x02). 409 3.2. The Context Transfer Data Message 411 The Context Transfer Data Message is the message sent from the pPAA 412 to the nPAA in response to a CT-Request. This message carries the 413 PANA context. 415 The CTD message header (as defined in [RFC4067]) is shown on Figure 7 416 0 1 2 3 417 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 |Vers.| Type |V|A| Reserved | Length | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Elapsed Time (in milliseconds) | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 ~ Mobile Node's Previous Care-of Address ~ 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 425 | Algorithm | Key Length | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCTD 427 | Key | only 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V 429 ~ First Context Data Block ~ 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 ~ Next Context Data Block ~ 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 ~ ........ ~ 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Figure 7: CTD header 438 The pPAA MUST copy the identifier sent by the nPAA in the MN's 439 Previous Care-of Address field of the CT-Request message in the 440 corresponding field of the CTD message. 442 As the predictive case is not considered in this current 443 specification, the fields corresponding to PCTD are not used. 445 The Context Data Block contains the PANA context sent from pPAA to 446 the nPAA and is defined below. 448 The PANA Context is what should be transferred between the two PAAs 449 to avoid re-authentication from scratch. The attributes described in 450 [I-D.ietf-pana-pana] list elements that could constitute the PANA 451 context at PAA. However some of these data are specific to the pPAA 452 and as such does not need to be transferred. 454 Figure 8 summarizes the PANA Context. 456 +------------------+------------+----------------------------+ 457 | Data | Type | Length | 458 +------------------+------------+----------------------------+ 459 | Session-Lifetime | Unsigned32 | Fixed | 460 | Remaining | | | 461 +------------------+------------+----------------------------+ 462 | AAA-Key-int | UTF8String | Fixed (64 octets) | 463 +------------------+------------+----------------------------+ 465 Figure 8: The PANA Context 467 Data have the following meanings: 469 Session-Lifetime: The authentication phase also determines the PANA 470 session lifetime when authorization succeeds. This value is 471 included in Session-Lifetime AVP. In Diameter [RFC3588], this AVP 472 (Session-Timeout) is of type Unsigned32 and contains the maximum 473 number of seconds of service to be provided to the user before 474 session termination. Note that the value forwarded to the new PAA 475 needs to reflect the already 'consumed' session lifetime. This 476 helps to avoid problems where roaming is used to reset the 477 lifetime when re-attaching at a new PAA. It must be assured that 478 the sum of the individual session lifetimes is never greater than 479 the initially communicated lifetime (type: Unsigned32, length: 4). 480 For this reason, the pPAA provides to the nPAA the remaining 481 Session-Lifetime. 483 AAA-Key-int: cf. [I-D.ietf-pana-mobopts]. 485 4. Conditions to Perform the Transfer 487 In this section, we list conditions and recommendations to perform a 488 PANA context transfer between two PAAs. This list is mostly 489 inherited from [I-D.aboba-802-context]: 491 o Homogeneous PAA's device deployment within a single administrative 492 domain. 494 o This solution only considers intradomain scenario. 496 o Entities engaged in the context transfer should authenticate to 497 each other. For this purpose, CXTP indicates that IPsec ESP must 498 be used in order to provide connectionless integrity, data origin 499 authentication and confidentiality protection. Thus pPAA and nPAA 500 should have IPsec SAs to protect CXTP messages. 502 o The nPAA should not obtain keys used to encrypt traffic between 503 PaC and pEP. This traffic may be encrypted at layer 2 or at layer 504 3. 506 o The new key (AAA-Key-new) derived between PaC and nPAA is based on 507 Nonces exchanged during PANA-Start-Exchange. For this reason, the 508 proposed solution only work with PANA Stateful Discovery 509 mechanism. 511 5. Security considerations 513 This document deals with interaction between the Seamoby Context 514 Transfer Protocol and PANA. Therefore, all security considerations 515 described in [RFC4067], in [I-D.ietf-pana-pana] and in [I-D.ietf- 516 pana-mobopts] also apply here. 518 The approach described in this document considers only the intra- 519 domain scenario. This means that the PAAs involved in the context 520 transfer belong to the same administrative domain. Therefore, at 521 this stage the inter-domain scenario is out of scope. 523 As described in [RFC4067] IPsec ESP must be used to protect CXTP 524 messages between PAAs. In order to avoid the introduction of 525 additional latency due to the need for establishment of a secure 526 channel between the context transfer peers, the two PAAs should 527 establish such a secure channel in advance. The mechanism used by 528 the PAAs to establish such a channel is out of the scope of this 529 draft: for example, IKE [RFC2409] with pre-shared key authentication 530 might be used. 532 6. IANA Considerations 534 TBD for FPT 536 7. Acknowledgements 538 The authors would like to thank Sasikanth Bharadwaj, Vijay 539 Devarapalli, James Kempf, Rajeev Koodli, Nakhjiri Madjid-MNAKHJI, 540 Jean-Jacques Puig, Rene Soltwitsch and Alper Yegin for their valuable 541 comments. 543 8. Changes 545 8.1. Changes from 00 to 01 547 Added an Applicability Statement. 549 Changed "Session-Lifetime Elapsed" to "Session-Lifetime 550 Remaining". 552 The nPAA sends its Identity in the CTB. For this purpose, we 553 added TLVs. This identity is used for the AAA-Key-int Key 554 computation. 556 The Context Data Block is specified both for the CT-Request and 557 CTD message. 559 The MN's previous Care-of Address field is filled with an 560 identifier in order to match requests to responses. 562 Changed MAC AVP to AUTH AVP. 564 9. References 566 9.1. Normative References 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", BCP 14, RFC 2119, March 1997. 571 [I-D.ietf-pana-pana] 572 Forsberg, D., "Protocol for Carrying Authentication for 573 Network Access (PANA)", draft-ietf-pana-pana-11 (work in 574 progress), March 2006. 576 [I-D.ietf-pana-mobopts] 577 Forsberg, D., "PANA Mobility Optimizations", 578 draft-ietf-pana-mobopts-01 (work in progress), 579 October 2005. 581 [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, 582 "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 584 9.2. Informative References 586 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 587 (IKE)", RFC 2409, November 1998. 589 [I-D.ietf-pana-snmp] 590 Mghazli, Y., "SNMP usage for PAA-EP interface", 591 draft-ietf-pana-snmp-05 (work in progress), January 2006. 593 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 594 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 596 [I-D.aboba-802-context] 597 Aboba, B. and T. Moore, "A Model for Context Transfer in 598 IEEE 802", draft-aboba-802-context-02 (work in progress), 599 April 2002. 601 Authors' Addresses 603 Julien Bournelle 604 GET/INT 605 9 rue Charles Fourier 606 Evry 91011 607 France 609 Email: julien.bournelle@int-evry.fr 611 Maryline Laurent-Maknavicius 612 GET/INT 613 9 rue Charles Fourier 614 Evry 91011 615 France 617 Email: maryline.maknavicius@int-evry.fr 619 Hannes Tschofenig 620 Siemens Corporate Technology 621 Otto-Hahn-Ring 6 622 81739 Munich 623 Germany 625 Email: Hannes.Tschofenig@siemens.com 627 Yacine El Mghazli 628 Alcatel 629 Route de Nozay 630 Marcoussis 91460 631 France 633 Email: yacine.el_mghazli@alcatel.fr 635 Gerardo Giaretta 636 TILab 637 via G. Reiss Romoli, 274 638 TORINO 10148 639 Italy 641 Email: gerardo.giaretta@telecomitalia.it 642 Rafa Marin Lopez 643 University of Murcia 644 30071 Murcia 645 Spain 647 Email: rafa@dif.um.es 649 Yoshihiro Ohba 650 Toshiba America Research, Inc. 651 1 Telcordia Drive 652 Piscateway, NJ 08854 653 USA 655 Phone: +1 732 699 5365 656 Email: yohba@tari.toshiba.com 658 Intellectual Property Statement 660 The IETF takes no position regarding the validity or scope of any 661 Intellectual Property Rights or other rights that might be claimed to 662 pertain to the implementation or use of the technology described in 663 this document or the extent to which any license under such rights 664 might or might not be available; nor does it represent that it has 665 made any independent effort to identify any such rights. Information 666 on the procedures with respect to rights in RFC documents can be 667 found in BCP 78 and BCP 79. 669 Copies of IPR disclosures made to the IETF Secretariat and any 670 assurances of licenses to be made available, or the result of an 671 attempt made to obtain a general license or permission for the use of 672 such proprietary rights by implementers or users of this 673 specification can be obtained from the IETF on-line IPR repository at 674 http://www.ietf.org/ipr. 676 The IETF invites any interested party to bring to its attention any 677 copyrights, patents or patent applications, or other proprietary 678 rights that may cover technology that may be required to implement 679 this standard. Please address the information to the IETF at 680 ietf-ipr@ietf.org. 682 Disclaimer of Validity 684 This document and the information contained herein are provided on an 685 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 686 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 687 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 688 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 689 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 690 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 692 Copyright Statement 694 Copyright (C) The Internet Society (2006). This document is subject 695 to the rights, licenses and restrictions contained in BCP 78, and 696 except as set forth therein, the authors retain all their rights. 698 Acknowledgment 700 Funding for the RFC Editor function is currently provided by the 701 Internet Society.