wdiff rfc5030.original rfc5030.txt

Network Working Group M. Nakhjiri, Ed.
Internet-Draft Huawei USA
Intended status:
Request for Comments: 5030 Motorola
Category: Informational K. Chowdhury
Expires: January 21, 2008
Starent Networks
A. Lior
Bridgewater Systems
K. Leung
Cisco Systems
July 20,
October 2007

Mobile IPv4 RADIUS requirements
draft-ietf-mip4-radius-requirements-04.txt Requirements

Status of this This Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of

This memo provides information for the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. community. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list does
not specify an Internet standard of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list any kind. Distribution of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 21, 2008. this
memo is unlimited.

Abstract

This document provides an applicability statement as well as a scope
definition for specifying RADIUS Remote Authentication Dial-In User Service
(RADIUS) extensions to support Mobile IPv4. The goal is to allow
specification of RADIUS attributes to assist the Mobile IPv4
signaling procedures.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 . 3
3. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . . 4 . 3
3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 . 4
3.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 . 4
4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 . 5
6. Security considerations Considerations . . . . . . . . . . . . . . . . . . . 6 . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 10 7

1. Introduction

To kick start the Mobile IPv4 [RFC3344] processing of its packets by
Mobile IP agents, a mobile node (MN) needs to be able to acquire a
pair of home and care of addresses (HoA and CoA, respectively), find
a willing agent to act as a Home Agent, HA, Agent (HA) for the MN and perform a
registration process with the HA. The registration process consists
of an exchange of a registration request and reply message between
the MN and the HA. The specification in [RFC3344] allows an MN to
start the registration process prior to having acquired its home
address or the address of its HA. Acquiring those parameters by the
MN is typically part of a process referred to as bootstrapping.

Successful processing of registration requests, and replies among
other things depends on successful creation and verification of a
number of authentication extensions developed specifically to protect
the integrity and security of the registration requests and replies
and the entities processing them, i.e. i.e., MN, HA and some times,
foreign agents, FA
Foreign Agents (FAs) [RFC3344]. Creation as well as verification of
these extensions requires existence of trust relationships and shared
keys between MN and each of the mobility agents. However, creation
of these trust relationships, typically referred to as mobility
security associations, MSA, associations (MSAs) is considered outside scope of the base
Mobile IPv4 specification defined in [RFC3344]. It is desired to
avoid Avoiding the
scalability issues arising from creating static security associations
between an MN and all possible mobility agents. Thus it agents is preferred to establish desired. Thus,
establishing the associations dynamically using the pre-
existing pre-existing
relationship between the MN and the AAA server. server is preferred.

To allow for utilization of an existing AAA infrastructure in the
bootstrapping of the Mobile IPv4 parameters and security
relationships, the Mobile IPv4 working group has developed extensions
to allow the MN to authenticate to the home AAA server [RFC4721] and
to request assistance from the AAA server in creation of security
associations [RFC3957] with the mobility agents, all based on the
pre-established trust relationship between the MN and its home AAA
server.

However, utilization of the AAA infrastructure for Mobile IPv4
purposes,
purposes involves both Mobile IP and AAA signaling, where the
interaction between the MN and the mobility agents (HA and FA) is
based on Mobile IP signaling, while the signaling beyond the mobility
agents to the AAA server is based on AAA protocols. Around the same
time, when the specification was being developed, the AAA community
was in the process of designing Diameter as a successor to RADIUS.
Thus, the Mobile IP group developed a set of guidelines and
requirements specifically from the Mobile IP standpoint [RFC2977] for
such a successor. These requirements, requirements led to the development of an a
specification for use of using Diameter in Mobile IPv4 bootstrapping
[RFC4004], while the requirement document is essentially standardized
[RFC4004]. The requirements for Mobile IP Authentication,
Authorization, and Accounting [RFC2977] were standardized after the
standardization of RADIUS [RFC2865]

Thus [RFC2865].

Thus, it is obvious that RADIUS does not and cannot meet all the
requirements listed In in [RFC2977] without undergoing an extensive
design change and thus no RADIUS attributes have been standardized
for Mobile IP support thus far. However, in the absence of IETF
standardized RADIUS attributes for that support of MIPv4, different wireless
SDOs have taken the path of developing VSAs Vendor Specific Attributes
(VSAs) for dynamic bootstrapping of Mobile IPv4 registration procedure.
procedures. The use of different VSAs and different RADIUS
procedures for the same purpose of Mobile IPv4 bootstrapping at
different SDOs will cause a lack interoperability between these
wireless standards, potentially hindering mobility across these
wireless networks.

To respond to the described issue, it is desired to standardize a set
of RADIUS attributes within IETF to allow 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].

Given that RADIUS as

As it stands today today, RADIUS cannot meet all the requirements in [RFC2977], the
[RFC2977]. The purpose of this requirement these requirements is to define a set of
goals and nongoals non-goals specifically defined for RADIUS when it comes to
assisting mobile nodes and mobility agents in bootstrapping Mobile
IPv4 operation.

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 [RFC2119].

3. Goals and Non-Goals

Since this document serves as a requirement specification for RADIUS
extensions supporting that support Mobile IPv4 interaction with RADIUS
infrastructure, the goals and non-goals refer to only those RADIUS
extensions that are required for to support of 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. agents (e.g., Home
agent (HA) and Foreign Agent (FA) (FA)) map the Mobile IP registration
message fields into the proposed RADIUS attributes attributes, and vice versa.

o It is required of the 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.

o All RADIUS work MUST be backward compatible with existing RADIUS
RFCs, including RFCs as follows: the following: [RFC2865], [RFC2866],
[RFC2867], [RFC2868], [RFC2869], [RFC3576], [RFC3579], and
[RFC3580].

o It is also required of the 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 signaling, and vice versa. Details on
the behavior of Mobile IP agents as RADIUS clients are to be
provided by the solution draft 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. agents (e.g., Home
agent (HA) and Foreign Agent (FA) (FA)) map the Mobile IP registration
message fields into the proposed RADIUS attributes attributes, and vice versa.
It is not the intention to extend
Extension of the functionality of the existing protocol or RADIUS
servers or protocol. is not intended. More specifically, the following are
NON-GOALS: NON-
GOALS:

o 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. e.g., Message-Authenticator (80) described in
[RFC2869], are used. The security considerations for use of using RADIUS
in bootstrapping Mobile IPv4 are described in a later section of
this document.

o Enhancing RADIUS transport reliability: Transport The transport properties
of RADIUS remain intact. No new reliability mechanisms are
defined in the transport of such Access Requests.

o 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 for to
support of Mobile IP signaling, depending on whether Diameter server
is dealing with a Mobile IP HA or an FA. RADIUS currently does
not 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 facilitates 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.

o RFC2977 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. While some of the attributes may already be
standardized, others will require standardization and IANA type
assignments.

5. IANA Considerations

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

6. Security considerations Considerations

Enhancing security properties of RADIUS are a specific non-goal for
the RADIUS extensions providing support for Mobile IP. Also, as this
is a requirement requirements document and not a solution specification document,
no new security considerations are noted, aside from those that
already exist for RADIUS are noted. RADIUS. As such, the existing RADIUS security
considerations described previously apply, and no additional security
considerations are added here. For instance, the assumption in
RADIUS is that intermediary nodes are trusted, while at the same time
there is a concern on using AAA protocols that use hop by hop hop-by-hop
security to distribute keys. Use of hop by hop hop-by-hop security for key
distribution can be in conflict with some of the requirements stated
in [housley-aaa-key-mgmt], [RFC4962], such as the requirement on binding a key to its context
and the requirement on limitation of the key scope. The former for
instance states that a key Must MUST be bound to the parties that are
expected to have access to the keying material, while the latter
implies that parties that do not require access to a key to perform
their role MUST not have access to the key. Both of these
requirements rule against trusting intermediary nodes and proxies
with distribution of keys. Due to lack of end to end end-to-end security
mechanisms for RADIUS, imposing a MUST requirement for not trusting
proxies is not possible. The RADIUS extension Extension working group is in
the process of specifying procedures for wrapping key materials
within RADIUS attributes. For the time being, support of Mobile IP
within RADIUS may need to be based on trust of intermediaries,
despite the security considerations described.

When it comes to protecting attributes in the Access Request, [RFC2868]
section
[RFC2868], Section 3.5 provides a mechanism for encrypting RADIUS
attributes, such as passwords. There is also work under progress for
specifying wrapping of sensitive attributes, such as key material
within RADIUS Access Accept messages. This work is currently
considered as part of RADIUS crypto-agility extensions and when
completed can be used in the process of distributing sensitive
attributes, such as keying material from RADIUS servers.

It is also possible to protect RADIUS transactions using IPsec (e.g. (e.g.,
as in RFC3579).

7. Acknowledgements

The authors would like to thank Alan DeKok for review and feedback,
and Pete McCann and Jari Arkko for diligent shepherding of this
document.

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", Service (RADIUS)",
RFC 2865, June 2000.

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

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

[RFC2977] Glass, S. 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", Support for IPv4", RFC 3344,
August 2002.

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

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

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

[housley-aaa-key-mgmt]

[RFC4962] Housley, R., R. and B. Aboba, "Guidance for AAA key management",
draft-housley-aaa-key-mgmt-09 (work in progress). 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] Cogdon, 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)
Huawei USA

Email: mnakhjiri@huawei.com
Motorola

EMail: madjid.nakhjiri@motorola.com

Kuntal Chowdhury
Starent Networks

Email:

EMail: kchowdhury@starentnetworks.com

Avi Lior
Bridgewater Systems

Email:

EMail: avi@bridgewatersystems.com

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

Email:

EMail: kleung@cisco.com

Full Copyright Statement

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.

Acknowledgment

Acknowledgement

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).