idnits 2.17.1 draft-ietf-mext-aaa-ha-goals-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 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 495. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 513. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 519. 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 : ---------------------------------------------------------------------------- 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 (December 27, 2007) is 5964 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) ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 4640 (ref. '2') == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-05 ** Downref: Normative reference to an Informational RFC: RFC 4285 (ref. '5') -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. '8') (Obsoleted by RFC 5996) Summary: 4 errors (**), 0 flaws (~~), 3 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 Expires: June 29, 2008 I. Guardini 5 E. Demaria 6 Telecom Italia 7 J. Bournelle 8 Orange Labs 9 R. Lopez 10 Univ. of Murcia 11 December 27, 2007 13 AAA Goals for Mobile IPv6 14 draft-ietf-mext-aaa-ha-goals-00 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 June 29, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 In commercial and enterprise deployments Mobile IPv6 can be a service 48 offered by a Mobility Services Provider (MSP). In this case all 49 protocol operations may need to be explicitly authorized and traced, 50 requiring the interaction between Mobile IPv6 and the AAA 51 infrastructure. Integrating the AAA infrastructure (e.g. NAS and 52 AAA server) offers also a solution component for Mobile IPv6 53 bootstrapping. This document describes various scenarios where a AAA 54 interface for Mobile IPv6 is required. Additionally, it lists design 55 goals and requirements for such an interface. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Bootstrapping Scenarios . . . . . . . . . . . . . . . . . . . 4 63 4.1. Split Scenario . . . . . . . . . . . . . . . . . . . . . . 4 64 4.2. Integrated Scenario . . . . . . . . . . . . . . . . . . . 5 65 5. Goals for AAA-HA interface . . . . . . . . . . . . . . . . . . 6 66 5.1. General goals . . . . . . . . . . . . . . . . . . . . . . 6 67 5.2. Service Authorization . . . . . . . . . . . . . . . . . . 6 68 5.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5.4. Mobile Node Authentication . . . . . . . . . . . . . . . . 8 70 5.5. Provisioning of Configuration Parameters . . . . . . . . . 8 71 6. Goals for the AAA-NAS interface . . . . . . . . . . . . . . . 9 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 79 Intellectual Property and Copyright Statements . . . . . . . . . . 12 81 1. Introduction 83 Mobile IPv6 [1] provides the basic IP mobility functionality for 84 IPv6. When Mobile IPv6 is used in tightly managed environments with 85 the use of the AAA (Authentication, Authorization and Accounting) 86 infrastructure, an interface between Mobile IPv6 and AAA protocols 87 needs to be defined. Also, two scenarios for bootstrapping Mobile 88 IPv6 service [2] , i.e., split [3] and integrated [4] scenarios, 89 require the specification of a message exchange between the HA and 90 AAA infrastructure for authentication and authorization purposes and 91 a message exchange between the AAA server and the NAS in order to 92 provide the visited network with the necessary configuration 93 information (e.g. Home Agent address). 95 This document describes various scenarios where a AAA interface is 96 required. Additionally, it lists design goals and requirements for 97 the communication between the HA and the AAA server and the NAS and 98 the AAA server needed in the split and integrated scenarios. 99 Requirements are listed in case either IPsec or rfc 4285 [5] is used 100 for Mobile IPv6 authentication. 102 This document only describes requirements, goals and scenarios. It 103 does not provide solutions. 105 Notice that this document builds on the security model of the AAA 106 infrastructure. As such, the end host/user shares credentials with 107 the home AAA server and the communication between the AAA server and 108 the AAA client may be protected. If the AAA server and the AAA 109 client are not part of the same administrative domain, then some sort 110 of contractual relationship between the involved administrative 111 domains is typically in place in form of roaming agreements. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [6], with the 118 qualification that unless otherwise stated these words apply to the 119 design of the AAA protocol extension, not its implementation or its 120 usage. 122 Some of the terms are also extracted from [2]. 124 o Access Service Authorizer (ASA). A network operator that 125 authenticates a mobile node and establishes the mobile node's 126 authorization to receive Internet service. 128 o Access Service Provider (ASP). A network operator that provides 129 direct IP packet forwarding to and from the end host. 130 o Mobility Service Authorizer (MSA). A service provider that 131 authorizes Mobile IPv6 service. 132 o Mobility Service Provider (MSP). A service provider that provides 133 Mobile IPv6 service. In order to obtain such service, the mobile 134 node must be authenticated and prove authorization to obtain the 135 service. 137 3. Motivation 139 Mobile IPv6 specification [1] requires that Mobile Nodes (MNs) are 140 provisioned with a set of configuration parameters, namely the Home 141 Address and the Home Agent Address, in order to accomplish a home 142 registration. Moreover, MNs and Home Agents (HAs) must share the 143 cryptographic material needed in order to setup IPsec security 144 associations to protect Mobile IPv6 signaling (e.g. shared keys or 145 certificates). This is referred as the bootstrapping problem: as 146 described in [2], the AAA infrastructure can be used as the central 147 element to enable dynamic Mobile IPv6 bootstrapping. In this case 148 the AAA infrastructure can be exploited to offload the end host's 149 authentication to the AAA server as well as to deliver the necessary 150 configuration parameters to the visited network. 152 Moreover, in case Mobile IPv6 is a service offered by a Mobility 153 Service Provider (MSP), all protocol operations (e.g., home 154 registrations) may need to be explicitly authorized and monitored 155 (e.g., for accounting purposes). This can be accomplished relying on 156 the AAA infrastructure of the MSA that stores user profiles and 157 credentials. 159 4. Bootstrapping Scenarios 161 This section describes some bootstrapping scenarios in which a 162 communication between the AAA infrastructure of the Mobility Service 163 Provider and the Home Agent is needed. The need of a MIPv6-aware 164 communication between the AAA server and the Network Access Server 165 (NAS) is also described. For more details, please refer to the 166 bootstrapping documents [2], [3] and [4]. 168 4.1. Split Scenario 170 In the split scenario [3], there is the assumption that the mobility 171 service and network access service are not provided by the same 172 administrative entity. This implies that the mobility service is 173 authorized by the MSA that is a different entity from the ASA. 175 In this scenario, the Mobile Node discovers the Home Agent Address 176 using the Domain Name Service (DNS). It queries the address based on 177 the Home Agent name or by service name. In the former case, the 178 Mobile Node is configured with the Fully Qualified Domain Name (FDQN) 179 of the Home Agent. In the latter case, [3] defines a new service 180 resource record (SRV RR). 182 Then the Mobile Node performs an IKEv2 [8] exchange with the HA to 183 setup IPsec SAs (to protect Mobile IPv6 signaling) and to configure 184 its Home Address (HoA). Mutual authentication for IKEv2 between 185 Mobile Node and Home Agent can be done with or without use of 186 Extensible Authentication Protocol (EAP). 188 If EAP is used for authentication, the operator can choose any 189 available EAP methods. Use of EAP with the AAA infrastructure allows 190 the HA for not necessarily maintaining authentication credentials for 191 each Mobile Node by itself. It also allows roaming in terms of 192 Mobile IPv6 service where MSP and MSA belong to different 193 administrative domains. 195 The Mobile Node may also want to update its FQDN in the DNS with the 196 newly allocated Home Address. [3] recommends that the HA performs the 197 DNS entry update on behalf of the Mobile Node. For that purpose, the 198 Mobile Node indicates its FDQN in the IKEv2 exchange (IDi field in 199 IKE_AUTH) and adds a DNS Update Option in the Binding Update message 200 sent to the HA. 202 When the Mobile Node uses a Home Agent belonging to a different 203 administrative domain (MSP != MSA), the local HA may not share a 204 security association with the home DNS server. In this case, [3] 205 suggests that the home AAA server is responsible for the update. 206 Thus, the HA should send to the home AAA server the (FDQN, HoA) pair. 208 4.2. Integrated Scenario 210 In the integrated scenario [4], the assumption is that the Access 211 Service Authorizer (ASA) is same as the Mobility Service Authorizer 212 (MSA). 214 The Home Agent can the assigned either in the Access Service 215 Provider's network or in the seprate network. In the former case, 216 the MSP is the same entity as the ASP, whereas in the latter case MSP 217 and ASP are different entities. 219 In this scenario, Mobile Node discovers the Home Agent Address using 220 DHCPv6. If the user is authorized for Mobile IPv6 service, during 221 the network access authentication the AAAH sends the information 222 about the assigned home agent to the Network Access Server (NAS) 223 where the Mobile Node is currently attached. To request home agent 224 data, the Mobile Node sends a DHCPv6 Information Request to the 225 All_DHCP_Relay_Agents_and_Servers multicast address. With this 226 request, the Mobile Node can specify if it wants a home agent 227 provided by the visited domain (ASP/MSP) or by the home domain (ASA/ 228 MSA). In both cases, the NAS acts a DHCPv6 relay. When the NAS 229 receives the DHCPv6 Information Request then it sends home agent 230 information received from AAAH in a new DHC Relay Agent Option as 231 defined in [4]. 233 In case the Mobile Node cannot acquire home agent information via 234 DHCPv6, it can try the default mechanism based on DNS described in 235 [3]. After the Mobile Node has acquired the home agent information, 236 the mechanism used to bootstrap the HoA, IPsec Security Association, 237 and Authentication and Authorization with the MSA is the same 238 described in the bootstrapping solution for split scenario [3]. 240 5. Goals for AAA-HA interface 242 Section 4 raises the need to define extensions for the AAA protocol 243 used between the AAA server of the MSA and the HA. The following 244 sections list the goals for such an interface. This communication is 245 needed for both split and integrated scenario. 247 5.1. General goals 249 G1.1 The AAAH server and the HA MUST be able to authenticate each 250 other (mutual authentication) in order to prevent the installation 251 of unauthorized state on the HA. In some deployment scenarios, it 252 may not be feasible for HA and AAA server to mutually authenticate 253 each other. In such a case, several AAA intermediate proxies 254 could forward MIP6 bootstrapping information between HA and AAA. 255 Thus, to prevent the installation of unauthorized state on the HA, 256 the path between HA and AAAH should be secure. 258 G1.2 The AAA-HA interface MUST provide integrity protection in order 259 to prevent any alteration of exchanged data (e.g., Mobile IPv6 260 configuration parameters). 262 G1.3 The AAA-HA interface MUST provide replay protection. 264 5.2. Service Authorization 265 G2.1 The AAA-HA interface MUST allow the use of Network Access 266 Identifier (NAI) to identify the user. 268 G2.2 The HA MUST be able to query the AAAH server to verify Mobile 269 IPv6 service authorization for the mobile node. 271 G2.3 The AAAH server MAY assign explicit operational limitations and 272 authorization restrictions on the HA (e.g., packet filters, QoS 273 parameters). 275 G2.4 The AAAH server MUST be able to send an authorization lifetime 276 to the HA to limit Mobile IPv6 session duration for the MN. 278 G2.5 The HA MUST be able to request to the AAAH server an extension 279 of the authorization lifetime granted to the MN. 281 G2.6 The AAAH server MUST be able to force the HA to terminate an 282 active Mobile IPv6 session for authorization policy reasons (e.g., 283 credit exhaustion). 285 G2.7 The HA MUST be able to indicate the IPv6 HoA that will be 286 assigned to the MN. 288 G2.8 The AAAH server MUST be able to authorize the MN to use an IPv6 289 HoA. 291 G2.9 The AAAH server MUST be able to indicate to the HA whether 292 return routability test (HoT, HoTi) shall be permitted or not via 293 the HA for a given MN. 295 G2.10 The AAAH server MUST be able to authorize the MN for Dual 296 Stack operation [9]. 298 G2.11 The AAAH server MUST be able to indicate to the HA whether the 299 bearer traffic for the MN needs to receive IPsec ESP protection. 301 G2.12 The HA MUST be able to authenticate the MN through the AAAH in 302 case a pre-share key is used in IKEv2 for user authentication. 303 The exact procedure is part of the solution space. 305 5.3. Accounting 307 G3.1 The AAA-HA interface MUST support the transfer of accounting 308 records needed for service control and charging. These include 309 (but may not be limited to): time of binding cache entry creation 310 and deletion, octets sent and received by the mobile node in bi- 311 directional tunneling, etc. 313 5.4. Mobile Node Authentication 315 G4.1 The AAA-HA interface MUST allow the HA to act as a pass-through 316 EAP authenticator. 318 G4.2 The AAA - HA interface SHOULD support authentication based on 319 the Mobility Message Authentication Options defined in [5]. 321 G4.3 The HA SHOULD be able to request either the keying material to 322 generate MN-HA key for MN-HA Mobility Message Authentication 323 Option or SHOULD be able to request the MN-HA key and the related 324 SPI values from the AAAH server. 326 G4.4 The HA SHOULD be able to request the AAAH server to 327 authenticate the MN with the value in the MN-AAA Mobility Message 328 Authentication Option. 330 G4.5 The HA MUST include the Mobile Node Identifier option [7] in 331 the AAA transactions with the AAAH server. 333 G4.6 The AAAH server SHOULD be able to authenticate the MN 334 identified by the value in the Mobile Node Identifier option using 335 the value in MN-AAA Mobility Message Authentication Option and the 336 corresponding value of the SPI. 338 G4.7 If the MN-AAA Mobility Message Authentication Option is not 339 included by the HA or the MN-AAA Mobility Message Authentication 340 Option is included and the MN-AAA authentication is successful, 341 the AAAH MUST send the keying material for MN-HA key to the HA if 342 the HA requested for MN-HA keying material only. The AAAH MUST 343 send the MN-HA key and the corresponding SPI value to the HA if 344 the HA requested for MN-HA key and SPI. 346 5.5. Provisioning of Configuration Parameters 348 o The HA SHOULD be able to communicate to the AAAH server the Home 349 Address allocated to the MN and the FQDN of the MN (e.g., for 350 allowing the AAAH server to perform a DNS update on behalf of the 351 MN). 353 o The AAAH SHOULD be able to indicate to the HA if the MN is 354 authorized to autoconfigure its Home Address. 356 6. Goals for the AAA-NAS interface 358 In the integrated scenario, the AAA server provides the HA 359 information to the NAS as part of the whole AAA operations for 360 network access. 362 G6.1 The AAAH server MUST be able to communicate the Home Agent 363 Information (IP Address or FQDN) to the NAS. 365 G6.2 The NAS SHOULD be able to notify the AAAH of the 366 functionalities described in [4]. 368 G6.3 The ASP/MSP SHOULD be able to indicate to the MSA if it can 369 allocate a Home Agent to the MN. Therefore the NAS SHOULD be able 370 to include suggested HA address in the ASP in the NAS - AAA 371 interaction. 373 G6.4 The AAA server of the MSA MUST be able to indicate to the NAS 374 whether the MN is authorized to use a local Home Agent (i.e. a 375 Home Agent in the ASP/MSP). 377 G6.5 The overall AAA solution for integrated scenario MUST support 378 the scenario where the AAA server of the ASA/MSA used for network 379 access authentication is different from the AAA server used for 380 mobility service authentication and authorization. 382 7. IANA Considerations 384 This document does not require actions by IANA. 386 8. Security Considerations 388 As stated in Section 5.1 the AAA-HA interface must provide mutual 389 authentication, integrity and replay protection. Furthermore, if 390 security parameters (e.g., IKE pre-shared key) are transferred 391 through this interface, confidentiality is strongly recommended to be 392 supported. In this case the links between the HA and the AAA server 393 of the MSA and between the NAS and the AAA server must be secure. 395 9. Acknowledgements 397 The authors would like to thank James Kempf, Alper Yegin, Vijay 398 Devarapalli, Basavaraj Patil, Gopal Dommety and Madjid Nakhjiri for 399 their comments and feedback. Moreover the authors would like to 400 thank Hannes Tschofenig for his deep technical and editorial review 401 of the draft. Finally the aithors would like to thank Kuntal 402 Chowdhury who contribbuted identifying the goals related to rfc4285 403 authentication. 405 10. References 407 10.1. Normative References 409 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 410 IPv6", RFC 3775, June 2004. 412 [2] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 413 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 415 [3] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 416 Bootstrapping in Split Scenario", RFC 5026, October 2007. 418 [4] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 419 Integrated Scenario", 420 draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in 421 progress), July 2007. 423 [5] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 424 "Authentication Protocol for Mobile IPv6", RFC 4285, 425 January 2006. 427 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 428 Levels", BCP 14, RFC 2119, March 1997. 430 [7] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 431 "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", 432 RFC 4283, November 2005. 434 10.2. Informative References 436 [8] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 437 December 2005. 439 [9] Soliman, H., "Mobile IPv6 support for dual stack Hosts and 440 Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-06 (work in 441 progress), November 2007. 443 Authors' Addresses 445 Gerardo Giaretta 446 Qualcomm 447 5995 Morehouse Drive 448 San Diego, 92109 449 USA 451 Email: gerardog@qualcomm.com 453 Ivano Guardini 454 Telecom Italia Lab 455 via G. Reiss Romoli, 274 456 TORINO, 10148 457 Italy 459 Email: ivano.guardini@telecomitalia.it 461 Elena Demaria 462 Telecom Italia Lab 463 via G. Reiss Romoli, 274 464 TORINO, 10148 465 Italy 467 Email: elena.demaria@telecomitalia.it 469 Julien Bournelle 470 Orange Labs 472 Email: julien.bournelle@gmail.com 474 Rafa Marin Lopez 475 University of Murcia 476 30071 Murcia 477 Spain 479 Email: rafa@dif.um.es 481 Full Copyright Statement 483 Copyright (C) The IETF Trust (2007). 485 This document is subject to the rights, licenses and restrictions 486 contained in BCP 78, and except as set forth therein, the authors 487 retain all their rights. 489 This document and the information contained herein are provided on an 490 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 491 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 492 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 493 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 494 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 495 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 497 Intellectual Property 499 The IETF takes no position regarding the validity or scope of any 500 Intellectual Property Rights or other rights that might be claimed to 501 pertain to the implementation or use of the technology described in 502 this document or the extent to which any license under such rights 503 might or might not be available; nor does it represent that it has 504 made any independent effort to identify any such rights. Information 505 on the procedures with respect to rights in RFC documents can be 506 found in BCP 78 and BCP 79. 508 Copies of IPR disclosures made to the IETF Secretariat and any 509 assurances of licenses to be made available, or the result of an 510 attempt made to obtain a general license or permission for the use of 511 such proprietary rights by implementers or users of this 512 specification can be obtained from the IETF on-line IPR repository at 513 http://www.ietf.org/ipr. 515 The IETF invites any interested party to bring to its attention any 516 copyrights, patents or patent applications, or other proprietary 517 rights that may cover technology that may be required to implement 518 this standard. Please address the information to the IETF at 519 ietf-ipr@ietf.org. 521 Acknowledgment 523 Funding for the RFC Editor function is provided by the IETF 524 Administrative Support Activity (IASA).