RFC 5637

Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6

📅 published September 2009, from ietf

RFC 5637 🎀 Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6

okay bestie, this one is the Informational RFC from September 2009 📅 and it's from the Network Working Group 💖. The authors are G. Giaretta (Qualcomm), I. Guardini, E. Demaria (Telecom Italia), J. Bournelle (Orange Labs), and R. Lopez (University of Murcia) 🫶. It's a requirements doc, not a spec, and it doesn't obsolete or update any other RFC ✨.

Abstract 🌸

okay so, commercial and enterprise setups can offer Mobile IPv6 as a service through a Mobility Services Provider (MSP) 🧚. When that happens, every protocol operation might need explicit authorization and tracing, which means Mobile IPv6 has to talk to the AAA infrastructure 🔥. Plugging in the AAA infrastructure (like a Network Access Server and an AAA server) also gives you a helpful piece for Mobile IPv6 bootstrapping 💅. This doc walks through the scenarios where a AAA interface for Mobile IPv6 is needed, and lists the design goals and requirements for that interface 👑.

Status of This Memo 🦋

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents 🍓

1. Introduction ....................................................3
2. Terminology .....................................................3
3. Motivation ......................................................4
4. Bootstrapping Scenarios .........................................4
   4.1. Split Scenario .............................................5
   4.2. Integrated Scenario ........................................6
5. Goals for AAA-HA Interface ......................................6
   5.1. General Goals ..............................................6
   5.2. Service Authorization ......................................7
   5.3. Accounting .................................................8
   5.4. Mobile Node Authentication .................................8
   5.5. Provisioning of Configuration Parameters ...................8
6. Goals for the AAA-NAS Interface .................................9
7. Security Considerations .........................................9
8. Acknowledgements ................................................9
9. References .....................................................10
   9.1. Normative References ......................................10
   9.2. Informative References ....................................10

1. Introduction 💖

okay so, Mobile IPv6 [1] gives you the basic IP mobility stuff for IPv6 🦋. When you run Mobile IPv6 in tightly managed environments that use the AAA (Authentication, Authorization, and Accounting) infrastructure, you need an interface between Mobile IPv6 and AAA protocols 🔥. Two bootstrapping scenarios for Mobile IPv6 service [2], the split [3] and integrated [6] ones, also need a message exchange between the Home Agent (HA) and the AAA infrastructure for authentication and authorization 🫶. They need a message exchange between the AAA server and the NAS too, so the visited network gets the configuration info it needs (like the Home Agent address) ✨.

This doc describes the scenarios where a AAA interface is needed 🎀. It also lists design goals and requirements for the HA-to-AAA-server and NAS-to-AAA-server communication, for the split and integrated scenarios 💅. The requirements are listed in case either IPsec or RFC 4285 [4] is used for Mobile IPv6 authentication 👑.

This document only describes requirements, goals, and scenarios. It does not provide solutions 🌸.

Notice that this document builds on the security model of the AAA infrastructure 🔐. So the end host/user shares credentials with the home AAA server, and the communication between the AAA server and the AAA client may be protected 🧚. If the AAA server and the AAA client aren't part of the same administrative domain, there is typically some sort of contractual relationship between those domains, in the form of roaming agreements 🍓.

2. Terminology 🌈

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5]. The qualification is that, unless otherwise stated, these words apply to the design of the AAA protocol extension, not its implementation or its usage 💜.

The following terms are extracted from [2] 🦋.

  • Access Service Authorizer (ASA). A network operator that authenticates a Mobile Node and establishes the Mobile Node's authorization to receive Internet service 🔥.
  • Access Service Provider (ASP). A network operator that provides direct IP packet forwarding to and from the end host 🫶.
  • Mobility Service Authorizer (MSA). A service provider that authorizes Mobile IPv6 service ✨.
  • Mobility Service Provider (MSP). A service provider that provides Mobile IPv6 service. To get that service, the Mobile Node must be authenticated and prove authorization to obtain it 👑.

3. Motivation 🎀

The Mobile IPv6 spec [1] requires that Mobile Nodes (MNs) are provisioned with a set of configuration parameters, namely the Home Address and the Home Agent Address, so they can do a home registration 💅. On top of that, MNs and Home Agents (HAs) need to share the cryptographic material needed to set up IPsec security associations that protect Mobile IPv6 signaling (like shared keys or certificates) 🔐. This is called the bootstrapping problem 🌸. As described in [2], the AAA infrastructure can be the central piece that enables dynamic Mobile IPv6 bootstrapping 🧚. In that setup, the AAA infrastructure can take over the end host's authentication from the AAA server, and deliver the necessary configuration parameters to the visited network (like the Home Agent address, as specified in [6]) 🍓.

Also, if Mobile IPv6 is a service run by a Mobility Service Provider (MSP), then all protocol operations (like home registrations) may need to be explicitly authorized and monitored, for example for accounting purposes 💖. This can be done by relying on the AAA infrastructure of the Mobility Service Authorizer (MSA), which stores user profiles and credentials 🦋.

4. Bootstrapping Scenarios 🌈

This section describes some bootstrapping scenarios where the MSP's AAA infrastructure has to talk to the Home Agent 🔥. It also describes why MIPv6-aware communication between the AAA server and the Network Access Server (NAS) is needed 🫶. The purpose here is just to explain the situations where bootstrapping is required. The actual mechanisms and extra details are specified elsewhere or left for future work (see, e.g., [2], [3], and [6]) ✨.

4.1. Split Scenario 🎀

In the split scenario [3], the mobility service and the network access service are assumed to not be provided by the same administrative entity 💅. That means the mobility service is authorized by the MSA, which is a different entity from the ASA 👑.

In this scenario, the Mobile Node finds the Home Agent Address using the Domain Name Service (DNS) 🌸. It queries the address either by the Home Agent name or by service name 🧚. In the former case, the Mobile Node is configured with the Fully Qualified Domain Name (FDQN) of the Home Agent 🍓. In the latter case, [3] defines a new service resource record (SRV RR) 💖.

Then the Mobile Node does an IKEv2 [7] exchange with the HA 🦋. This sets up IPsec Security Associations (SAs) to protect Mobile IPv6 signaling, and configures its Home Address (HoA) 🌈. Mutual authentication for IKEv2 between the Mobile Node and the Home Agent can be done with or without the Extensible Authentication Protocol (EAP) 🔥.

If EAP is used for authentication, the operator can pick any available EAP methods 🫶. Using EAP with the AAA infrastructure lets the HA check the validity of each MN's credentials with the AAA infrastructure, instead of having to keep credentials for every MN itself ✨. It also allows roaming for Mobile IPv6 service, where the MSP and MSA belong to different administrative domains 🎀. In that case, the HA in the MSP can check the validity of the credentials the MN provides with the AAA infrastructure of the MSA, and receive the relevant authorization information 💅.

The Mobile Node may also want to update its FQDN in the DNS with the newly allocated Home Address 👑. [3] recommends that the HA does the DNS entry update on behalf of the Mobile Node 🌸. For that, the Mobile Node puts its FDQN in the IKEv2 exchange (in the IDi field in IKE_AUTH) and adds a DNS Update Option to the Binding Update message sent to the HA 🧚.

When the Mobile Node uses a Home Agent that belongs to a different administrative domain (MSP != MSA), the local HA may not share a security association with the home DNS server 🙈. In this case, [3] suggests that the home AAA server is responsible for the update. Thus, the HA should send the (FDQN, HoA) pair to the home AAA server 💀.

4.2. Integrated Scenario 🌸

Okay so in the integrated scenario, the Access Service Authorizer (ASA) and the Mobility Service Authorizer (MSA) are the same entity 💅. More details on this kind of scenario are being worked on separately [6].

The Home Agent can live either in the Access Service Provider's network or in a separate network. If it's in the access network, the MSP is the same entity as the ASP. If it's in a separate network, the MSP and ASP are different entities 🧚.

Here's how it goes. The Mobile Node finds the Home Agent Address using DHCPv6. If the user is authorized for Mobile IPv6 service, then during network access authentication, the AAAH (the AAA server in the home network) sends info about the assigned Home Agent to the NAS where the Mobile Node is currently attached 🦋. To ask for Home Agent data, the Mobile Node sends a DHCPv6 Information Request to the All_DHCP_Relay_Agents_and_Servers multicast address. In that request, it can say whether it wants a Home Agent from the visited domain (ASP/MSP) or from the home domain (ASA/MSA). Either way, the NAS acts as a DHCPv6 relay. When the NAS gets the DHCPv6 Information Request, it passes the Home Agent info it got from the AAAH server to the DHCP server, for instance using mechanisms defined in [6] ✨.

If the Mobile Node can't get Home Agent info via DHCPv6, it can try the default DNS-based mechanism described in [3]. Once it has the Home Agent info, the way it bootstraps the HoA, the IPsec Security Association, and the authentication and authorization with the MSA is the same as in the bootstrapping solution for the split scenario [3] 💖.

5. Goals for AAA-HA Interface 🎀

Remember how Section 4 said we need to define extensions for the AAA protocol that runs between the AAA server of the MSA and the HA? Yep, these next sections list the goals for that interface. This communication is needed for both the split and integrated scenarios 🫶.

5.1. General Goals 💜

  • G1.1: The communication between the AAAH server and the HA MUST reuse existing AAA security mechanisms with regard to authentication, replay, integrity, and confidentiality protection. These communication security mechanisms prevent a number of classical threats, including the alteration of exchanged data (e.g., Mobile IPv6 configuration parameters) and the installation of unauthorized state 🔐.

5.2. Service Authorization 🌈

  • G2.1: The AAA-HA interface MUST allow the use of a Network Access Identifier (NAI) to identify the user.
  • G2.2: The HA MUST be able to query the AAAH server to verify Mobile IPv6 service authorization for the Mobile Node.
  • G2.3: The AAAH server MAY assign explicit operational limitations and authorization restrictions on the HA (e.g., packet filters, QoS parameters).
  • G2.4: The AAAH server MUST be able to send an authorization lifetime to the HA to limit Mobile IPv6 session duration for the MN.
  • G2.5: The HA MUST be able to request that the AAAH server grant an extension of the authorization lifetime to the MN.
  • G2.6: The AAAH server MUST be able to force the HA to terminate an active Mobile IPv6 session for authorization policy reasons (e.g., credit exhaustion).
  • G2.7: The HA MUST be able to indicate to the AAAH server the IPv6 HoA that will be assigned to the MN.
  • G2.8: The AAAH server MUST be able to authorize the MN to use an IPv6 HoA and MUST indicate that to the HA.
  • G2.9: The AAAH server MUST be able to indicate to the HA whether or not the return routability test (HoT (Home Test) and HoTi (Home Test Init)) shall be permitted via the HA for a given MN.
  • G2.10: The AAAH server MUST be able to support different levels of Mobile IPv6 authorization. For example, the AAAH server may authorize the MN to use MIPv6 (as defined in [1]) or may authorize the MN to utilize an IPv4 HoA assigned for Dual Stack MIPv6 [8].
  • G2.11: The AAAH server MUST be able to indicate to the HA whether the bearer traffic for the MN needs to receive IPsec Encapsulating Security Payload (ESP) protection.
  • G2.12: The HA MUST be able to authenticate the MN through the AAAH server in case a pre-shared key is used in IKEv2 for user authentication. The exact procedure is part of the solution space.

5.3. Accounting 🧾

  • G3.1: The AAA-HA interface MUST support the transfer of accounting records needed for service control and charging. These include (but may not be limited to): time of binding cache entry creation and deletion, octets sent and received by the Mobile Node in bi-directional tunneling, etc.

5.4. Mobile Node Authentication 🔑

  • G4.1: The AAA-HA interface MUST allow the HA to act as a pass-through EAP authenticator.
  • G4.2: The AAA-HA interface MUST support authentication based on the Mobility Message Authentication Options defined in [4].
  • G4.3: The AAAH server MUST be able to provide a MN-HA key (or data used for subsequent key derivation of the MN-HA key by the HA) to the HA if requested. Additional data, such as the Security Parameter Index (SPI) or lifetime parameters, are sent along with the keying material.
  • G4.4: The HA supporting the Authentication Protocol MUST be able to request that the AAAH server authenticate the MN with the value in the MN-AAA Mobility Message Authentication Option.
  • G4.5: The HA MUST include an identifier of the Mobile Node in the AAA transactions with the AAAH server.

5.5. Provisioning of Configuration Parameters ⚙️

  • The HA SHOULD be able to communicate to the AAAH server the Home Address allocated to the MN and the FQDN of the MN (e.g., for allowing the AAAH server to perform a DNS update on behalf of the MN).
  • The AAAH server SHOULD be able to indicate to the HA if the MN is authorized to autoconfigure its Home Address. If the AAAH does not indicate to the HA if a MN is authorized to autoconfigure its address, the MN is not authorized.

6. Goals for the AAA-NAS Interface 🛰️

In the integrated scenario, the AAA server provides the HA information to the NAS as part of the whole AAA operation for network access 💫.

  • G6.1: The AAAH server MUST be able to communicate the Home Agent Information (IP address or FQDN) to the NAS.
  • G6.2: The NAS MUST be able to notify the AAAH server if it supports the AAA extensions designed to receive the HA assignment information.
  • G6.3: The ASP/MSP supporting the allocation of a Home Agent MUST be able to indicate to the MSA if it can allocate a Home Agent to the MN. Therefore, the NAS MUST be able to include a suggested HA address in the ASP in the AAA-NAS interaction.
  • G6.4: The AAA server of the MSA MUST be able to indicate to the NAS whether the MN is authorized to use a local Home Agent (i.e., a Home Agent in the ASP/MSP).
  • G6.5: The overall AAA solution for the integrated scenario MUST support the scenario where the AAA server of the ASA/MSA used for network access authentication is different from the AAA server used for mobility service authentication and authorization.

7. Security Considerations 🚨

As stated in Section 5.1, the AAA-HA interface must provide mutual authentication, integrity, and replay protection. Furthermore, if security parameters (e.g., IKE pre-shared key) are transferred through this interface, confidentiality is strongly recommended to be supported. In this case, the links between the HA and the AAA server of the MSA and between the NAS and the AAA server MUST be secure. 💀

8. Acknowledgements 🙏

The authors want to thank James Kempf, Alper Yegin, Vijay Devarapalli, Basavaraj Patil, Gopal Dommety, Marcelo Bagnulo, and Madjid Nakhjiri for their comments and feedback 💕. They also want to thank Hannes Tschofenig for his deep technical and editorial review of the document 👑. Finally, the authors want to thank Kuntal Chowdhury, who contributed by identifying the goals related to RFC 4285 authentication 🌟.

9. References 📚

9.1. Normative References

  • [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
  • [2] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
  • [3] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
  • [4] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006.
  • [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2. Informative References

  • [6] Chowdhury, K., Ed., and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", Work in Progress, April 2008.
  • [7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
  • [8] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.

Authors' Addresses 💌

Gerardo Giaretta
Qualcomm
5775 Morehouse Drive
San Diego, CA  92109
USA

EMail: gerardo@qualcomm.com


Ivano Guardini
Telecom Italia Lab
via G. Reiss Romoli, 274
TORINO  10148
Italy

EMail: ivano.guardini@telecomitalia.it


Elena Demaria
Telecom Italia Lab
via G. Reiss Romoli, 274
TORINO  10148
Italy

EMail: elena.demaria@telecomitalia.it


Julien Bournelle
Orange Labs

EMail: julien.bournelle@gmail.com


Rafa Marin Lopez
University of Murcia
30071 Murcia
Spain

EMail: rafa@dif.um.es
📦 where this page comes from