idnits 2.17.1 draft-ietf-pana-preauth-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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 401. 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 IETF Trust 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 24, 2008) is 5663 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) == Outdated reference: A later version (-12) exists of draft-ietf-hokey-preauth-ps-04 ** Downref: Normative reference to an Informational draft: draft-ietf-hokey-preauth-ps (ref. 'I-D.ietf-hokey-preauth-ps') Summary: 2 errors (**), 0 flaws (~~), 3 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 27, 2009 October 24, 2008 6 Pre-authentication Support for PANA 7 draft-ietf-pana-preauth-03 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 27, 2009. 34 Abstract 36 This document defines an extension to the Protocol for carrying 37 Authentication for Network Access (PANA) for proactively establishing 38 a PANA SA (Security Association) between a PaC in one access network 39 and a PAA in another access network to which the PaC may move. The 40 proposed method operates across multiple administrative domains. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 46 2. Terminogy . . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Pre-authentication Procedure . . . . . . . . . . . . . . . . . 4 48 4. PANA Extensions . . . . . . . . . . . . . . . . . . . . . . . 7 49 5. Authorization and Accounting Considerations . . . . . . . . . 8 50 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 51 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 52 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 53 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 54 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 55 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 Intellectual Property and Copyright Statements . . . . . . . . . . 10 59 1. Introduction 61 The Protocol for carrying Authentication for Network Access (PANA) 62 [RFC5191] carries EAP messages between a PaC (PANA Client) and a PAA 63 (PANA Authentication Agent) in the access network. If the PaC is a 64 mobile device and is capable of moving one access network to another 65 while running its applications, it is critical for the PaC to perform 66 a handover seamlessly without degrading the performance of the 67 applications during the handover period. When the handover requires 68 the PaC to establish a PANA session with the PAA in the new access 69 network, the signaling to establish the PANA session should be 70 completed as fast as possible. 72 This document defines an extension to the PANA protocol [RFC5191] 73 used for proactively executing EAP authentication and establishing a 74 PANA SA (Security Association) between a PaC in an access network and 75 a PAA in another access network to which the PaC may move. The 76 proposed method operates across multiple AAA domains. The extension 77 to the PANA protocol is designed to realize direct pre-authentication 78 defined in [I-D.ietf-hokey-preauth-ps]. 80 1.1. Specification of Requirements 82 In this document, several words are used to signify the requirements 83 of the specification. These words are often capitalized. The key 84 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 85 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 86 are to be interpreted as described in [RFC2119]. 88 2. Terminogy 90 The following terms are used in this document in addition to the 91 terms defined in [RFC5191]. 93 Serving PAA (SPAA): A PAA that resides in the serving network and 94 provides network access authentication for a particular PaC. For 95 simplicity, this document assumes that there is only one SPAA in 96 the serving network while the pre-authentication mechanism 97 described in this document is generally applicable to the case 98 where there are two or more SPAAs in the serving network. 100 Candidate PAA (CPAA): A PAA that resides in a candidate network to 101 which the PaC may move. A CPAA for a particular PaC may be a SPAA 102 for another PaC. 104 Pre-authentication: Pre-authentication refers to EAP pre- 105 authentication and defined as the utilization of EAP to pre- 106 establish EAP keying material on an authenticator prior to arrival 107 of the peer at the access network served by that authenticator 108 [I-D.ietf-hokey-preauth-ps]. In this draft, EAP pre- 109 authentication is performed between a PaC and a CPAA. 111 Pre-authorization: An authorization for a PaC, made by a CPAA for 112 the PaC at the time of pre-authentication. 114 Post-authorization: An authorization for a PaC, made by a CPAA for 115 the PaC when the CPAA becomes the SPAA for the PaC. 117 Pre-authorization SA: A PANA SA established between a PaC and its 118 CPAA. 120 Post-authorization SA: A PANA SA established between the PaC and its 121 SPAA. 123 3. Pre-authentication Procedure 125 A PaC that supports pre-authentication may establish a PANA session 126 for each CPAA. 128 There may be several mechanisms for a PaC and a CPAA to discover each 129 other. However, such mechanisms are out of the scope of this 130 document. 132 There may be a number of criteria for CPAA selection, the timing to 133 start pre-authentication and the timing to make a pre-authorization 134 SA a post-authorization SA (and hence the CPAA becomes the SPAA). 135 Such criteria can be implementation specific and thus are outside the 136 scope of this document. 138 Pre-authentication may be initiated by both a PaC and a CPAA. A new 139 'E' (prE-authentication) bit is defined in the PANA header. When 140 pre-authentication is performed, the 'E' (prE-authentication) bit of 141 PANA messages are set in order to indicate whether this PANA run is 142 for pre-authentication. Use of pre-authentication is negotiated as 143 follows. 145 o When a PaC initiates pre-authentication, it sends a PANA-Client- 146 Initiation (PCI) message with the 'E' (prE-authentication) bit 147 set. The PCI message MUST be unicast. The CPAA responds with a 148 PANA-Start-Request (PSR) message with the 'S' (Start) and 'E' 149 (prE-authentication) bits set only if it supports pre- 150 authentication. Otherwise, it MUST silently discard the message. 152 o When a CPAA initiates pre-authentication, it sends a PSR message 153 with the 'S' (Start) and 'E' (prE-authentication) bits set. The 154 PaC responds with a PANA-Start-Answer (PSA) message with the 'S' 155 (Start) and 'E' (prE-authentication) bits set only if it supports 156 pre-authentication. Otherwise, it MUST silently discard the 157 message. 159 o Once the PaC and CPAA have agreed on performing pre-authentication 160 using the 'S' (Start) and 'E' (prE-authentication) bits, the 161 subsequent PANA messages exchanged between them MUST have the 'E' 162 (prE-authentication) bit set. 164 When a CPAA with which the PaC has a pre-authorization SA becomes the 165 SPAA due to, e.g., movement of the PaC, the PaC performs an IP 166 address update procedure defined in Section 5.6 of [RFC5191] in order 167 to update the SPAA with the PaC's new address obtained from the new 168 serving network. PANA-Notification-Request (PNR) and PANA- 169 Notification-Answer (PNA) messages with 'P' (Ping) bit set are used 170 for this purpose. The completion of the IP address update procedure 171 will change the pre-authorization SA to a post-authorization SA. In 172 this case, the 'E' MUST NOT be set in the PNR and PNA messages and 173 subsequent PANA messages. 175 If there is another CPAA with which the PaC has a pre-authorization 176 SA and the PaC wants to keep the pre-authorization SA after the 177 change of SPAA, the PaC also performs an IP address update procedure 178 defined in Section 5.6 of [RFC5191] in order to update the CPAA with 179 the PaC's new address. PNR and PNA messages with 'P' (Ping) bit set 180 is used for this purpose. In this case, the 'E' (prE-authentication) 181 bit MUST be set in the PNR and PNA messages and subsequent PANA 182 messages. The IP address update procedure with the CPAA will not 183 change the pre-authorization SA to a post-authorization SA. 185 The pre-authorization SA and the corresponding PANA session between 186 the PaC and a CPAA is deleted by entering the termination phase of 187 the PANA protocol. 189 Example call flows for PaC-initiated pre-authentication and PAA- 190 initiated pre-authentication are shown in Figure 1 and Figure 2, 191 respectively. 193 PaC CPAA 194 | | 195 +------------------+ | 196 |Pre-authentication| | 197 |trigger | | 198 +------------------+ | 199 | PCI w/'E' bit set | 200 |------------------------------------------------>| 201 | PAR w/'S' and 'E' bits set | 202 |<------------------------------------------------| 203 | PAN w/'S' and 'E' bits set | 204 |------------------------------------------------>| 205 | PAR-PAN exchange w/'E' bit set | 206 |<----------------------------------------------->| 207 | +------------------+ 208 | |pre-authorization | 209 | +------------------+ 210 | PAR w/'C' and 'E' bits set | 211 |<------------------------------------------------| 212 | PAN w/'C' and 'E' bits set | 213 |------------------------------------------------>| 214 . . . 215 . . . 216 +----------+ | 217 | Movement | | 218 +----------+ | 219 | PNR w/ 'P' bit set and w/o 'E' bit set | 220 |------------------------------------------------>| 221 | +-------------------+ 222 | |post-authorization | 223 | |(CPAA becomes SPAA)| 224 | +-------------------+ 225 | PNA w/ 'P' bit set and w/o 'E' bit set | 226 |<------------------------------------------------| 227 | | 229 Figure 1: PaC-initiated Pre-authentication Call Flow 231 PaC CPAA 232 | | 233 | +------------------+ 234 | |Pre-authentication| 235 | |trigger | 236 | +------------------+ 237 | PAR w/'S' and 'E' bits set | 238 |<------------------------------------------------| 239 | PAN w/'S' and 'E' bits set | 240 |------------------------------------------------>| 241 | PAR-PAN exchange w/'E' bit set | 242 |<----------------------------------------------->| 243 | +------------------+ 244 | |pre-authorization | 245 | +------------------+ 246 | PAR w/'C' and 'E' bits set | 247 |<------------------------------------------------| 248 | PAN w/'C' and 'E' bits set | 249 |------------------------------------------------>| 250 . . . 251 . . . 252 +----------+ | 253 | Movement | | 254 +----------+ | 255 | PNR w/ 'P' bit set and w/o 'E' bit set | 256 |------------------------------------------------>| 257 | +-------------------+ 258 | |post-authorization | 259 | |(CPAA becomes SPAA)| 260 | +-------------------+ 261 | PNA w/ 'P' bit set and w/o 'E' bit set | 262 |<------------------------------------------------| 263 | | 265 Figure 2: PAA-initiated Pre-authentication Call Flow 267 4. PANA Extensions 269 A new 'E' (prE-authentication) bit is defined in Flags field of PANA 270 header as follows. 272 0 1 273 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 |R S C A P I E r r r r r r r r r| 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 E(PrE-authentication) When pre-authentication is performed, the 'E' 278 (prE-authentication) bit of PANA messages are set in order to 279 indicate whether this PANA run is for establishing a pre- 280 authorization SA. The exact usage of this bit is described in 281 Section 3. This bit is to be assigned by IANA. 283 5. Authorization and Accounting Considerations 285 A pre-authorization and a post-authorization for the PaC may have 286 different authorization policies. For example, the pre-authorization 287 policy may not allow the PaC to sent or receive packets through an 288 Enforcement Point (EP) that is under control of the CPAA, while both 289 the pre-authorization and post-authorization policies may allow 290 installing credentials to the EP, where the credentials are used for 291 establishing a security association for per-packet cryptographic 292 filtering. 294 In an access network where accounting is performed, accounting starts 295 when the pre-authorization SA becomes the post-authorization SA by 296 default. Depending on the pre-authorization policy, accounting may 297 start immediately after the pre-authorization SA is established. 299 6. Security Considerations 301 Since the mechanism described in this document is designed to work 302 across multiple access networks, each EP in the serving network 303 SHOULD be configured to allow PANA messages to be forwarded between a 304 PaC and a CPAA only if the PaC has a post-authorization SA with the 305 SPAA in order to avoid an unauthorized PaC to initiate pre- 306 authentication. Also, each access network that supports pre- 307 authentication SHOULD block pre-authentication attempts from networks 308 from which a handover is not likely to occur. 310 When pre-authentication is initiated by a CPAA, it is possible that 311 the PaC simultaneously communicates with multiple CPAAs initiating 312 pre-authentication. In order to avoid possible resource consumption 313 attacks on the PaC caused by a blind attacker initiating pre- 314 authentication for the PaC by changing source addresses, the PaC 315 SHOULD limit the maximum number of CPAAs allowed to communicate. 317 The pre-authentication mechanism defined in this document does not 318 have an issue on context binding in which link-layer independent 319 context carried over pre-authentication signaling is bound to the 320 link-layer specific context [I-D.ietf-hokey-preauth-ps], because the 321 same EAP transport protocol (i.e., PANA) is used for normal 322 authentication and pre-authentication in the candidate network. 324 7. IANA Considerations 326 As described in Section 4, bit 6 of the Flags field of PANA Header 327 needs to be assigned by IANA for the 'E' (prE-authentication) bit. 329 8. Acknowledgments 331 The author would like to thank Alper Yegin, Ashutosh Dutta, Julien 332 Bournelle and Sasikanth Bharadwaj for their valuable comments. 334 9. References 336 9.1. Normative References 338 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 339 Yegin, "Protocol for Carrying Authentication for Network 340 Access (PANA)", RFC 5191, May 2008. 342 [I-D.ietf-hokey-preauth-ps] 343 Ohba, Y., "EAP Pre-authentication Problem Statement", 344 draft-ietf-hokey-preauth-ps-04 (work in progress), 345 September 2008. 347 9.2. Informative References 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, March 1997. 352 Author's Address 354 Yoshihiro Ohba 355 Toshiba America Research, Inc. 356 1 Telcordia Drive 357 Piscateway, NJ 08854 358 USA 360 Phone: +1 732 699 5305 361 Email: yohba@tari.toshiba.com 363 Full Copyright Statement 365 Copyright (C) The IETF Trust (2008). 367 This document is subject to the rights, licenses and restrictions 368 contained in BCP 78, and except as set forth therein, the authors 369 retain all their rights. 371 This document and the information contained herein are provided on an 372 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 373 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 374 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 375 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 376 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 377 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 379 Intellectual Property 381 The IETF takes no position regarding the validity or scope of any 382 Intellectual Property Rights or other rights that might be claimed to 383 pertain to the implementation or use of the technology described in 384 this document or the extent to which any license under such rights 385 might or might not be available; nor does it represent that it has 386 made any independent effort to identify any such rights. Information 387 on the procedures with respect to rights in RFC documents can be 388 found in BCP 78 and BCP 79. 390 Copies of IPR disclosures made to the IETF Secretariat and any 391 assurances of licenses to be made available, or the result of an 392 attempt made to obtain a general license or permission for the use of 393 such proprietary rights by implementers or users of this 394 specification can be obtained from the IETF on-line IPR repository at 395 http://www.ietf.org/ipr. 397 The IETF invites any interested party to bring to its attention any 398 copyrights, patents or patent applications, or other proprietary 399 rights that may cover technology that may be required to implement 400 this standard. Please address the information to the IETF at 401 ietf-ipr@ietf.org.