idnits 2.17.1 draft-ietf-pana-preauth-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (December 3, 2008) is 5594 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 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 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 Intended status: Standards Track December 3, 2008 5 Expires: June 6, 2009 7 Pre-authentication Support for PANA 8 draft-ietf-pana-preauth-04 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on June 6, 2009. 33 Copyright Notice 35 Copyright (c) 2008 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 This document defines an extension to the Protocol for carrying 48 Authentication for Network Access (PANA) for proactively establishing 49 a PANA SA (Security Association) between a PaC in one access network 50 and a PAA in another access network to which the PaC may move. The 51 proposed method operates across multiple administrative domains. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 57 2. Terminogy . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Pre-authentication Procedure . . . . . . . . . . . . . . . . . 4 59 4. PANA Extensions . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Authorization and Accounting Considerations . . . . . . . . . . 8 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 63 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 66 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 The Protocol for carrying Authentication for Network Access (PANA) 72 [RFC5191] carries EAP messages between a PaC (PANA Client) and a PAA 73 (PANA Authentication Agent) in the access network. If the PaC is a 74 mobile device and is capable of moving one access network to another 75 while running its applications, it is critical for the PaC to perform 76 a handover seamlessly without degrading the performance of the 77 applications during the handover period. When the handover requires 78 the PaC to establish a PANA session with the PAA in the new access 79 network, the signaling to establish the PANA session should be 80 completed as fast as possible. 82 This document defines an extension to the PANA protocol [RFC5191] 83 used for proactively executing EAP authentication and establishing a 84 PANA SA (Security Association) between a PaC in an access network and 85 a PAA in another access network to which the PaC may move. The 86 proposed method operates across multiple AAA domains. The extension 87 to the PANA protocol is designed to realize direct pre-authentication 88 defined in [I-D.ietf-hokey-preauth-ps]. 90 1.1. Specification of Requirements 92 In this document, several words are used to signify the requirements 93 of the specification. These words are often capitalized. The key 94 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 95 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 96 are to be interpreted as described in [RFC2119]. 98 2. Terminogy 100 The following terms are used in this document in addition to the 101 terms defined in [RFC5191]. 103 Serving PAA (SPAA): A PAA that resides in the serving network and 104 provides network access authentication for a particular PaC. For 105 simplicity, this document assumes that there is only one SPAA in 106 the serving network while the pre-authentication mechanism 107 described in this document is generally applicable to the case 108 where there are two or more SPAAs in the serving network. 110 Candidate PAA (CPAA): A PAA that resides in a candidate network to 111 which the PaC may move. A CPAA for a particular PaC may be a SPAA 112 for another PaC. 114 Pre-authentication: Pre-authentication refers to EAP pre- 115 authentication and defined as the utilization of EAP to pre- 116 establish EAP keying material on an authenticator prior to arrival 117 of the peer at the access network served by that authenticator 118 [I-D.ietf-hokey-preauth-ps]. In this draft, EAP pre- 119 authentication is performed between a PaC and a CPAA. 121 Pre-authorization: An authorization for a PaC, made by a CPAA for 122 the PaC at the time of pre-authentication. 124 Post-authorization: An authorization for a PaC, made by a CPAA for 125 the PaC when the CPAA becomes the SPAA for the PaC. 127 Pre-authorization SA: A PANA SA established between a PaC and its 128 CPAA. 130 Post-authorization SA: A PANA SA established between the PaC and its 131 SPAA. 133 3. Pre-authentication Procedure 135 A PaC that supports pre-authentication may establish a PANA session 136 for each CPAA. 138 There may be several mechanisms for a PaC and a CPAA to discover each 139 other. However, such mechanisms are out of the scope of this 140 document. 142 There may be a number of criteria for CPAA selection, the timing to 143 start pre-authentication and the timing to make a pre-authorization 144 SA a post-authorization SA (and hence the CPAA becomes the SPAA). 145 Such criteria can be implementation specific and thus are outside the 146 scope of this document. 148 Pre-authentication may be initiated by both a PaC and a CPAA. A new 149 'E' (prE-authentication) bit is defined in the PANA header. When 150 pre-authentication is performed, the 'E' (prE-authentication) bit of 151 PANA messages are set in order to indicate whether this PANA run is 152 for pre-authentication. Use of pre-authentication is negotiated as 153 follows. 155 o When a PaC initiates pre-authentication, it sends a PANA-Client- 156 Initiation (PCI) message with the 'E' (prE-authentication) bit 157 set. The PCI message MUST be unicast. The CPAA responds with a 158 PANA-Auth-Request (PAR) message with the 'S' (Start) and 'E' (prE- 159 authentication) bits set only if it supports pre-authentication. 160 Otherwise, it MUST silently discard the message. 162 o When a CPAA initiates pre-authentication, it sends a PAR message 163 with the 'S' (Start) and 'E' (prE-authentication) bits set. The 164 PaC responds with a PANA-Auth-Answer (PAN) message with the 'S' 165 (Start) and 'E' (prE-authentication) bits set only if it supports 166 pre-authentication. Otherwise, it MUST silently discard the 167 message. 169 o Once the PaC and CPAA have agreed on performing pre-authentication 170 using the 'S' (Start) and 'E' (prE-authentication) bits, the 171 subsequent PANA messages exchanged between them MUST have the 'E' 172 (prE-authentication) bit set. 174 When a CPAA with which the PaC has a pre-authorization SA becomes the 175 SPAA due to, e.g., movement of the PaC, the PaC performs an IP 176 address update procedure defined in Section 5.6 of [RFC5191] in order 177 to update the SPAA with the PaC's new address obtained from the new 178 serving network. PANA-Notification-Request (PNR) and PANA- 179 Notification-Answer (PNA) messages with 'P' (Ping) bit set are used 180 for this purpose. The completion of the IP address update procedure 181 will change the pre-authorization SA to a post-authorization SA. In 182 this case, the 'E' MUST NOT be set in the PNR and PNA messages and 183 subsequent PANA messages. 185 If there is another CPAA with which the PaC has a pre-authorization 186 SA and the PaC wants to keep the pre-authorization SA after the 187 change of SPAA, the PaC also performs an IP address update procedure 188 defined in Section 5.6 of [RFC5191] in order to update the CPAA with 189 the PaC's new address. PNR and PNA messages with 'P' (Ping) bit set 190 is used for this purpose. In this case, the 'E' (prE-authentication) 191 bit MUST be set in the PNR and PNA messages and subsequent PANA 192 messages. The IP address update procedure with the CPAA will not 193 change the pre-authorization SA to a post-authorization SA. 195 The pre-authorization SA and the corresponding PANA session between 196 the PaC and a CPAA is deleted by entering the termination phase of 197 the PANA protocol. 199 Example call flows for PaC-initiated pre-authentication and PAA- 200 initiated pre-authentication are shown in Figure 1 and Figure 2, 201 respectively. 203 PaC CPAA 204 | | 205 +------------------+ | 206 |Pre-authentication| | 207 |trigger | | 208 +------------------+ | 209 | PCI w/'E' bit set | 210 |------------------------------------------------>| 211 | PAR w/'S' and 'E' bits set | 212 |<------------------------------------------------| 213 | PAN w/'S' and 'E' bits set | 214 |------------------------------------------------>| 215 | PAR-PAN exchange w/'E' bit set | 216 |<----------------------------------------------->| 217 | +------------------+ 218 | |pre-authorization | 219 | +------------------+ 220 | PAR w/'C' and 'E' bits set | 221 |<------------------------------------------------| 222 | PAN w/'C' and 'E' bits set | 223 |------------------------------------------------>| 224 . . . 225 . . . 226 +----------+ | 227 | Movement | | 228 +----------+ | 229 | PNR w/ 'P' bit set and w/o 'E' bit set | 230 |------------------------------------------------>| 231 | +-------------------+ 232 | |post-authorization | 233 | |(CPAA becomes SPAA)| 234 | +-------------------+ 235 | PNA w/ 'P' bit set and w/o 'E' bit set | 236 |<------------------------------------------------| 237 | | 239 Figure 1: PaC-initiated Pre-authentication Call Flow 241 PaC CPAA 242 | | 243 | +------------------+ 244 | |Pre-authentication| 245 | |trigger | 246 | +------------------+ 247 | PAR w/'S' and 'E' bits set | 248 |<------------------------------------------------| 249 | PAN w/'S' and 'E' bits set | 250 |------------------------------------------------>| 251 | PAR-PAN exchange w/'E' bit set | 252 |<----------------------------------------------->| 253 | +------------------+ 254 | |pre-authorization | 255 | +------------------+ 256 | PAR w/'C' and 'E' bits set | 257 |<------------------------------------------------| 258 | PAN w/'C' and 'E' bits set | 259 |------------------------------------------------>| 260 . . . 261 . . . 262 +----------+ | 263 | Movement | | 264 +----------+ | 265 | PNR w/ 'P' bit set and w/o 'E' bit set | 266 |------------------------------------------------>| 267 | +-------------------+ 268 | |post-authorization | 269 | |(CPAA becomes SPAA)| 270 | +-------------------+ 271 | PNA w/ 'P' bit set and w/o 'E' bit set | 272 |<------------------------------------------------| 273 | | 275 Figure 2: PAA-initiated Pre-authentication Call Flow 277 4. PANA Extensions 279 A new 'E' (prE-authentication) bit is defined in Flags field of PANA 280 header as follows. 282 0 1 283 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 |R S C A P I E r r r r r r r r r| 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 E(PrE-authentication) When pre-authentication is performed, the 'E' 288 (prE-authentication) bit of PANA messages are set in order to 289 indicate whether this PANA run is for establishing a pre- 290 authorization SA. The exact usage of this bit is described in 291 Section 3. This bit is to be assigned by IANA. 293 5. Authorization and Accounting Considerations 295 A pre-authorization and a post-authorization for the PaC may have 296 different authorization policies. For example, the pre-authorization 297 policy may not allow the PaC to sent or receive packets through an 298 Enforcement Point (EP) that is under control of the CPAA, while both 299 the pre-authorization and post-authorization policies may allow 300 installing credentials to the EP, where the credentials are used for 301 establishing a security association for per-packet cryptographic 302 filtering. 304 In an access network where accounting is performed, accounting starts 305 when the pre-authorization SA becomes the post-authorization SA by 306 default. Depending on the pre-authorization policy, accounting may 307 start immediately after the pre-authorization SA is established. 309 6. Security Considerations 311 Since the mechanism described in this document is designed to work 312 across multiple access networks, each EP in the serving network 313 SHOULD be configured to allow PANA messages to be forwarded between a 314 PaC and a CPAA only if the PaC has a post-authorization SA with the 315 SPAA in order to avoid an unauthorized PaC to initiate pre- 316 authentication. Also, each access network that supports pre- 317 authentication SHOULD block pre-authentication attempts from networks 318 from which a handover is not likely to occur. 320 When pre-authentication is initiated by a CPAA, it is possible that 321 the PaC simultaneously communicates with multiple CPAAs initiating 322 pre-authentication. In order to avoid possible resource consumption 323 attacks on the PaC caused by a blind attacker initiating pre- 324 authentication for the PaC by changing source addresses, the PaC 325 SHOULD limit the maximum number of CPAAs allowed to communicate. 327 The pre-authentication mechanism defined in this document does not 328 have an issue on context binding in which link-layer independent 329 context carried over pre-authentication signaling is bound to the 330 link-layer specific context [I-D.ietf-hokey-preauth-ps], because the 331 same EAP transport protocol (i.e., PANA) is used for normal 332 authentication and pre-authentication in the candidate network. 334 7. IANA Considerations 336 As described in Section 4, bit 6 of the Flags field of PANA Header 337 needs to be assigned by IANA for the 'E' (prE-authentication) bit. 339 8. Acknowledgments 341 The author would like to thank Alper Yegin, Ashutosh Dutta, Julien 342 Bournelle and Sasikanth Bharadwaj for their valuable comments. 344 9. References 346 9.1. Normative References 348 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 349 Yegin, "Protocol for Carrying Authentication for Network 350 Access (PANA)", RFC 5191, May 2008. 352 9.2. Informative References 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, March 1997. 357 [I-D.ietf-hokey-preauth-ps] 358 Ohba, Y., "EAP Pre-authentication Problem Statement", 359 draft-ietf-hokey-preauth-ps-04 (work in progress), 360 September 2008. 362 Author's Address 364 Yoshihiro Ohba 365 Toshiba America Research, Inc. 366 1 Telcordia Drive 367 Piscateway, NJ 08854 368 USA 370 Phone: +1 732 699 5305 371 Email: yohba@tari.toshiba.com