idnits 2.17.1 draft-ietf-pana-cxtp-00.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 535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 520. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (October 6, 2005) is 6777 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: 'MAC' is mentioned on line 339, but not defined == Missing Reference: 'PSA' is mentioned on line 333, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-10 == Outdated reference: A later version (-01) exists of draft-ietf-pana-mobopts-00 -- 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-04 -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 4 errors (**), 0 flaws (~~), 7 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: April 9, 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 October 6, 2005 17 Use of Context Transfer Protocol (CXTP) for PANA 18 draft-ietf-pana-cxtp-00 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 April 9, 2006. 45 Copyright Notice 47 Copyright (C) The Internet Society (2005). 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.1 PANA framework . . . . . . . . . . . . . . . . . . . . . . 6 66 3.2 Performance limitations in mobile environments . . . . . . 6 67 3.3 CXTP protocol overview . . . . . . . . . . . . . . . . . . 7 68 4. The PANA Context . . . . . . . . . . . . . . . . . . . . . . 9 69 5. CXTP usage in the PANA framework . . . . . . . . . . . . . . 10 70 6. Conditions to Perform the Transfer . . . . . . . . . . . . . 12 71 7. Security considerations . . . . . . . . . . . . . . . . . . 13 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 10.1 Normative References . . . . . . . . . . . . . . . . . . 16 76 10.2 Informative References . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 78 Intellectual Property and Copyright Statements . . . . . . . 19 80 1. Introduction 82 In IP based access network, PANA [I-D.ietf-pana-pana] may be used as 83 a front-end to a AAA architecture in order to authenticate users 84 before granting them access to the resources. For this purpose, it 85 uses EAP which offers a variety of authentication methods. In a 86 shared medium, this is typically accomplished with the help of 87 cryptographic mechanisms. Note that this type of cryptographic 88 mechanism prevents a malicious node from sending packet to the 89 network and thereby authenticating each data packet. In addition, 90 encryption is often enabled to prevent eavesdropping. 92 While roaming, the PANA client might change its access router. In 93 some cases and without extensions to PANA, the PaC has to restart a 94 new PANA protocol exchange to authenticate itself to the network. 95 This authentication may need to execute the EAP exchange from 96 scratch. 98 In this document, we analyse the interaction between the framework 99 defined in [RFC4067] and PANA. In particular, we define what should 100 be transferred (i.e. the PANA context). 102 Rough consensus in the PANA working group leaded to the solution 103 where the transfer occurs between authentication agents, according to 104 the recommendations in [I-D.ietf-pana-mobopts]. 106 2. Terminology 108 Most of the terms are defined in the PANA [I-D.ietf-pana-pana] and 109 CXTP [RFC4067] specifications: 111 nAR New Access Router. The router to which the PaC attaches after 112 the handover. 114 pAR Previous Access Router. The router to which the PaC was attached 115 before the handover. 117 CTAA Context Transfer Activate Acknowledge. 119 CTAR Context Transfer Activate Request. 121 CTD Context Transfer Data. 123 CXTP Context Transfer Protocol. 125 EP Enforcement Point. (PANA term) 127 FPT Feature Profile Type (CXTP term). 129 PaC PANA Client. A mobile node (MN) using a PANA protocol 130 implementation to authenticate itself to the network. 132 PAA PANA Authentication Agent. The access network (server) side 133 entity of the PANA protocol. A PAA is in charge of interfacing 134 with the PaCs for authenticating and authorizing them for the 135 network access service. 137 nPAA New PANA Authentication Agent. The PAA in charge of the subnet 138 to which the PaC is attached after the handover. 140 pPAA Previous PANA Authentication Agent. The PaC's default PAA prior 141 to handover. 143 PANA Protocol for Carrying Network Authentication for Network Access 145 3. Background 147 This section gives basic information on PANA framework and CXTP 148 protocol. The intent here is to further explain the context being 149 referred to and the terminology used in the remaining of the 150 document. 152 3.1 PANA framework 154 PANA is a protocol that carries EAP over IP/UDP to authenticate 155 users. The PANA Authentication Agent (PAA) is the endpoint of the 156 PANA protocol at the access network. The PAA itself might not be 157 able to authenticate the user by terminating the EAP protocol. 158 Instead the PAA might forward the EAP payloads to the backend AAA 159 infrastructure. 161 The Enforcement Point (EP) is an entity which enforces the result of 162 the PANA protocol exchange. The EP might be co-located with the PAA 163 or separated as a stand-alone device. In the latter case, the SNMPv3 164 protocol [I-D.ietf-pana-snmp] is used to communicate between PAA and 165 EP. 167 A successful EAP authentication exchange results in a PANA security 168 association (PANA SA) if the EAP method was able to derive session 169 keys. In this case, all further PANA messages between PaC and PAA 170 will be authenticated, replay and integrity protected thanks to the 171 MAC AVP. 173 3.2 Performance limitations in mobile environments 175 PaC ------------ pEP ---- pPAA 176 | | 177 | | 178 | +------ pAR 179 (IP handover) | 180 | 181 v 182 PaC------------ nEP ---- nPAA 183 | 184 | 185 +------ nAR 187 Figure 1: Example Scenario 189 Figure 1 shows an example scenario with a roaming PaC which has been 190 previously authenticated. The PAA is at one IP hop away from PaC; 191 this means that a specific PANA module on a PAA is in charge of one 192 IP network. After a PaC's IP handover, the PaC changes of IP subnet 193 and of PAA accordingly. The new PAA (nPAA) does not share any 194 context with the PaC. The new EP (nEP) will detect the PaC and will 195 trigger a new PANA authentication phase from scratch. A new 196 authentication phase involving the AAA infrastructure will then 197 occur. Such a signaling can seriously degrade handover performance 198 in term of latency. 200 For this reason, we propose to use the Context Transfer Protocol 201 (CXTP) to transfer the PANA context established between the PaC and 202 pPAA to the nPAA. 204 3.3 CXTP protocol overview 206 Context Transfer Protocol (CXTP) [RFC4067] enables context transfers 207 between access routers (ARs). The context transfer can be either 208 initiated by a request from the mobile node ("mobile initiated") or 209 at the initiative of either the new or the previous access router 210 ("network initiated"). Furthermore it can be performed prior to 211 handover ("predictive mode") or after the handover ("reactive mode"). 213 In reactive mode, the MN sends a CT Activate Request (CTAR) to the 214 new AR (nAR) (cf. Figure 2). In this message the MN includes an 215 authorization token: this token is calculated based on a secret 216 shared between the MN and the previous AR (pAR) and it is used in 217 order to authorize the transfer. This means that the MN and the pAR 218 must share a secret. The definition of this secret is out of scope 219 of CXTP. As soon as the nAR receives a CTAR message, it generates a 220 CT-Request message which includes the authorization token and the 221 context to be transferred (i.e. Feature Profile Types). This 222 message is received by the pAR that verifies the authorization token 223 and sends a Context Transfer Data (CTD) message including the 224 requested context. 226 MN nAR pAR 227 -- --- --- 228 | | | 229 | CTAR | | 230 +------------->| | 231 | | CT-Request | 232 | +------------->| 233 | | | 234 | | CTD | 235 | |<-------------+ 236 | CTAA | | 237 |<-------------+ | 238 Figure 2: CXTP in reactive mode 240 In the predictive case, the pAR receives a CTAR message from the MN 241 whose feature contexts are to be transferred. This message provides 242 the IP address of the nAR and an authorization token. The pAR 243 predictively transmits to the nAR a Context Transfer Data (CTD) that 244 contains feature contexts. This message contains also parameters for 245 the nAR to compute an authorization token in order to verify the MN's 246 token. Regardless the MN sent the CTAR to the pAR, it sends another 247 CTAR message to the nAR in order to ascertain that the context 248 transfer reliably took place. Furthermore in this CTAR the MN 249 includes the authorization token so that the nAR verifies it. 251 CXTP messages use Feature Profile Types (FPTs) to identify the way 252 data is organized for a particular feature context. The FPTs are 253 registered in a number space that allows a node to unambiguously 254 determine the type of context and the context parameters present in 255 the protocol messages. 257 4. The PANA Context 259 The PANA Context is what should be transferred between the two PAAs 260 to avoid re-authentication from scratch. The attributes described in 261 [I-D.ietf-pana-pana] list elements that could constitute the PANA 262 context at PAA. However some of these data are PAA specific and as 263 such does not need to be transferred. 265 Figure 3 summarizes the PANA Context. 267 +------------------+------------+----------------------------+ 268 | Data | Type | Length | 269 +------------------+------------+----------------------------+ 270 | Session-Lifetime | Unsigned32 | Fixed | 271 | Elapsed | | | 272 +------------------+------------+----------------------------+ 273 | AAA-Key-int | UTF8String | Fixed (64 octets) | 274 +------------------+------------+----------------------------+ 276 Figure 3: The PANA Context 278 Data have the following meanings: 280 Session-Lifetime: The authentication phase also determines the PANA 281 session lifetime when authorization succeeds. This value is 282 included in Session-Lifetime AVP. In Diameter [RFC3588], this AVP 283 (Session-Timeout) is of type Unsigned32 and contains the maximum 284 number of seconds of service to be provided to the user before 285 session termination. Note that the value forwarded to the new PAA 286 needs to reflect the already 'consumed' session lifetime. This 287 helps to avoid problems where roaming is used to reset the 288 lifetime when re-attaching at a new PAA. It must be assured that 289 the sum of the individual session lifetimes is never greater than 290 the initially communicated lifetime (type: Unsigned32, length: 4) 292 AAA-Key-int: cf. [I-D.ietf-pana-mobopts]. 294 5. CXTP usage in the PANA framework 296 The transfer may occur either after or before the handover. From 297 this standpoint, we only consider the reactive mode. This means that 298 the PaC has already performed the handover. Predictive mode is left 299 for further study. 301 The solution described here is based on [I-D.ietf-pana-mobopts]: the 302 transfer is triggered using the PANA signalling and CTD message is 303 used to carry the PANA context. 305 The CTD message is described in the following figure (ABNF notation): 307 CTD-PANA ::= < CTD-Header> 308 < Context Data Block, Ctx-Type: PANA-Context-Transfer, FPT> 310 { Session-Lifetime-Elapsed } 311 { AAA-Key-int } 313 Figure 4: CTD-PANA message 315 where FPT (Feature Profile Type) identifies the way the particular 316 feature context is organized. 318 In the solution proposed by PANA [I-D.ietf-pana-mobopts], the PaC 319 does not use CTAR message to request and activate the context. 320 Instead, it replies to PSR message with a PSA message containing the 321 unexpired previous PANA session identifier and a MAC AVP (cf. 322 Figure 5). This AVP is computed using the PANA_MAC_KEY shared 323 between the PaC and its pPAA. 325 PaC nPAA pPAA 326 --- ---- ---- 327 PSR[PAA_Nonce] 328 <------------ 330 PSA[oSession-ID][PaC_Nonce][MAC] 331 --------------> 333 CT-Request [PSA] 334 ----------------> 335 CTD-PANA 336 <---------------- 337 PBR[nSession-Id][MAC] 338 <-------------- 339 PBA [MAC] 340 ---------------> 341 Figure 5: The PANA approach 343 The nPAA receives this PSA message and it deduces that it must 344 perform CXTP (because of the Session-Id AVP). It determines the 345 identity of pPAA by looking at the DiameterIdentity part of the PANA 346 session identifier. It sends a CT-Request to the pPAA containing the 347 PSA message. The pPAA checks the validity of the PSA message and 348 transfers the PANA context in the CTD message. Then the PANA session 349 continues with a PANA-Bind exchange. 351 6. Conditions to Perform the Transfer 353 In this section, we list conditions and recommendations to perform a 354 PANA context transfer between two PAAs. This list is mostly 355 inherited from [I-D.aboba-802-context]: 357 o Homogeneous PAA's device deployment within a single administrative 358 domain. 360 o This solution only consider intradomain scenario. 362 o Entities engaged in the context transfer should authenticate each 363 other. For this purpose, CXTP indicates that IPsec ESP must be 364 used in order to provide connectionless integrity, data origin 365 authentication and confidentiality protection. Thus pPAA and nPAA 366 should have IPsec SAs to protect CXTP messages. 368 o The nPAA should not obtain keys used to encrypt traffic between 369 PaC and pEP. This traffic may be encrypted at layer 2 or at layer 370 3. 372 o The new key (AAA-Key-new) derived between PaC and nPAA is based on 373 Nonces exchanged during PANA-Start-Exchange. For this reason, the 374 proposed solution only work with PANA Stateful Discovery 375 mechanism. 377 7. Security considerations 379 This document deals with interaction between the Seamoby Context 380 Transfer Protocol and PANA. Therefore, all security considerations 381 described in [RFC4067], in [I-D.ietf-pana-pana] and in [I-D.ietf- 382 pana-mobopts] also apply here. 384 The approach described in this document considers only the intra- 385 domain scenario. This means that the PAAs involved in the context 386 transfer belong to the same administrative domain. Therefore, at 387 this stage the inter-domain scenario is out of scope. 389 As described in [RFC4067] IPsec ESP must be used to protect CXTP 390 messages between PAAs. In order to avoid the introduction of 391 additional latency due to the need for establishment of a secure 392 channel between the context transfer peers, the two PAAs should 393 establish such a secure channel in advance. The mechanism used by 394 the PAAs to establish such a channel is out of the scope of this 395 draft: for example, IKE [RFC2409] with pre-shared key authentication 396 might be used. 398 8. IANA Considerations 400 TBD for FPT 402 9. Acknowledgements 404 The authors would like to thank Vijay Devarapalli, James Kempf, 405 Rajeev Koodli, Nakhjiri Madjid-MNAKHJI, Jean-Jacques Puig, Rene 406 Soltwitsch and Alper Yegin for their valuable comments. 408 10. References 410 10.1 Normative References 412 [I-D.ietf-pana-pana] 413 Forsberg, D., "Protocol for Carrying Authentication for 414 Network Access (PANA)", draft-ietf-pana-pana-10 (work in 415 progress), July 2005. 417 [I-D.ietf-pana-mobopts] 418 Forsberg, D., "PANA Mobility Optimizations", 419 draft-ietf-pana-mobopts-00 (work in progress), 420 January 2005. 422 [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, 423 "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 425 10.2 Informative References 427 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 428 (IKE)", RFC 2409, November 1998. 430 [I-D.ietf-pana-snmp] 431 Mghazli, Y., "SNMP usage for PAA-EP interface", 432 draft-ietf-pana-snmp-04 (work in progress), July 2005. 434 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 435 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 437 [I-D.aboba-802-context] 438 Aboba, B. and T. Moore, "A Model for Context Transfer in 439 IEEE 802", draft-aboba-802-context-02 (work in progress), 440 April 2002. 442 Authors' Addresses 444 Julien Bournelle 445 GET/INT 446 9 rue Charles Fourier 447 Evry 91011 448 France 450 Email: julien.bournelle@int-evry.fr 451 Maryline Laurent-Maknavicius 452 GET/INT 453 9 rue Charles Fourier 454 Evry 91011 455 France 457 Email: maryline.maknavicius@int-evry.fr 459 Hannes Tschofenig 460 Siemens Corporate Technology 461 Otto-Hahn-Ring 6 462 81739 Munich 463 Germany 465 Email: Hannes.Tschofenig@siemens.com 467 Yacine El Mghzali 468 Alcatel 469 Route de Nozay 470 Marcoussis 91460 471 France 473 Email: yacine.el_mghazli@alcatel.fr 475 Gerardo Giaretta 476 TILab 477 via G. Reiss Romoli, 274 478 TORINO 10148 479 Italy 481 Email: gerardo.giaretta@telecomitalia.it 483 Rafa Marin Lopez 484 University of Murcia 485 30071 Murcia 486 Spain 488 Email: rafa@dif.um.es 489 Yoshihiro Ohba 490 Toshiba America Research, Inc. 491 1 Telcordia Drive 492 Piscateway, NJ 08854 493 USA 495 Phone: +1 732 699 5365 496 Email: yohba@tari.toshiba.com 498 Intellectual Property Statement 500 The IETF takes no position regarding the validity or scope of any 501 Intellectual Property Rights or other rights that might be claimed to 502 pertain to the implementation or use of the technology described in 503 this document or the extent to which any license under such rights 504 might or might not be available; nor does it represent that it has 505 made any independent effort to identify any such rights. Information 506 on the procedures with respect to rights in RFC documents can be 507 found in BCP 78 and BCP 79. 509 Copies of IPR disclosures made to the IETF Secretariat and any 510 assurances of licenses to be made available, or the result of an 511 attempt made to obtain a general license or permission for the use of 512 such proprietary rights by implementers or users of this 513 specification can be obtained from the IETF on-line IPR repository at 514 http://www.ietf.org/ipr. 516 The IETF invites any interested party to bring to its attention any 517 copyrights, patents or patent applications, or other proprietary 518 rights that may cover technology that may be required to implement 519 this standard. Please address the information to the IETF at 520 ietf-ipr@ietf.org. 522 The IETF has been notified of intellectual property rights claimed in 523 regard to some or all of the specification contained in this 524 document. For more information consult the online list of claimed 525 rights. 527 Disclaimer of Validity 529 This document and the information contained herein are provided on an 530 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 531 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 532 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 533 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 534 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 535 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 537 Copyright Statement 539 Copyright (C) The Internet Society (2005). This document is subject 540 to the rights, licenses and restrictions contained in BCP 78, and 541 except as set forth therein, the authors retain all their rights. 543 Acknowledgment 545 Funding for the RFC Editor function is currently provided by the 546 Internet Society.