idnits 2.17.1 draft-ietf-mip6-aaa-ha-goals-01.txt: -(81): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 436. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 443. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 463), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** 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 seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There are 2 instances of lines with non-ascii characters in the document. == 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 Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 5. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 263 instances of too long lines in the document, the longest one being 14 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (January 2006) is 6673 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) -- Missing reference section? '1' on line 348 looks like a reference -- Missing reference section? '2' on line 351 looks like a reference -- Missing reference section? '3' on line 356 looks like a reference -- Missing reference section? '4' on line 359 looks like a reference -- Missing reference section? '5' on line 363 looks like a reference -- Missing reference section? '6' on line 367 looks like a reference -- Missing reference section? '7' on line 370 looks like a reference -- Missing reference section? '8' on line 374 looks like a reference -- Missing reference section? '9' on line 377 looks like a reference -- Missing reference section? '10' on line 381 looks like a reference -- Missing reference section? '11' on line 384 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group G. Giaretta 3 Internet Draft I. Guardini 4 Expires: July 2006 E. Demaria 5 TILab 6 J. Bournelle 7 GET/INT 8 R. Lopez 9 Univ. of Murcia 10 January 2006 12 Goals for AAA-HA interface 13 draft-ietf-mip6-aaa-ha-goals-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that 18 any applicable patent or other IPR claims of which he or she is 19 aware have been or will be disclosed, and any of which he or she 20 becomes aware will be disclosed, in accordance with Section 6 of 21 BCP 79. 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 Internet- 26 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on July 27, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). All Rights Reserved. 44 Abstract 46 In commercial deployments Mobile IPv6 can be a service offered by a 47 Mobility Services Provider (MSP). In this case all protocol 48 operations may need to be explicitly authorized and traced, 49 requiring the interaction between Mobile IPv6 and the AAA 50 infrastructure. Integrating the AAA infrastructure offers also a 51 solution component for Mobile IPv6 bootstrapping in integrated and 52 This document describes various scenarios where a AAA interface for 53 Mobile IPv6 is actually required. Additionally, it lists design 54 goals and requirements for such an interface. 56 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC-2119 [1]. 62 Table of Contents 64 1. Introduction................................................3 65 2. Motivation..................................................4 66 3. Bootstrapping scenarios.....................................5 67 3.1 Split Scenario...........................................5 68 3.2 Integrated Scenario......................................6 69 4. Goals for the AAA-HA interface..............................7 70 4.1 General goals............................................7 71 4.2 Service Authorization....................................7 72 4.3 Accounting...............................................8 73 4.4 Mobile Node Authentication...............................8 74 4.5 Provisioning of configuration parameters.................8 75 5. IANA Considerations.........................................9 76 6. Security Considerations....................................10 77 7. Acknowledgment.............................................11 78 8. References.................................................12 79 8.1 Normative References....................................12 80 8.2 Informative References..................................12 81 Authors� Addresses..............................................13 82 1. Introduction 84 Mobile IPv6 [2] was originally designed as a protocol without any 85 integration with the AAA infrastructure of the Mobility Service 86 Provider (MSP) that offers mobility service. Nonetheless, in some 87 environments it might be desirable to authenticate the user based on 88 existing credentials stored in the AAA infrastructure, to authorize 89 protocol operations and to enable accounting. Due to this 90 requirement, Mobile IPv6 might require the interaction with the AAA 91 infrastructure. Integrating the AAA infrastructure offers also a 92 solution component for Mobile IPv6 bootstrapping [3] in split [4] 93 and integrated [5] scenarios. 95 This document describes various scenarios where a AAA interface is 96 required. Additionally, it lists design goals and requirements for 97 such an interface. 99 This document only describes requirements, goals and scenarios. It 100 does not provide solutions. 102 Notice that this document builds on the security model of the AAA 103 infrastructure. As such, the end host shares credentials with the 104 home AAA server and the communication between the AAA server and 105 the AAA client can be protected. If the AAA server and the AAA 106 client are not part of the same administrative domain, then some 107 sort of contractual relationship between the involved administrative 108 domains is typically in place in form of roaming agreements. 110 2. Motivation 112 Mobile IPv6 specification [2] requires that Mobile Nodes (MNs) are 113 provisioned with a set of configuration parameters, namely the Home 114 Address and the Home Agent Address, in order to accomplish a home 115 registration. Moreover MNs and Home Agents (HAs) must share the 116 cryptographic material needed to protect Mobile IPv6 signaling (e.g. 117 shared keys or certificates to setup IPsec security associations). 119 One approach is to statically provision the necessary configuration 120 parameters at MNs and HAs. This solution is sub-optimal from a 121 deployment perspective, especially in large networks with a lot of 122 users (e.g., a mobile operator network). For this reason the Mobile 123 IPv6 bootstrapping problem was investigated [3]. Based on the 124 analysed scenarios (i.e. integrated and split), two solutions were 125 developed. The solution for the split scenario is described in [4] 126 and the one for the integrated scenario can be found at [5]. A key 127 point behind these mechanisms is that, whenever static provisioning 128 is not feasible, the AAA infrastructure of the MSP can be used as 129 the central element to enable dynamic Mobile IPv6 bootstrapping. In 130 this case the AAA infrastructure can be exploited to offload the end 131 host's authentication to the AAA server as well as to deliver the 132 necessary configuration parameters to the HA. 134 Moreover, in case Mobile IPv6 is a service offered by a Mobility 135 Service Provider (MSP), all protocol operations (e.g. home 136 registrations) may need to be explicitly authorized and monitored 137 (e.g. for accounting purposes). This can be accomplished relying on 138 the AAA infrastructure of the MSP, that stores users' service 139 profiles and credentials. 141 The deployment of this service model requires the availability of an 142 interface between the AAA infrastructure and the HA, that can be 143 seen as the Network Access Server (NAS) for Mobile IPv6. The core 144 capabilities that should be supported by this interface include 145 Mobile IPv6 service authorization and maintenance (e.g. asynchronous 146 service termination) as well as the exchange of accounting data. 147 This basic set of features is needed in any Mobile IPv6 148 bootstrapping scenario. 150 There is therefore space for the definition of a general AAA-HA 151 communication interface capable to support the basic features 152 described above (e.g. authorization and accounting) as well as the 153 extended capabilities (e.g. transfer of configuration data) needed 154 to enable various dynamic Mobile IPv6 bootstrapping scenarios. 156 3. Bootstrapping scenarios 158 This section describes some bootstrapping scenarios in which a 159 communication between the AAA infrastructure of the Mobility Service 160 Provider and the Home Agent is needed. 162 3.1 Split Scenario 164 In the split scenario [4], there is the assumption that the mobility 165 service and network access service are separate. This implies that 166 the mobility service can be authorized by a different entity 167 deploying its own AAA infrastructure. The entity offering the 168 mobility service is called Mobility Service Provider (MSP) while the 169 entity authorizing the service is the Mobility Service Authorizer 170 (MSA). 172 In this scenario, the Mobile Node discovers the Home Agent Address 173 using the Domain Name Service (DNS). It queries the address based on 174 the Home Agent name or by service name. In the former case, the 175 Mobile Node is configured with the Fully Qualified Domain Name 176 (FDQN) of the Home Agent. In the latter case, the document [4] 177 defines a new service resource record (SRV RR). 179 Then the Mobile Node performs an IKEv2 [6] exchange with the HA to 180 setup IPsec SAs (to protect Mobile IPv6 signaling) and to configure 181 its Home Address (HoA). The IKEv2 Mobile Node to Home Agent 182 authentication can be done using either public key signatures or the 183 Extensible Authentication Protocol (EAP). 185 If EAP is used for authentication, the operator can choose any 186 available EAP authentication methods. Note that even if EAP is used, 187 the MN authenticates the HA using public key signature based 188 authentication. The HA may rely on a remote EAP server. In this 189 case, a AAA protocol such as RADIUS EAP [7] or Diameter EAP Error! 190 Reference source not found. must be used between the HA and the home 191 EAP server. This allows a pool of HAs to rely on the same EAP server 192 to authenticate Mobile Nodes. It also allows the roaming mobility 193 case in which the Mobile Node obtains the mobility service in a 194 different administrative domain (MSP != MSA). 196 The Mobile Node may also want to update its FQDN in the DNS with the 197 newly allocated Home Address. The document [4] recommends that the 198 HA performs the DNS entry update on behalf of the Mobile Node. For 199 that purpose, the Mobile Node indicates its FDQN in the IKEv2 200 exchange (IDii field in IKE_AUTH) and adds a DNS Update Option in 201 the Binding Update message sent to the HA. 203 When the Mobile Node uses a Home Agent belonging to a different 204 administrative domain (MSP != MSA), the local HA may not share a 205 security association with the home DNS server. In this case, the 206 document [4] suggests the home AAA server to be responsible of the 207 update. Thus the HA should send to the home AAA server the FDQN-HoA 208 pair through the AAA protocol. Note that the AAA exchange between 209 the HA and the AAA infrastructure is normally terminated before the 210 HA receives the Binding Update message. The reason is that the 211 authentication has succeeded if the Mobile Node is able to send the 212 BU. 214 3.2 Integrated Scenario 216 In the integrated scenario [5], the assumption is which the mobile 217 user's mobility service is authorized by the same authorizer than 218 network access service. Basically Mobility Service Authorizer (MSA) 219 and the Access Service Authorizer (ASA) are the same entity. The 220 scenario considers two cases: 222 1. Mobile Node requests a home agent to its home domain (ASA/MSA) 224 2. Mobile Node requests a home agent to the Access Service Provider 225 (ASP) 227 In the first case, Home Agent is allocated by user's home domain. In 228 the second case it is allocated by user's visited domain. In both 229 cases, it is assumed that the AAA server in the home domain (AAAH) 230 authorizes both network access service and mobility service. 232 In this scenario, Mobile Node discovers the Home Agent Address using 233 DHCPv6. During network access service authentication and 234 authorization, AAAH also verifies if authenticating user is 235 authorized to use mobility service. In affirmative case, AAAH sends 236 to the Network Access Server (NAS) where the Mobile Node is 237 attached, the information about the assigned home agent. Then NAS 238 stores that information. To request home agent data, Mobile Node 239 sends a DHCPv6 Information Request to the 240 All_DHCP_Relay_Agents_and_Servers multicast address. With this 241 request, Mobile Node can specify if it wants a home agent provided 242 by the visited domain (ASP) or by the home domain (ASA). In both 243 cases, the NAS acts a DHCPv6 relay. When the NAS receives DHCPv6 244 Information Request then it attaches home agent information received 245 from AAAH in a new DHC Relay Agent Option defined in [5]. 247 In case Mobile Node cannot acquire home agent information via 248 DHCPv6, it can try the default mechanism based on DNS described in 249 [4]. After the Mobile Node has acquired home agent information, the 250 mechanism used to bootstrap the HoA, IPsec Security Association, and 251 Authentication and Authorization with the MSA is the same described 252 in the bootstrapping solution for split scenario [4]. 254 4. Goals for the AAA-HA interface 256 The motivations and scenarios illustrated in previous sections raise 257 the need to define an interface between the AAAH server and the HA. 258 The following sections list a set of goals for this interface. 260 4.1 General goals 262 G1.1 The AAAH server and the HA MUST be able to authenticate each 263 other (mutual authentication) in order to prevent the 264 installation of unauthorized state on the HA. 266 G1.2 The AAA-HA interface MUST provide integrity protection in 267 order to prevent any alteration of exchanged data (e.g. Mobile 268 IPv6 configuration parameters). 270 G1.3 The AAA-HA interface MUST provide replay protection. 272 G1.4 The AAA-HA interface SHOULD provide confidentiality since it 273 may be used to transfer keying material (e.g. shared key 274 generated during EAP authentication). 276 G1.5 The AAA-HA interface should support inactive peer detection. 277 This functionality can be used by the AAAH server to maintain 278 a list of active HAs (e.g. useful for HA selection). 280 4.2 Service Authorization 282 G2.1 The AAA-HA interface SHOULD allow the use of Network Access 283 Identifier (NAI) to identify the mobile node. 285 G2.2 The HA SHOULD be able to query the AAAH server to verify 286 Mobile IPv6 service authorization for the mobile node. 288 G2.3 The AAAH server MAY enforce explicit operational limitations 289 and authorization restrictions on the HA (e.g. packet filters, 290 QoS parameters). 292 G2.4 The AAAH server MUST be able to send an authorization lifetime 293 to the HA to limit Mobile IPv6 session duration for the MN. 295 G2.5 The HA MUST be able to request to the AAAH server an extension 296 of the authorization lifetime granted to the MN. 298 G2.6 The AAAH server MUST be able to force the HA to terminate an 299 active Mobile IPv6 session for authorization policy reasons 300 (e.g. credit exhaustion). 302 4.3 Accounting 304 G3.1 The AAA-HA interface must support the transfer of accounting 305 records needed for service control and charging. These include 306 (but may not be limited to): time of binding cache entry 307 creation and deletion, octets sent and received by the mobile 308 node in Bi-directional Tunneling, etc. 310 4.4 Mobile Node Authentication 312 G4.1 The AAA-HA interface MUST support pass-through EAP 313 authentication with the HA working as EAP authenticator 314 operating in pass-through mode and the AAAH server working as 315 back-end authentication server. 317 4.5 Provisioning of configuration parameters 319 G5.1 The HA should be able to communicate to the AAAH server the 320 Home Address allocated to the MN (e.g. for allowing the AAAH 321 server to perform DNS update on behalf of the MN). 323 5. IANA Considerations 325 No new message formats or services are defined in this document. 327 6. Security Considerations 329 As stated in section 4.1 the AAA-HA interface must provide mutual 330 authentication, integrity and replay protection. Furthermore, if 331 security parameters (e.g. IKE pre-shared key) are transferred 332 through this interface, confidentiality is a feature that is 333 strongly recommended to be supported. However note that some 334 suitable interfaces may not provide end-to-end confidentiality 335 between AAA and HA (e.g. AAA protocols). 337 7. Acknowledgments 339 The authors would like to thank James Kempf, Alper Yegin, Vijay 340 Devarapalli, Basavaraj Patil, Gopal Dommety for their comments and 341 feedback. Moreover the authors would like to thank Hannes Tschofenig 342 for his deep technical and editorial review of the draft. 344 8. References 346 8.1 Normative References 348 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 349 Levels", BCP 14, RFC 2119, March 1997. 351 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", 352 RFC 3775, June 2004. 354 8.2 Informative References 356 [3] Patel, A. et al. "Problem Statement for bootstrapping Mobile IPv6", 357 draft-ietf-mip6-bootstrap-ps-02 (work in progress), March 2005. 359 [4] Giaretta, G., Kempf, J. and Devarapalli, V., "Mobile IPv6 360 bootstrapping in split scenario", draft-ietf-mip6-bootstrapping- 361 split-01 (work in progress), October 2005. 363 [5] Chowdhury, K. and Yegin, A., "MIP6-bootstrapping via DHCPv6 for the 364 Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc- 365 00 (work in progress), October 2005. 367 [6] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf- 368 ipsec-ikev2-17 (work in progress), September 2004. 370 [7] Aboba, B. and Calhoun, P., "RADIUS (Remote Authentication Dial In 371 User Service) Support For Extensible Authentication Protocol 372 (EAP)", RFC 3579, September 2003. 374 [8] Eronen, P., Hiller, T. and Zorn, G., "Diameter Extensible 375 Authentication Protocol (EAP) Application", RFC 4072, August 2005. 377 [9] Chowdhury, K. and Lior, A., "RADIUS Attributes for Mobile IPv6 378 bootstrapping", draft-chowdhury-mip6-bootstrap-radius-01 (work in 379 progress), October 2004. 381 [10] Jang, H. J. and Yegin, A., "DHCP Option for Home Agent Discovery 382 in MIPv6", draft-jang-dhc-haopt-01 (work in progress), April 2005. 384 [11] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., Laurent- 385 Maknavicius, M., "MIPv6 Authorization and Configuration based on 386 EAP", draft-giaretta-mip6-authorization-eap-02 (work in progress), 387 September 2004. 389 Authors� Addresses 391 Gerardo Giaretta 392 Telecom Italia Lab 393 via G. Reiss Romoli, 274 394 10148 TORINO 395 Italy 396 Phone: +39 011 2286904 397 Email: gerardo.giaretta@tilab.com 399 Ivano Guardini 400 Telecom Italia Lab 401 via G. Reiss Romoli, 274 402 10148 TORINO 403 Italy 404 Phone: +39 011 2285424 405 Email: ivano.guardini@tilab.com 407 Elena Demaria 408 Telecom Italia Lab 409 via G. Reiss Romoli, 274 410 10148 TORINO 411 Italy 412 Phone: +39 011 2285403 413 Email: elena.demaria@tilab.com 415 Julien Bournelle 416 GET/INT 417 9 rue Charles Fourier 418 Evry 91011 419 France 420 Email: julien.bournelle@int-evry.fr 422 Rafa Marin Lopez 423 University of Murcia 424 30071 Murcia 425 Spain 426 EMail: rafa@dif.um.es 427 Intellectual Property Statement 429 The IETF takes no position regarding the validity or scope of any 430 Intellectual Property Rights or other rights that might be claimed 431 to pertain to the implementation or use of the technology described 432 in this document or the extent to which any license under such 433 rights might or might not be available; nor does it represent that 434 it has made any independent effort to identify any such rights. 435 Information on the procedures with respect to rights in RFC 436 documents can be found in BCP 78 and BCP 79. 438 Copies of IPR disclosures made to the IETF Secretariat and any 439 assurances of licenses to be made available, or the result of an 440 attempt made to obtain a general license or permission for the use 441 of such proprietary rights by implementers or users of this 442 specification can be obtained from the IETF on-line IPR repository 443 at http://www.ietf.org/ipr. 445 The IETF invites any interested party to bring to its attention any 446 copyrights, patents or patent applications, or other proprietary 447 rights that may cover technology that may be required to implement 448 this standard. Please address the information to the IETF at ietf 449 ipr@ietf.org 451 Disclaimer of Validity 453 This document and the information contained herein are provided on 454 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 455 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 456 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 457 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 458 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 459 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 461 Copyright Statement 463 Copyright (C) The Internet Society (2006). 465 This document is subject to the rights, licenses and restrictions 466 contained in BCP 78, and except as set forth therein, the authors 467 retain all their rights. 469 Acknowledgment 471 Funding for the RFC Editor function is currently provided by the 472 Internet Society.