Internet DRAFT - draft-nakhjiri-radius-mip4
draft-nakhjiri-radius-mip4
RADIUS Mobile IPv4 extensions October 2005
Internet Draft Madjid Nakhjiri
draft-nakhjiri-radius-mip4-02.txt Motorola Labs
Category: Internet draft Kuntal Chowdhury
Expires: May 2006 Starent Networks
Avi Lior
Bridgewater systems
Kent Leung
Cisco Systems
October 2005
RADIUS Mobile IPv4 extensions
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
section 6 of BCP 79.
Internet-Drafts are working documents of 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. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. This Internet-Draft will expire in May, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Mobile IPv4 specifies mechanisms that need assistance from a AAA
server and a AAA infrastructure. Examples of such mechanisms are
Nakhjiri et. al. Expires - May 2006 [Page 1]
RADIUS Mobile IPv4 extensions October 2005
those providing key management and authentication services during a
registration process of the mobile node with MN-AAA authentication
extension. Although Diameter Mobile IP application is being specified
to support the needs of Mobile IPv4 from the point of view of the AAA
infrastructure, such support does not exist within RADIUS framework.
This document defines the RADIUS attributes that provide support for
Mobile IPv4 operation.
Conventions used in this document
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.
Table of Contents
1. Introduction...................................................2
2. Terminology and Assumptions....................................3
3. Protocol Overview..............................................4
3.1 Direct registration to Home Agent..........................5
3.2 Registration through a Foreign Agent.......................9
4. RADIUS entity requirements....................................14
4.1 RADIUS client requirements................................14
4.2 RADIUS server and routing requirements....................15
4.3 Mobile IP agent requirements..............................16
5. Attributes....................................................18
5.1 Use of existing attributes................................18
5.2 Suggested attributes for RADIUS-Mobile support............19
5.3 Attribute List............................................31
6. Diameter compatibility considerations.........................32
7. IANA considerations...........................................33
8. Security considerations.......................................33
9. References....................................................34
Acknowledgments..................................................35
Author's Addresses...............................................35
1. Introduction
Mobile IP provides routing services to the nodes that need to change
their IP address due to mobility [MIPv4]. To help setting up such
routing services, the mobile node (MN) needs to engage in an
authenticated registration message exchange with the Mobile IP
agents. Message authentication is performed by inclusion of specific
authentication extensions to the mobility registration messages and
relies on existence of trust relationships between the mobile node
Nakhjiri et. al. Expires - May 2006 [Page 2]
RADIUS Mobile IPv4 extensions October 2005
and its mobility agents. These trust relationships include, among
other things, keys that are shared between the mobile node and these
agents.
Many times such trust does not exist in advance and hence there is a
need for dynamic key management methods in conjunction with Mobile IP
signaling.
Mobile IPv4 working group has developed extensions for the
registration process to allow the MN and mobility agents to request
assistance from the AAA server in authentication [MIP4CHAL] and
creation of the key material [MIPKEYS], all based on the pre-
established trust relationship between the MN and its home AAA
server.
However, on the AAA side, currently only Diameter provides
specification for interaction with Mobile IP agents [DIAMIP]. The
available RADIUS support for Mobile IP is mostly vendor proprietary
and lacks support for interoperability between vendors. The goal of
this document is to provide a specification for IETF RADIUS
attributes supporting Mobile IPv4.
2. Terminology and Assumptions
The scope of this draft is to introduce RADIUS functionality and
attributes, designed to support Mobile IP registration for roaming
within or beyond the administrative domain of the mobile node. The
design in this document also serves inter-domain scenarios in which
both a foreign AAA server (AAAF) and the home AAA server (AAAH) are
involved. However, to keep the scenario discussions simple we treat
the entire AAA infrastructure as consisting of a AAAF and a AAAH, but
note that in the multi-domain scenario, the operation may involve a
number of AAA proxies (AAA nodes operating between AAAF and AAAH) to
provide Mobile IP-RADIUS interaction for a roaming mobile node.
A critical assumption in this draft is that the MN shares a key,
called MN-AAA key with its home RADIUS server (AAAH).
MN-AAA key
The MN-AAA key is the basis for the creation of all the keys that
are created dynamically between MN and its mobility agents.
Mobility Security Association (MSA)
The security associations that are created as a result of Mobile
IP-AAA signaling are called mobility security association
(MSA)[MIPKEYS].
Home agent (HA)
Nakhjiri et. al. Expires - May 2006 [Page 3]
RADIUS Mobile IPv4 extensions October 2005
A Mobile IP Home Agent that is responsible for generating and
keeping a binding between mobile node home address and its care of
address.
Foreign Agent (FA)
A Mobile IP Foreign agent that is responsible for serving the
mobile node in foreign networks.
Mobile IP Agent (MA)
Mobile IP Agent: Refers to HA or FA or both.
Home AAA server (AAAH)
The AAAH is a RADIUS server that operates in the home network.
The home network is the network that holds the user record.
Foreign AAA server (AAAF)
The AAAF is a RADIUS server that acts as a "forwarding server",
forwarding RADIUS packets to the AAAH. The AAAF resides in the
same domain that hosts the FA in the foreign network or hosts the
HA when the HA is also in the foreign network. Other Broker AAA
‘‘proxy servers’’ may exist between the AAAF and the AAAH. The role
of these "proxy servers" is not germane to this document and will
not be discussed henceforth.
ALL_ZEROs_OR_ONES:
This means an IP address set to either 0.0.0.0 or 255.255.255.255.
In this document the terms AAAF and AAAH refer to RADIUS servers.
3. Protocol Overview
In this section we will provide an overview of a preferred method on
how a mobility agent and a RADIUS server can interact during a mobile
node registration process, to perform registration, authentication
and key distribution. Different standard developing organizations
(such as 3GPP2 and WiMAX) may have alternative signaling procedures
to implement Mobile IP-RADIUS interaction, depending on their
architecture or trust assumptions. Our main objective is to
standardize a set of RADIUS attributes to provide support for such
activities. Depending on the type of Care-of Address and the mobility
agents used during Mobile IPv4 registration there are two possible
cases to consider:
1) When the MN acquires a co-located CoA (CCoA), it performs a
direct registration with the HA without the interaction of a
Mobile IP foreign agent.
2a) When the MN acquires a CoA from a Mobile IP foreign agent (FA)
on the foreign network, the MN must register through the FA and
Nakhjiri et. al. Expires - May 2006 [Page 4]
RADIUS Mobile IPv4 extensions October 2005
use the FA based CoA for Mobile IP registration. The FA forwards
the registration to the HA for processing. b) When the MN acquires
a CCoA but the FA requires the MN to register via the FA (R-bit
set in Agent Advertisement), the MN must send the registration
request to the FA. The FA forwards the registration messages
to/from the HA.
3.1 Direct registration to Home Agent
In the case where the MN acquires a co-located CoA (CCoA), the MN
registers its CCoA with the HA directly. When the MN has a mobility
security association (MSA) with the HA, the HA can authenticate MN
registration directly. However, when this MSA does not exist, the HA
needs to outsource the authentication to the AAA infrastructure. Note
that, this outsourcing requires a pre-established security
association between MN and the AAA server (MN-AAA key).
The HA may reside in the home domain of the mobile node. In such
cases, the HA can reach the AAAH directly or the HA may reside in a
foreign domain, which means the HA must reach the AAAH via the AAA
infrastructure. In the following picture we do not show the AAA
infrastructure (AAAF) that routes this messaging to the AAAH, since
it does not impact the discussion in this draft. The HA in this model
acts as a conversion point, turning Mobile IP registration messages
into RADIUS messages and vice versa.
+--------+
| AAAH |
| |
| server |
+--------+
^ |
Access | | Access
Request | | Response
| v
+--------+ RRQ +---------+
| Mobile | -------------> | Home |
| Node | RRP | Agent |
+--------+ <------------ +---------+
Figure 1a: Direct registration with HA
Nakhjiri et. al. Expires - May 2006 [Page 5]
RADIUS Mobile IPv4 extensions October 2005
MN HA AAAH Server
| Reg Req. | |
|---------> | |
| | Access Request |
| | ------------------------> |
| | Access Accept (key mtrl)|
| | <-------------------------|
|Reg Rep. | |
| <---------| |
Figure 1b: Mobile IP and RADIUS messaging for direct registration.
The operation is as follows:
. The Mobile Node creates a registration request (RRQ) that
includes MN-AAA Authentication extension and various key
generation nonce request extensions [MIPKEY]. The latter
extensions are included by the MN to request key material that
is needed for establishment of MSA between the MN and the Mobile
IP HA. The former extension is included to help the AAAH to
authenticate the MN on behalf of the HA as
Authenticator = MD5( 0 || Key ||
MD5(Preceding Mobile IP data ||
Type, Subtype (if present), Length, SPI) ||
237 octets of zeros)
(Note: the 0 octets in the authenticator for the co-located
case are inserted instead of the octets used from the challenge
in the FA-based CoA case [MIP4CHAL] to preserve
interoperability). The use of challenge in co-located case is
not required.).
. Upon receiving a registration request (RRQ), the home agent (HA)
examines the contents of the RRQ. If the HA finds the
construction of RRQ acceptable, and is acting as a RADIUS NAS,
it builds a RADIUS Access Request message and deals with the
information within the RRQ as described in section for generic
consideration for Mobile IP agents (section 4.3). The following
shows the complete list of attributes included in the RADIUS
Access Request formed by the HA. When forming the MIP-feature-
vector attribute for co-located MNs, the HA shall set the ‘‘Co-
located Mobile Node’’ flag as well as other appropriate flags to
indicate the request from MN for keying material. The values
insides parentheses following the attributes represent
recommended attribute values. For more details on the
recommendations, the reader is referred to section on Mobile IP
agent requirements (4.2). Attributes included inside ‘‘<>’’ are
optional. However, note that at least one of User-Name or MIP-
MN-HoA MUST be present.
Nakhjiri et. al. Expires - May 2006 [Page 6]
RADIUS Mobile IPv4 extensions October 2005
RADIUS-Access Request {
<User-Name>, (1) (MN NAI, when available in RRQ)
<MIP-MN-HoA>, (from RRQ, when not ALL_ZEROs_OR_ONES)
<MIP-HA-IP address> (from RRQ, when available)
NAS-ID (32, as per RADIUS specifications)
MIP-MA-Type (1 to indicate client as HA)
MIP-HASH-RRQ,
(see section 6 on Diameter compatibility)
MIP-MN-AAA-SPI,
MIP-MN-AAA-Authenticator,
MIP-feature-vector (with co-located MN flag set)
Message-Authenticator (80)}
. The AAAH verifies the authentication data, by computing the MN-
AAA-Authenticator value (as described in section 4.2) and
comparing to what received in MIP-MN-AAA-Authenticator
attribute. After successful authentication, the AAAH prepares
the RADIUS Access Accept to be sent to the HA as follows
-The User-Name or MIP-HA-HoA attribute (depending on
presence) copied from the Access-Request.
-If the ‘‘MN-HA-Key-Nonce-Request’’ flag was set in the MIP-
feature-vector attribute in the RADIUS Access Request, the
AAAH looks up the SPI value in the MIP-MN-AAA-SPI attribute
to index the key generation method to derive the MN-HA key
in accordance to RFC 3957. The following attributes are
included in the Access Accept to convey the information in
the MSA: MIP-MN-AAA-SPI, MIP-MN-to-HA-SPI, MIP-HA-to-MN-SPI,
MIP-MN-HA-key (for the HA), MIP-MN-HA-Nonce (for the MN),
MIP-MN-HA-ALGORITHMID, MIP-MN-HA-REPLAY, MIP-MN-HA-MSA-
LIFETIME.
-If the ‘‘Mobile-Node-Home-Address-Requested’’ flag in MIP-
feature-vector attribute in RADIUS Access Request was set,
the AAAH includes the MIP-MN-HoA attribute for the assigned
Home Address, which may not be the same as the hint in the
MIP-MN-HoA attribute of the Access Request message.
-If the ‘‘Home-Agent-Requested’’ flag in MIP-feature-vector
attribute in RADIUS Access Request was set, the AAAH
includes the MIP-HA-IP attribute for the assigned Home
Agent.
-Policy set on the AAAH may dictate that value for the flags
(e.g. ‘‘Home Agent in Foreign network’’) in the attribute.
The AAAH then sends a RADIUS Access Accept message to the home
agent. The Access Accept message includes the attributes listed
below ([] indicates need for specific security protection):
RADIUS Access Accept {
<User-Name>
Nakhjiri et. al. Expires -- May 2006 [Page 7]
RADIUS Mobile IPv4 extensions October 2005
<MIP-MN-HoA>
MIP-MA-Type (1 to indicate client is an HA)
MIP-MN-AAA-SPI
MIP-MN-to-HA SPI,
MIP-HA-to-MN-SPI,
[MIP-MN-HA-key],
MIP-MN-HA-Nonce,
MIP-MN-HA-ALGORITHMID,
MIP-MN-HA-REPLAY,
MIP-MN-HA-MSA-LIFETIME
Message-Authenticator (80)
}
. In case of authentication failure or failure to identify the MN
based on the provided User-Name or MN-HoA attributes, the AAAH
generates a RADIUS Access-Reject packet.
. Reception of RADIUS Access Accept is an indication of successful
MN authentication. Thus, the HA processes the Mobile IP RRQ and
generates a Mobile IP registration reply (RRP). The following
describes how the RADIUS attributes are used in preparation of
the RRP:
-The value of the User-Name attribute is included in the MN-
NAI Extension.
-If the MIP-MN-HoA attribute exists, Home Address field in
the RRP is set to the Address field value.
-If the MIP-HA-IP attribute exists, the HA checks if it owns
the IP address in the Address field. If so, the value is
placed into the Home Agent field of the RRP. Otherwise, HA
puts its IP address in the Home Agent field and the HA
address from the RADIUS server in the Redirected HA
Extension as specified in [MIPDYNHA].
-The values in the MIP-MN-to-HA SPI, MIP-MN-AAA-SPI, MIP-MN-
HA-ALGORITHMID, MIP-MN-HA-REPLAY and MIP-MN-HA-MSA-LIFETIME
provide the information in the ‘‘MN-HA Key Generation Nonce
Reply Extension’’. Specifically, the String field in the MIP-
MN-HA-Nonce attribute is extracted and put the MN-HA Key
Generation Nonce Reply Extension.
-The values in the MIP-HA-to-MN SPI, MIP-MN-to-HA SPI, MIP
MN-HA-key, MIP-MN-HA-ALGORITHMID, MIP-MN-HA-REPLAY and MIP-
MN-HA-MSA-LIFETIME are used to create the MSA for MN on the
Home Agent.
The home agent also calculates an MN-HA Authentication
extension based on the HA-to-MN SPI and received MN-HA key and
includes in the RRP destined towards the MN.
. If the MN-HA Key Generation Nonce Reply Extension is in the
Registration Reply, the MN extracts the necessary information
from the extension to derive the MN-HA key [MIPKEYS] and verify
Nakhjiri et. al. Expires -- May 2006 [Page 8]
RADIUS Mobile IPv4 extensions October 2005
the MN-HA authentication extension. If successful, the MN builds
the MSA with the HA.
3.2 Registration through a Foreign Agent
When the MN uses FA based CoAs, it needs to send its registration
request to the FA. The block and message diagrams are shown in
Figures 2a and 2b.
+--------+ Access Request(2a) +--------+
| AAAF |---------------------->| AAAH |
| | | |
| server |< ---------------------|server |
+--------+ Access Accept (3a) +--------+
(2) ^ | (3) (5) ^ | (6)
Access | | Access Access | | Access
Request | | Accept Request | | Accept
| V | V
+--------+RRQ (1) +---------+ RRQ (4) +----------+
| Mobile | ------->| Foreign | ------------------->| Home |
| Node | RRP (8) | Agent | RRP (7) | Agent |
| |<--------| |<--------------------| |
+--------+ +---------+ +----------+
Figure 2a. Mobile IP and RADIUS entities when registration takes
place through the FA (FA-based CoA or CcoA with R-bit set).
The operation is as follows:
MN FA HA AAAF AAAH
-- --- ---- --- ----
| | | | |
|Ad+Challenge | | | |
| <--------- | | | |
| RRQ-----. |
| | |
| |Access Request(RRQ)| Access |
| | ----------------> | Req (RRQ)|
| | | |-------. |
| | | |Acc. Accpt|
| | | |(key mtrl |
| | | | for FA |
| | | |< --------|
| | Access Accept | |
| | <-----------------| |
| | RRQ | | |
| | -------->| | |
| | | Acc. Request(RRQ) |
| | | -----------> |
Nakhjiri et. al. Expires -- May 2006 [Page 9]
RADIUS Mobile IPv4 extensions October 2005
| | | Acc. Accept |
| | |(key mtrl for HA) |
| |(RRP) |< -----------------|
| RRP |<------- | | |
| < -------- | | | |
Figure 2b- Mobile IP and RADIUS messaging when registration takes
place through the FA (FA-based CoA or CcoA with R-bit set).
. An MN being served by an FA, with whom the MN does not have an
MSA, forms a registration request (RRQ) including MN-HA-key-
generation-nonce-request, MN-FA-key-generation-nonce-request
[MIPKEYS], challenge extensions [MIP4CHAL] and MN-AAA
authentication extension and sends this message to FA. The MN
calculates the MN-AAA-Authenticator as follows
Authenticator = MD5(
High-order byte from Challenge || Key ||
MD5(Preceding Mobile IP data ||
Type, Subtype (if present), Length, SPI) ||
Least-order 237 bytes from Challenge)
. The FA checks the challenge [MIP4CHAL] and process the necessary
information from the RRQ to form the attributes to be included
in a RADIUS Access Request message as described in section 4.3.
When creating the Access Request and forming the MIP-feature-
vector attribute, the FA may set the appropriate flags within
MIP-feature vector to indicate to the AAAH that it requires keys
for FA-MN-MSA and FA-HA-MSA and perform the operation described
by [MIPKEYS]. If the HA IP address field within the RRQ is not
available, the FA inserts the HA NAI (if available) from the RRQ
inside the MIP-HA-ID attribute. The FA includes its own
identifier (e.g. NAI) inside the NAS-ID. The FA forms a RADIUS
Access Request towards the AAA infrastructure(either AAAF or to
AAAH directly) as follows
RADIUS-Access Request {
<User-Name>, (1) (MN NAI, when available in RRQ)
<MIP-MN-HoA>, (from RRQ, when not ALL_ZEROs_OR_ONES)
<MIP-HA-IP address> (from RRQ, when available)
<MIP-HA-ID>
MIP-MA-Type (0 to indicate client is an FA)
NAS-ID ((32, as per RADIUS specification)
<MIP-MN-CoA> (from RRQ)
MIP-MN-FA_Challenge,
MIP-HASH-RRQ,
MIP-MN-AAA-SPI,
MIP-MN-AAA-Authenticator,
Nakhjiri et. al. Expires -- May 2006 [Page 10]
RADIUS Mobile IPv4 extensions October 2005
MIP-feature-vector (with co-located MN flag cleared)
Message-Authenticator(80)}
. The RADIUS Access request will eventually arrive at the AAAH
through the AAA infrastructure. The AAAH server computes its own
copy of the MN-AAA authenticator as follows (described in
section 4.2):
Authenticator = MD5(
High-order byte from Challenge || Key ||
Value of MIP-HASH-RRQ ||
Least-order 237 bytes from Challenge)
The challenge is the value within the MIP-MN-FA-Challenge.
. The AAAH compares this value with what it has received in MIP-
MN-AAA-Authenticator attribute from FA. After successful
authentication, the AAAH prepares the RADIUS Access Accept as
follows
-The User-Name or MIP-HA-HoA attribute (depending on
presence) copied from the Access-Request.
-If the ‘‘MN-FA-Key-Nonce-Request’’ flag was set in the MIP-
feature-vector attribute in the RADIUS Access Request, the
AAAH looks up the SPI value in the MIP-MN-AAA-SPI attribute
to index the key generation method to derive the MN-HA key
in accordance to RFC 3957. The following attributes are
included in the Access Accept to convey the information in
the MSA: MIP-MN-AAA-SPI, MIP-MN-to-FA-SPI, MIP-FA-to-MN-SPI,
MIP-MN-FA-key (for the FA), MIP-MN-FA-Nonce (for the MN),
MIP-MN-FA-ALGORITHMID, MIP-MN-FA-REPLAY, MIP-MN-FA-MSA-
LIFETIME.
-If the ‘‘FA-HA-Key-Request’’ flag was set in the MIP-feature-
vector attribute in the RADIUS Access Request, the following
attributes are included in the Access Accept to convey the
information in the MSA: MIP-MN-AAA-SPI, MIP-FA-to-HA-SPI,
MIP-HA-to-FA-SPI, MIP-MN-FA-key (for the FA), MIP-MN-FA-
Nonce (for the MN), MIP-FA-HA-ALGORITHMID, MIP-FA-HA-MSA-
LIFETIME.
-Policy set on the AAAH may dictate that value for the flags
(e.g. ‘‘Home Agent in Foreign network’’) in the attribute.
The AAA server sends a RADIUS Access-Accept message including
the following attributes to the FA ([] indicates need for
specific security protection):
RADIUS Access Accept {
<User-Name>
Nakhjiri et. al. Expires -- May 2006 [Page 11]
RADIUS Mobile IPv4 extensions October 2005
<MIP-MN-HoA>
MIP-MA-Type (0 to indicate client is an FA)
<MIP-HA-IP address> (If HA is being delivered by AAA)
<MIP-HA-ID>
[MIP-FA-HA key],
MIP-MN-AAA-SPI
MIP-FA-to-HA-SPI,
MIP-HA-to-FA-SPI,
MIP-FA-HA-ALGORITHMID,
MIP-FA-HA-MSA-LIFETIME,
Encrypted [MIP-MN-FA key],
MIP-MN-to-FA-SPI,
MIP-FA-to-MN-SPI,
MIP-MN-FA-Nonce,
MIP-MN-FA-MSA-LIFETIME,
MIP-MN-FA-ALGORITHMID,
Message-Authenticator (80)
}
. Reception of RADIUS Access Accept by the FA is an indication of
successful MN authentication. The FA needs to at this point
extract the information regarding the MSAs with the MN and HA,
build the SAs and follow the Mobile IP processing as defined in
[MIPv4] and other specifications (such [MIPCHAL], [MIPKEYS],
[MIPDYNHA], as set by policies). Processing of the attributes in
the RADIUS Access Accept is as follows
-If the MIP-HA-IP or MIP-HA-ID attributes exist, the FA uses
the information for routing of the RRQ, while leaving the
initial RRQ in tact (otherwise the MN-AAA-AE will not be
computed by the AAA properly later)
-If the MIP-MN-HoA attribute exists, the FA checks to see if
there is a match with the MIP-MN-HoA received in RRQ (what if
it is not?).
-The values in the MIP-MN-to-FA SPI, MIP-MN-AAA-SPI, MIP-MN-
HA-ALGORITHMID, MIP-MN-HA-REPLAY and MIP-MN-HA-MSA-LIFETIME
provide the information in the ‘‘MN-HA Key Generation Nonce
Reply Extension’’. Specifically, the String field in the MIP-
MN-HA-Nonce attribute is extracted and put the MN-HA Key
Generation Nonce Reply Extension.
- The values of MIP-MN-to-FA-SPI, MIP-FA-to-MN-SPI, MIP-MN-
FA-key (for the FA), MIP-MN-FA-Nonce (for the MN), MIP-MN-
FA-ALGORITHMID, MIP-MN-FA-REPLAY, MIP-MN-FA-MSA-LIFETIME.
are used to create the MSA for MN and for HA at the Foreign
Agent.
. After building the MSA with the HA, the relays the initial
registration request including the MN-AAA Authentication
extension to the HA. The FA May append the FA-HA Authentication
extension with the authenticator computed using the received FA-
HA key. The FA-HA authentication extension also includes the SPI
that is copied from the received MIP-FA-to-HA-SPI attribute.
Nakhjiri et. al. Expires - - May 2006 [Page 12]
RADIUS Mobile IPv4 extensions October 2005
. Upon receiving the registration request from the FA, The HA
creates a new RADIUS Access Request for the AAAH and includes
the attributes shown below. The HA follows the guidelines in
processing the RRQ fields as described in section 4.3 (including
building hash from RRQ). The HA sets the appropriate flags
within the MIP-feature-vector attribute to request keys and
nonces from the AAAH for the HA-MN-MSA and HA-FA-MSA and clears
the ‘‘co-located Mobile Node’’ flag. Note, if an HA-FA-MSA exists,
the HA can simply verify the authenticator within FA-HA-
Authenticator, without requesting the key for this MSA from the
AAA server. This would mean the feature vector needs to be
configured accordingly. Otherwise, the HA will store the FA-HA-
Authentication extension for future verification.
RADIUS-Access Request {
<User-Name> (1) (MN NAI, when available in RRQ)
<MIP-MN-HoA>, (from RRQ, when not ALL_ZEROs_OR_ONES)
NAS-ID (HA ID as per RADIUS specification)
MIP-MA-Type (1 to indicate client is an HA)
<MIP-HA-IP address>,
<MIP-FA-IP address>,
<MIP-FA-ID> (FA ID as per RADIUS specification)
MIP-MN-FA challenge,
MIP-MN-AAA-SPI,
MIP-MN-AAA-Authenticator,
MIP-FA-to-HA-SPI,
MIP-HASH-RRQ,
MIP-feature-vector,
Message_Authenticator (80)}
. The AAAH finds the FA-HA MSA based on the included MIP-FA-to-HA-
SPI and/or MIP-MN-AAA-SPI. The AAAH verifies the MN-AAA
Authenticator in the same manner as explained in section 4.2. If
successful, the AAAH creates the MN-HA key and the corresponding
nonces for MN-HA MSAs and sends a RADIUS Access Accept to the HA
including the following attributes. Notes that both the all
nonces for the MN (including those for MN-FA MSAs) are sent
through this message to help the HA with one stop processing of
the registration reply. The HA-FA and the MN-HA keys must be
encrypted with the security association shared by the AAAH and
HA ([] indicates need for specific security protection).
RADIUS Access Accept {
<User-Name>
<MIP-MN-HoA>
MIP-MA-Type (1 to indicate client is an HA)
<MIP-HA-IP address> (If HA is being delivered by AAA)
Nakhjiri et. al. Expires -- May 2006 [Page 13]
RADIUS Mobile IPv4 extensions October 2005
<MIP-HA-ID>
[MIP-FA-HA key],
MIP-FA-to-HA-SPI,
MIP-HA-to-FA-SPI,
MIP-FA-HA-ALGORITHMID,
MIP-FA-HA-MSA-LIFETIME,
[MIP-MN-HA key],
MIP-MN-to-HA SPI,
MIP-HA-to-MN-SPI,
MIP-MN-HA-Nonce,
MIP-MN-HA-ALGORITHMID,
MIP-MN-HA-REPLAY,
MIP-MN-HA-MSA-LIFETIME
MIP-MN-FA-Nonce,
MIP-MN-FA-ALGORITHMID,
MIP-MN-FA-REPLAY,
MIP-MN-FA-MSA-LIFETIME,
Message-Authenticator (80)
}
. Reception of RADIUS Access Accept by the HA is an indication of
successful MN authentication. The HA retrieves the key materials
and the keys from the attributes included in the RADIUS access
Accept message from the AAAH. If the HA had received material
regarding an MSA with the FA and had earlier received at FA-HA
Authentication extension within the RRQ from FA, the AF
validates the authenticator at this point [MIPKEYS]. The HA
processes the RRQ and builds a Mobile IP registration reply for
the mobile node. The HA includes MIP-MN-FA-Nonce and MIP-MN-HA-
Nonce and related information into specified nonce reply
extensions [MIPKEYS], builds MN-HA authentication extension and
FA-HA Authentication extension (computed with received MN-HA key
and FA-HA key, respectively) and sends the RRP to the FA.
. The FA relays the RRP back to the MN as described in [RFC 3344]
and [MIPKEYS] after building the MN-FA authentication extension
when required.
4. RADIUS entity requirements
4.1 RADIUS client requirements
User-Password (2), CHAP-Password(3), CHAP challenge(60), and ARAP-
Password(70) MUST not be present in an Access-Request packet
containing the attributes discussed in this document.
As per RFC2869, packets that do not contain the above attribute MUST
contain the Message-Authenticator (80).
Nakhjiri et. al. Expires -- May 2006 [Page 14]
RADIUS Mobile IPv4 extensions October 2005
As mentioned in section 8 and [MIPKEYS], the AAA server needs the MN
identifier from the RADIUS Access Request sent by the RADIUS client.
The MN identifier is either the MN's NAI, if present in the
Registration Request, or the Home Address from the Registration
Request otherwise. Hence the RADIUS Access Request MUST include at
least one of the User-Name or MIP-MN-HoA attributes in the RADIUS
Access Request.
The NAS ID used in RADIUS Access Request packets SHALL be an
identifier that complies with the RADIUS infrastructure (it may be
the IP address that the HA uses towards the RADIUS server and
different from the IP address included in MIP-HA_IP address).
When the HA acts as a RADIUS NAS, the HA IP address included inside
the optional MIP-HA-IP address attribute is retrieved from the
initial RRQ (if included), while the NAS ID SHALL be an identifier
that complies with the RADIUS infrastructure (it may or may not be
the IP address that the HA uses towards the RADIUS server and
different from the IP address included in MIP-HA-IP address).
Besides, the attributes listed in this specification, the Access
Request may include other RADIUS attributes such as NAS-IP-Address
(4), Service-Type(6),etc required for RADIUS messaging.
4.2 RADIUS server and routing requirements
The RADIUS servers are required to be able to understand and process
the attributes described in this specification. The RADIUS server is
also required to be able to support the authentication, key and nonce
generation procedures described in this document.
Upon receiving the Access-Request messages that contain Message-
Authenticator (80) attribute, the RADIUS server MUST validate the
value of the Message-Authenticator (80) as described in [RFC2869].
If the authenticator fails to validate, the RADIUS server MUST
silently discard the Access-Request. An Access-Request which does
not contain a Message-Authenticator (80) MUST be silently discarded.
Message-Authenticator (80) SHOULD also be included in the Access-
Accept message. The Message-Authenticator (80) calculation is
described in RFC2869.
In addition to the processing defined in this document after
successful authentication the RADIUS server MAY include other
authorization attributes in the Access-Accept packets that correspond
to other features that are supported by the mobility agents.
If a RADIUS forwarding server does not have enough information to
route the packet, it shall send an Access Reject towards the NAS.
Nakhjiri et. al. Expires -
- May 2006 [Page 15]
RADIUS Mobile IPv4 extensions October 2005
If a RADIUS server does not have enough information to identify the
user for authentication purposes, the server MUST send an Access
Reject.
4.3 Mobile IP agent requirements
In this document both the FA and HA operate as RADIUS clients. They
are responsible for passing user information to designated RADIUS
servers, and acting on the responses received thereafter. In the
context of RFC-2865 the FA and HA are NASes. This also means when
sending RADIUS Access Requests, the HA and FA need to use their
RADIUS-infrastructure-compatible identifier (can be an IP address)
inside NAS-ID attribute. On the other hand, HA or FA need to
specifically use the IP addresses that they use when interacting with
the MN during MIP signaling inside MIP-HA-IP-address and MIP-FA-IP-
address attributes. Since both FA and HA can act as NASes during the
registration process, it is especially important for the NAS to
include its IP address towards the MN (used for MIP signaling) in the
RADIUS Access Requests, especially in cases where the MIP agent is
using different IP interfaces towards the MN and towards the RADIUS
server. This way, the server will know that it is receiving Access
Requests from a Mobile IP capable NAS and it knows whether it is
creating keys for an MN-FA or an MN-HA MSA. However, when the Access
Request is sent from the FA to the AAAH, the IP address or NAI of the
HA needs to be included to the message for authentication and key
generation purposes. The use of MIP-HA-NAI and MIP-FA-NAI may be
required for Mobile IP signaling.
When receiving an RRQ from the MN, the Mobile IP agents (MA: HA or
FA) and creating a RADIUS Access Request towards the AAA server, the
MA will perform the following operations:
-NAI-extension: If the HA finds a MN-NAI extension inside
the RRQ with a NAI value, the HA includes the NAI value
inside the User-Name attribute.
-Home Address If the HA finds a routable HoA (other than
ALL_ZEROs_OR_ONES) for the MN, the HA includes the value
inside the MIP-MN-HoA.
-Home Agent address field: If the HA finds a IP address
other than ‘‘ALL_ZEROS_OR_ONES’’ inside the HA IP address
field of the RRQ, the HA will include that inside the MIP-
HA-IP address attribute. However, if the HA field is set to
‘‘ALL_ZEROS_OR_ONES’’ inside the RRQ from the MN, the HA SHALL
set the value of ‘‘Home-Agent-Requested’’ inside MIP-feature-
vector to indicate to the AAA server that MN has requested
an HA assignment.
-Requested HA extension: If an Requested HA Extension
[MIPDYNHA] exists in the RRQ, the HA SHALL set the value of
‘‘Home-Agent-Requested’’ inside MIP-feature-vector to indicate
to the AAA server that MN has requested an HA assignment.
Nakhjiri et. al. Expires -- May 2006 [Page 16]
RADIUS Mobile IPv4 extensions October 2005
- If the MN-HA Key Generation Nonce Request Extension is in
the RRQ, then the HA sets the value of ‘‘MN-HA-Key-Nonce-
Request’’ inside MIP-feature-vector attribute. Also, the HA
includes the SPI value in the MN-AAA Authentication
Extension to the MIP-MN-AAA-SPI attribute.
-Registration Request: The Mobile IP registration request
can include a large number of extensions, especially when
key generation material is requested and authentication
extensions including lengthy authenticators are present. To
avoid the upper size limit for RADIUS attributes, the HA
will create a hash of RRQ and inserts it in MIP-hash-RRQ
attribute.
A Foreign Agent that is forwarding an RRQ to the HA after having
received a RADIUS Access Accept from the AAAH, will forward the
initial RRQ to the HA as is, even though the Access Accept provides
updated information (e.g. when the RRQ was missing HoA, while the
AAAH has provided this information). This is to preserve the validity
of the MN-AAA-AE added to the RRQ by the MN.
Furthermore, note that creating a RADIUS Access Request based on a
RRQ is within the discretion of HA or FA. If the MIP agent deems the
RRQ or its contents (such as the HoA or HA-IP included in the RRQ) or
lack thereof (such as NAI) inappropriate for processing, it MAY
reject the RRQ without creating a RADIUS Access Request. For
instance, in cases the RRQ does not include a routable HoA and lack
MN-NAI extension, the HA may simply reject the RRQ. The details are
outside the scope of this document.
In roaming situations, RADIUS proxies typically route the Access-
Request using the User-Name(1) attribute that contains an NAI [RFC
2486bis]. Therefore, Mobile IP Agents SHOULD populate the User-
Name(1) attribute with the NAI value received in the RRQ when the MN-
NAI extension is provided.
When the MN-NAI extension is not provided, the User-Name (1) should
be constructed using the MN HoA IP address.
User-Password(2), CHAP-Password(3), CHAP challenge(60), and ARAP-
Password(70) MUST not be present in an Access-Request packet
containing the attributes discussed in this document. In these
cases, the Mobile IP agent must include the Message-Authenticator
(80) in the Access-Accept packet. The Message-Authenticator (80) is
to be computed as per RFC2869.
If the Access-Accept packet contains a Message-Authenticator (80)
then the Mobile IP agent MUST validate the contents by computing the
authenticator as describe in RFC2869. If the authenticator is not
valid then the Mobile IP agent MUST silently discard the Access-
Nakhjiri et. al. Expires -- May 2006 [Page 17]
RADIUS Mobile IPv4 extensions October 2005
Accept packet. If the Mobile IP agent receives an Access-Accept
packet that does not contain the Message-Authenticator it MUST
silently discard the Access-Accept.
Once the Message-Authenticator (80) attribute has been validated, the
Mobile-IP agent decrypts the protected attributes as per RFC2868.
In order to verify the value of authenticator within the MN-AAA-
Authentication extension, the AAA server must follow the following
expression:
Authenticator = MD5(
High-order byte from Challenge || Key ||
Value from MIP-Hash-RRQ attribute ||
Least-order 237 bytes from Challenge)
Since the MIP-Hash-RRQ includes
MD5(Preceding Mobile IP data ||
Type, Subtype (if present), Length, SPI)
The AAA server will in a sense follows the same calculation performed
by the RADIUS clients (HA or FA):
Authenticator = MD5(
High-order byte from Challenge || Key ||
MD5(Preceding Mobile IP data ||
Type, Subtype (if present), Length, SPI) ||
Least-order 237 bytes from Challenge)
The challenge value is from MIP-FA-Challenge if present in the RADIUS
Access Request or 0 octets, otherwise.
This document does not address RADIUS accounting from the Mobile-IP
agent and therefore whether RADIUS accounting packet are sent is not
within scope of this document.
5.
Attributes
This section describes the full set of attributes required for
RADIUS-Mobile IP interaction. Some of the attributes listed are
already standardized (as noted by the attribute type value), while
others will require standardization and IANA type assignments.
5.1 Use of existing attributes
This subsection describes the use of those RADIUS attributes that are
already standardized (e.g. by RFC 2865 and 3579).
. User-Name (1)(per RFC 2865)
Nakhjiri et. al. Expires -- May 2006 [Page 18]
RADIUS Mobile IPv4 extensions October 2005
This is the same as User-Name attribute defined in RFC 2865. When an
MN-NAI extension is available with Mobile IP RRQ, the NAI value is
inserted into the value field of User-Name attribute.
It should be noted that Mobile IP signaling does not mandate the use
of MN-NAI extension when the MN has an HoA.
. NAS_IP (4) (per RFC 2865)
The IPv4 address of the mobility agent, acting as the RADIUS NAS.
. NAS_ID (32) (per RFC 2865)
The identifier (such as NAI) of the mobility agent, acting as the
RADIUS NAS. In case the MN supports AAA NAI processing [RFC 3846]
the MN may add the MIP-HA-NAI.
5.2 Suggested attributes for RADIUS-Mobile support
This section describes a proposal for a set of new attributes for
RADIUS-Mobile IP support.
. MIP-MA-Type
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Unsigned8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Mobility Agent Type
Type
To be assigned by IANA
Length
3
Unsigned value
1 if the Mobile IP agent is an HA
0 if the Mobile IP agent is an FA
Note: An alternative to creation of a new MIP-MA-Type is to extend
the existing value set for attribute NAS-Port-Type (61) to include a
value for HA and for FA as new NAS port values. TBD during RADIUS
expert review.
. MIP-MN-HoA
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nakhjiri et. al. Expires -- May 2006 [Page 19]
RADIUS Mobile IPv4 extensions October 2005
Name
Mobile Node Home IPv4 address
Type
To be assigned by IANA
Length
6
Address
Mobile Node Home IPv4 address
When NAI extension is not added to the registration requests, MN HoA
IP address is used to identify the MN (key management draft [MIPKEYS,
section 5]). The AAAH should be able to use HoA for identifying the
MN, when NAI is not provided.
. MIP-MN-CoA
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Mobile Node IPv4 care of address
Type
To be assigned by IANA
Length
6
Address
Mobile Node IPv4 care of address
. MIP-HA-IP address
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Home Agent Ipv4 Address
Type
To be assigned by IANA
Length
Nakhjiri et. al. Expires -- May 2006 [Page 20]
RADIUS Mobile IPv4 extensions October 2005
6
Address
Home Agent Ipv4 Address
If the MN is assigned an HA and has included the IP address of the HA
in its registration request (HA address other than
ALL_ZEROS_OR_ONES), then this attribute is used in RADIUS access
request. The Address field MUST be populated with the destination
address of the received RRQ at the HA. This attribute is required
when FA-HA AE is needed (the FA is requesting FA-HA-MSA keying
material). For dynamic HA assignments via RADIUS, this field MAY be
set to ALL_ZEROS_OR_ONES at the FA to indicate to the RADIUS server
that the MN is requesting a dynamic HA assignment. It is however
preferred that the FA uses the appropriate bit within the MIP-
feature-vector attribute for that purpose.
. MIP-HA-IP address
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Home Agent IPv4 Address
Type
To be assigned by IANA
Length
6
Address
Home Agent Ipv4 Address
. MIP-FA-IP address
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Foreign Agent IPv4 Address
Type
To be assigned by IANA
Nakhjiri et. al. Expires -- May 2006 [Page 21]
RADIUS Mobile IPv4 extensions October 2005
Length
6
Address
Foreign Agent IPv4 Address
. MIP-HASH-RRQ
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Mobile IPv4 hashed Registration Request
Type
To be assigned by IANA
Length
>3
String
MD5(Preceding Mobile IP data from MN-AAA AE|| Type, Subtype (if
present), Length, SPI)
This attribute includes an MD5 hash version of Mobile IP registration
request (similar to RFC 3012 section 8). This attribute is carried by
the Access request.
The Mobile IP registration request can include a large number of
extensions, especially when key generation material is requested and
authentication extensions including lengthy authenticators are
present. To avoid the upper size limit for RADIUS attributes, the HA
or FA will create a hash of RRQ and insert it in MIP-hash-RRQ
attribute.
The AAA server uses the value of MIP-HASH_RRQ to calculate the
authenticator in MN-AAA Authenticator as follows.
Authenticator = MD5(
High-order byte from Challenge || Key ||
Value of MIP-HASH-RRQ ||
Least-order 237 bytes from Challenge)
The challenge is the value within the MIP-MN-FA-Challenge or 0.
. MIP-FA challenge
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nakhjiri et. al. Expires -- May 2006 [Page 22]
RADIUS Mobile IPv4 extensions October 2005
Name
Mobile IPv4 Foreign Agent Challenge
Type
To be assigned by IANA
Length
> 3
String
Mobile IPv4 Foreign Agent Challenge
There is a Challenge Extension defined in RFC 3012 section 4.
This attribute can be included in Access Request from FA to AAA and
from the HA to the AAA, since it is used in the MN-AAA authentication
extension.
. MIP-MN-AAA SPI
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Unsigned32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Mobile IPv4 Node SPI
Type
To be assigned by IANA
Length
6
Unsigned32
AAA SPI [MIPKEYS].
The AAA server uses this SPI to locate the security context needed to
verify the MN-AAA authenticator calculated by the MN over the
registration request data. The security context includes the MN-AAA
key, and key related information and the algorithm used for
calculation of authenticator fields.
. MIP-MN-AAA-Authenticator
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Mobile IPv4 Mobile Node-AAA Authenticator value
Type
To be assigned by IANA
Length
> 3
Nakhjiri et. al. Expires -- May 2006 [Page 23]
RADIUS Mobile IPv4 extensions October 2005
String
MN-AAA authenticator value
This attribute carries the value of MN-AAA-authenticator within the
MN-AAA Authentication extension.
The value is calculated based on a hash of RRQ and other information.
The general expression (used for FA-based mobile nodes) is as follows
Authenticator = MD5(
High-order byte from Challenge || Key ||
MD5(Preceding Mobile IP data ||
Type, Subtype (if present), Length, SPI) ||
Least-order 237 bytes from Challenge)
For co-located mobile nodes, which register directly with the HA, no
challenge value exists and therefore the values related to challenge
are replaced with zero octets in the expression above.
. MIP feature vector
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Unsigned32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Mobile IPv4 feature vector
Type
To be assigned by IANA
Length
6
Unsigned32
Mobile IPv4 feature vector
This a flag vector of type Unsigned32, where each set flag represents
a condition, such keys requested for FA or HA and so on. The flag
values are as provided by Diameter, in order to facilitate
interoperability between RADIUS and Diameter:
1 Mobile-Node-Home-Address-Requested
(When MN does not have an HoA)
2 Home-Address-Allocatable-Only-in-Home-Realm
4 Home-Agent-Requested (when MN not allocated an HA)
8 Foreign-Home-Agent-Available
16 MN-HA-Key-Nonce-Request (key material for MN-HA MSA is
requested)
32 MN-FA-Key-Nonce-Request
64 FA-HA-Key-Request
128 Home Agent in Foreign network
Nakhjiri et. al. Expires -- May 2006 [Page 24]
RADIUS Mobile IPv4 extensions October 2005
256 Co-located-Mobile-Node
This attribute is added to the RADIUS Access Request message.
For instance, when the MN has included a nonce generation request
extension for MN-HA SA, the mobility agent (FA in FA CoA case and HA
in CcoA case) sets the MN-HA key request flag in the MIP feature
vector attribute included in the RADIUS Access Request message to
indicate to the AAA that the MN requires nonces for MN-HA SA.
The same goes for MN-FA nonce generation request extension from MN.
When an FA is being used and FA requires keying material from the AAA
server, the FA sets the FA-HA-key request flag.
. MIP-MN-to-HA SPI
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Unsigned32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Mobile Node to Home Agent SPI
Type
To be assigned by IANA
Length
6
Unsigned32
Mobile node to Home Agent SPI
This attribute can be included in the Access Request (from HA to
AAAH) and Access Accept message (from AAAH to HA) and points to the
MN-to-HA MSA that includes security context material (MN-HA Key
Generation nonce, AAA SPI, Replay Method, Lifetime, and Algorithm
Identifier) for the MN. This SPI is allocated by the HA.
. MIP-HA-to-MN SPI
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Unsigned32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Home agent to Mobile Node SPI
Type
To be assigned by IANA
Length
6
Unsiged32
Nakhjiri et. al. Expires -- May 2006 [Page 25]
RADIUS Mobile IPv4 extensions October 2005
Home Agent to Mobile Node SPI
This attribute can be included in the Access Request (from HA to
AAAH) and Access Accept message (from AAAH to HA) and points to the
HA-to-MN MSA that includes security context material (MN-HA Key,
Replay Method, Lifetime, and Algorithm Identifier??) for the HA. This
SPI is allocated by the MN and is included in the initial Mobile-
Home-Key generation nonce request extension within the RRQ generated
by the MN.
. MIP-MN-HA-key
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Home Agent-Mobile Node MSA key
Type
To be assigned by IANA
Length
> 3
String
MN-HA key
This attribute can be included in the Access Accept message from the
AAAH to HA and includes MN-HA key for the HA to use when interacting
with the MN. This attribute MUST be encrypted using procedures
defined in RFC 2868 [RADTUNN].
. MIP-MN-HA-Nonce
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Home Agent-Mobile Node MSA nonce
Type
To be assigned by IANA
Length
> 3
String
MN-HA nonce
Nakhjiri et. al. Expires -- May 2006 [Page 26]
RADIUS Mobile IPv4 extensions October 2005
This attribute can be included in the Access Accept message from the
AAAH to HA and includes MN-HA nonce for the MN to use for calculating
the MN-HA key used when interacting with the MN.
. MIP-MN-HA-ALGORITHMID
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Unsigned8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Home Agent-Mobile Node MSA Algorithm identifier
Type
To be assigned by IANA
Length
3
Unsigned8
MN-HA MSA algorithm identifier
This attribute can be included in any message that includes the MIP-
MN-to-HA SPI or MIP-HA-to-MN SPI and identifies the algorithm that is
used for MSA between MN and HA. Suggested values:
1 MD5
2 HMAC-MD5
3 SHA1
. MIP-MN-HA-REPLAY
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Unsigned8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Home Agent-Mobile Node MSA replay mode
Type
To be assigned by IANA
Length
3
String
MN-HA MSA replay mode identifier
This attribute can be included in any message that includes the MIP-
MN-to-HA SPI or MIP-HA-to-MN SPI and identifies the replay mode that
is used for MSA between MN and HA. Suggested values:
Nakhjiri et. al. Expires -- May 2006 [Page 27]
RADIUS Mobile IPv4 extensions October 2005
1 timestamp
2 nonce
. MIP-MN-HA-MSA-LIFETIME
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Unsigned32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Home Agent-Mobile Node MSA life time
Type
To be assigned by IANA
Length
6
Unsigned32
MN-HA MSA life time
This attribute can be included in any message that includes the MIP-
MN-to-HA SPI or MIP-HA-to-MN SPI and identifies the life time value
for MSA between MN and HA.
. MIP-MN-to-FA SPI
Similar to MN-to-HA SPI.
. MIP-FA-to-MN SPI
Similar to HA-to-MN SPI.
. MIP-MN-FA-key
Similar to MIP-MN-HA-key.
. MIP-MN-FA-Nonce
Similar to MIP-MN-HA-Nonce
. MIP-MN-FA-MSA-LIFETIME
Similar to MIP-MN-HA-MSA-LIFETIME
. MIP-MN-FA-ALGORITHMID
Similar to MIP-MN-HA-ALGORITHMID
. MIP-FA-to-HA-SPI
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Unsigned32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nakhjiri et. al. Expires -- May 2006 [Page 28]
RADIUS Mobile IPv4 extensions October 2005
Name
Foreign agent to Home agent SPI
Type
To be assigned by IANA
Length
6
Unsigned32
Foreign agent to Home Agent SPI
This attribute carries the SPI pointing to the security context
between the FA and the HA for the HA. The SPI is allocated by the HA.
The signaling in this draft does not require this attribute, since
the SPI can be carried in Mobile IP extensions.
. MIP-HA-to-FA SPI
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Unsigned32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Home agent to Foreign agent SPI
Type
To be assigned by IANA
Length
6
Unsigned32
Home agent to Foreign agent SPI
This attribute carries the SPI pointing to the security context
between the FA and the HA for the FA. The SPI is allocated by the FA.
This attribute is included in the access request from FA to AAAH and
later in access accept from AAAH to HA.
. MIP-FA-HA-key
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Foreign agent to Home Agent to key
Type
To be assigned by IANA
Length
> 3
Nakhjiri et. al. Expires -- May 2006 [Page 29]
RADIUS Mobile IPv4 extensions October 2005
String
FA-HA key
This attribute is sent to FA and to HA in an Access Accept messages
from the AAAH to these agents. The key is used by FA and HA for
integrity protection. This attribute MUST be encrypted using
procedures defined in RFC 2868 [RADTUNN].
. MIP-FA-HA-ALGORITHMID
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Foreign Agent-Home Agent MSA Algorithm identifier
Type
To be assigned by IANA
Length
> 3
String
FA-HA MSA algorithm identifier
This attribute can be included in any message that includes the MIP-
FA-to-HA SPI or MIP-HA-to-FA SPI and identifies the algorithm that is
used for MSA between MN and HA.
. MIP-FA-HA-MSA-LIFETIME
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Unsigned32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Foreign Agent-Home Agent MSA life time
Type
To be assigned by IANA
Length
6
Unsigned32
FA-HA MSA life time
This attribute can be included in any message that includes the MIP-
FA-to-HA SPI or MIP-HA-to-FA SPI and identifies the life time value
for MSAs between FA and HA.
Nakhjiri et. al. Expires -- May 2006 [Page 30]
RADIUS Mobile IPv4 extensions October 2005
. MIP-FA-HA-Authenticator
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
string (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Foreign Agent-Home Agent Authenticator value
Type
To be assigned by IANA
Length
> 3 (2+128)
String
FA-HA Authenticator
This attribute is included in message from HA to AAAH for
verification of authenticator added the FA for HA, when HA is not
aware of the MSAs it shares with the FA.
5.3 Attribute List
This list will be completed as an attribute table that includes
information on the messages that are allowed to carry each attribute
and whether each attribute must be protected in the next version of
the draft.
Request Accept Reject Challenge # Attribute
0-1 0-1 0 0 1 User-Name,
0-1 0 0 0 4 NAS-IP,
0-1 0 0 0 32 NAS-ID,
0-1 0-1 0 0 NA MIP-MA-Type
0-1 0-1 0 0 NA MIP-MN-HoA,
0-1 0-1 0 0 NA MIP-MN-CoA,
0-1 0 0 0 NA MIP-HA-ID,
0-1 0 0 0 NA MIP-FA-ID,
0-1 0 0 0 NA MIP-HA-IP address,
0-1 0 0 0 NA MIP-FA-IP address,
0-1 0 0 0 NA MIP-HASH-RRQ,
0-1 0 0 0 NA MIP-MN-FA challenge,
0-1 0 0 0 NA MIP-MN-AAA-Authenticator,
0-1 0 0 0 NA MIP-feature-vector
1 1 1 1 80 Message Authenticator
0-1 0-1 0 0 NA MIP-MN-AAA-SPI,
0 0-1 0 0 NA MIP-MN-to-HA SPI,
0 0-1 0 0 NA MIP-HA-to-MN-SPI,
Nakhjiri et. al. Expires - - May 2006 [Page 31]
RADIUS Mobile IPv4 extensions October 2005
0-1 0-1 0 0 NA MIP-FA-to-HA-SPI,
0 0-1 0 0 NA MIP-HA-to-FA-SPI,
0 0-1 0 0 NA MIP-MN-to-FA SPI,
0 0-1 0 0 NA MIP-FA-to-MN-SPI,
0 0-1 0 0 NA MIP-MN-HA-key,
0 0-1 0 0 NA MIP-MN-FA-key,
0 0-1 0 0 NA MIP-FA-HA key,
0 0-1 0 0 NA MIP-MN-HA-Nonce,
0 0-1 0 0 NA MIP-MN-FA-Nonce,
0 0-1 0 0 NA MIP-MN-HA-ALGORITHMID,
0 0-1 0 0 NA MIP-FA-HA-ALGORITHMID,
0 0-1 0 0 NA MIP-MN-FA-ALGORITHMID,
0 0-1 0 0 NA MIP-MN-HA-REPLAY,
0 0-1 0 0 NA MIP-MN-FA-REPLAY,
0 0-1 0 0 NA MIP-MN-HA-MSA-LIFETIME
0 0-1 0 0 NA MIP-FA-HA-MSA-LIFETIME,
0 0-1 0 0 NA MIP-MN-FA-MSA-LIFETIME
6. Diameter compatibility considerations
Diameter Mobile IP application has defined new command codes for
support of Mobile IP signaling such as, AA-Mobile node request (AMR),
AA-Mobile Node answer (AMA), Home agent MIP-request (HMR), Home agent
MIP-answer (HMA). RADIUS currently does not have any messages that
correspond to these Diameter commands. However RADIUS provides the
flexibility of defining new command codes. The solution in this draft
is designed based on the assumption that the RADIUS community (and
RADEXT) is not interested in defining new RADIUS messages hence we
will be using RADIUS access request and RADIUS access accept for
providing messaging from mobility agents to RADIUS server and vice
versa. The following pictures show the Diameter messaging to support
Mobile IP signaling as described in [DIAMIP].
+--------+
|Diameter|
| server |
+--------+
Diameter ^ |Diameter
AMR | | AMA
| |
RRQ | V
+--- + -----> +----+
| MN | RRP | HA |
+----+ <----- +----+
Figure 3a Diameter messaging for co-located MNs
Nakhjiri et. al. Expires -- May 2006 [Page 32]
RADIUS Mobile IPv4 extensions October 2005
+-----+ Diameter HAR +--------+
| HA |-------------------->|Diameter|
| |< -------------------|server |
+-----+ Diameter HAA +--------+
^ |
Diameter | |Diameter
AMR | | AMA
| V
+----+ RRQ +----+
| MN | ------->| FA |
| | RRP (8) | |
+----+<--------+----+
Figure 3b Diameter messaging for FA-based MNs
Comparing the Diameter messaging (figure 2) with our suggestion for
RADIUS messaging (figure 3), the following simple rules apply to
Diameter to RADIUS translation, as long as the new MIP-MA-Type
identifying the type the Mobile IP agent (FA or HA) is used.
Diameter HAR <-> RADIUS Access Request
Diameter HAA <-> RADIUS Access Accept/Reject (MIP-MA-Type=1)
Diameter AMR <-> RADIUS Access Request
Diameter AMA <-> RADIUS Access Accept/Reject (MIP-MA-Type=0)
The attributes defined in this specification follow the Diameter AVP
definition to the extent possible for RADIUS. Exceptions are cases
where a Diameter AVP is of grouped type or potentially has a size
that exceeds the RADIUS attribute size limit (253 byte).
For grouped type Diameter AVPs, we simply convert each data field of
the Diameter AVP into a separate RADIUS attribute. This is
implemented for all the MSA-related AVP/ attributes.
One specific such case is the use of Diameter MIP-Reg-Request AVP.
For RADIUS we suggest hashing all the data in RRQ up to the MN-
AAA-Authentication extension and including the hash inside MIP-
HASH-RRQ to adhere to RADIUS attribute size limitation (253
bytes). This is explained in the attributes section as well as in
the section dealing with RADIUS server considerations.
7. IANA considerations
This draft introduces new RADIUS attributes. Therefore there is need
for defining new attribute type numbers by IANA.
8. Security considerations
Nakhjiri et. al. Expires -- May 2006 [Page 33]
RADIUS Mobile IPv4 extensions October 2005
We recommend the use of the optional Mobile IP (RFC 3344) Foreign-
Home authentication extension for protecting the integrity of
messaging between FA and HA to protect the HA from DoS attacks
launched by the FA.
Another possible attack is DoS attacks by MNs using large numbers of
Mobile IP RRQs. Therefore, we require that the FA implements the
challenge response mechanism in RFC 3012 and forwards the challenge
inside RRQ to the HA.
Another security concern is on the distribution of keys from the AAA
server to mobility agents. The AAAH creates and distributes keys for
the Mobile IP agents and nonces for mobile nodes. The key transfer
must happen in a secure manner. This means, the MSA-attributes
including HA and FA keys must be encrypted with the security
associations between the AAAH and the mobility agents. Such security
association may be based on RADIUS shared secrets (hop by hop) or
methods similar to those defined in [KEYWRAP] based on end-to-end SAs
(possibly IPsec) between the AAAH and the mobility agents. For
foreign agents, other trusted AAA servers (such as AAAF and AAAF-AAAH
keys) may have to be involved. Also, it is important that the keys
for each mobility agent are kept hidden from other mobility agents.
For instance keys for FA must be kept secret from HA. This means the
AAA server must have separate keys with each of the HA and FAs. On
the other hand, the nonces generated by the AAA server, destined to
the mobile can be transmitted in the clear. The MN-FA and MN-HA
nonces are protected by the FA and HA authentications to the MN.
However, to prevent man-in-the-middle tampering with the nonces in
transit from AAAH to the HA and to FA to the MN, We recommend that
the AAAH also authenticates the nonce-reply-extensions with the AAA
SA it shares with the MN.
Finally, we assume the following formula [MIPKEYS] is used by the MN
for generating the key out of the nonce:
Key = HMAC-SHA1 (AAA-key, {Key Generation Nonce || MN identifier})
,which means the AAA server needs the MN identifier from the RADIUS
Access Request to generate the keys corresponding the nonces.
For RADIUS threats and vulnerabilities please refer to the Security
Section in RFC3579.
9. References
[MIPv4] C. Perkins, IP Mobility Support, IETF, RFC 3344, August
2002.
Nakhjiri et. al. Expires -- May 2006 [Page 34]
RADIUS Mobile IPv4 extensions October 2005
[MIP4CHAL] C. Perkins, P. Calhoun, Mobile IP Challenge/Response
Extensions, draft-ietf-mip4-rfc3012bis-04.txt., June 2005.
[MIPKEYS] C. Perkins, P. Calhoun, AAA Registration Keys for Mobile
IP, IETF, RFC 3957, March 2005.
[MIPDYNHA] M. Kulkarni, A. Patel, K. Leung, ‘‘Mobile IPv4 Dynamic
Home Agent Assignment’’, draft-ietf-mip4-dynamic-assignment-06.txt
August 2005.
[DIAMIP] P. Calhoun, C. Perkins, Diameter Mobile IP application,
IETF, RFC 4004, May 2004.
[RADTUNN], G. Zorn, Et. Al., RADIUS Attributes for Tunnel Protocol
Support, IETF, RFC 2868, June 2000.
[KEYWRAP], G. Zorn, Et. Al., RADIUS Attributes for Key Delivery,
draft-zorn-radius-keywrap-08.txt.
Acknowledgments
The authors would like to give special thanks to Farid Adrangi for
the initial discussions and recommendations on the attribute design
work. The authors would also like to thank Charlie Perkins for
consultation on the use of RFC 3012 procedures.
Author's Addresses
Madjid Nakhjiri
Motorola Inc.
Contact Email: Madjid.Nakhjiri@motorola.com
Kuntal Chowdhury
Starent Networks
Contact Email: kchowdhury@starentnetworks.com
Avi Lior
Bridgewater systems
Contact Email: avi@bridgewatersystems.com
Kent Leung
Cisco Systems
Contact Email: kleung@cisco.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
Nakhjiri et. al. Expires -- May 2006 [Page 35]
RADIUS Mobile IPv4 extensions October 2005
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
This Internet-Draft will expire on January 14, 2006.
Nakhjiri et. al. Expires -- May 2006 [Page 36]
