draft-ietf-mip6-auth-protocol-06.txt   draft-ietf-mip6-auth-protocol-07.txt 
Network Working Group A. Patel Network Working Group A. Patel
Internet-Draft K. Leung Internet-Draft K. Leung
Expires: March 2, 2006 Cisco Systems Expires: March 23, 2006 Cisco Systems
M. Khalil M. Khalil
H. Akhtar H. Akhtar
Nortel Networks Nortel Networks
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
August 29, 2005 September 19, 2005
Authentication Protocol for Mobile IPv6 Authentication Protocol for Mobile IPv6
draft-ietf-mip6-auth-protocol-06.txt draft-ietf-mip6-auth-protocol-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 2, 2006. This Internet-Draft will expire on March 23, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
IPsec is specified as the sole means of securing all signaling IPsec is specified as the means of securing signaling messages
messages between the Mobile Node and Home agent for Mobile IPv6. A between the Mobile Node and Home agent for Mobile IPv6 (MIPv6).
flexible model for security between the Mobile Node and Home Agent is MIPv6 signalling messages that are secured include the Binding
required from the perspective of deployment of the Mobile IPv6 Updates and Acknowledgement messages used for managing the bindings
protocol. One instance of such deployment need comes from networks between a Mobile Node and its Home Agent. This document proposes an
that are built on 3GPP2 standards. This document proposes an alternate method for securing MIPv6 signaling messages between a
alternate method for securing the signaling messages that are Mobile Nodes and Home Agents. The alternate method defined here
responsible for performing Registration of a Mobile Node at a home conists of a MIPv6-specific authentication option that can be added
agent. to MIPv6 signalling messages.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Operational flow . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 6
5. Mobility message authentication option . . . . . . . . . . . . 7 4. Operational flow . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. MN-HA authentication mobility option . . . . . . . . . . . 8 5. Mobility message authentication option . . . . . . . . . . . . 8
5.1.1. Processing Considerations . . . . . . . . . . . . . . 9 5.1. MN-HA authentication mobility option . . . . . . . . . . . 10
5.2. MN-AAA authentication mobility option . . . . . . . . . . 10 5.1.1. Processing Considerations . . . . . . . . . . . . . . 10
5.2.1. Processing Considerations . . . . . . . . . . . . . . 10 5.2. MN-AAA authentication mobility option . . . . . . . . . . 11
5.3. Authentication Failure Detection at the Mobile Node . . . 11 5.2.1. Processing Considerations . . . . . . . . . . . . . . 12
6. Mobility message replay protection option . . . . . . . . . . 12 5.3. Authentication Failure Detection at the Mobile Node . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Mobility message replay protection option . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Rationale for mobility message replay protection Appendix A. Rationale for mobility message replay protection
option . . . . . . . . . . . . . . . . . . . . . . . 19 option . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23
1. Introduction 1. Introduction
The base Mobile IPv6 specification [RFC3775] specifies the signaling The base Mobile IPv6 specification [RFC3775] specifies the signaling
messages, Binding Update (BU) and Binding Acknowledgement (BA), messages, Binding Update (BU) and Binding Acknowledgement (BA),
between the Mobile Node and Home agent to be secured by the IPsec between the Mobile Node and Home agent to be secured by the IPsec
Security Associations (IPsec SAs) that are established between these Security Associations (IPsec SAs) that are established between these
two entities. two entities.
The architecture of cdma2000 networks and the motivation of using the
authentication option for Mobile IP in that architecture is described
in [whyauth].
This document proposes a solution for securing the Binding Update and This document proposes a solution for securing the Binding Update and
Binding Acknowledgment messages between the Mobile Node and Home Binding Acknowledgment messages between the Mobile Node and Home
agent using an authentication option which is included in these agent using an authentication option which is included in these
messages. Such a mechanism enables IPv6 mobility in a host without messages. Such a mechanism enables IPv6 mobility in a host without
having to establish an IPsec SA with its Home Agent. A Mobile Node having to establish an IPsec SA with its Home Agent. A Mobile Node
can implement Mobile IPv6 without having to integrate it with the can implement Mobile IPv6 without having to integrate it with the
IPsec module, in which case the Binding Update and Binding IPsec module, in which case the Binding Update and Binding
Acknowldegement messages (between MN-HA) are secured with the Acknowldegement messages (between MN-HA) are secured with the
authentication option. It does not imply that the availability of authentication option.
such a solution deprecates the use of IPsec for securing Mobile IPv6
signaling between Mobile Nodes and Home Agents. Home agents still
have to implement and support registrations from Mobile Nodes that
are secured via IPsec as well as with the authentication option.
The authentication mechanism proposed here is similar to the The authentication mechanism proposed here is similar to the
authentication mechanism used in Mobile IPv4 [RFC3344]. authentication mechanism used in Mobile IPv4 [RFC3344].
1.1. Applicability Statement
The 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 (eg. AAA home server). MIP6 as per RFC3775/
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
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 an NAI [MN_Ident],
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 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 if not within the scope of the authentication option
Section 5 and hence 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
[IKEv2-REF] 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 MIP6 deployment.
- Networks which expressly rely on the backend AAA infrastructure as
the primary means for identifying and authentication/authorizing a
mobile user for MIP6 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 which are bandwidth constrained (such as cellular wireless
networks) and there exists a strong desire to minimize the number of
signaling messages sent over such interfaces. MIP6 signaling which
relies on 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 authentication option carried in the BU/BAck messages.
One such example of networks that have such characteristics are cdma
networks as defined in [3GPP2].
2. Overview 2. Overview
This document presents a lightweight mechanism to authenticate the This document presents a lightweight mechanism to authenticate the
Mobile Node at the Home Agent or at the Authentication, Authorization Mobile Node at the Home Agent or at the Authentication, Authorization
and Accounting (AAA) server in Home network (AAAH) based on a shared and Accounting (AAA) server in Home network (AAAH) based on a shared-
key based mobility security association between the Mobile Node and key based mobility security association between the Mobile Node and
the respective authenticating entity. This shared key based mobility the respective authenticating entity. This shared-key based mobility
security association (shared-key based SA) may be statically security association (shared-key based mobility SA) may be statically
provisioned or dynamically created. The term "mobility security provisioned or dynamically created. The term "mobility security
association" referred to in this document is understood to be a association" referred to in this document is understood to be a
"shared-key based Mobile IPv6 authentication" security association. "shared-key based Mobile IPv6 authentication" security association.
This document introduces new mobility options to aid in This document introduces new mobility options to aid in
authentication of the Mobile Node to the Home Agent or AAAH server. authentication of the Mobile Node to the Home Agent or AAAH server.
The confidentiality protection of Return Routability messages and The confidentiality protection of Return Routability messages and
authentication/integrity protection of Mobile Prefix Discovery (MPD) authentication/integrity protection of Mobile Prefix Discovery (MPD)
is outside the scope of this document. The Home Agent SHOULD prevent is not provided when these options are used for authentication of the
these operations for a Mobile Node when such protection cannot be Mobile Node to the Home Agent. Thus, unless the network can
provided by the network. guarantee such protection (for instance, like in 3gpp2 networks),
Route Optimization and Mobile Prefix Discovery should not be used
when using the authentication option.
3. Terminology 3. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
3.1. General Terms 3.1. General Terms
First (size, input) First (size, input)
Some formulas in this specification use a functional form "First Some formulas in this specification use a functional form "First
(size, input)" to indicate truncation of the "input" data so that (size, input)" to indicate truncation of the "input" data so that
only the first "size" bits remain to be used. only the first "size" bits remain to be used.
Shared-key based Mobility Security Association
Security relation between 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 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 4. Operational flow
The figure below describes the sequence of messages sent and received The figure below describes the sequence of messages sent and received
between the MN and HA in the registration process. Binding Update between the MN and HA in the registration process. Binding Update
(BU) and Binding Acknowledgement (BA) messages are used in the (BU) and Binding Acknowledgement (BA) messages are used in the
registration process. registration process.
MN HA/AAAH MN HA/AAAH
| BU to HA | | BU to HA |
(a) |----------------------------------------------------->| (a) |----------------------------------------------------->|
skipping to change at page 6, line 30 skipping to change at page 7, line 30
| | | |
| | | |
| BA to MN | | BA to MN |
(b) |<-----------------------------------------------------| (b) |<-----------------------------------------------------|
| (including MN-ID option, | | (including MN-ID option, |
| Message ID option [optional], authentication option)| | Message ID option [optional], authentication option)|
| | | |
Figure 1: Home Registration with Authentication Protocol Figure 1: Home Registration with Authentication Protocol
Mobile Node MUST use the Mobile Node Identifier Option, specifically The Mobile Node MUST use the Mobile Node Identifier Option,
the MN-NAI mobility option as defined in [MN_Ident] to identify specifically the MN-NAI mobility option as defined in [MN_Ident] to
itself while authenticating with the Home Agent. The mobile node identify itself while authenticating with the Home Agent. The mobile
uses the Mobile Node Identifier option as defined in [MN_Ident] to node uses the Mobile Node Identifier option as defined in [MN_Ident]
identify itself as may be required for use with some existing AAA to identify itself as may be required for use with some existing AAA
infrastructure designs. infrastructure designs.
Mobile Node MAY use Message Identifier option as defined in Section 6 Mobile Node MAY use Message Identifier option as defined in Section 6
for additional replay protection. for additional replay protection.
The authentication option described in Section 5 may be used by the The authentication option described in Section 5 may be used by the
mobile node to transfer authentication data when the mobile node and mobile node to transfer authentication data when the mobile node and
the home agent are utilizing an SPI to index between multiple the home agent are utilizing a mobility SPI (a number in the range
mobility security associations. For the case when there is only one [0-4294967296] used to index into the shared-key based mobility
such mobility security association, and no SPI is needed, the Mobile security associations). to index between multiple mobility security
Node and Home Agent can use the Binding Authorization Data option as associations.
defined in the base Mobile IPv6 specification [RFC3775] for this same
purpose. Since that option does not have any SPI, the Mobile Node
and the Home Agent implicitly agree that the mobility security
association to be used is the only mobility security association that
is defined for their mutual authentication needs.
5. Mobility message authentication option 5. Mobility message authentication option
This section defines a message authentication mobility option that This section defines a message authentication mobility option that
may be used to secure Binding Update and Binding Acknowledgement may be used to secure Binding Update and Binding Acknowledgement
messages. This option can be used along with IPsec or preferably as messages. This option can be used along with IPsec or preferably as
an alternate mechanism to authenticate Binding Update and Binding an alternate mechanism to authenticate Binding Update and Binding
Acknowledgement messages in the absence of IPsec. Acknowledgement messages in the absence of IPsec.
This document also defines subtype numbers, which identify the mode This document also defines subtype numbers, which identify the mode
of authentication and the peer entity to authenticate the message. of authentication and the peer entity to authenticate the message.
Two subtype numbers are specified in this document. Other subtypes Two subtype numbers are specified in this document. Other subtypes
may be defined for use in the future. may be defined for use in the future.
Only one instance of an authentication option of a particular subtype Only one instance of an authentication option of a particular subtype
can be present in the message. One message may contain multiple can be present in the message. One message may contain multiple
instances of authentication options with different subtype values. instances of authentication options with different subtype values.
If both MN-HA and MN-AAA authentication options are present, 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 When a Binding Update or Binding Acknowledgement is received without
an authentication option and the entity receiving it is configured to an authentication option and the entity receiving it is configured to
use authentication option or has the shared-key based mobility use authentication option or has the shared-key based mobility
security association for authentication option, the entity should security association for authentication option, the entity should
silently discard the received message. silently discard the received message.
0 1 2 3 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 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 | | Option Type | Option Length | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI | | Mobility SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data .... | Authentication Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Figure 2
Option Type: Option Type:
AUTH-OPTION-TYPE to be defined by IANA. An 8-bit identifier of AUTH-OPTION-TYPE to be defined by IANA. An 8-bit identifier of
the type mobility option. the type mobility option.
Option Length: Option Length:
8-bit unsigned integer, representing the length in octets of 8-bit unsigned integer, representing the length in octets of
the Sub-type, Security Parameter Index (SPI) and Authentication the Sub-type, mobility Security Parameter Index (SPI) and
Data fields. Authentication Data fields.
Subtype: Subtype:
A number assigned to identify the entity and/or mechanism to be A number assigned to identify the entity and/or mechanism to be
used to authenticate the message. used to authenticate the message.
SPI: Mobility SPI:
Security Parameter Index Mobility Security Parameter Index
Authentication Data: Authentication Data:
This field has the information to authenticate the relevant This field has the information to authenticate the relevant
mobility entity. This protects the message beginning at the mobility entity. This protects the message beginning at the
Mobility Header upto and including the SPI field. Mobility Header upto and including the mobility SPI field.
Alignment requirements : Alignment requirements :
The alignment requirement for this option is 4n + 1. The alignment requirement for this option is 4n + 1.
5.1. MN-HA authentication mobility option 5.1. MN-HA authentication mobility option
The format of the MN-HA authentication mobility option is as defined The format of the MN-HA authentication mobility option is as defined
in Figure 2. This option uses the subtype value of 1. The MN-HA in Figure 2. This option uses the subtype value of 1. The MN-HA
authentication mobility option is used to authenticate the Binding authentication mobility option is used to authenticate the Binding
Update and Binding Acknowledgement messages based on the shared-key Update and Binding Acknowledgement messages based on the shared-key
based security association between the Mobile Node and the Home based security association between the Mobile Node and the Home
Agent. Agent.
The shared-key based mobility security association between Mobile The shared-key based mobility security association between Mobile
Node and Home Agent used within this specification consists of a SPI, Node and Home Agent used within this specification consists of a
a key, an authentication algorithm and the replay protection mobility SPI, a key, an authentication algorithm and the replay
mechanism in use. The SPI is a number in range [0-4294967296], where protection mechanism in use. The mobility SPI is a number in range
the range [0-255] is reserved. The key consists of an arbitrary [0-4294967296], where the range [0-255] is reserved. The key
value and is 16 octets in length. The authentication algorithm is consists of an arbitrary value and is 16 octets in length. The
HMAC_SHA1. The replay protection mechanism may use the Sequence authentication algorithm is HMAC_SHA1. The replay protection
number as specified in [RFC3775] or the option as defined in mechanism may use the Sequence number as specified in [RFC3775] or
Section 6. If the Timestamp option is used for replay protection as the option as defined in Section 6. If the Timestamp option is used
defined in Section 6, the mobility security association includes a for replay protection as defined in Section 6, the mobility security
"close enough" field to account for clock drift. A default value of association includes a "close enough" field to account for clock
7 seconds MAY be used. This value SHOULD be greater than 3 seconds. drift. A default value of 7 seconds SHOULD be used. This value
SHOULD be greater than 3 seconds.
This MUST be the last option in a message with mobility header if it This MUST be the last option in a message with mobility header if it
is the only authentication option in the message. is the only authentication option in the message.
The authentication data is calculated on the message starting from The authentication data is calculated on the message starting from
the mobility header upto and including the SPI value of this option. the mobility header upto and including the mobility SPI value of this
option.
Authentication Data = First (96, HMAC_SHA1(MN-HA Shared key, Mobility Authentication Data = First (96, HMAC_SHA1(MN-HA Shared key, Mobility
Data)) Data))
Mobility Data = care-of address | home address | Mobility Header(MH) Mobility Data = care-of address | home address | Mobility Header(MH)
Data Data
MH Data is the content of the Mobility Header upto and including the MH Data is the content of the Mobility Header upto and including the
SPI field of this option. The Checksum field in Mobility Header MUST mobility SPI field of this option. The Checksum field in Mobility
be set to 0 to calculate the Mobility Data. Header MUST be set to 0 to calculate the Mobility Data.
The first 96 bits from the MAC result are used as the Authentication The first 96 bits from the MAC result are used as the Authentication
Data field. Data field.
5.1.1. Processing Considerations 5.1.1. Processing Considerations
The assumption is that Mobile Node has a shared-key based security The assumption is that Mobile Node has a shared-key based security
association with the Home Agent. The Mobile Node MUST include this association with the Home Agent. The Mobile Node MUST include this
option in a BU if it has a shared-key based mobility security option in a BU if it has a shared-key based mobility security
association with the Home Agent. The Home Agent MUST include this association with the Home Agent. The Home Agent MUST include this
option in the BA if it received this option in the corresponding BU option in the BA if it received this option in the corresponding BU
and Home Agent has a shared-key based mobility security association and Home Agent has a shared-key based mobility security association
with the Mobile Node. with the Mobile Node.
The Mobile Node or Home Agent receiving this option MUST verify the The Mobile Node or Home Agent receiving this option MUST verify the
authentication data in the option. If authentication fails, the Home authentication data in the option. If authentication fails, the Home
Agent MUST send BA with Status Code MIPV6-AUTH-FAIL. If the Home Agent MUST send BA with Status Code MIPV6-AUTH-FAIL. If the Home
Agent does not have shared-key based SA, Home Agent MUST discard the Agent does not have shared-key based mobility SA, Home Agent MUST
BU. The Home Agent MAY log such events. discard the BU. The Home Agent MAY log such events.
5.2. MN-AAA authentication mobility option 5.2. MN-AAA authentication mobility option
The format of the MN-AAA authentication mobility option is as defined The format of the MN-AAA authentication mobility option is as defined
in Figure 2. This option uses the subtype value of 2. The MN-AAA in Figure 2. This option uses the subtype value of 2. The MN-AAA
authentication mobility option is used to authenticate the Binding authentication mobility option is used to authenticate the Binding
Update message based on the shared mobility security association Update message based on the shared mobility security association
between Mobile Node and AAA server in Home network (AAAH). It is not between Mobile Node and AAA server in Home network (AAAH). It is not
used in Binding Acknowledgement messages. The corresponding Binding used in Binding Acknowledgement messages. The corresponding Binding
Acknowledgement messages must be authenticated using the MN-HA Acknowledgement messages must be authenticated using the MN-HA
authentication option Section 5.1. authentication option Section 5.1.
This must be the last option in a message with mobility header. The This must be the last option in a message with mobility header. The
corresponding response MUST include the Mobile-Home Authentication corresponding response MUST include the Mobile-Home Authentication
option, and MUST NOT include the Mobile-AAA Authentication option. option, and MUST NOT include the Mobile-AAA Authentication option.
The Mobile Node MAY use Mobile Node Identifier option [MN_Ident] to The Mobile Node MAY use Mobile Node Identifier option [MN_Ident] to
enable the Home Agent to make use of available AAA infrastructure. enable the Home Agent to make use of available AAA infrastructure.
The authentication data is calculated on the message starting from The authentication data is calculated on the message starting from
the mobility header upto and including the SPI value of this option. the mobility header upto and including the mobility SPI value of this
option.
The authentication data shall be calculated as follows: The authentication data shall be calculated as follows:
Authentication data = hash_fn(MN-AAA Shared key, MAC_Mobility Data) Authentication data = hash_fn(MN-AAA Shared key, MAC_Mobility Data)
hash_fn() is decided by the value of SPI field in the authentication hash_fn() is decided by the value of mobility SPI field in the
option. authentication option.
SPI = HMAC_SHA1_SPI: SPI = HMAC_SHA1_SPI:
If SPI has the well-known value HMAC_SHA1_SPI, then hash_fn() is If mobility SPI has the well-known value HMAC_SHA1_SPI, then
HMAC_SHA1. When HMAC_SHA1_SPI is used, the BU is authenticated by hash_fn() is HMAC_SHA1. When HMAC_SHA1_SPI is used, the BU is
AAA using HMAC_SHA1 authentication. In that case, MAC_Mobility Data authenticated by AAA using HMAC_SHA1 authentication. In that case,
is calculated as follows: MAC_Mobility Data is calculated as follows:
MAC_Mobility Data = SHA1(care-of address | home address | MH Data) MAC_Mobility Data = SHA1(care-of address | home address | MH Data)
MH Data is the content of the Mobility Header upto and including the MH Data is the content of the Mobility Header upto and including the
SPI field of this option. mobility SPI field of this option.
5.2.1. Processing Considerations 5.2.1. Processing Considerations
Interaction between the HA and the AAA server is beyond the scope of The use of the MN-AAA 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 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. this document.
When the Home Agent receives a Binding Update with the Mobile-AAA When the Home Agent receives a Binding Update with the Mobile-AAA
authentication option, the Binding Update is authenticated by an authentication option, the Binding Update is authenticated by an
entity external to the Home Agent, typically a AAA server. entity external to the Home Agent, typically a AAA server.
5.3. Authentication Failure Detection at the Mobile Node 5.3. Authentication Failure Detection at the Mobile Node
In case of authentication failure, the Home Agent MUST send a Binding In case of authentication failure, the Home Agent MUST send a Binding
Acknowledgement with status code MIPV6-AUTH-FAIL to the Mobile Node, Acknowledgement with status code MIPV6-AUTH-FAIL to the Mobile Node,
if an SA to be used between Mobile Node and Home Agent for if a shared-key based mobility security association to be used
authentication exists. 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- Upon receiving a Binding Acknowledgement with status code MIPV6-AUTH-
FAIL, the Mobile Node SHOULD stop sending new Binding Updates to the FAIL, the Mobile Node SHOULD stop sending new Binding Updates to the
Home Agent. Home Agent.
6. Mobility message replay protection option 6. Mobility message replay protection option
The Mobility message replay protection option MAY be used in Binding The Mobility message replay protection option MAY be used in Binding
Update/Binding Acknowledgement messages when authenticated using the Update/Binding Acknowledgement messages when authenticated using the
mobility message authentication option as described in Section 5. mobility message authentication option as described in Section 5.
skipping to change at page 12, line 21 skipping to change at page 13, line 21
The mobility message replay protection option is used to let the Home The mobility message replay protection option is used to let the Home
Agent verify that a Binding Update has been freshly generated by the Agent verify that a Binding Update has been freshly generated by the
Mobile Node and not replayed by an attacker from some previous Mobile Node and not replayed by an attacker from some previous
Binding Update. This is especially useful for cases where the Home Binding Update. This is especially useful for cases where the Home
Agent does not maintain stateful information about the Mobile Node Agent does not maintain stateful information about the Mobile Node
after the binding entry has been removed. The Home Agent does the after the binding entry has been removed. The Home Agent does the
replay protection check after the Binding Update has been replay protection check after the Binding Update has been
authenticated. The mobility message replay protection option when authenticated. The mobility message replay protection option when
included is used by the Mobile Node for matching BA with BU. included is used by the Mobile Node for matching BA with BU.
If this mode of replay protection is used, it needs to be part of the
shared-key based mobility security association.
If the policy at Home Agent mandates replay protection using this If the policy at Home Agent mandates replay protection using this
option (as opposed to the sequence number in Mobility Header in option (as opposed to the sequence number in Mobility Header in
Binding Update) and the Binding Update from Mobile Node does not Binding Update) and the Binding Update from Mobile Node does not
include this option, Home Agent discards the BU and sets the Status include this option, Home Agent discards the BU and sets the Status
Code in BA to MIPV6-MESG-ID-REQD. Code in BA to MIPV6-MESG-ID-REQD.
When the Home Agent receives the mobility message replay protection When the Home Agent receives the mobility message replay protection
option in Binding Update, it SHOULD include the mobility message option in Binding Update, it MUST include the mobility message replay
replay protection option in Binding Acknowledgement. Appendix A protection option in Binding Acknowledgement. Appendix A provides
provides details regarding why the mobility message replay protection details regarding why the mobility message replay protection option
option MAY be used when using the authentication option. MAY be used when using the authentication option.
0 1 2 3 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 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 | | Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp ... | | Timestamp ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 24 skipping to change at page 17, line 24
for the MESG-ID-OPTION-TYPE Mobility Option. for the MESG-ID-OPTION-TYPE Mobility Option.
The values for status codes MIPV6-ID-MISMATCH, MIPv6-AUTH-FAIL and The values for status codes MIPV6-ID-MISMATCH, MIPv6-AUTH-FAIL and
MIPV6-MESG-ID-REQD as defined in Section 6, Section 6 and Section 5.3 MIPV6-MESG-ID-REQD as defined in Section 6, Section 6 and Section 5.3
also need to be assigned. The suggested values are 144 for MIPV6-ID- also need to be assigned. The suggested values are 144 for MIPV6-ID-
MISMATCH 145 for MIPV6-MESG-ID-REQD and 146 for MIPV6-AUTH-FAIL. MISMATCH 145 for MIPV6-MESG-ID-REQD and 146 for MIPV6-AUTH-FAIL.
IANA should record values for these new Mobility Options and the new IANA should record values for these new Mobility Options and the new
Status Codes. Status Codes.
A new section for enumerating algorithms identified by specific SPIs A new section for enumerating algorithms identified by specific
within the range 0-255 is to be added to mobility SPIs within the range 0-255 is to be added to
http://www.isi.edu/in-notes/iana/assignments/mobility-parameters http://www.isi.edu/in-notes/iana/assignments/mobility-parameters
The currently defined values are as follows: The currently defined values are as follows:
The value 0 should not be assigned. The value 0 should not be assigned.
The value 3 is suggested for HMAC_SHA1_SPI as defined in Section 5.2. The value 3 is suggested for HMAC_SHA1_SPI as defined in Section 5.2.
The value 5 is reserved for use by 3GPP2. The value 5 is reserved for use by 3GPP2.
New values for this namespace can be allocated using Standards Action New values for this namespace can be allocated using IETF Consensus.
[RFC2434]. [RFC2434].
In addition, IANA needs to create a new namespace for the subtype In addition, IANA needs to create a new namespace for the subtype
field of the MN-HA and MN-AAA authentication mobility options under field of the MN-HA and MN-AAA authentication mobility options under
http://www.isi.edu/in-notes/iana/assignments/mobility-parameters http://www.isi.edu/in-notes/iana/assignments/mobility-parameters
The currently allocated values are as follows: The currently allocated values are as follows:
1 MN-HA authentication mobility option Section 5.1 1 MN-HA authentication mobility option Section 5.1
2 MN-AAA authentication mobility option Section 5.2 2 MN-AAA authentication mobility option Section 5.2
New values for this namespace can be allocated using Standards Action New values for this namespace can be allocated using IETF Consensus.
[RFC2434]. [RFC2434].
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Basavaraj Patil, Charlie Perkins The authors would like to thank Basavaraj Patil, Charlie Perkins
Vijay Devarapalli and Jari Arkko for their thorough review and Vijay Devarapalli, Jari Arkko and Gopal Dommety for their thorough
suggestions on the document. The authors would like to acknowledge review and suggestions on the document. The authors would like to
the fact that a similar authentication method was considered in base acknowledge the fact that a similar authentication method was
protocol [RFC3775] at one time. considered in base protocol [RFC3775] at one time.
10. References 10. References
10.1. Normative References 10.1. Normative References
[MN_Ident] [MN_Ident]
Patel et. al., A., "Mobile Node Identifier Option for Patel et. al., A., "Mobile Node Identifier Option for
Mobile IPv6", draft-ietf-mip6-mn-ident-option-03.txt (work Mobile IPv6", draft-ietf-mip6-mn-ident-option-03.txt (work
in progress), December 2004. in progress), December 2004.
skipping to change at page 18, line 29 skipping to change at page 19, line 29
October 1998. October 1998.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
10.2. Informative References 10.2. Informative References
[3GPP2] "cdma2000 Wireless IP Network Standard", 3GPP2 X.S0011-D,
September 2005.
[IKEv2-REF]
Kaufman, et. al, C., "Internet Key Exchange (IKEv2)
Protocol", draft-ietf-ipsec-ikev2-17.txt (work in
progress).
[whyauth] Patil et. al., B., "Why Authentication Data suboption is [whyauth] Patil et. al., B., "Why Authentication Data suboption is
needed for MIP6", needed for MIP6",
draft-patil-mip6-whyauthdataoption-01.txt (work in draft-patil-mip6-whyauthdataoption-01.txt (work in
progress), September 2005. progress), September 2005.
Appendix A. Rationale for mobility message replay protection option Appendix A. Rationale for mobility message replay protection option
Mobile IPv6 [RFC3775] defines a Sequence Number in the mobility Mobile IPv6 [RFC3775] defines a Sequence Number in the mobility
header to prevent replay attacks. There are two aspects that stand header to prevent replay attacks. There are two aspects that stand
out in regards to using the Sequence Number to prevent replay out in regards to using the Sequence Number to prevent replay
skipping to change at page 19, line 38 skipping to change at page 20, line 38
authentication option is used, Sequence Number does not provide authentication option is used, Sequence Number does not provide
protection against replay attack. protection against replay attack.
One solution to this problem (when Home Agent does not save state One solution to this problem (when Home Agent does not save state
information for every Mobile Node) would be for the Home Agent to information for every Mobile Node) would be for the Home Agent to
reject the first BU and assign a (randomly generated) starting reject the first BU and assign a (randomly generated) starting
sequence number for the session and force the Mobile Node to send a sequence number for the session and force the Mobile Node to send a
fresh BU with the suggested sequence number. While this would work fresh BU with the suggested sequence number. While this would work
in most cases, it would require an additional round trip and this in most cases, it would require an additional round trip and this
extra signalling and latency is not acceptable in certain deployments extra signalling and latency is not acceptable in certain deployments
(3GPP2). Also, this rejection and using sequence number as a nonce [3GPP2]. Also, this rejection and using sequence number as a nonce
in rejection is a new behavior that is not specified in [RFC3775]. in rejection is a new behavior that is not specified in [RFC3775].
Thus, this specification uses the mobility message replay protection Thus, this specification uses the mobility message replay protection
option to prevent replay attacks. Specifically, timestamps are used option to prevent replay attacks. Specifically, timestamps are used
to prevent replay attacks as described in Section 6. to prevent replay attacks as described in Section 6.
It is important to note that as per Mobile IPv6 [RFC3775] this It is important to note that as per Mobile IPv6 [RFC3775] this
problem with sequence number exists. Since the base specification problem with sequence number exists. Since the base specification
mandates the use of IPsec (and naturally that goes with IKE in most mandates the use of IPsec (and naturally that goes with IKE in most
cases), the real replay protection is provided by IPsec/IKE. In case cases), the real replay protection is provided by IPsec/IKE. In case
 End of changes. 41 change blocks. 
109 lines changed or deleted 195 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/