idnits 2.17.1 draft-ietf-mext-aaa-ha-goals-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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 490. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 503. 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 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 (May 2, 2008) is 5838 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '7' is defined on line 414, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. '8') (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group G. Giaretta 3 Internet-Draft Qualcomm 4 Intended status: Informational I. Guardini 5 Expires: November 3, 2008 E. Demaria 6 Telecom Italia 7 J. Bournelle 8 Orange Labs 9 R. Lopez 10 Univ. of Murcia 11 May 2, 2008 13 AAA Goals for Mobile IPv6 14 draft-ietf-mext-aaa-ha-goals-01 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of 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. 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 November 3, 2008. 41 Abstract 43 In commercial and enterprise deployments Mobile IPv6 can be a service 44 offered by a Mobility Services Provider (MSP). In this case all 45 protocol operations may need to be explicitly authorized and traced, 46 requiring the interaction between Mobile IPv6 and the AAA 47 infrastructure. Integrating the AAA infrastructure (e.g. NAS and 48 AAA server) offers also a solution component for Mobile IPv6 49 bootstrapping. This document describes various scenarios where a AAA 50 interface for Mobile IPv6 is required. Additionally, it lists design 51 goals and requirements for such an interface. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Bootstrapping Scenarios . . . . . . . . . . . . . . . . . . . 4 59 4.1. Split Scenario . . . . . . . . . . . . . . . . . . . . . . 4 60 4.2. Integrated Scenario . . . . . . . . . . . . . . . . . . . 5 61 5. Goals for AAA-HA interface . . . . . . . . . . . . . . . . . . 6 62 5.1. General goals . . . . . . . . . . . . . . . . . . . . . . 6 63 5.2. Service Authorization . . . . . . . . . . . . . . . . . . 6 64 5.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 7 65 5.4. Mobile Node Authentication . . . . . . . . . . . . . . . . 8 66 5.5. Provisioning of Configuration Parameters . . . . . . . . . 8 67 6. Goals for the AAA-NAS interface . . . . . . . . . . . . . . . 8 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 75 Intellectual Property and Copyright Statements . . . . . . . . . . 12 77 1. Introduction 79 Mobile IPv6 [1] provides the basic IP mobility functionality for 80 IPv6. When Mobile IPv6 is used in tightly managed environments with 81 the use of the AAA (Authentication, Authorization and Accounting) 82 infrastructure, an interface between Mobile IPv6 and AAA protocols 83 needs to be defined. Also, two scenarios for bootstrapping Mobile 84 IPv6 service [2] , i.e., split [3] and integrated [4] scenarios, 85 require the specification of a message exchange between the HA and 86 AAA infrastructure for authentication and authorization purposes and 87 a message exchange between the AAA server and the NAS in order to 88 provide the visited network with the necessary configuration 89 information (e.g. Home Agent address). 91 This document describes various scenarios where a AAA interface is 92 required. Additionally, it lists design goals and requirements for 93 the communication between the HA and the AAA server and the NAS and 94 the AAA server needed in the split and integrated scenarios. 95 Requirements are listed in case either IPsec or rfc 4285 [5] is used 96 for Mobile IPv6 authentication. 98 This document only describes requirements, goals and scenarios. It 99 does not provide solutions. 101 Notice that this document builds on the security model of the AAA 102 infrastructure. As such, the end host/user shares credentials with 103 the home AAA server and the communication between the AAA server and 104 the AAA client may be protected. If the AAA server and the AAA 105 client are not part of the same administrative domain, then some sort 106 of contractual relationship between the involved administrative 107 domains is typically in place in form of roaming agreements. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [6], with the 114 qualification that unless otherwise stated these words apply to the 115 design of the AAA protocol extension, not its implementation or its 116 usage. 118 Some of the terms are also extracted from [2]. 120 o Access Service Authorizer (ASA). A network operator that 121 authenticates a mobile node and establishes the mobile node's 122 authorization to receive Internet service. 124 o Access Service Provider (ASP). A network operator that provides 125 direct IP packet forwarding to and from the end host. 126 o Mobility Service Authorizer (MSA). A service provider that 127 authorizes Mobile IPv6 service. 128 o Mobility Service Provider (MSP). A service provider that provides 129 Mobile IPv6 service. In order to obtain such service, the mobile 130 node must be authenticated and prove authorization to obtain the 131 service. 133 3. Motivation 135 Mobile IPv6 specification [1] requires that Mobile Nodes (MNs) are 136 provisioned with a set of configuration parameters, namely the Home 137 Address and the Home Agent Address, in order to accomplish a home 138 registration. Moreover, MNs and Home Agents (HAs) must share the 139 cryptographic material needed in order to setup IPsec security 140 associations to protect Mobile IPv6 signaling (e.g. shared keys or 141 certificates). This is referred as the bootstrapping problem: as 142 described in [2], the AAA infrastructure can be used as the central 143 element to enable dynamic Mobile IPv6 bootstrapping. In this case 144 the AAA infrastructure can be exploited to offload the end host's 145 authentication to the AAA server as well as to deliver the necessary 146 configuration parameters to the visited network (e.g. Home Agent 147 address as specified in [4]). 149 Moreover, in case Mobile IPv6 is a service offered by a Mobility 150 Service Provider (MSP), all protocol operations (e.g., home 151 registrations) may need to be explicitly authorized and monitored 152 (e.g., for accounting purposes). This can be accomplished relying on 153 the AAA infrastructure of the MSA that stores user profiles and 154 credentials. 156 4. 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. The need of a MIPv6-aware 161 communication between the AAA server and the Network Access Server 162 (NAS) is also described. For more details, please refer to the 163 bootstrapping documents [2], [3] and [4]. 165 4.1. Split Scenario 167 In the split scenario [3], there is the assumption that the mobility 168 service and network access service are not provided by the same 169 administrative entity. This implies that the mobility service is 170 authorized by the MSA that is a different entity from the ASA. 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 (FDQN) 176 of the Home Agent. In the latter case, [3] defines a new service 177 resource record (SRV RR). 179 Then the Mobile Node performs an IKEv2 [8] exchange with the HA to 180 setup IPsec SAs (to protect Mobile IPv6 signaling) and to configure 181 its Home Address (HoA). Mutual authentication for IKEv2 between 182 Mobile Node and Home Agent can be done with or without use of 183 Extensible Authentication Protocol (EAP). 185 If EAP is used for authentication, the operator can choose any 186 available EAP methods. Use of EAP with the AAA infrastructure allows 187 the HA for not necessarily maintaining authentication credentials for 188 each Mobile Node by itself, checking the validity of the credentials 189 with the AAA infrastructure. It also allows roaming in terms of 190 Mobile IPv6 service where MSP and MSA belong to different 191 administrative domains. In this case the HA in the MSP can check the 192 vailidity of the credentials provided by the MN with the AAA 193 infrastructure of MSA, receiving the relevant authorization 194 information. 196 The Mobile Node may also want to update its FQDN in the DNS with the 197 newly allocated Home Address. [3] recommends that the HA performs the 198 DNS entry update on behalf of the Mobile Node. For that purpose, the 199 Mobile Node indicates its FDQN in the IKEv2 exchange (IDi field in 200 IKE_AUTH) and adds a DNS Update Option in the Binding Update message 201 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, [3] 206 suggests that the home AAA server is responsible for the update. 207 Thus, the HA should send to the home AAA server the (FDQN, HoA) pair. 209 4.2. Integrated Scenario 211 In the integrated scenario [4], the assumption is that the Access 212 Service Authorizer (ASA) is same as the Mobility Service Authorizer 213 (MSA). 215 The Home Agent can the assigned either in the Access Service 216 Provider's network or in the separate network. In the former case, 217 the MSP is the same entity as the ASP, whereas in the latter case MSP 218 and ASP are different entities. 220 In this scenario, Mobile Node discovers the Home Agent Address using 221 DHCPv6. If the user is authorized for Mobile IPv6 service, during 222 the network access authentication the AAAH sends the information 223 about the assigned Home Agent to the Network Access Server (NAS) 224 where the Mobile Node is currently attached. To request Home Agent 225 data, the Mobile Node sends a DHCPv6 Information Request to the 226 All_DHCP_Relay_Agents_and_Servers multicast address. With this 227 request, the Mobile Node can specify if it wants a Home Agent 228 provided by the visited domain (ASP/MSP) or by the home domain (ASA/ 229 MSA). In both cases, the NAS acts a DHCPv6 relay. When the NAS 230 receives the DHCPv6 Information Request then it sends Home Agent 231 information received from AAAH in a new DHC Relay Agent Option as 232 defined in [4]. 234 In case the Mobile Node cannot acquire Home Agent information via 235 DHCPv6, it can try the default mechanism based on DNS described in 236 [3]. After the Mobile Node has acquired the Home Agent information, 237 the mechanism used to bootstrap the HoA, IPsec Security Association, 238 and Authentication and Authorization with the MSA is the same 239 described in the bootstrapping solution for split scenario [3]. 241 5. Goals for AAA-HA interface 243 Section 4 raises the need to define extensions for the AAA protocol 244 used between the AAA server of the MSA and the HA. The following 245 sections list the goals for such an interface. This communication is 246 needed for both split and integrated scenario. 248 5.1. General goals 250 G1.1 The communication between the AAAH server and the HA MUST reuse 251 existing AAA security mechanisms with regard to authentication, 252 replay, integrity, and confidentiality protection. These 253 communication security mechanisms prevent a number of classical 254 threats, including the alteration of exchanged data (e.g., Mobile 255 IPv6 configuration parameters) and the installation of 256 unauthorized state. 258 5.2. Service Authorization 259 G2.1 The AAA-HA interface MUST allow the use of Network Access 260 Identifier (NAI) to identify the user. 262 G2.2 The HA MUST be able to query the AAAH server to verify Mobile 263 IPv6 service authorization for the mobile node. 265 G2.3 The AAAH server MAY assign explicit operational limitations and 266 authorization restrictions on the HA (e.g., packet filters, QoS 267 parameters). 269 G2.4 The AAAH server MUST be able to send an authorization lifetime 270 to the HA to limit Mobile IPv6 session duration for the MN. 272 G2.5 The HA MUST be able to request to the AAAH server an extension 273 of the authorization lifetime granted to the MN. 275 G2.6 The AAAH server MUST be able to force the HA to terminate an 276 active Mobile IPv6 session for authorization policy reasons (e.g., 277 credit exhaustion). 279 G2.7 The HA MUST be able to indicate to the AAAH the IPv6 HoA that 280 will be assigned to the MN. 282 G2.8 The AAAH server MUST be able to authorize the MN to use an IPv6 283 HoA and MUST indicate that to the HA. 285 G2.9 The AAAH server MUST be able to indicate to the HA whether 286 return routability test (HoT, HoTi) shall be permitted or not via 287 the HA for a given MN. 289 G2.10 The AAAH server MUST be able to support different levels of 290 Mobile IPv6 authorization. For example, the AAAH server may 291 authorize the MN to use of MIPv6 (as defined in [1]) or may 292 authorize the MN to utilize an IPv4 HoA assigned for Dual Stack 293 MIPv6 [9]. 295 G2.11 The AAAH server MUST be able to indicate to the HA whether the 296 bearer traffic for the MN needs to receive IPsec ESP protection. 298 G2.12 The HA MUST be able to authenticate the MN through the AAAH in 299 case a pre-share key is used in IKEv2 for user authentication. 300 The exact procedure is part of the solution space. 302 5.3. Accounting 303 G3.1 The AAA-HA interface MUST support the transfer of accounting 304 records needed for service control and charging. These include 305 (but may not be limited to): time of binding cache entry creation 306 and deletion, octets sent and received by the mobile node in bi- 307 directional tunneling, etc. 309 5.4. Mobile Node Authentication 311 G4.1 The AAA-HA interface MUST allow the HA to act as a pass-through 312 EAP authenticator. 314 G4.2 The AAA - HA interface MUST support authentication based on the 315 Mobility Message Authentication Options defined in [5]. 317 G4.3 The AAAH MUST be able to provide a MN-HA key (or data used for 318 subsequent key derivation of the MN-HA key by the HA) to the HA if 319 requested. Additional data, such as the SPI or lifetime 320 parameters, are sent along with the keying material. 322 G4.4 The HA SHOULD be able to request the AAAH server to 323 authenticate the MN with the value in the MN-AAA Mobility Message 324 Authentication Option. 326 G4.5 The HA MUST include an identifier of the mobile node in the AAA 327 transactions with the AAAH server. 329 5.5. Provisioning of Configuration Parameters 331 o The HA SHOULD be able to communicate to the AAAH server the Home 332 Address allocated to the MN and the FQDN of the MN (e.g., for 333 allowing the AAAH server to perform a DNS update on behalf of the 334 MN). 336 o The AAAH SHOULD be able to indicate to the HA if the MN is 337 authorized to autoconfigure its Home Address. 339 6. Goals for the AAA-NAS interface 341 In the integrated scenario, the AAA server provides the HA 342 information to the NAS as part of the whole AAA operations for 343 network access. 345 G6.1 The AAAH server MUST be able to communicate the Home Agent 346 Information (IP Address or FQDN) to the NAS. 348 G6.2 The NAS MUST be able to notify the AAAH if it supports the AAA 349 extensions designed to receive the HA assignment information 350 described in [4]. 352 G6.3 The ASP/MSP SHOULD be able to indicate to the MSA if it can 353 allocate a Home Agent to the MN. Therefore the NAS SHOULD be able 354 to include suggested HA address in the ASP in the NAS - AAA 355 interaction. 357 G6.4 The AAA server of the MSA MUST be able to indicate to the NAS 358 whether the MN is authorized to use a local Home Agent (i.e. a 359 Home Agent in the ASP/MSP). 361 G6.5 The overall AAA solution for integrated scenario MUST support 362 the scenario where the AAA server of the ASA/MSA used for network 363 access authentication is different from the AAA server used for 364 mobility service authentication and authorization. 366 7. IANA Considerations 368 This document does not require actions by IANA. 370 8. Security Considerations 372 As stated in Section 5.1 the AAA-HA interface must provide mutual 373 authentication, integrity and replay protection. Furthermore, if 374 security parameters (e.g., IKE pre-shared key) are transferred 375 through this interface, confidentiality is strongly recommended to be 376 supported. In this case the links between the HA and the AAA server 377 of the MSA and between the NAS and the AAA server MUST be secure. 379 9. Acknowledgements 381 The authors would like to thank James Kempf, Alper Yegin, Vijay 382 Devarapalli, Basavaraj Patil, Gopal Dommety, Marcelo Bagnulo and 383 Madjid Nakhjiri for their comments and feedback. Moreover the 384 authors would like to thank Hannes Tschofenig for his deep technical 385 and editorial review of the draft. Finally the aithors would like to 386 thank Kuntal Chowdhury who contribbuted identifying the goals related 387 to rfc4285 authentication. 389 10. References 391 10.1. Normative References 393 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 394 IPv6", RFC 3775, June 2004. 396 [2] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 397 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 399 [3] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 400 Bootstrapping in Split Scenario", RFC 5026, October 2007. 402 [4] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 403 Integrated Scenario", 404 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in 405 progress), April 2008. 407 [5] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 408 "Authentication Protocol for Mobile IPv6", RFC 4285, 409 January 2006. 411 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 412 Levels", BCP 14, RFC 2119, March 1997. 414 [7] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 415 "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", 416 RFC 4283, November 2005. 418 10.2. Informative References 420 [8] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 421 December 2005. 423 [9] Soliman, H., "Mobile IPv6 support for dual stack Hosts and 424 Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-06 (work in 425 progress), November 2007. 427 Authors' Addresses 429 Gerardo Giaretta 430 Qualcomm 431 5775 Morehouse Drive 432 San Diego, 92109 433 USA 435 Email: gerardo@qualcomm.com 437 Ivano Guardini 438 Telecom Italia Lab 439 via G. Reiss Romoli, 274 440 TORINO, 10148 441 Italy 443 Email: ivano.guardini@telecomitalia.it 445 Elena Demaria 446 Telecom Italia Lab 447 via G. Reiss Romoli, 274 448 TORINO, 10148 449 Italy 451 Email: elena.demaria@telecomitalia.it 453 Julien Bournelle 454 Orange Labs 456 Email: julien.bournelle@gmail.com 458 Rafa Marin Lopez 459 University of Murcia 460 30071 Murcia 461 Spain 463 Email: rafa@dif.um.es 465 Full Copyright Statement 467 Copyright (C) The IETF Trust (2008). 469 This document is subject to the rights, licenses and restrictions 470 contained in BCP 78, and except as set forth therein, the authors 471 retain all their rights. 473 This document and the information contained herein are provided on an 474 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 475 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 476 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 477 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 478 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 479 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 481 Intellectual Property 483 The IETF takes no position regarding the validity or scope of any 484 Intellectual Property Rights or other rights that might be claimed to 485 pertain to the implementation or use of the technology described in 486 this document or the extent to which any license under such rights 487 might or might not be available; nor does it represent that it has 488 made any independent effort to identify any such rights. Information 489 on the procedures with respect to rights in RFC documents can be 490 found in BCP 78 and BCP 79. 492 Copies of IPR disclosures made to the IETF Secretariat and any 493 assurances of licenses to be made available, or the result of an 494 attempt made to obtain a general license or permission for the use of 495 such proprietary rights by implementers or users of this 496 specification can be obtained from the IETF on-line IPR repository at 497 http://www.ietf.org/ipr. 499 The IETF invites any interested party to bring to its attention any 500 copyrights, patents or patent applications, or other proprietary 501 rights that may cover technology that may be required to implement 502 this standard. Please address the information to the IETF at 503 ietf-ipr@ietf.org.