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