Request for Comments: 4285 K. Leung
Category: Informational Cisco Systems
M. Khalil
H. Akhtar
Nortel Networks
K. Chowdhury
Starent Networks
January 2006
Authentication Protocol for Mobile IPv6
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
IESG Note
This RFC is not a candidate for any level of Internet Standard. RFC
3775 and 3776 define Mobile IPv6 and its security mechanism. This
document presents an alternate security mechanism for Mobile IPv6
used in 3GPP2 networks.
The security properties of this mechanism have not been reviewed in
the IETF. Conducting this review proved difficult because the
standards-track security mechanism for Mobile IPv6 is tightly
integrated into the protocol; extensions to Mobile IPv6 and the core
documents make assumptions about the properties of the security model
without explicitly stating what assumptions are being made. There is
no documented service model. Thus it is difficult to replace the
security mechanism and see if the current protocol and future
extensions meet appropriate security requirements both under the
original and new security mechanisms. If a service model for Mobile
IPv6 security is ever formally defined and reviewed, a mechanism
similar to this one could be produced and fully reviewed.
Section 1.1 of this document provides an applicability statement for
this RFC. The IESG recommends against the usage of this
specification outside of environments that meet the conditions of
that applicability statement. In addition the IESG recommends those
considering deploying or implementing this specification conduct a
sufficient security review to meet the conditions of the environments
in which this RFC will be used.
Abstract
IPsec is specified as the means of securing signaling messages
between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6).
MIPv6 signaling messages that are secured include the Binding Updates
and Acknowledgement messages used for managing the bindings between a
Mobile Node and its Home Agent. This document proposes an alternate
method for securing MIPv6 signaling messages between Mobile Nodes and
Home Agents. The alternate method defined here consists of a
MIPv6-specific mobility message authentication option that can be
added to MIPv6 signaling messages.
Table of Contents
1. Introduction ....................................................3
1.1. Applicability Statement ....................................3
2. Overview ........................................................4
3. Terminology .....................................................5
3.1. General Terms ..............................................5
4. Operational Flow ................................................6
5. Mobility Message Authentication Option ..........................7
5.1. MN-HA Mobility Message Authentication Option ...............8
5.1.1. Processing Considerations ...........................9
5.2. MN-AAA Mobility Message Authentication Option ..............9
5.2.1. Processing Considerations ..........................10
5.3. Authentication Failure Detection at the Mobile Node .......11
6. Mobility Message Replay Protection Option ......................11
7. Security Considerations ........................................13
8. IANA Considerations ............................................14
9. Acknowledgements ...............................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative References ...................................15
Appendix A. Rationale for mobility message replay protection
option ................................................16
1. Introduction
The base Mobile IPv6 specification [RFC3775] specifies the signaling
messages, Binding Update (BU) and Binding Acknowledgement (BA),
between the Mobile Node (MN) and Home Agent (HA) to be secured by the
IPsec Security Associations (IPsec SAs) that are established between
these two entities.
This document proposes a solution for securing the Binding Update and
Binding Acknowledgment messages between the Mobile Node and Home
Agent using a mobility message authentication option that is included
in these messages. Such a mechanism enables IPv6 mobility in a host
without having to establish an IPsec SA with its Home Agent. A
Mobile Node can implement Mobile IPv6 without having to integrate it
with the IPsec module, in which case the Binding Update and Binding
Acknowledgement messages (between MN-HA) are secured with the
mobility message authentication option.
The authentication mechanism proposed here is similar to the
authentication mechanism used in Mobile IPv4 [RFC3344].
1.1. Applicability Statement
The mobility message authentication option specified in Section 5 is
applicable in certain types of networks that have the following
characteristics:
- Networks in which the authentication of the MN for network access
is done by an authentication server in the home network via the home
agent. The security association is established by the network
operator (provisioning methods) between the MN and a backend
authentication server (e.g., Authentication, Authorization, and
Accounting (AAA) home server). MIPv6 as per RFCs 3775 and 3776
relies on the IPsec SA between the MN and an HA. In cases where the
assignment of the HA is dynamic and the only static or long-term SA
is between the MN and a backend authentication server, the mobility
message authentication option is desirable.
- In certain deployment environments, the mobile node needs dynamic
assignment of a home agent and home address. The assignment of such
can be on a per-session basis or on a per-MN power-up basis. In such
scenarios, the MN relies on an identity such as a Network Access
Identifier (NAI) [RFC4283], and a security association with a AAA
server to obtain such bootstrapping information. The security
association is created via an out-of-band mechanism or by non Mobile
IPv6 signaling. The out-of-band mechanism can be specific to the
deployment environment of a network operator. In Code Division
Multiple Access (CDMA) network deployments, this information can be
obtained at the time of network access authentication via [3GPP2]
specific extensions to PPP or DHCPv6 on the access link and by AAA
extensions in the core. It should be noted that the out-of-band
mechanism is not within the scope of the mobility message
authentication option (Section 5) and hence is not described therein.
- Network deployments in which not all Mobile Nodes and Home Agents
have IKEv2 implementations and support for the integration of IKEv2
with backend AAA infrastructures. IKEv2 as a technology has yet to
reach maturity status and widespread implementations needed for
commercial deployments on a large scale. At the time of this
writing, [RFC4306] is yet to be published as an RFC. Hence from a
practical perspective that operators face, IKEv2 is not yet capable
of addressing the immediate need for MIPv6 deployment.
- Networks that expressly rely on the backend AAA infrastructure as
the primary means for identifying and authentication/authorizing a
mobile user for MIPv6 service.
- Networks in which the establishment of the security association
between the Mobile Node and the authentication server (AAA Home) is
established using an out-of-band mechanism and not by any key
exchange protocol. Such networks will also rely on out-of-band
mechanisms to renew the security association (between MN and AAA
Home) when needed.
- Networks that are bandwidth constrained (such as cellular wireless
networks) and for which there exists a strong desire to minimize the
number of signaling messages sent over such interfaces. MIPv6
signaling that relies on Internet Key Exchange (IKE) as the primary
means for setting up an SA between the MN and HA requires more
signaling messages compared with the use of an mobility message
authentication option carried in the BU/BA messages.
One such example of networks that have such characteristics are CDMA
networks as defined in [3GPP2].
2. Overview
This document presents a lightweight mechanism to authenticate the
Mobile Node at the Home Agent or at the Authentication,
Authorization, and Accounting (AAA) server in Home network (AAAH)
based on a shared-key-based mobility security association between the
Mobile Node and the respective authenticating entity. This shared-
key-based mobility security association (shared-key-based mobility
SA) may be statically provisioned or dynamically created. The term
"mobility security association" referred to in this document is
understood to be a "shared-key-based Mobile IPv6 authentication"
security association.
This document introduces new mobility options to aid in
authentication of the Mobile Node to the Home Agent or AAAH server.
The confidentiality protection of Return Routability messages and
authentication/integrity protection of Mobile Prefix Discovery (MPD)
is not provided when these options are used for authentication of the
Mobile Node to the Home Agent. Thus, unless the network can
guarantee such protection (for instance, like in 3GPP2 networks),
Route Optimization and Mobile Prefix Discovery should not be used
when using the mobility message authentication option.
3. Terminology
The keywords "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.
3.1. General Terms
First (size, input)
Some formulas in this specification use a functional form "First
(size, input)" to indicate truncation of the "input" data so that
only the first "size" bits remain to be used.
Shared-key-based Mobility Security Association
Security relation between the Mobile Node and its Home Agent, used
to authenticate the Mobile Node for mobility service. The
shared-key-based mobility security association between Mobile Node
and Home Agent consists of a mobility Security Parameter Index
(SPI), a shared key, an authentication algorithm, and the replay
protection mechanism in use.
Mobility SPI
A number in the range [0-4294967296] used to index into the
shared-key-based mobility security associations.
4. Operational Flow
The figure below describes the sequence of messages sent and received
between the MN and HA in the registration process. Binding Update
(BU) and Binding Acknowledgement (BA) messages are used in the
registration process.
MN HA/AAAH
| BU to HA |
(a) |----------------------------------------------------->|
| (including MN-ID option, |
| mobility message replay protection option[optional],|
| mobility message authentication option) |
| |
| HA/AAAH authenticates MN
| |
| |
| BA to MN |
(b) |<-----------------------------------------------------|
| (including MN-ID option, |
| mobility message replay protection option[optional],|
| mobility message authentication option) |
| |
Figure 1: Home Registration with Authentication Protocol
The Mobile Node MUST use the Mobile Node Identifier option,
specifically the MN-NAI mobility option as defined in [RFC4283] to
identify itself while authenticating with the Home Agent. The Mobile
Node uses the Mobile Node Identifier option as defined in [RFC4283]
to identify itself as may be required for use with some existing AAA
infrastructure designs.
The Mobile Node MAY use the Message Identifier option as defined in
Section 6 for additional replay protection.
The mobility message authentication option described in Section 5 may
be used by the Mobile Node to transfer authentication data when the
Mobile Node and the Home Agent are utilizing a mobility SPI (a number
in the range [0-4294967296] used to index into the shared-key-based
mobility security associations) to index between multiple mobility
security associations.
5. Mobility Message Authentication Option
This section defines a mobility message authentication option that
may be used to secure Binding Update and Binding Acknowledgement
messages. This option can be used along with IPsec or preferably as
an alternate mechanism to authenticate Binding Update and Binding
Acknowledgement messages in the absence of IPsec.
This document also defines subtype numbers, which identify the mode
of authentication and the peer entity to authenticate the message.
Two subtype numbers are specified in this document. Other subtypes
may be defined for use in the future.
Only one instance of a mobility message authentication option of a
particular subtype can be present in the message. One message may
contain multiple instances of the mobility message authentication
option with different subtype values. If both MN-HA and MN-AAA
authentication options are present, the MN-HA authentication option
must be present before the MN-AAA authentication option (else, the HA
MUST discard the message).
When a Binding Update or Binding Acknowledgement is received without
a mobility message authentication option and the entity receiving it
is configured to use the mobility message authentication option or
has the shared-key-based mobility security association for the
mobility message authentication option, the entity should silently
discard the received message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobility SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Mobility Message Authentication Option
Option Type:
AUTH-OPTION-TYPE value 9 has been defined by IANA. An 8-bit
identifier of the type mobility option.
Option Length:
8-bit unsigned integer, representing the length in octets of
the Subtype, mobility Security Parameter Index (SPI) and
Authentication Data fields.
Subtype:
A number assigned to identify the entity and/or mechanism to be
used to authenticate the message.
Mobility SPI:
Mobility Security Parameter Index
Authentication Data:
This field has the information to authenticate the relevant
mobility entity. This protects the message beginning at the
Mobility Header up to and including the mobility SPI field.
Alignment requirements :
The alignment requirement for this option is 4n + 1.
5.1. MN-HA Mobility Message Authentication Option
The format of the MN-HA mobility message authentication option is as
defined in Figure 2. This option uses the subtype value of 1. The
MN-HA mobility message authentication option is used to authenticate
the Binding Update and Binding Acknowledgement messages based on the
shared-key-based security association between the Mobile Node and the
Home Agent.
The shared-key-based mobility security association between Mobile
Node and Home Agent used within this specification consists of a
mobility SPI, a key, an authentication algorithm, and the replay
protection mechanism in use. The mobility SPI is a number in the
range [0-4294967296], where the range [0-255] is reserved. The key
consists of an arbitrary value and is 16 octets in length. The
authentication algorithm is HMAC_SHA1. The replay protection
mechanism may use the Sequence number as specified in [RFC3775] or
the Timestamp option as defined in Section 6. If the Timestamp
option is used for replay protection, the mobility security
association includes a "close enough" field to account for clock
drift. A default value of 7 seconds SHOULD be used. This value
SHOULD be greater than 3 seconds.
The MN-HA mobility message authentication option MUST be the last
option in a message with a mobility header if it is the only mobility
message authentication option in the message.
The authentication data is calculated on the message starting from
the mobility header up to and including the mobility SPI value of
this option.
Authentication Data = First (96, HMAC_SHA1(MN-HA Shared key, Mobility
Data))
Mobility Data = care-of address | home address | Mobility Header (MH)
Data
MH Data is the content of the Mobility Header up to and including the
mobility SPI field of this option. The Checksum field in the
Mobility Header MUST be set to 0 to calculate the Mobility Data.
The first 96 bits from the Message Authentication Code (MAC) result
are used as the Authentication Data field.
5.1.1. Processing Considerations
The assumption is that the Mobile Node has a shared-key-based
security association with the Home Agent. The Mobile Node MUST
include this option in a BU if it has a shared-key-based mobility
security association with the Home Agent. The Home Agent MUST
include this option in the BA if it received this option in the
corresponding BU and Home Agent has a shared-key-based mobility
security association with the Mobile Node.
The Mobile Node or Home Agent receiving this option MUST verify the
authentication data in the option. If authentication fails, the Home
Agent MUST send BA with Status Code MIPV6-AUTH-FAIL. If the Home
Agent does not have shared-key-based mobility SA, Home Agent MUST
discard the BU. The Home Agent MAY log such events.
5.2. MN-AAA Mobility Message Authentication Option
The format of the MN-AAA mobility message authentication option is as
defined in Figure 2. This option uses the subtype value of 2. The
MN-AAA authentication mobility option is used to authenticate the
Binding Update message based on the shared mobility security
association between the Mobile Node and AAA server in Home network
(AAAH). It is not used in Binding Acknowledgement messages. The
corresponding Binding Acknowledgement messages must be authenticated
using the MN-HA mobility message authentication option (Section 5.1).
The MN-AAA mobility message authentication option must be the last
option in a message with a mobility header. The corresponding
response MUST include the MN-HA mobility message authentication
option, and MUST NOT include the MN-AAA mobility message
authentication option.
The Mobile Node MAY use the Mobile Node Identifier option [RFC4283]
to enable the Home Agent to make use of available AAA infrastructure.
The authentication data is calculated on the message starting from
the mobility header up to and including the mobility SPI value of
this option.
The authentication data shall be calculated as follows:
Authentication data = hash_fn(MN-AAA Shared key, MAC_Mobility Data)
hash_fn() is decided by the value of mobility SPI field in the MN-AAA
mobility message authentication option.
SPI = HMAC_SHA1_SPI:
If mobility SPI has the well-known value HMAC_SHA1_SPI, then
hash_fn() is HMAC_SHA1. When HMAC_SHA1_SPI is used, the BU is
authenticated by AAA using HMAC_SHA1 authentication. In that case,
MAC_Mobility Data is calculated as follows:
MAC_Mobility Data = SHA1(care-of address | home address | MH Data)
MH Data is the content of the Mobility Header up to and including the
mobility SPI field of this option.
5.2.1. Processing Considerations
The use of the MN-AAA mobility message authentication option assumes
that AAA entities at the home site communicate with the HA via an
authenticated channel. Specifically, a BU with the MN-AAA mobility
message authentication option is authenticated via a home AAA server.
The specific details of the interaction between the HA and the AAA
server is beyond the scope of this document.
When the Home Agent receives a Binding Update with the MN-AAA
mobility message authentication option, the Binding Update is
authenticated by an entity external to the Home Agent, typically a
AAA server.
5.3. Authentication Failure Detection at the Mobile Node
In case of authentication failure, the Home Agent MUST send a Binding
Acknowledgement with status code MIPV6-AUTH-FAIL to the Mobile Node,
if a shared-key-based mobility security association to be used
between Mobile Node and Home Agent for authentication exists. If
there is no shared-key-based mobility security association, HA drops
the Binding Update. HA may log the message for administrative
action.
Upon receiving a Binding Acknowledgement with status code MIPV6-
AUTH-FAIL, the Mobile Node SHOULD stop sending new Binding Updates to
the Home Agent.
6. Mobility Message Replay Protection Option
The Mobility message replay protection option MAY be used in Binding