idnits 2.17.1 draft-ietf-pana-mobopts-01.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 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 340. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 21, 2005) is 6762 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.irtf-aaaarch-handoff' is defined on line 268, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-07 == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-10 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Forsberg (Ed.) 3 Internet-Draft Nokia 4 Expires: April 24, 2006 Y. Ohba 5 Toshiba 6 B. Patil 7 Nokia 8 H. Tschofenig 9 Siemens 10 A. Yegin 11 Samsung 12 October 21, 2005 14 PANA Mobility Optimizations 15 draft-ietf-pana-mobopts-01.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on April 24, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 This specification describes PANA optimizations for handling 49 mobility. Proposed optimizations aim reducing protocol latency and 50 signaling associated with PANA-based network access AAA. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 56 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 6 58 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 59 6. Keying Considerations . . . . . . . . . . . . . . . . . . . . 9 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 63 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 65 Intellectual Property and Copyright Statements . . . . . . . . . . 14 67 1. Introduction 69 A PaC using PANA [I-D.ietf-pana-pana] MUST execute full EAP/PANA upon 70 inter-subnet (inter-PAA) movement. In case seamless mobility is 71 desirable, having to execute full EAP authentication with a AAA 72 server would incur undesirable latency. This document outlines the 73 required extensions to the base PANA specification to eliminate the 74 need to execute EAP each time the PaC performs an inter-PAA handover. 76 The scheme described in this document allows creation of a new PANA 77 session with a new PAA based on an existing session with another PAA. 78 Generation of the new PANA session does not require executing EAP- 79 based authentication. Instead, a context-transfer-based scheme is 80 used to bring in relevant state information from the previous PAA to 81 the new PAA. 83 It should be noted that this document is limited to describing AAA 84 optimizations on the PANA protocol. Additional optimizations aiming 85 at EAP or specific AAA backend protocols (e.g., RADIUS, Diameter) can 86 be defined independently. Furthermore, specification of the required 87 context-transfer mechanism is left to other documents 88 ([I-D.bournelle-pana-ctp]). 90 2. Requirements notation 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 3. Framework 98 The call flow depicting mobility-optimized PANA execution is shown 99 below. 101 PaC newPAA prePAA 102 | | | 103 1 |<---------- live PANA session ----------->| 104 | | | 105 2 x move from subnet1 | | 106 | to subnet2 | | 107 | | | 108 | PDI | | 109 3 |---------------------->| | 110 | PSR | | 111 4 |<----------------------| | 112 | PSA | | 113 5 |---------------------->| CT-req | 114 6 | |----------------->| 115 | | CT-resp | 116 7 | PBR |<-----------------| 117 8 |<----------------------| | 118 | PBA | | 119 9 |---------------------->| | 121 In this flow, the PaC is already authorized and connected to subnet1, 122 where prePAA resides (step 1). Later, the PaC performs a handover 123 from subnet1 to subnet2 (step 2). Following the movement, PANA 124 discovery and handshake phases are executed (steps 3-5). In response 125 to the parameters included in the PSA, PANA session context is 126 transferred from the prePAA to the newPAA (steps 6,7). Finally, 127 PANA-Bind exchange signals the successful PANA authorization (steps 128 8,9). In this flow, EAP authentication does not take place. 130 4. Protocol Details 132 A mobile PaC's network access authentication performance can be 133 enhanced by deploying a context-transfer-based mechanism, where some 134 session attributes are transferred from the previous PAA to the new 135 one in order to avoid performing a full EAP authentication (reactive 136 approach). Additional mechanisms that are based on the proactive AAA 137 state establishment at one or more candidate PAAs may be developed in 138 the future (see for example [I-D.irtf-aaaarch-handoff]'). The 139 details of a context-transfer-based mechanism is provided in this 140 section. 142 Upon changing its point of attachment, a PaC that wants to quickly 143 resume its ongoing PANA session without running EAP MAY send its 144 unexpired PANA session identifier in its PANA-Start-Answer message. 145 Along with the Session-Id AVP, a MAC AVP MUST be included in this 146 message. The MAC AVP is computed by using the PANA_MAC_KEY shared 147 between the PaC and its previous PAA that has an unexpired PANA 148 session with the PaC. This action signals the PaC's desire to 149 perform the mobility optimization. In the absence of a Session-Id 150 AVP in this message, the PANA session takes its usual course (i.e., 151 EAP-based authentication is performed). 153 If a PAA receives a session identifier in the PANA-Start-Answer 154 message, and it is configured to enable this optimization, it SHOULD 155 retrieve the PANA session attributes from the previous PAA. The 156 identity of the previous PAA is determined by looking at the 157 DiameterIdentity part of the PANA session identifier. The MAC AVP 158 can only be verified by the previous PAA, therefore a copy of the 159 PANA message MUST be provided to the previous PAA. The mechanism 160 required to send a copy of the PANA-Start-Answer message from current 161 PAA to the previous PAA, and to retrieve the session attributes is 162 outside the scope of PANA protocol. The Context Transfer Protocol 163 [I-D.ietf-seamoby-ctp] might be useful for this purpose. 165 When the previous or current PAA is not configured to enable this 166 optimization, the current PAA can not retrieve the PANA session 167 attributes, or the PANA session has already expired (i.e., session 168 lifetime is zero), the PAA MUST send the PANA-Auth-Request message 169 with a new session identifier and let the PANA exchange take its 170 usual course. As a result the PaC will engage in EAP-based 171 authentication and create a fresh PANA session from scratch. 173 In case the current PAA can retrieve the on-going PANA session 174 attributes from the previous PAA, the PANA session continues with a 175 PANA-Bind exchange. 177 As part of the context transfer, an intermediate AAA-Key material is 178 provided by the previous PAA to the current PAA. 180 AAA-Key-int = The first N bits of 181 HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) 183 The value of N depends on the integrity protection algorithm in use, 184 i.e., N=160 for HMAC-SHA1. DiameterIdentity is the identifier of the 185 current (new) PAA. Session-ID is the identifier of the PaC's PANA 186 session with the previous PAA. 188 The current PAA and the PaC compute the new AAA-Key by using the 189 nonce values and the AAA-Key-int. 191 AAA-Key-new = The first N bits of 192 HMAC-SHA1(AAA-Key-int, PaC_nonce | PAA_nonce) 194 New PANA_MAC_KEY is computed based on the algorithm described in 195 [I-D.ietf-pana-pana], by using the new AAA-Key and the new Session-ID 196 assigned by the current PAA. The MAC AVP contained in the PANA-Bind- 197 Request and PANA-Bind-Answer messages MUST be generated and verified 198 by using the new PANA_MAC_KEY. The Session-ID AVP MUST include a new 199 session identifier assigned by the current PAA. A new PANA session 200 is created upon successful completion of this exchange. 202 5. Deployment Considerations 204 Correct operation of this optimization relies on many factors, 205 including applicability of authorization state from one network 206 attachment to another. [I-D.ietf-eap-keying] identifies this 207 operation as "fast handoff" and provides deployment considerations. 208 Operators are recommended to take those guidelines into account when 209 using this optimization in their networks. 211 6. Keying Considerations 213 Upon PaC's movement to a another PAA (new PAA) and request to perform 214 a context transfer based optimization, the previous PAA computes a 215 AAA-Key-int based on the AAA-Key, ID of new PAA, and the session ID. 216 This AAA-Key-int is delivered to the new PAA, and used in the 217 computation of the AAA-Key-new, which further takes a pair of nonce 218 values into account. After this point on, the AAA-Key-new becomes 219 the AAA-Key between the PaC and the new PAA. 221 The AAA-Key-int can be deleted as soon as AAA-Key-new is derived. 222 The lifetime of AAA-Key-new is bounded by the lifetime of AAA-Key. 224 7. Security Considerations 226 The mobility optimization described in this document involves the 227 previous PAA (possessing the AAA-Key) providing a AAA-Key-new to the 228 current PAA of the PaC. There are security risks stemming from 229 potential compromise of PAAs. Compromise of the current PAA does not 230 yield compromise of the previous PAA, as the AAA-Key cannot be 231 computed from a compromised AAA-Key-new. But a compromised previous 232 PAA along with the intercepted nonce values on the current link leads 233 to the compromise of AAA-Key-new. Operators should be aware of the 234 potential risk of using this optimization. 236 An operator can reduce the risk exposure by forcing the PaC to 237 perform an EAP-based authentication immediately after the PaC gains 238 access to new link via the optimized PANA execution. 240 8. References 242 8.1. Normative References 244 [I-D.ietf-eap-keying] 245 Aboba, B., "Extensible Authentication Protocol (EAP) Key 246 Management Framework", draft-ietf-eap-keying-07 (work in 247 progress), July 2005. 249 [I-D.ietf-pana-pana] 250 Forsberg, D., "Protocol for Carrying Authentication for 251 Network Access (PANA)", draft-ietf-pana-pana-10 (work in 252 progress), July 2005. 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, March 1997. 257 8.2. Informative References 259 [I-D.bournelle-pana-ctp] 260 Bournelle, J., "Use of Context Transfer Protocol (CxTP) 261 for PANA", draft-bournelle-pana-ctp-03 (work in progress), 262 June 2005. 264 [I-D.ietf-seamoby-ctp] 265 Loughney, J., "Context Transfer Protocol", 266 draft-ietf-seamoby-ctp-11 (work in progress), August 2004. 268 [I-D.irtf-aaaarch-handoff] 269 Arbaugh, W. and B. Aboba, "Experimental Handoff Extension 270 to RADIUS", draft-irtf-aaaarch-handoff-04 (work in 271 progress), November 2003. 273 Authors' Addresses 275 Dan Forsberg 276 Nokia Research Center 277 P.O. Box 407 278 FIN-00045 NOKIA GROUP 279 Finland 281 Phone: +358 50 4839470 282 Email: dan.forsberg@nokia.com 284 Yoshihiro Ohba 285 Toshiba America Research, Inc. 286 1 Telcordia Drive 287 Piscataway, NJ 08854 288 USA 290 Phone: +1 732 699 5305 291 Email: yohba@tari.toshiba.com 293 Basavaraj Patil 294 Nokia 295 6000 Connection Dr. 296 Irving, TX 75039 297 USA 299 Phone: +1 972-894-6709 300 Email: Basavaraj.Patil@nokia.com 302 Hannes Tschofenig 303 Siemens Corporate Technology 304 Otto-Hahn-Ring 6 305 81739 Munich 306 Germany 308 Email: Hannes.Tschofenig@siemens.com 309 Alper E. Yegin 310 Samsung Advanced Institute of Technology 311 75 West Plumeria Drive 312 San Jose, CA 95134 313 USA 315 Phone: +1 408 544 5656 316 Email: alper.yegin@samsung.com 318 Intellectual Property Statement 320 The IETF takes no position regarding the validity or scope of any 321 Intellectual Property Rights or other rights that might be claimed to 322 pertain to the implementation or use of the technology described in 323 this document or the extent to which any license under such rights 324 might or might not be available; nor does it represent that it has 325 made any independent effort to identify any such rights. Information 326 on the procedures with respect to rights in RFC documents can be 327 found in BCP 78 and BCP 79. 329 Copies of IPR disclosures made to the IETF Secretariat and any 330 assurances of licenses to be made available, or the result of an 331 attempt made to obtain a general license or permission for the use of 332 such proprietary rights by implementers or users of this 333 specification can be obtained from the IETF on-line IPR repository at 334 http://www.ietf.org/ipr. 336 The IETF invites any interested party to bring to its attention any 337 copyrights, patents or patent applications, or other proprietary 338 rights that may cover technology that may be required to implement 339 this standard. Please address the information to the IETF at 340 ietf-ipr@ietf.org. 342 Disclaimer of Validity 344 This document and the information contained herein are provided on an 345 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 346 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 347 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 348 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 349 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 350 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 352 Copyright Statement 354 Copyright (C) The Internet Society (2005). This document is subject 355 to the rights, licenses and restrictions contained in BCP 78, and 356 except as set forth therein, the authors retain all their rights. 358 Acknowledgment 360 Funding for the RFC Editor function is currently provided by the 361 Internet Society.