idnits 2.17.1 draft-ietf-pana-mobopts-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 3667, Section 5.1 on line 21. -- 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. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 356), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 == Line 75 has weird spacing: '...ocument allow...' == Line 225 has weird spacing: '...ocument invol...' -- 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 (January 17, 2005) is 7039 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-04 == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-07 == Outdated reference: A later version (-03) exists of draft-bournelle-pana-ctp-01 Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Forsberg 2 Internet-Draft Nokia 3 Expires: July 18, 2005 Y. Ohba 4 Toshiba 5 B. Patil 6 Nokia 7 H. Tschofenig 8 Siemens 9 A. Yegin (Ed.) 10 Samsung 11 January 17, 2005 13 PANA Mobility Optimizations 14 draft-ietf-pana-mobopts-00.txt 16 Status of this Memo 18 By submitting this Internet-Draft, I certify that any applicable 19 patent or other IPR claims of which I am aware have been disclosed, 20 and any of which I become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on July 18, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). All Rights Reserved. 45 Abstract 47 This specification describes PANA optimizations for handling 48 mobility. Proposed optimizations aim reducing protocol latency and 49 signaling associated with PANA-based network access AAA. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 55 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 58 6. Keying Considerations . . . . . . . . . . . . . . . . . . . . 9 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 62 8.2 Informative References . . . . . . . . . . . . . . . . . . . 11 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 64 Intellectual Property and Copyright Statements . . . . . . . . 13 66 1. Introduction 68 A PaC using PANA [I-D.ietf-pana-pana] MUST execute full EAP/PANA 69 upon inter-subnet (inter-PAA) movement. In case seamless mobility is 70 desirable, having to execute full EAP authentication with a AAA 71 server would incur undesirable latency. This document outlines the 72 required extensions to the base PANA specification to eliminate the 73 need to execute EAP each time the PaC performs an inter-PAA handover. 75 The scheme described in this document allows creation of a new PANA 76 session with a new PAA based on an existing session with another PAA. 77 Generation of the new PANA session does not require executing 78 EAP-based authentication. Instead, a context-transfer-based scheme 79 is used to bring in relevant state information from the previous PAA 80 to the new PAA. 82 It should be noted that this document is limited to describing AAA 83 optimizations on the PANA protocol. Additional optimizations aiming 84 at EAP or specific AAA backend protocols (e.g., RADIUS, Diameter) can 85 be defined independently. Furthermore, specification of the required 86 context-transfer mechanism is left to other documents 87 ([I-D.bournelle-pana-ctp]). 89 2. Requirements notation 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 3. Framework 97 The call flow depicting mobility-optimized PANA execution is shown 98 below. 100 PaC newPAA prePAA 101 | | | 102 1 |<---------- live PANA session ----------->| 103 | | | 104 2 x move from subnet1 | | 105 | to subnet2 | | 106 | | | 107 | PDI | | 108 3 |---------------------->| | 109 | PSR | | 110 4 |<----------------------| | 111 | PSA | | 112 5 |---------------------->| CT-req | 113 6 | |----------------->| 114 | | CT-resp | 115 7 | PBR |<-----------------| 116 8 |<----------------------| | 117 | PBA | | 118 9 |---------------------->| | 120 In this flow, the PaC is already authorized and connected to subnet1, 121 where prePAA resides (step 1). Later, the PaC performs a handover 122 from subnet1 to subnet2 (step 2). Following the movement, PANA 123 discovery and handshake phases are executed (steps 3-5). In response 124 to the parameters included in the PSA, PANA session context is 125 transferred from the prePAA to the newPAA (steps 6,7). Finally, 126 PANA-Bind exchange signals the successful PANA authorization (steps 127 8,9). In this flow, EAP authentication does not take place. 129 4. Protocol Details 131 A mobile PaC's network access authentication performance can be 132 enhanced by deploying a context-transfer-based mechanism, where some 133 session attributes are transferred from the previous PAA to the new 134 one in order to avoid performing a full EAP authentication (reactive 135 approach). Additional mechanisms that are based on the proactive AAA 136 state establishment at one or more candidate PAAs may be developed in 137 the future (see for example [I-D.irtf-aaaarch-handoff]'). The 138 details of a context-transfer-based mechanism is provided in this 139 section. 141 Upon changing its point of attachment, a PaC that wants to quickly 142 resume its ongoing PANA session without running EAP MAY send its 143 unexpired PANA session identifier in its PANA-Start-Answer message. 144 Along with the Session-Id AVP, a MAC AVP MUST be included in this 145 message. The MAC AVP is computed by using the PANA_MAC_KEY shared 146 between the PaC and its previous PAA that has an unexpired PANA 147 session with the PaC. This action signals the PaC's desire to 148 perform the mobility optimization. In the absence of a Session-Id 149 AVP in this message, the PANA session takes its usual course (i.e., 150 EAP-based authentication is performed). 152 If a PAA receives a session identifier in the PANA-Start-Answer 153 message, and it is configured to enable this optimization, it SHOULD 154 retrieve the PANA session attributes from the previous PAA. The 155 identity of the previous PAA is determined by looking at the 156 DiameterIdentity part of the PANA session identifier. The MAC AVP 157 can only be verified by the previous PAA, therefore a copy of the 158 PANA message MUST be provided to the previous PAA. The mechanism 159 required to send a copy of the PANA-Start-Answer message from current 160 PAA to the previous PAA, and to retrieve the session attributes is 161 outside the scope of PANA protocol. The Context Transfer Protocol 162 [I-D.ietf-seamoby-ctp] might be useful for this purpose. 164 When the previous or current PAA is not configured to enable this 165 optimization, the current PAA can not retrieve the PANA session 166 attributes, or the PANA session has already expired (i.e., session 167 lifetime is zero), the PAA MUST send the PANA-Auth-Request message 168 with a new session identifier and let the PANA exchange take its 169 usual course. As a result the PaC will engage in EAP-based 170 authentication and create a fresh PANA session from scratch. 172 In case the current PAA can retrieve the on-going PANA session 173 attributes from the previous PAA, the PANA session continues with a 174 PANA-Bind exchange. 176 As part of the context transfer, an intermediate AAA-Key material is 177 provided by the previous PAA to the current PAA. 179 AAA-Key-int = The first N bits of 180 HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) 182 The value of N depends on the integrity protection algorithm in use, 183 i.e., N=160 for HMAC-SHA1. DiameterIdentity is the identifier of the 184 current (new) PAA. Session-ID is the identifier of the PaC's PANA 185 session with the previous PAA. 187 The current PAA and the PaC compute the new AAA-Key by using the 188 nonce values and the AAA-Key-int. 190 AAA-Key-new = The first N bits of 191 HMAC-SHA1(AAA-Key-int, PaC_nonce | PAA_nonce) 193 New PANA_MAC_KEY is computed based on the algorithm described in 194 [I-D.ietf-pana-pana], by using the new AAA-Key and the new Session-ID 195 assigned by the current PAA. The MAC AVP contained in the 196 PANA-Bind-Request and PANA-Bind-Answer messages MUST be generated and 197 verified by using the new PANA_MAC_KEY. The Session-ID AVP MUST 198 include a new session identifier assigned by the current PAA. A new 199 PANA session is created upon successful completion of this exchange. 201 5. Deployment Considerations 203 Correct operation of this optimization relies on many factors, 204 including applicability of authorization state from one network 205 attachment to another. [I-D.ietf-eap-keying] identifies this 206 operation as "fast handoff" and provides deployment considerations. 207 Operators are recommended to take those guidelines into account when 208 using this optimization in their networks. 210 6. Keying Considerations 212 Upon PaC's movement to a another PAA (new PAA) and request to perform 213 a context transfer based optimization, the previous PAA computes a 214 AAA-Key-int based on the AAA-Key, ID of new PAA, and the session ID. 215 This AAA-Key-int is delivered to the new PAA, and used in the 216 computation of the AAA-Key-new, which further takes a pair of nonce 217 values into account. After this point on, the AAA-Key-new becomes 218 the AAA-Key between the PaC and the new PAA. 220 The AAA-Key-int can be deleted as soon as AAA-Key-new is derived. 221 The lifetime of AAA-Key-new is bounded by the lifetime of AAA-Key. 223 7. Security Considerations 225 The mobility optimization described in this document involves the 226 previous PAA (possessing the AAA-Key) providing a AAA-Key-new to the 227 current PAA of the PaC. There are security risks stemming from 228 potential compromise of PAAs. Compromise of the current PAA does not 229 yield compromise of the previous PAA, as the AAA-Key cannot be 230 computed from a compromised AAA-Key-new. But a compromised previous 231 PAA along with the intercepted nonce values on the current link leads 232 to the compromise of AAA-Key-new. Operators should be aware of the 233 potential risk of using this optimization. 235 An operator can reduce the risk exposure by forcing the PaC to 236 perform an EAP-based authentication immediately after the PaC gains 237 access to new link via the optimized PANA execution. 239 8. References 241 8.1 Normative References 243 [I-D.ietf-eap-keying] 244 Aboba, B., "Extensible Authentication Protocol (EAP) Key 245 Management Framework", draft-ietf-eap-keying-04 (work in 246 progress), November 2004. 248 [I-D.ietf-pana-pana] 249 Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. 250 Yegin, "Protocol for Carrying Authentication for Network 251 Access (PANA)", draft-ietf-pana-pana-07 (work in 252 progress), December 2004. 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 (CTP) for 261 PANA", draft-bournelle-pana-ctp-01 (work in progress), 262 October 2004. 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 283 Yoshihiro Ohba 284 Toshiba America Research, Inc. 285 1 Telcordia Drive 286 Piscataway, NJ 08854 287 USA 289 Phone: +1 732 699 5305 290 EMail: yohba@tari.toshiba.com 292 Basavaraj Patil 293 Nokia 294 6000 Connection Dr. 295 Irving, TX 75039 296 USA 298 Phone: +1 972-894-6709 299 EMail: Basavaraj.Patil@nokia.com 301 Hannes Tschofenig 302 Siemens Corporate Technology 303 Otto-Hahn-Ring 6 304 81739 Munich 305 Germany 307 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.