RFC 5030

Mobile IPv4 RADIUS Requirements

📅 published October 2007, from ietf

RFC 5030: Mobile IPv4 RADIUS Requirements 🎀

Okay bestie, so this is an Informational RFC from the Network Working Group, dated October 2007 🦋 It was written by M. Nakhjiri (Motorola, the editor 🌸), K. Chowdhury (Starent Networks), A. Lior (Bridgewater Systems), and K. Leung (Cisco Systems). Its header doesn't list anything it obsoletes or updates. Slay for keeping it simple 💅

Status of This Memo ✨

This memo is here to provide information for the Internet community 📚 It does not specify an Internet standard of any kind, and distribution of it is unlimited 🌈

Abstract 💜

This doc gives an applicability statement and a scope definition for specifying Remote Authentication Dial-In User Service (RADIUS) extensions that support Mobile IPv4. The whole point is to let people specify RADIUS attributes that help out with Mobile IPv4 signaling procedures 🧚

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.  Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . . . 3
  3.1.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
  3.2.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.  Attributes  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
  8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7

1. Introduction 🦋

Okay so first things first 💅 To kick-start the Mobile IPv4 [RFC3344] processing of its packets by Mobile IP agents, a mobile node (MN) has to be able to get a pair of home and care of addresses (HoA and CoA, respectively), find a willing agent to be its Home Agent (HA), and then do a registration process with that HA.

The registration process is an exchange of a registration request and a registration reply message between the MN and the HA. The specification in [RFC3344] lets an MN start registration before it has its home address or the address of its HA. Getting those parameters is typically part of a process called bootstrapping 🌱

Successful processing of registration request and reply messages depends on, among other things, successfully creating and verifying a bunch of authentication extensions. These were built specifically to protect the integrity and security of those messages and the entities processing them, i.e., the MN, the HA, and sometimes the Foreign Agents (FAs) [RFC3344] 🔐 Creating and verifying these extensions requires trust relationships and shared keys between the MN and each of the mobility agents. Creating those trust relationships, usually called mobility security associations (MSAs), is considered outside the scope of the base Mobile IPv4 specification in [RFC3344]. It's also desired to avoid the scalability issues that come from creating static security associations between an MN and all possible mobility agents 😭 So, establishing the associations dynamically, using the existing relationship between the MN and the AAA server, is the preferred move 🫶

To allow for using an existing AAA infrastructure in bootstrapping the Mobile IPv4 parameters and security relationships, the Mobile IPv4 working group developed extensions that let the MN authenticate to the home AAA server [RFC4721]. The extensions also let the MN ask the AAA server for help creating mobility security associations [RFC3957] with the mobility agents, using the pre-established trust relationship between the MN and its home AAA server 👑

Mobile IPv4 extensions are necessary for using AAA infrastructure for Mobile IPv4 purposes, but they aren't sufficient on their own 🙈 The interaction between the MN and the mobility agents (HA and FA) is based on Mobile IP signaling. However, the signaling beyond the mobility agents to the AAA server is typically based on AAA protocols. Around the time the Mobile IP extensions were being developed, the AAA community was busy designing a successor to RADIUS ✨

So the Mobile IP group put together a set of guidelines and requirements from the Mobile IP standpoint [RFC2977] specifically for that successor (which turned out to be Diameter). Those requirements led to a specification for using Diameter in Mobile IPv4 bootstrapping [RFC4004]. The requirements for Mobile IP Authentication, Authorization, and Accounting [RFC2977] were standardized after RADIUS was standardized [RFC2865] 🕰️

Thus, it's obvious that RADIUS does not and cannot meet all the requirements listed in [RFC2977] without an extensive design change 😬 Because of that, no RADIUS attributes have been standardized within the IETF for Mobile IP support so far. However, without IETF-standardized RADIUS attributes, different wireless SDOs have gone ahead and developed Vendor Specific Attributes (VSAs) for Mobile IPv4 support. Using different vendor specific RADIUS attributes and procedures for the same Mobile IPv4 bootstrapping purpose at different SDOs is deemed to cause a lack of interoperability between these wireless standards, which could potentially hinder mobility across these wireless networks 🚧

To fix this, it's desired to standardize a set of RADIUS attributes within the IETF, so there's a consistent and interoperable interaction with RADIUS-based AAA infrastructure during the Mobile IPv4 Registration procedure 🎀 The bootstrapping attributes can include configuration parameters as well as material used for provisioning security of Mobile IPv4 messaging (authentication), as defined by [RFC4721] and [RFC3957].

As things stand today, RADIUS cannot meet all the requirements in [RFC2977]. The purpose of those requirements is to define a set of goals and non-goals specifically for RADIUS when it comes to helping mobile nodes and mobility agents bootstrap Mobile IPv4 operation 🌈

2. Terminology 📝

Here's the vocab check, bestie 💖 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 [RFC2119].

3. Goals and Non-Goals 🎯

Since this document is a requirement specification for RADIUS extensions that support Mobile IPv4 interaction with RADIUS infrastructure, the goals and non-goals only refer to those RADIUS extensions that are required to support Mobile IPv4 🧚

3.1. Goals ⭐

The scope of the work is to standardize RADIUS attributes and to define the procedure by which the Mobile IPv4 agents (e.g., Home agent (HA) and Foreign Agent (FA)) map the Mobile IP registration message fields into the proposed RADIUS attributes, and vice versa.

  • RADIUS servers are REQUIRED to be able to understand and process the attributes to be defined for Mobile IPv4 support and to perform verification of authentication extensions specified in [RFC4721]. RADIUS proxies are expected to be able to forward messages including the Mobile IPv4 related attributes as they would with any other RADIUS messages and attributes.
  • All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs the following: [RFC2865], [RFC2866], [RFC2867], [RFC2868], [RFC2869], [RFC3576], [RFC3579], and [RFC3580]. 💜
  • Mobile IP agents (FA and HA) are REQUIRED to operate as RADIUS clients (NASes in context of [RFC2865]) when translating RADIUS signaling into Mobile IP signaling, and vice versa. Details on the behavior of Mobile IP agents as RADIUS clients are to be provided by the solution document describing the RADIUS extensions for Mobile IP support.

3.2. Non-Goals 🙅‍♀️

The scope of this work is to only standardize RADIUS attributes and to define the procedure by which the Mobile IPv4 agents (e.g., Home agent (HA) and Foreign Agent (FA)) map the Mobile IP registration message fields into the proposed RADIUS attributes, and vice versa. Extending the functionality of the existing protocol or RADIUS servers is not intended. More specifically, the following are NON-GOALS:

  • Enhancing RADIUS Security: Creating new security properties for RADIUS, such as creating key transport capabilities, is not the goal. No new security mechanisms are to be defined for the transport of RADIUS Access Requests in relation to the support of Mobile IPv4 bootstrapping. Existing RADIUS authentication procedures, e.g., Message-Authenticator (80) described in [RFC2869], are used. The security considerations for using RADIUS in bootstrapping Mobile IPv4 are described in a later section of this document. 🔐
  • Enhancing RADIUS transport reliability: The transport properties of RADIUS remain intact. No new reliability mechanisms are defined in the transport of such Access Requests.
  • Extending RADIUS message set: RADIUS extensions for bootstrapping Mobile IPv4 are not to define new RADIUS messages. The Diameter Mobile IP application [RFC4004] has defined new command codes to support Mobile IP signaling, depending on whether the Diameter server is dealing with a Mobile IP HA or an FA. RADIUS currently doesn't have any messages that correspond to these Diameter commands. Instead, RADIUS extensions for Mobile IPv4 bootstrapping need to provide proposals for new RADIUS attributes that facilitate Diameter-RADIUS messaging translation without defining any new RADIUS messaging. At the same time, the RADIUS extensions for Mobile IPv4 need to re-use Diameter AVPs to the fullest extent possible 🧩
  • RFC 2977 compatibility: Extending RADIUS in a way that fulfills the full list of requirements in [RFC2977] will not be attempted. 🚫

4. Attributes 🎀

A specification of the RADIUS extensions for Mobile IPv4 needs to describe the full set of attributes required for RADIUS-Mobile IP interaction. Some of the attributes may already be standardized, while others will require standardization and IANA type assignments 💅

5. IANA Considerations 🔢

This requirement document doesn't allocate any numbers, so there are no IANA considerations. On the other hand, future solution documents for RADIUS support of Mobile IPv4 will likely introduce new RADIUS attributes. Thus, those documents will need new attribute type numbers assigned by IANA 🦋

Part 1 wraps here, bestie 🫶 Part 2 is coming with the rest of the doc, so stay tuned 💜

6. Security Considerations 🔒✨

okay bestie, this section is where the drama lives 😭 first the tea: securing RADIUS is a specific non-goal for the RADIUS Mobile IP extensions, so don't expect it to fix everything here 💅. this is a requirements doc, not a solution spec, so it doesn't add any new security considerations. the existing RADIUS ones still apply, and that's it 🫶

the big vibe check is trust. RADIUS assumes intermediary nodes are trusted 👀, but there's also a real worry about using AAA protocols that rely on hop-by-hop security to distribute keys 💀. hop-by-hop key distribution can clash with some requirements in [RFC4962] 🙈. one says a key MUST be bound to the parties that are expected to have access to the keying material. the other says parties that do not require access to a key to perform their role MUST not have access to the key 🚨. both of those basically say "don't trust middle nodes or proxies with keys" 😭

and here's the messy part: RADIUS has no end-to-end security mechanism, so we literally can't slap a MUST requirement on not trusting proxies 🥲. the RADIUS Extension working group is working on procedures for wrapping key material inside RADIUS attributes 🎀. until that's done, Mobile IP inside RADIUS might have to rely on trusting intermediaries, even with all these security concerns hanging over it 💔

for protecting attributes in the Access Request, [RFC2868], Section 3.5 has a mechanism for encrypting RADIUS attributes, like passwords 🔐. there's also ongoing work on wrapping sensitive attributes, like key material in RADIUS Access Accept messages ✨. that work is considered part of the RADIUS crypto-agility extensions, and once it's done it can help distribute sensitive attributes, like keying material, from RADIUS servers 🦋

and last but not least, you can protect RADIUS transactions with IPsec, for example as in RFC3579 🛡️🌸

7. Acknowledgements 🫶

the authors want to thank Alan DeKok for reviewing and giving feedback 💖, and Pete McCann and Jari Arkko for shepherding this document so carefully 👑

8. References 📚🧚

8.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
           "Remote Authentication Dial In User Service (RADIUS)",
           RFC 2865, June 2000.

[RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

[RFC2867]  Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting
           Modifications for Tunnel Protocol Support", RFC 2867,
           June 2000.

[RFC2977]  Glass, S., Hiller, T., Jacobs, S., and C. Perkins, "Mobile
           IP Authentication, Authorization, and Accounting
           Requirements", RFC 2977, October 2000.

[RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
           August 2002.

[RFC3957]  Perkins, C. and P. Calhoun, "Authentication,
           Authorization, and Accounting (AAA) Registration Keys for
           Mobile IPv4", RFC 3957, March 2005.

[RFC4004]  Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
           P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
           August 2005.

[RFC4721]  Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4
           Challenge/Response Extensions (Revised)", RFC 4721,
           January 2007.

[RFC4962]  Housley, R. and B. Aboba, "Guidance for Authentication,
           Authorization, and Accounting (AAA) Key Management",
           BCP 132, RFC 4962, July 2007.

8.2. Informative References

[RFC2868]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
           M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
           Support", RFC 2868, June 2000.

[RFC2869]  Rigney, C., Willats, W., and P. Calhoun, "RADIUS
           Extensions", RFC 2869, June 2000.

[RFC3576]  Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
           Aboba, "Dynamic Authorization Extensions to Remote
           Authentication Dial In User Service (RADIUS)", RFC 3576,
           July 2003.

[RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
           Dial In User Service) Support For Extensible
           Authentication Protocol (EAP)", RFC 3579, September 2003.

[RFC3580]  Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
           "IEEE 802.1X Remote Authentication Dial In User Service
           (RADIUS) Usage Guidelines", RFC 3580, September 2003.

Authors' Addresses 🎀

Madjid Nakhjiri (editor)
Motorola

EMail: madjid.nakhjiri@motorola.com


Kuntal Chowdhury
Starent Networks

EMail: kchowdhury@starentnetworks.com


Avi Lior
Bridgewater Systems

EMail: avi@bridgewatersystems.com


Kent Leung
Cisco Systems
170 West Tasman Drive
San Jose, CA  95134
US

EMail: kleung@cisco.com

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 💜

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

📦 where this page comes from