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