draft-ietf-mip6-auth-protocol-04.txt   draft-ietf-mip6-auth-protocol-05.txt 
Network Working Group A. Patel Network Working Group A. Patel
Internet-Draft K. Leung Internet-Draft K. Leung
Expires: August 11, 2005 Cisco Systems Expires: February 23, 2006 Cisco Systems
M. Khalil M. Khalil
H. Akhtar H. Akhtar
Nortel Networks Nortel Networks
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
February 10, 2005 August 22, 2005
Authentication Protocol for Mobile IPv6 Authentication Protocol for Mobile IPv6
draft-ietf-mip6-auth-protocol-04.txt draft-ietf-mip6-auth-protocol-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. 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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 August 11, 2005. This Internet-Draft will expire on February 23, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
IPsec is specified as the sole means of securing all signaling IPsec is specified as the sole means of securing all signaling
messages between the Mobile Node and Home agent for Mobile IPv6. A messages between the Mobile Node and Home agent for Mobile IPv6. A
flexible model for security between the Mobile Node and Home Agent is flexible model for security between the Mobile Node and Home Agent is
required from the perspective of deployment of the Mobile IPv6 required from the perspective of deployment of the Mobile IPv6
protocol. One instance of such deployment need comes from networks protocol. One instance of such deployment need comes from networks
that are built on 3GPP2 standards. This document proposes an that are built on 3GPP2 standards. This document proposes an
alternate method for securing the signaling messages that are alternate method for securing the signaling messages that are
responsible for performing Registration of a Mobile Node at a home responsible for performing Registration of a Mobile Node at a home
agent. agent.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 General Terms . . . . . . . . . . . . . . . . . . . . . . 5 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 5
4. Operational flow . . . . . . . . . . . . . . . . . . . . . . . 6 4. Operational flow . . . . . . . . . . . . . . . . . . . . . . . 6
5. Mobility message authentication option . . . . . . . . . . . . 7 5. Mobility message authentication option . . . . . . . . . . . . 7
5.1 MN-HA authentication mobility option . . . . . . . . . . . 8 5.1. MN-HA authentication mobility option . . . . . . . . . . . 8
5.1.1 Processing Considerations . . . . . . . . . . . . . . 9 5.1.1. Processing Considerations . . . . . . . . . . . . . . 9
5.2 MN-AAA authentication mobility option . . . . . . . . . . 9 5.2. MN-AAA authentication mobility option . . . . . . . . . . 10
5.2.1 Processing Considerations . . . . . . . . . . . . . . 10 5.2.1. Processing Considerations . . . . . . . . . . . . . . 10
5.3 Authentication Failure Detection at the Mobile Node . . . 10 5.3. Authentication Failure Detection at the Mobile Node . . . 11
6. Mobility message replay protection option . . . . . . . . . . 11 6. Mobility message replay protection option . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. Normative References . . . . . . . . . . . . . . . . . . . . 17 10. Normative References . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Rationale for mobility message replay protection
A. Rationale for mobility message replay protection option . . . 19 option . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 21
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. This security model for Mobile IPv6 does not fit in two entities.
very well for deployment scenarios which:
1. rely on the use of an Authentication, Authorization and
Accounting (AAA) infrastructure for authenticating the subscriber
2. require dynamic assignment of Home Agent and home addresses
3. have constraints on the number of messages involved in setting up
IPsec SAs
4. include Mobile Nodes that do not support IKEv1
This indicates the need for a solution that does not necessarily The draft draft-patil-mip6-whyauthdataoption-01.txt describes the
require an IPsec SA for securing the signaling messages that deal architecture of cdma2000 networks and the motivation of using the
with the Registration process of a Mobile Node with a home agent. authentication option for Mobile IP in that architecture.
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. It does not imply that the availability of
skipping to change at page 4, line 10 skipping to change at page 4, line 10
are secured via IPsec as well as with the authentication option. 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].
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 security association between the Mobile Node and the key based mobility security association between the Mobile Node and
respective authenticating entity. This shared key based security the respective authenticating entity. This shared key based mobility
association (shared-key based SA) may be statically provisioned or security association (shared-key based SA) may be statically
dynamically created. The term "security association" referred to in provisioned or dynamically created. The term "mobility security
this document is understood to be a "shared-key based Mobile IPv6 association" referred to in this document is understood to be a
authentication" security association. The Mobile Node MUST use only "shared-key based Mobile IPv6 authentication" security association.
one means of authentication, based on either the shared key based
authentication or IPsec security association with a selected Home
Agent at any given time. However a MN that implements both schemes
of authentication may choose any appropriate scheme with the chosen
HA. The determination of what authentication scheme to use is beyond
the scope of this document. Home agents still have to implement and
support registrations from Mobile Nodes that are secured via IPsec as
well as with the authentication option.
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. is outside the scope of this document. The Home Agent SHOULD prevent
these operations for a Mobile Node when such protection cannot be
provided by the network.
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 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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.
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) |----------------------------------------------------->|
| (including MN-ID option [optional], | | (including MN-ID option, |
| Message ID option [optional], authentication option)| | Message ID option [optional], authentication option)|
| | | |
| | | |
| HA/AAAH authenticates MN | HA/AAAH authenticates MN
| | | |
| | | |
| BA to MN | | BA to MN |
(b) |<-----------------------------------------------------| (b) |<-----------------------------------------------------|
| (including MN-ID option [optional], | | (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 MAY use Mobile Node Identifier Option as defined in Mobile Node MUST use the Mobile Node Identifier Option, specifically
[MN_Ident] or Home Address to identify itself while authenticating the MN-NAI mobility option as defined in [MN_Ident] to identify
with the Home Agent. The mobile node uses the Mobile Node Identifier itself while authenticating with the Home Agent. The mobile node
option as defined in [MN_Ident] to identify itself as may be required uses the Mobile Node Identifier option as defined in [MN_Ident] to
for use with some existing AAA infrastructure designs. identify itself as may be required for use with some existing AAA
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 an SPI to index between multiple
security associations. For the case when there is only one such mobility security associations. For the case when there is only one
security association, and no SPI is needed, the Mobile Node and Home such mobility security association, and no SPI is needed, the Mobile
Agent can use the Binding Authorization Data option as defined in the Node and Home Agent can use the Binding Authorization Data option as
base Mobile IPv6 specification [RFC3775] for this same purpose. defined in the base Mobile IPv6 specification [RFC3775] for this same
Since that option does not have any SPI, the Mobile Node and the Home purpose. Since that option does not have any SPI, the Mobile Node
Agent implicitly agree that the security association to be used is and the Home Agent implicitly agree that the mobility security
the only mobility security association that is defined for their association to be used is the only mobility security association that
mutual authentication needs. 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.
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 security use authentication option or has the shared-key based mobility
association for authentication option, the entity should silently security association for authentication option, the entity should
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 | | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data .... | Authentication Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 24 skipping to change at page 8, line 28
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 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 security association between Mobile Node and The shared-key based mobility security association between Mobile
Home Agent used within this specification consists of a SPI, a key, Node and Home Agent used within this specification consists of a SPI,
an authentication algorithm and the replay protection mechanism in a key, an authentication algorithm and the replay protection
use. The SPI is a number in range [0-4294967296], where the range mechanism in use. The SPI is a number in range [0-4294967296], where
[0-255] is reserved. The key consists of an arbitrary value and is the range [0-255] is reserved. The key consists of an arbitrary
16 octets in length. The authentication algorithm is HMAC_SHA1. The value and is 16 octets in length. The authentication algorithm is
replay protection mechanism may use the Sequence number as specified HMAC_SHA1. The replay protection mechanism may use the Sequence
in [RFC3775] or the option as defined in Section 6. If the Timestamp number as specified in [RFC3775] or the option as defined in
option is used for replay protection as defined in Section 6, the Section 6. If the Timestamp option is used for replay protection as
security association includes a "close enough" field to account for defined in Section 6, the mobility security association includes a
clock drift. A default value of 7 seconds MAY be used. This value "close enough" field to account for clock drift. A default value of
SHOULD be greater than 3 seconds. 7 seconds MAY 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. It must occur is the only authentication option in the message.
before the MN-AAA Section 5.2 authentication option if both options
are present 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 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 SPI field of this option. The Checksum field in Mobility Header MUST
be set to 0 to calculate the Mobility Data. 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 security association with option in a BU if it has a shared-key based mobility security
the Home Agent. The Home Agent MUST include this option in the BA if association with the Home Agent. The Home Agent MUST include this
it received this option in the corresponding BU and Home Agent has a option in the BA if it received this option in the corresponding BU
shared-key based security association with the Mobile Node. 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 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 SA, Home Agent MUST discard the
BU. The Home Agent MAY log such events. 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 security association between Update message based on the shared mobility security association
Mobile Node and AAA server in Home network (AAAH). It is not used in between Mobile Node and AAA server in Home network (AAAH). It is not
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. If This must be the last option in a message with mobility header. The
both Mobile-Home and Mobile-AAA authentication mobility options are corresponding response MUST include the Mobile-Home Authentication
present, the Mobile-Home Authentication option MUST appear prior to option, and MUST NOT include the Mobile-AAA Authentication option.
the Mobile-AAA Authentication option. The corresponding response
MUST include the Mobile-Home Authentication 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 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)
skipping to change at page 10, line 27 skipping to change at page 10, line 46
If SPI has the well-known value HMAC_SHA1_SPI, then hash_fn() is If 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 HMAC_SHA1. When HMAC_SHA1_SPI is used, the BU is authenticated by
AAA using HMAC_SHA1 authentication. In that case, MAC_Mobility Data AAA using HMAC_SHA1 authentication. In that case, MAC_Mobility Data
is calculated as follows: 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. 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 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 an SA to be used between Mobile Node and Home Agent for
authentication exists. authentication exists.
Upon receiving a Binding Acknowledgement with status code Upon receiving a Binding Acknowledgement with status code MIPV6-AUTH-
MIPV6-AUTH-FAIL, the Mobile Node SHOULD stop sending new Binding FAIL, the Mobile Node SHOULD stop sending new Binding Updates to the
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.
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
skipping to change at page 12, line 22 skipping to change at page 13, line 25
This field carries the 64 bit timestamp. This field carries the 64 bit timestamp.
Alignment requirements : Alignment requirements :
The alignment requirement for this option is 8n + 2. The alignment requirement for this option is 8n + 2.
The basic principle of timestamp replay protection is that the node The basic principle of timestamp replay protection is that the node
generating a message inserts the current time of day, and the node generating a message inserts the current time of day, and the node
receiving the message checks that this timestamp is sufficiently receiving the message checks that this timestamp is sufficiently
close to its own time of day. Unless specified differently in the close to its own time of day. Unless specified differently in the
shared-key based security association between the nodes, a default shared-key based mobility security association between the nodes, a
value of 7 seconds MAY be used to limit the time difference. This default value of 7 seconds MAY be used to limit the time difference.
value SHOULD be greater than 3 seconds. The two nodes must have This value SHOULD be greater than 3 seconds. The two nodes must have
adequately synchronized time-of-day clocks. adequately synchronized time-of-day clocks.
The Mobile Node MUST set the Timestamp field to a 64-bit value The Mobile Node MUST set the Timestamp field to a 64-bit value
formatted as specified by the Network Time Protocol [RFC1305]. The formatted as specified by the Network Time Protocol [RFC1305]. The
low-order 32 bits of the NTP format represent fractional seconds, and low-order 32 bits of the NTP format represent fractional seconds, and
those bits which are not available from a time source SHOULD be those bits which are not available from a time source SHOULD be
generated from a good source of randomness. Note, however, that when generated from a good source of randomness. Note, however, that when
using timestamps, the 64-bit Timestamp used in a Binding Update from using timestamps, the 64-bit Timestamp used in a Binding Update from
the Mobile Node MUST be greater than that used in any previous the Mobile Node MUST be greater than that used in any previous
successful Binding Update. successful Binding Update.
skipping to change at page 14, line 12 skipping to change at page 15, line 12
authentication data in the BA. If the values do not match, the authentication data in the BA. If the values do not match, the
Mobile Node silently discards the BA. Mobile Node silently discards the BA.
7. Security Considerations 7. Security Considerations
This document proposes new authentication options to authenticate the This document proposes new authentication options to authenticate the
control message between Mobile Node, Home Agent and/or home AAA (as control message between Mobile Node, Home Agent and/or home AAA (as
an alternative to IPsec). The new options provide for authentication an alternative to IPsec). The new options provide for authentication
of Binding Update and Binding Acknowledgement messages. The MN-AAA of Binding Update and Binding Acknowledgement messages. The MN-AAA
authentication options provides for authentication with AAA authentication options provides for authentication with AAA
infrastructure. It can be used to generate a per session key between infrastructure.
Mobile Node and Home Agent for subsequent authentication of BU/BA
between Mobile Node and Home Agent via the MN-HA authentication
option.
This specification also introduces an optional replay protection This specification also introduces an optional replay protection
mechanism in Section 6, to prevent replay attacks. The sequence mechanism in Section 6, to prevent replay attacks. The sequence
number field in the Binding Update is not used if this mechanism is number field in the Binding Update is not used if this mechanism is
used. This memo defines the timestamp option to be used for mobility used. This memo defines the timestamp option to be used for mobility
message replay protection. message replay protection.
8. IANA Considerations 8. IANA Considerations
IANA services are required for this specification. The values for IANA services are required for this specification. The values for
new mobility options and status codes must be assigned from the new mobility options and status codes must be assigned from the
Mobile IPv6 [RFC3775] numbering space. Mobile IPv6 [RFC3775] numbering space.
The values for Mobility Option types AUTH-OPTION-TYPE and The values for Mobility Option types AUTH-OPTION-TYPE and MESG-ID-
MESG-ID-OPTION-TYPE, as defined in Section 5 and Section 6 need to be OPTION-TYPE, as defined in Section 5 and Section 6 need to be
assigned. The suggested values are 8 for the AUTH-OPTION-TYPE and 9 assigned. The suggested values are 8 for the AUTH-OPTION-TYPE and 9
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 also need to be assigned. The suggested values are 144 for MIPV6-ID-
MIPV6-ID-MISMATCH 145 for MIPV6-MESG-ID-REQD and 146 for MISMATCH 145 for MIPV6-MESG-ID-REQD and 146 for MIPV6-AUTH-FAIL.
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 SPIs
within the range 0-255 is to be added to 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:
skipping to change at page 17, line 13 skipping to change at page 17, line 13
[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 and Jari Arkko for their thorough review and
suggestions on the document. The authors would like to acknowledge suggestions on the document. The authors would like to acknowledge
the fact that a similar authentication method was considered in base the fact that a similar authentication method was considered in base
protocol [RFC3775] at one time. protocol [RFC3775] at one time.
10 Normative References 10. 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-01.txt (work Mobile IPv6", draft-ietf-mip6-mn-ident-option-03.txt (work
in progress), December 2004. in progress), December 2004.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC "Remote Authentication Dial In User Service (RADIUS)",
2865, June 2000. RFC 2865, June 2000.
[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.
Authors' Addresses
Alpesh Patel
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
US
Phone: +1 408-853-9580
EMail: alpesh@cisco.com
Kent Leung
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
US
Phone: +1 408-526-5030
EMail: kleung@cisco.com
Mohamed Khalil
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082
US
Phone: +1 972-685-0574
EMail: mkhalil@nortelnetworks.com
Haseeb Akhtar
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082
US
Phone: +1 972-684-4732
EMail: haseebak@nortelnetworks.com
Kuntal Chowdhury
Starent Networks
2540 Coolwater Dr.
Plano, TX 75025
US
Phone: +1 214 550 1416
EMail: kchowdury@starentnetworks.com
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
attacks. attacks.
Firstly, the specification states that Home Agent should accept a BU Firstly, the specification states that Home Agent should accept a BU
with a Sequence Number greater than the Sequence Number from previous with a Sequence Number greater than the Sequence Number from previous
Binding Update. This implicitly assumes that the Home Agent has some Binding Update. This implicitly assumes that the Home Agent has some
skipping to change at page 20, line 5 skipping to change at page 19, line 5
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
of BU/BA between Mobile Node and CN, the liveness proof is provided of BU/BA between Mobile Node and CN, the liveness proof is provided
by the use of nonces which the CN generates. by the use of nonces which the CN generates.
Authors' Addresses
Alpesh Patel
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
US
Phone: +1 408-853-9580
Email: alpesh@cisco.com
Kent Leung
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
US
Phone: +1 408-526-5030
Email: kleung@cisco.com
Mohamed Khalil
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082
US
Phone: +1 972-685-0574
Email: mkhalil@nortel.com
Haseeb Akhtar
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082
US
Phone: +1 972-684-4732
Email: haseebak@nortel.com
Kuntal Chowdhury
Starent Networks
30 International Place
Tewksbury, MA 01876
US
Phone: +1 214 550 1416
Email: kchowdury@starentnetworks.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 

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