draft-ietf-mip6-auth-protocol-02.txt   draft-ietf-mip6-auth-protocol-03.txt 
Network Working Group A. Patel Network Working Group A. Patel
Internet-Draft K. Leung Internet-Draft K. Leung
Expires: June 23, 2005 Cisco Systems Expires: July 19, 2005 Cisco Systems
M. Khalil M. Khalil
H. Akhtar H. Akhtar
Nortel Networks Nortel Networks
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
December 23, 2004 January 18, 2005
Authentication Protocol for Mobile IPv6 Authentication Protocol for Mobile IPv6
draft-ietf-mip6-auth-protocol-02.txt draft-ietf-mip6-auth-protocol-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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 June 23, 2005. This Internet-Draft will expire on July 19, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
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
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 . . . . . . . . . . 9
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 . . . 10
6. Mobility message replay protection option . . . . . . . . . . 11 6. Mobility message replay protection option . . . . . . . . . . 11
6.1 Timestamp option . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. Normative References . . . . . . . . . . . . . . . . . . . . 16 10. Normative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
A. Rationale for message identification option . . . . . . . . . 18 A. Rationale for mobility message replay protection option . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 20
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. This security model for Mobile IPv6 does not fit in
very well for deployment scenarios which: very well for deployment scenarios which:
1. rely on the use of a Authentication, Authorization and Accounting 1. rely on the use of a Authentication, Authorization and Accounting
(AAA) infrastructure for authenticating the subscriber (AAA) infrastructure for authenticating the subscriber
2. require dynamic assignment of home agent and home addresses 2. require dynamic assignment of Home Agent and home addresses
3. have constraints on the number of messages involved in setting up 3. have constraints on the number of messages involved in setting up
a IPsec SAs using protocols like IKEv1 IPsec SAs
4. include mobile nodes that do not support IKEv1 4. include Mobile Nodes that do not support IKEv1
The conclusion drawn thereby is the need for a solution that does not This indicates the need for a solution that does not necessarily
necessarily require an IPsec SA for securing the signaling messages require an IPsec SA for securing the signaling messages that deal
that deal with the Registration process of a mobile node with a home with the Registration process of a Mobile Node with a home agent.
agent.
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 hosts 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 should be noted that it does not imply authentication option. It does not imply that the availability of
that the availability of such a solution deprecates the use of IPsec such a solution deprecates the use of IPsec for securing Mobile IPv6
for securing Mobile IPv6 signaling between MNs and HAs. Home agents signaling between Mobile Nodes and Home Agents. Home agents still
however have to implement and support registrations from mobile nodes have to implement and support registrations from Mobile Nodes that
that 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
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 HA or at the Authentication, Authorization and Mobile Node at the Home Agent or at the Authentication, Authorization
Accounting (AAA) server in Home network (AAAH) based on a shared key and Accounting (AAA) server in Home network (AAAH) based on a shared
based security association between the mobile node and the respective key based security association between the Mobile Node and the
authenticating entity. This shared key based security association respective authenticating entity. This shared key based security
(shared-key based SA) may be statically provisioned or dynamically association (shared-key based SA) may be statically provisioned or
created. The term "security association" referred to in this dynamically created. The term "security association" referred to in
document is understood to be a "shared-key based Mobile IPv6 this document is understood to be a "shared-key based Mobile IPv6
authentication" security association. authentication" security association. The Mobile Node MUST use only
one means of authentication, based on either the shared key based
authentication or IPsec security association. 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 HA or AAAH server. The authentication of the Mobile Node to the Home Agent or AAAH server.
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.
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 document are to be interpreted as described in RFC 2119. 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.
4. Operational flow 4. Operational flow
MN HA/AAAH MN HA/AAAH
| BU to HA | | BU to HA |
(a) |----------------------------------------------------->| (a) |----------------------------------------------------->|
| (including MN-ID option [optional], | | (including MN-ID option [optional], |
| 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 [optional], |
| Message ID option [optional], authentication option)| | Message ID option [optional], authentication option)|
| | | |
Figure 1: Home Registration with Authentication Protocol
Mobile Node MAY use Mobile Node Identifier Option as defined in Mobile Node MAY use Mobile Node Identifier Option as defined in
[MN_Ident] to identify itself while authenticating with the HA. The [MN_Ident] or Home Address to identify itself while authenticating
mobile node MUST use the Mobile Node Identifier option as defined in with the Home Agent. The mobile node uses the Mobile Node Identifier
[MN_Ident] to identify itself while authenticating with the AAA option as defined in [MN_Ident] to identify itself as may be required
infrastructure. for use with some existing AAA infrastructure designs.
MN MAY use Message Identifier option as defined in Section 6 for Mobile Node MAY use Message Identifier option as defined in Section 6
replay protection. for additional replay protection.
The authentication option in this document Section 5 may be used by
the mobile node to transfer authentication data when the mobile node
and the home agent are utilizing an SPI to index between multiple
security associations. For the case when there is only one such
security association, and no SPI is needed, the Mobile Node and Home
Agent can use the Binding Authorization Data option as 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 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 the 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 absence of IPsec. Acknowledgement messages in 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. It is expected Two subtype numbers are specified in this document. It is expected
that other subtypes will be defined by other documents in the future. that other subtypes will be defined by other documents in the future.
skipping to change at page 7, line 35 skipping to change at page 7, line 35
association for authentication option, the entity should silently association for authentication option, the entity should silently
discard the received message. 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 ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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, Security Parameter Index (SPI) and Authentication
Data fields. Data fields.
skipping to change at page 8, line 20 skipping to change at page 8, line 22
Security Parameter Index 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 SPI field.
Alignment requirements : Alignment requirements :
The alignment requirement for this option is 4n + 1 octets. 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 Section 5. 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 HA. based security association between the Mobile Node and the Home
Agent.
The shared-key based security association between MN and HA as per The shared-key based security association between Mobile Node and
this specification consists of a SPI, a key, an authentication Home Agent used within this specification consists of a SPI, a key,
algorithm and the replay protection mechanism in use. The SPI is a an authentication algorithm and the replay protection mechanism in
number in range [0-4294967296], where the range [0-255] is reserved. use. The SPI is a number in range [0-4294967296], where the range
The key consists of an arbitrary value and is 16 octets in length. [0-255] is reserved. The key consists of an arbitrary value and is
The authentication algorithm is HMAC_SHA1. The replay protection 16 octets in length. The authentication algorithm is HMAC_SHA1. The
mechanism may use the Sequence number as specified in [RFC3775] or replay protection mechanism may use the Sequence number as specified
the option as defined in Section 6. in [RFC3775] or the option as defined in Section 6. If the Timestamp
option is used for replay protection as defined in Section 6, the
security association includes a "close enough" field to account for
clock drift. A default value of 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. It must occur
before the MN-AAA authentication option if both options are present before the MN-AAA Section 5.2 authentication option if both options
in the message. 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 till (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 till (including) the
SPI field of this option. 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
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
MN MUST include this option in a BU if it has a shared-key based The assumption is that Mobile Node has a shared-key based security
security association with the HA. The HA MUST include this option in association with the Home Agent. The Mobile Node MUST include this
the BA if IPsec is not used and it has a shared-key based security option in a BU if it has a shared-key based security association with
association with the mobile node. 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 security association with the Mobile Node.
MN or HA receiving this option MUST verify the authentication data in The Mobile Node or Home Agent receiving this option MUST verify the
the option. If authentication fails, HA MUST discard the BU and send authentication data in the option. If authentication fails, the Home
BA with Status Code MIPV6-AUTH-FAIL, if the HA has a SA with the Agent MUST send BA with Status Code MIPV6-AUTH-FAIL. If the Home
mobile node. Agent does not have shared-key based SA, Home Agent MUST 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 Section 5. 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 MN Update message based on the shared security association between
and AAA server in Home network (AAAH). It is not used in Binding Mobile Node and AAA server in Home network (AAAH). It is not used in
Acknowledgement message. The corresponding Binding Acknowledgement Binding Acknowledgement messages. The corresponding Binding
messages must be authenticated using the MN-HA authentication option. Acknowledgement messages must be authenticated using the MN-HA
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. If
both Mobile-Home and Mobile-AAA authentication mobility options are both Mobile-Home and Mobile-AAA authentication mobility options are
present, the Mobile-Home Authentication Extension MUST appear prior present, the Mobile-Home Authentication option MUST appear prior to
to the Mobile-AAA Authentication option. The corresponding response the Mobile-AAA Authentication option. The corresponding response
MUST include the Mobile-Home Authentication Extension, and MUST NOT MUST include the Mobile-Home Authentication option, and MUST NOT
include the Mobile-AAA Authentication Extension. 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 till (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)
hash_fn() is decided by the value of SPI field in the authentication hash_fn() is decided by the value of SPI field in the authentication
option. The SPI field in the MN-AAA authentication option also option.
defines how the mobility options in BU are mapped to AAA attributes
for authentication.
SPI = HMAC_SHA1_SPI: SPI = HMAC_SHA1_SPI:
hash_fn() is HMAC_SHA1. When HMAC_SHA1_SPI is used, the BU is If SPI has the well-known value HMAC_SHA1_SPI, then hash_fn() is
authenticated by AAA using HMAC_SHA1 authentication. 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) MAC_Mobility Data = SHA1(care-of address | home address | MH Data)
MH Data is the content of the Mobility Header till (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
The MN-AAA authentication mobility option MUST be verified by the AAA When the Home Agent receives a Binding Update with the Mobile-AAA
infrastructure that has the shared secret with the mobile node. The authentication option, the Binding Update is authenticated by an
HA relays the authenticating information to the home AAA. The HA entity external to the Home Agent, typically a AAA server.
relies on the home AAA to admit or reject the Binding Update from the
mobile node.
5.2.1.1 Home Agent Considerations
Upon receiving a BU from the mobile node, the HA MUST extract the
MN-AAA authentication data and the SPI from the MN-AAA authentication
mobility option and extract the Mobile Node Identifier from the
Mobile Node Identifier mobility option [MN_Ident] (if present).
The HA MUST include the extracted MN-AAA authentication data, SPI and
the Mobile Node Identifier in AAA specific Attribute-Value Pairs
(AVPs) while initiating the authentication procedure via AAA
infrastructure.
5.3 Authentication Failure Detection at the Mobile Node 5.3 Authentication Failure Detection at the Mobile Node
In case of authentication failure, the HA 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 MN and HA for authentication exists. if an SA to be used between Mobile Node and Home Agent for
This MAY need administrative intervention to resolve the cause of the authentication exists.
authentication failure.
Upon receiving a Binding Acknowledgement with status code Upon receiving a Binding Acknowledgement with status code
MIPV6-AUTH-FAIL, the mobile node SHOULD stop sending new Binding MIPV6-AUTH-FAIL, the Mobile Node SHOULD stop sending new Binding
Updates to the responding HA. Updates to the Home Agent.
6. Mobility message replay protection option 6. Mobility message replay protection option
The Mobility message replay protection option MAY be used in a The Mobility message replay protection option MAY be used in Binding
Binding Update/Binding Acknowledgement messages when authenticated Update/Binding Acknowledgement messages when authenticated using the
using the mobility authentication option as described in Section 5. mobility message authentication option as described in Section 5.
The Replay Protection option is used to let the home agent verify
that a Binding Update has been freshly generated by the mobile node,
not replayed by an attacker from some previous Binding Update. The
Replay Protection option when included is used by the mobile node for
matching BA with BU.
The subtype field in the identification option specifies the style of
replay protection used. This document specifies timestamps as one
style of replay protection, as described in Section 6.1. The
Identification field in the Replay Protection option in a new Binding
Update MUST not be the same as in an immediately preceding Binding
Update.
The style of replay protection in effect between a mobile node and The mobility message replay protection option is used to let the Home
the HA is part of the shared-key based mobility security association. Agent verify that a Binding Update has been freshly generated by the
A mobile node and the HA MUST agree on which method of replay Mobile Node and not replayed by an attacker from some previous
protection will be used (even though the security association may be Binding Update. This is especially useful for cases where the Home
dynamically derived. This can be done as part of policy at the HA). Agent does not maintain stateful information about the Mobile Node
after the binding entry has been removed. The Home Agent does the
replay protection check after the Binding Update has been
authenticated. The mobility message replay protection option when
included is used by the Mobile Node for matching BA with BU.
If the policy at HA mandates replay protection using this option (as If the policy at Home Agent mandates replay protection using this
opposed to the sequence number in Mobility Header in Binding Update) option (as opposed to the sequence number in Mobility Header in
and the Binding Update from MN does not include this option, HA Binding Update) and the Binding Update from Mobile Node does not
discards the BU and sets the Status Code in BA to MIPV6-MESG-ID-REQD. include this option, Home Agent discards the BU and sets the Status
Code in BA to MIPV6-MESG-ID-REQD.
When mobility message identification option is used along with When the Home Agent receives the mobility message replay protection
authentication option, the mobile node SHOULD set the Sequence Number option in Binding Update, it SHOULD include the mobility message
in the mobility header in Binding Update to 0 and SHOULD ignore the replay protection option in Binding Acknowledgement. Appendix A
Sequence Number in Mobility Header in BA. Appendix A provides provides details regarding why the mobility message replay protection
details regarding why message identification option MAY be used when option MAY be used when using the authentication option.
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 | Subtype | | Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification ... | Timestamp ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
Option Type: Option Type:
MESG-ID-OPTION-TYPE to be defined by IANA. An 8-bit identifier MESG-ID-OPTION-TYPE to be defined by IANA. An 8-bit identifier
of the type mobility option. of 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 Subtype and Identification field. the Timestamp field.
Subtype:
8-bit unsigned integer indicating the style of replay
protection in use.
Identification: Timestamp:
The Identification field carries Subtype specific data for This field carries the 64 bit timestamp.
replay protection.
Alignment requirements : Alignment requirements :
This option does not have any specific alignment requirements. The alignment requirement for this option is 8n + 2.
6.1 Timestamp option
The format of the timestamp mobility option is as defined in Section
6. This option uses the subtype value of 1. The Identification
field carries timestamp for replay protection.
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 security association between the nodes, a default
value of 7 seconds MAY be used to limit the time difference. This value of 7 seconds MAY be used to limit the time difference. This
value SHOULD be greater than 3 seconds. Obviously the two nodes must value SHOULD be greater than 3 seconds. The two nodes must have
have adequately synchronized time-of-day clocks. adequately synchronized time-of-day clocks.
The mobile node MUST set the Identification 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 Identification used in a Binding Update using timestamps, the 64-bit Timestamp used in a Binding Update from
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
Binding Update. successful Binding Update.
After successful authentication of Binding Update (either locally at After successful authentication of Binding Update (either locally at
the HA or when a success indication is received from the AAA server), the Home Agent or when a success indication is received from the AAA
the home agent MUST check the Identification field for validity. In server), the Home Agent MUST check the Timestamp field for validity.
order to be valid, the timestamp contained in the Identification In order to be valid, the timestamp contained in the Timestamp field
field MUST be close enough to the home agent's time of day clock and MUST be close enough to the Home Agent's time of day clock and the
the timestamp MUST be greater than all previously accepted timestamps timestamp MUST be greater than all previously accepted timestamps for
for the requesting mobile node. the requesting Mobile Node.
If the timestamp is valid, the home agent copies the entire If the timestamp is valid, the Home Agent copies the entire Timestamp
Identification field into the Identification field in the BA it field into the Timestamp field in the BA it returns to the Mobile
returns to the mobile node. If the timestamp is not valid, the home Node. If the timestamp is not valid, the Home Agent copies only the
agent copies only the low-order 32 bits into the BA, and supplies the low-order 32 bits into the BA, and supplies the high-order 32 bits
high-order 32 bits from its own time of day. If the timestamp field from its own time of day.
is not valid but the authentication of the BU succeeds, HA MUST send
a Binding Acknowledgement with status code MIPV6-ID-MISMATCH. HA
does not create a binding cache entry if the timestamp check fails.
If the mobile node receives a Binding Acknowledgement with the code If the timestamp field is not valid but the authentication of the BU
MIPV6-ID-MISMATCH, the mobile node MUST authenticate the BA by succeeds, Home Agent MUST send a Binding Acknowledgement with status
processing the MN-HA authentication mobility option. If code MIPV6-ID-MISMATCH. The Home Agent does not create a binding
authentication succeeds, the mobile node MUST adjust its timestamp cache entry if the timestamp check fails.
and send subsequent Binding Update using the updated value. Upon
receiving a BA that does not contain the MIPV6-ID-MISMATCH status If the Mobile Node receives a Binding Acknowledgement with the code
code, the mobile node MUST compare the Identification value in the BA MIPV6-ID-MISMATCH, the Mobile Node MUST authenticate the BA by
to the Identification value it sent in the corresponding BU. If the processing the MN-HA authentication mobility option.
values match, the mobile node proceeds to process the MN-HA
authentication data in the BA. If the values do not match, the MN If authentication succeeds, the Mobile Node MUST adjust its timestamp
silently discards the BA. and send subsequent Binding Update using the updated value.
Upon receiving a BA that does not contain the MIPV6-ID-MISMATCH
status code, the Mobile Node MUST compare the Timestamp value in the
BA to the Timestamp value it sent in the corresponding BU. If the
values match, the Mobile Node proceeds to process the MN-HA
authentication data in the BA. If the values do not match, the
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 MN, HA and/or home AAA (as an alternative to control message between Mobile Node, Home Agent and/or home AAA (as
IPsec). The new options provide for authentication of Binding Update an alternative to IPsec). The new options provide for authentication
and Binding Acknowledgement messages. The MN-AAA authentication of Binding Update and Binding Acknowledgement messages. The MN-AAA
options provides for authentication with AAA infrastructure. It can authentication options provides for authentication with AAA
be used to generate a per session key between MN and HA for infrastructure. It can be used to generate a per session key between
subsequent authentication of BU/BA between MN and HA via the MN-HA Mobile Node and Home Agent for subsequent authentication of BU/BA
authentication option. between Mobile Node and Home Agent via the MN-HA authentication
option.
This memo also introduces an optional replay protection mechanism This memo also introduces an optional replay protection mechanism
Section 6, to prevent replay attacks. The sequence number field in Section 6, to prevent replay attacks. The sequence number field in
the Binding Update is not used if this mechanism is used. This memo the Binding Update is not used if this mechanism is used. This memo
defines the timestamp option to be used for message identification. defines the timestamp option to be used for mobility message replay
protection.
8. IANA Considerations 8. IANA Considerations
IANA services are required for this document. The values for new IANA services are required for this specification. The values for
mobility options and status codes must be assigned from the Mobile new mobility options and status codes must be assigned from the
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-OPTION-TYPE, as defined in Section 5 and Section 6 need to be MESG-ID-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.1, Section 6 and Section MIPV6-MESG-ID-REQD as defined in Section 6, Section 6 and Section 5.3
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-MISMATCH 145 for MIPV6-MESG-ID-REQD and 146 for MIPV6-ID-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:
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 The value 3 is suggested for HMAC_SHA1_SPI as defined in Section 5.2.
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
[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:
MN-HA authentication mobility option Section 5.1 [1] 1 MN-HA authentication mobility option Section 5.1
MN-AAA authentication mobility option Section 5.2 [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 Standards Action
[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., "MN Identifier Option for Mobile IPv6", Patel et. al., A., "Mobile Node Identifier Option for
draft-ietf-mip6-mn-ident-option-01.txt (work in progress), Mobile IPv6", draft-ietf-mip6-mn-ident-option-01.txt (work
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)", RFC
skipping to change at page 18, line 5 skipping to change at page 19, line 5
Kuntal Chowdhury Kuntal Chowdhury
Starent Networks Starent Networks
2540 Coolwater Dr. 2540 Coolwater Dr.
Plano, TX 75025 Plano, TX 75025
US US
Phone: +1 214 550 1416 Phone: +1 214 550 1416
EMail: kchowdury@starentnetworks.com EMail: kchowdury@starentnetworks.com
Appendix A. Rationale for message identification 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 HA should accept a BU with a Firstly, the specification states that Home Agent should accept a BU
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 HA has some Binding Update. This implicitly assumes that the Home Agent has some
information regarding the Sequence Number from previous BU (even when information regarding the Sequence Number from previous BU (even when
the binding cache entry is not present). Secondly, the specification the binding cache entry is not present). Secondly, the specification
states that if the HA has no binding cache entry for the indicated states that if the Home Agent has no binding cache entry for the
home address, it MUST accept any Sequence Number value in a received indicated home address, it MUST accept any Sequence Number value in a
Binding Update from this mobile node. received Binding Update from this Mobile Node.
With the mechanism defined in this draft, it is possible for the MN With the mechanism defined in this draft, it is possible for the
to register with a different home agent during each mobility session. Mobile Node to register with a different Home Agent during each
Thus, it is unreasonable to expect each HA in the network to maintain mobility session. Thus, it is unreasonable to expect each Home Agent
state about the mobile node. Also, if the HA does not cache in the network to maintain state about the Mobile Node. Also, if the
information regarding sequence number, as per the second point above, Home Agent does not cache information regarding sequence number, as
a replayed BU can cause a Home Agent to create a binding cache entry per the second point above, a replayed BU can cause a Home Agent to
for the mobile node. Thus, when authentication option is used, create a binding cache entry for the Mobile Node. Thus, when
Sequence Number does not provide protection against replay attack. authentication option is used, Sequence Number does not provide
protection against replay attack.
One solution to this problem (when HA does not save state information One solution to this problem (when Home Agent does not save state
for every MN) would be for the HA to reject the first BU and assign a information for every Mobile Node) would be for the Home Agent to
(randomly generated) starting sequence number for the session and reject the first BU and assign a (randomly generated) starting
force the MN to send a fresh BU with the suggested sequence number. sequence number for the session and force the Mobile Node to send a
While this would work in most cases, it would require an additional fresh BU with the suggested sequence number. While this would work
round trip and this extra signalling and latency is not acceptable in in most cases, it would require an additional round trip and this
certain deployments (3GPP2). Also, this rejection and using sequence extra signalling and latency is not acceptable in certain deployments
number as a nonce in rejection is a new behavior that is not (3GPP2). Also, this rejection and using sequence number as a nonce
specified in [RFC3775]. in rejection is a new behavior that is not specified in [RFC3775].
Thus, this specification uses the message identification option to Thus, this specification uses the mobility message replay protection
prevent replay attacks. Specifically, timestamps are used for option to prevent replay attacks. Specifically, timestamps are used
message identification to prevent replay attacks as described in to prevent replay attacks as described in Section 6.
Section 6.1.
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 MN and CN, the liveness proof is provided by the use of BU/BA between Mobile Node and CN, the liveness proof is provided
of nonces which the CN generates. by the use of nonces which the CN generates.
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
skipping to change at page 19, line 41 skipping to change at page 20, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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