idnits 2.17.1 draft-ohba-pana-preauth-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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 491. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 481. ** 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 (July 8, 2005) is 6867 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) == Unused Reference: 'I-D.ohba-mobopts-mpa-framework' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pana-mobopts' is defined on line 434, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-08 == Outdated reference: A later version (-05) exists of draft-ohba-mobopts-mpa-framework-00 == Outdated reference: A later version (-01) exists of draft-ietf-pana-mobopts-00 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAP Working Group Y. Ohba 3 Internet-Draft Toshiba 4 Expires: January 9, 2006 July 8, 2005 6 Pre-authentication Support for PANA 7 draft-ohba-pana-preauth-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 9, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document defines an extension to the PANA protocol used for 41 proactively establishing a PANA SA (Security Association) between a 42 PaC in an access network and a PAA in another access network to which 43 the PaC may move. The proposed method operates across multiple 44 administrative domains. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1 Specification of Requirements . . . . . . . . . . . . . . 4 50 2. Terminogy . . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 3. Pre-authentication Procedure . . . . . . . . . . . . . . . . . 7 52 4. PANA Extensions . . . . . . . . . . . . . . . . . . . . . . . 11 53 5. Authorization and Accounting Considerations . . . . . . . . . 12 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 56 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 57 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 58 9.1 Normative References . . . . . . . . . . . . . . . . . . . 16 59 9.2 Informative References . . . . . . . . . . . . . . . . . . 16 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 61 Intellectual Property and Copyright Statements . . . . . . . . 17 63 1. Introduction 65 The PANA protocol [I-D.ietf-pana-pana] carries EAP messages between a 66 PaC (PANA Client) and a PAA (PANA Authentication Agent) in the access 67 network. If the PaC is a mobile device and is capable of moving one 68 access network to another while running its applications, it is 69 critical for the PaC to perform a handover seamlessly without 70 degrading the performance of the applications during the handover 71 period. When the handover requires the PaC to establish a PANA 72 session with the PAA in the new access network, the signaling to 73 establish the PANA session should be completed as fast as possible. 75 There is an optimization method based on Context Transfer Protocol 76 (CTP) [I-D.ietf-seamoby-ctp] to reduce the signaling delay for 77 establishing a PANA session with a new PAA upon a handover [I-D.ietf- 78 pana-mobopts][I-D.bournelle-pana-ctp]. 80 The CTP-based method have the following issues. First, it is not 81 readily applicable to handovers across multiple administrative 82 domains since having a security association between PAAs in different 83 administrative domains is practically difficult. Second, even within 84 a single administrative domain, the CTP-based method is difficult to 85 work when the previous and new access networks have different 86 authorization characteristics, e.g., on use of NAP and ISP separate 87 authentication. Third, the CTP-based method relies on deriving the 88 PANA_MAC_Key used between the PaC and the PAA in the new access 89 network from the AAA-Key used between the PaC and the PAA in the 90 previous access network, which does not provide perfect cryptographic 91 separation between the PAAs. 93 To address the issues on the CTP-based method, this document defines 94 an extension to the PANA protocol [I-D.ietf-pana-pana] used for 95 proactively executing EAP authentication and establishing a PANA SA 96 (Security Association) between a PaC in an access network and a PAA 97 in another access network to which the PaC may move. The proposed 98 method operates across multiple administrative domains. The proposed 99 method is used as the authentication protocol in the framework of MPA 100 (Media-independent Pre-authentication) [I-D.ohba-mobopts-mpa- 101 framework]. 103 Although the proposed method covers the case that is also covered by 104 the CTP-based method (i.e., homogeneous authorization characteristics 105 in a single administrative domain), the purpose of this document is 106 not to replace the CTP-based method. Instead, the purpose of this 107 document is to provide a way to cover the cases that are not covered 108 by the other method. For the case covered by the CTP-based method, 109 the CTP-based method may be used. 111 1.1 Specification of Requirements 113 In this document, several words are used to signify the requirements 114 of the specification. These words are often capitalized. The key 115 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 116 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 117 are to be interpreted as described in [RFC2119]. 119 2. Terminogy 121 The following terms are used in this document in addition to the 122 terms defined in [I-D.ietf-pana-pana]. 124 Access Network: 126 A network through which a PaC can access to the Internet via one 127 or more EPs controlled by one or more PAAs. An access network may 128 consist of multiple IP links. 130 Local PAA: 132 A PAA that resides in the access network where the PaC is 133 connected. The term "local" is relative to the location of a 134 particular PaC. 136 Remote PAA: 138 A PAA that is not a local PAA for the PaC. The term "remote" is 139 relative to the location of a particular PaC. A PAA that is a 140 remote PAA for one PaC may be a local PAA for another PaC. 142 Local PaC: 144 A PaC that resides in the same access network as a particular PAA. 145 The term "local" is relative to the location of a specific PaC. 147 Remote PaC: 149 A PaC that is not a local PaC for a particular PAA. The term 150 "remote" is relative to the location of a particular PAA. A PaC 151 that is a remote PaC for one PAA may be a local PaC for another 152 PAA. 154 Active PAA: 156 A local PAA for which the PaC has a PANA session. 158 Preparing PAA: 160 A remote PAA which performs pre-authentication with the PaC. A 161 PAA that is serving as a preparing PAA for one PaC may be serving 162 as an active PAA for another PaC. 164 Pre-authentication: 166 Authentication performed between the PaC and a preparing PAA. 168 Pre-authentication SA: 170 A PANA SA that is established between the PaC and a preparing PAA 171 as a result of successful pre-authentication. 173 Active SA: 175 A PANA SA that is established between the PaC and an active PAA. 177 Pre-authorization: 179 An authorization that is made for the PaC by a preparing PAA as a 180 result of successful pre-authentication. 182 Post-authorization: 184 An authorization that was made for the PaC by a PAA that was 185 acting as a preparing PAA and has become the active PAA. 187 3. Pre-authentication Procedure 189 A PaC that supports pre-authentication may have one or more PANA 190 sessions for preparing PAAs in addition to the PANA session for one 191 of local PAAs. 193 There may be a number of ways to discover a remote PAA, however, 194 remote PAA discovery and remote PaC discovery is out of the scope of 195 this proposal. 197 There may be a number of criteria as to when and with which remote 198 PAA pre-authentication is performed. Such criteria can be 199 implementation specific and thus are outside the scope of this 200 document. 202 Pre-authentication may be initiated by both a PaC and a preparing 203 PAA. A new flag P-flag is defined in the PANA header. When pre- 204 authentication is performed, the P-flag of PANA messages are set in 205 order to indicate whether this PANA run is for establishing a pre- 206 authentication SA. Pre-authentication is negotiated in the PANA 207 discovery and handshake phase as follows. 209 o When a PaC initiates pre-authentication, it sends a PANA-PAA- 210 Discover message with the P-flag set. The PANA-PAA-Discover 211 message MUST be unicast. The PAA responds with a PANA-Start- 212 Request message with the P-flag set only when it supports pre- 213 authentication. Otherwise, it MUST silently discard the message. 215 o When a preparing PAA initiates pre-authentication, it sends a 216 PANA-Start-Request message with the P-flag set. The PaC responds 217 with a PANA-Start-Answer message with the P-flag set only when it 218 supports pre-authentication. Otherwise, it MUST silently discard 219 the message. 221 o Once the PaC and preparing PAA have agreed on performing pre- 222 authentication during the discovery and handshake phase, the 223 subsequent PANA messages exchanged between them MUST have the 224 P-flag set. 226 When the preparing PAA becomes an active PAA due to movement of the 227 PaC, the PaC performs an IP address update procedure using PANA- 228 Update exchange in order to update the PAA with the PaC's new address 229 obtained from the remote network where the PAA resides. The 230 completion of the PANA-Update procedure will change the pre- 231 authentication SA to the active SA. The P-flag is not set in the 232 PANA-Update messages and subsequent PANA messages. 234 When the PaC having an active SA with an active PAA as well as a pre- 235 authentication SA with a preparing PAA changes its active PAA but 236 without changing the preparing PAA, the PaC performs an IP address 237 update procedure using PANA-Update exchange in order to update the 238 PAA of the PaC's new address obtained from the remote network where 239 the new active PAA resides. The completion of the PANA-Update 240 procedure will not change the pre-authentication SA to the active SA. 241 The P-flag is set in the PANA-Update messages and subsequent PANA 242 messages. 244 The pre-authentication SA and corresponding PANA session between the 245 PaC and the pre-authenticated PAA can be deleted by entering the 246 termination phase of the PANA protocol and performing the required 247 procedure for that phase. 249 An example call flow for PaC-initiated pre-authentication is shown in 250 Figure 1. 252 A PaC in an access network establishes a PANA session with a local 253 PAA (l-PAA). At some point, it receives a trigger for pre- 254 authenticating to a remote PAA (r-PAA) in another access network. 255 The PaC then initiates a pre-authentication procedure by sending a 256 PANA-PAA-Discover message with the P-bit set. PANA messages are 257 exchanged between the PaC and r-PAA, with the P-bit set for all 258 messages. On successful completion of the PANA exchanges for pre- 259 authentication and pre-authorization, a pre-authentication SA will be 260 established between the PaC and l-PAA. On the other hand, the active 261 SA established between the PaC and l-PAA stays active. 263 At some point after establishing the pre-authentication SA, the PaC 264 moves to the access network of the r-PAA. Then the PaC initiates a 265 PANA-Update exchange to inform the PAA of the IP address change. In 266 this PANA-Update exchange, the P-bit is unset. On successful 267 completion of the PANA-Update exchange and post-authorization 268 procedure, the pre-authentication SA becomes the active SA. The 269 active SA between the PaC and l-PAA may stay active for a while to 270 deal with the case in which the PaC immediately switches back to the 271 previous access network. 273 PaC l-PAA r-PAA 274 | | | 275 | PANA w/o P-bit set | | 276 |<---------------------->| | 277 | | | 278 . . . 279 . . . 280 +------------------+ | | 281 |Pre-authentication| | | 282 |trigger | | | 283 +------------------+ | | 284 | PDI w/P-bit set | 285 |------------------------------------------------>| 286 | PSR w/P-bit set | 287 |<------------------------------------------------| 288 | PSA w/P-bit set | 289 |------------------------------------------------>| 290 | PAR-PAN exchange w/P-bit set | 291 |<----------------------------------------------->| 292 | | +------------------+ 293 | | |pre-authorization | 294 | | +------------------+ 295 | PBR-PBA exchange w/P-bit set | 296 |<----------------------------------------------->| 297 . . . 298 . . . 299 +----------+ | | 300 | Movement | | | 301 +----------+ | | 302 | PUR w/o P-bit set | 303 |------------------------------------------------>| 304 | | +------------------+ 305 | | |post-authorization| 306 | | +------------------+ 307 | PUA w/o P-bit set | 308 |<------------------------------------------------| 309 | | | 311 Figure 1: PaC-initiated Pre-authentication Call Flow 313 An example call flow for PAA-initiated pre-authentication is shown in 314 Figure 2. 316 PaC l-PAA r-PAA 317 | | | 318 | PANA w/o P-bit set | | 319 |<---------------------->| | 320 | | | 321 . . . 322 . . . 323 | | +------------------+ 324 | | |Pre-authentication| 325 | | |trigger | 326 | | +------------------+ 327 | PSR w/P-bit set | 328 |<------------------------------------------------| 329 | PSA w/P-bit set | 330 |------------------------------------------------>| 331 | PAR-PAN exchange w/P-bit set | 332 |<----------------------------------------------->| 333 | | +------------------+ 334 | | |pre-authorization | 335 | | +------------------+ 336 | PBR-PBA exchange w/P-bit set | 337 |<----------------------------------------------->| 338 . . . 339 . . . 340 +----------+ | | 341 | Movement | | | 342 +----------+ | | 343 | PUR w/o P-bit set | 344 |------------------------------------------------>| 345 | | +------------------+ 346 | | |post-authorization| 347 | | +------------------+ 348 | PUA w/o P-bit set | 349 |<------------------------------------------------| 350 | | | 352 Figure 2: PAA-initiated Pre-authentication Call Flow 354 4. PANA Extensions 356 A new P-flag is defined in Flags field of PANA header as follows. 358 0 1 359 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 |R S N P r r r r r r r r r r r r| 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 P(re-authentication) 366 When pre-authentication is performed, the P-flag of PANA messages 367 are set in order to indicate whether this PANA run is for 368 establishing a pre-authentication SA. The exact usage of this 369 flag is described in Section 3. This flag is to be assigned by 370 IANA. 372 5. Authorization and Accounting Considerations 374 A pre-authorization and a post-authorization for the PaC may have 375 different authorization policies. For example, the pre-authorization 376 policy may not allow the PaC to sent or receive packets through the 377 EP(s) under control of the preparing PAA, while both the pre- 378 authorization and post-authorization policies may allow installing 379 credentials to the EP(s), where the credentials are used for 380 establishing a security association for per-packet cryptographic 381 filtering. 383 Depending on the pre-authorization policy, the PAA that has an pre- 384 authentication SA for a PaC may start accounting immediately after 385 the pre-authentication SA is established or may not start accounting 386 until the pre-authentication SA becomes the active SA. 388 6. Security Considerations 390 Since the mechanism described in this document is designed to work 391 across multiple access networks, each EP (Enforcement Point) SHOULD 392 be configured to allow PANA messages to be forwarded between a PaC 393 and a preparing PAA in a different access network only if the PaC has 394 an active SA with a local PAA in order to avoid an unauthorized PaC 395 to initiate pre-authentication. 397 When pre-authentication is initiated by a remote PAA, it is possible 398 that the PaC simultaneously communicates with multiple remote PAAs 399 initiating pre-authentication. In order to avoid possible resource 400 consumption attacks on the PaC caused by a blind attacker initiating 401 pre-authentication for the PaC by changing source addresses, the PaC 402 SHOULD limit the maximum number of PAAs allowed to communicate. 404 7. IANA Considerations 406 As described in Section 4, a new flag in the Flags field of PANA 407 Header needs to be assigned by IANA. The new flag is bit 3 ('P're- 408 authentication). 410 8. Acknowledgments 412 The author would like to thank Alper Yegin and Ashutosh Dutta for 413 their valuable comments. 415 9. References 417 9.1 Normative References 419 [I-D.ietf-pana-pana] 420 Forsberg, D., "Protocol for Carrying Authentication for 421 Network Access (PANA)", draft-ietf-pana-pana-08 (work in 422 progress), May 2005. 424 9.2 Informative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, March 1997. 429 [I-D.ohba-mobopts-mpa-framework] 430 Ohba, Y., "A Framework of Media-Independent Pre- 431 Authentication (MPA)", draft-ohba-mobopts-mpa-framework-00 432 (work in progress), February 2005. 434 [I-D.ietf-pana-mobopts] 435 Forsberg, D., "PANA Mobility Optimizations", 436 draft-ietf-pana-mobopts-00 (work in progress), 437 January 2005. 439 [I-D.bournelle-pana-ctp] 440 Bournelle, J., "Use of Context Transfer Protocol (CxTP) 441 for PANA", draft-bournelle-pana-ctp-03 (work in progress), 442 June 2005. 444 [I-D.ietf-seamoby-ctp] 445 Loughney, J., "Context Transfer Protocol", 446 draft-ietf-seamoby-ctp-11 (work in progress), August 2004. 448 Author's Address 450 Yoshihiro Ohba 451 Toshiba America Research, Inc. 452 1 Telcordia Drive 453 Piscateway, NJ 08854 454 USA 456 Phone: +1 732 699 5365 457 Email: yohba@tari.toshiba.com 459 Intellectual Property Statement 461 The IETF takes no position regarding the validity or scope of any 462 Intellectual Property Rights or other rights that might be claimed to 463 pertain to the implementation or use of the technology described in 464 this document or the extent to which any license under such rights 465 might or might not be available; nor does it represent that it has 466 made any independent effort to identify any such rights. Information 467 on the procedures with respect to rights in RFC documents can be 468 found in BCP 78 and BCP 79. 470 Copies of IPR disclosures made to the IETF Secretariat and any 471 assurances of licenses to be made available, or the result of an 472 attempt made to obtain a general license or permission for the use of 473 such proprietary rights by implementers or users of this 474 specification can be obtained from the IETF on-line IPR repository at 475 http://www.ietf.org/ipr. 477 The IETF invites any interested party to bring to its attention any 478 copyrights, patents or patent applications, or other proprietary 479 rights that may cover technology that may be required to implement 480 this standard. Please address the information to the IETF at 481 ietf-ipr@ietf.org. 483 Disclaimer of Validity 485 This document and the information contained herein are provided on an 486 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 487 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 488 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 489 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 490 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 491 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 493 Copyright Statement 495 Copyright (C) The Internet Society (2005). This document is subject 496 to the rights, licenses and restrictions contained in BCP 78, and 497 except as set forth therein, the authors retain all their rights. 499 Acknowledgment 501 Funding for the RFC Editor function is currently provided by the 502 Internet Society.