idnits 2.17.1 draft-ietf-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 493. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 477. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 483. ** 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 12, 2005) is 6771 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 431, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pana-mobopts' is defined on line 436, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-10 == Outdated reference: A later version (-05) exists of draft-ohba-mobopts-mpa-framework-01 == 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 PANA Working Group Y. Ohba 3 Internet-Draft Toshiba 4 Expires: April 15, 2006 October 12, 2005 6 Pre-authentication Support for PANA 7 draft-ietf-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 April 15, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 17 61 Intellectual Property and Copyright Statements . . . . . . . . . . 18 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 In an access network where accounting is performed, accounting starts 384 when the pre-authentication SA becomes the active SA by default. 385 Depending on the pre-authorization policy, accounting may start 386 immediately after the pre-authentication SA is established. 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. Also, each access network that 396 supports pre-authentication SHOULD block pre-authentication attempts 397 from networks from which a handover is not likely to occur. 399 When pre-authentication is initiated by a remote PAA, it is possible 400 that the PaC simultaneously communicates with multiple remote PAAs 401 initiating pre-authentication. In order to avoid possible resource 402 consumption attacks on the PaC caused by a blind attacker initiating 403 pre-authentication for the PaC by changing source addresses, the PaC 404 SHOULD limit the maximum number of PAAs allowed to communicate. 406 7. IANA Considerations 408 As described in Section 4, a new flag in the Flags field of PANA 409 Header needs to be assigned by IANA. The new flag is bit 3 ('P're- 410 authentication). 412 8. Acknowledgments 414 The author would like to thank Alper Yegin, Ashutosh Dutta and Julien 415 Bournelle for their valuable comments. 417 9. References 419 9.1. Normative References 421 [I-D.ietf-pana-pana] 422 Forsberg, D., "Protocol for Carrying Authentication for 423 Network Access (PANA)", draft-ietf-pana-pana-10 (work in 424 progress), July 2005. 426 9.2. Informative References 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, March 1997. 431 [I-D.ohba-mobopts-mpa-framework] 432 Ohba, Y., "A Framework of Media-Independent Pre- 433 Authentication (MPA)", draft-ohba-mobopts-mpa-framework-01 434 (work in progress), July 2005. 436 [I-D.ietf-pana-mobopts] 437 Forsberg, D., "PANA Mobility Optimizations", 438 draft-ietf-pana-mobopts-00 (work in progress), 439 January 2005. 441 [I-D.bournelle-pana-ctp] 442 Bournelle, J., "Use of Context Transfer Protocol (CxTP) 443 for PANA", draft-bournelle-pana-ctp-03 (work in progress), 444 June 2005. 446 [I-D.ietf-seamoby-ctp] 447 Loughney, J., "Context Transfer Protocol", 448 draft-ietf-seamoby-ctp-11 (work in progress), August 2004. 450 Author's Address 452 Yoshihiro Ohba 453 Toshiba America Research, Inc. 454 1 Telcordia Drive 455 Piscateway, NJ 08854 456 USA 458 Phone: +1 732 699 5365 459 Email: yohba@tari.toshiba.com 461 Intellectual Property Statement 463 The IETF takes no position regarding the validity or scope of any 464 Intellectual Property Rights or other rights that might be claimed to 465 pertain to the implementation or use of the technology described in 466 this document or the extent to which any license under such rights 467 might or might not be available; nor does it represent that it has 468 made any independent effort to identify any such rights. Information 469 on the procedures with respect to rights in RFC documents can be 470 found in BCP 78 and BCP 79. 472 Copies of IPR disclosures made to the IETF Secretariat and any 473 assurances of licenses to be made available, or the result of an 474 attempt made to obtain a general license or permission for the use of 475 such proprietary rights by implementers or users of this 476 specification can be obtained from the IETF on-line IPR repository at 477 http://www.ietf.org/ipr. 479 The IETF invites any interested party to bring to its attention any 480 copyrights, patents or patent applications, or other proprietary 481 rights that may cover technology that may be required to implement 482 this standard. Please address the information to the IETF at 483 ietf-ipr@ietf.org. 485 Disclaimer of Validity 487 This document and the information contained herein are provided on an 488 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 489 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 490 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 491 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 492 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 493 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 495 Copyright Statement 497 Copyright (C) The Internet Society (2005). This document is subject 498 to the rights, licenses and restrictions contained in BCP 78, and 499 except as set forth therein, the authors retain all their rights. 501 Acknowledgment 503 Funding for the RFC Editor function is currently provided by the 504 Internet Society.