draft-ietf-mip6-auth-protocol-00.txt   draft-ietf-mip6-auth-protocol-01.txt 
Network Working Group A. Patel Network Working Group A. Patel
Internet-Draft K. Leung Internet-Draft K. Leung
Expires: December 31, 2004 Cisco Systems Expires: May 2, 2005 Cisco Systems
M. Khalil M. Khalil
H. Akhtar H. Akhtar
K. Chowdhury K. Chowdhury
Nortel Networks Nortel Networks
July 2, 2004 November 2004
Authentication Protocol for Mobile IPv6 Authentication Protocol for Mobile IPv6
draft-ietf-mip6-auth-protocol-00.txt draft-ietf-mip6-auth-protocol-01.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 38 skipping to change at page 1, line 38
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 December 31, 2004. This Internet-Draft will expire on May 2, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document defines new mobility options to enable authentication IPsec is specified as the sole means of securing all signaling
between mobility entities. These options can be used in addition to messages between the Mobile Node and Home agent for Mobile IPv6. A
or in lieu of IPsec to authenticate mobility messages as defined in flexible model for security between the mobile node and home agent is
the base Mobile IPv6 specification. required from the perspective of deployment of the Mobile IPv6
protocol. One instance of such deployment need comes from networks
that are built on 3GPP2 standards. This document proposes an
alternate method for securing the signaling messages that are
responsible for performing Registration of a mobile node at a home
agent.
Table of Contents Table of Contents
1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. General Terms . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Operational flow . . . . . . . . . . . . . . . . . . . . . . . 6
5. Operational flow . . . . . . . . . . . . . . . . . . . . . . . 7 5. Mobility message authentication option . . . . . . . . . . . . 7
6. Mobility message authentication option . . . . . . . . . . . . 8 5.1 MN-HA authentication mobility option . . . . . . . . . . . 8
6.1 MN-HA authentication mobility option . . . . . . . . . . . 9 5.1.1 Processing Considerations . . . . . . . . . . . . . . 9
6.2 MN-AAA authentication mobility option . . . . . . . . . . 9 5.2 MN-AAA authentication mobility option . . . . . . . . . . 9
6.2.1 Processing considerations . . . . . . . . . . . . . . 10 5.2.1 Processing Considerations . . . . . . . . . . . . . . 10
7. Mobility message identification option . . . . . . . . . . . . 11 5.3 Authentication Failure Detection at the MN . . . . . . . . 10
7.1 Processing considerations . . . . . . . . . . . . . . . . 12 6. Mobility message identification option . . . . . . . . . . . . 11
7.1.1 Home Agent Considerations . . . . . . . . . . . . . . 12 6.1 Timestamp option . . . . . . . . . . . . . . . . . . . . . 12
7.1.2 Mobile Node Considerations . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.1.3 AAA server Considerations . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Normative References . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
11. Normative References . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 18 A. Authentication using CHAP . . . . . . . . . . . . . . . . . . 18
A.1 Processing considerations . . . . . . . . . . . . . . . . 18
1. Motivation A.2 Mapping BU to Radius Attributes . . . . . . . . . . . . . 18
A.3 Processing of Radius response . . . . . . . . . . . . . . 18
B. Rationale for message identification option . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 21
The base specification of Mobile IPv6 [RFC3775] mandates IPsec 1. Introduction
support between MN and HA for authentication. Also, return
routability messages passing via the HA (HoT/HoTi) and mobile prefix
discovery messages must be protected using IPsec.
While IPsec (ESP) may offer strong protection (depending on the The base Mobile IPv6 specification [RFC3775] specifies the signaling
algorithms used), use of IPsec may not be required/feasible in all messages, Binding Update (BU) and Binding Acknowledegment (BA),
cases where Mobile IPv6 may be used. For small handheld devices, the between the Mobile node and Home agent to be secured by the IPsec SA
use of IPsec may be too taxing on battery and processor performance. that is established between these two entities. This security model
Also depending on the model of home agent deployment (HA deployed by for Mobile IPv6 does not fit in very well for deployment scenarios
enterprise/service provider), MN may have to VPN back into the which:
enterprise (which may impose dual IPsec requirement on MN).
Moreover, IPsec/IKE based Mobile IPv6 over public wireless carrier's 1. rely on the use of a AAA infrastructure for authenticating the
networks may pose serious capacity and scalability challenge. The subscriber
multiple round trips to perform ISAKMP/IKE to establish IPsec SA may 2. require dynamic assignment of home agent and home addresses
be too taxing on the wireless link, not to mention increase in setup 3. have constraints on the number of messages involved in setting up
latency during initial access and during handoffs. The use of manual a security association using protocols like IKEv1
IPsec SA in these large public network deployments suffer from 4. include mobile nodes that do not support IKEv1
scalability issue and involve provisioning nightmare.
Also, having an authentication mechanism tied to the Mobile's home IP The conclusion drawn thereby is the need for a solution that does not
address does not permit the mobility entity to derive or acquire a necessarily require an IPsec SA for securing the signaling messages
dynamic home address based on the configured prefix. If the MN's that deal with the Registration process of a mobile node with a home
home address is dynamically configured based on a fixed prefix or agent.
acquired during network access authentication (PPP, 802.1x etc.),
IPsec will most likely not work as the IPsec SAs are tied to the
address. The mechanism described in this draft is not tied with
mobility entities home IP address and therefore does not mandate SA
relationship with an IP address.
Another important motivation for this proposed mechanism is to allow This document proposes a solution for securing the Binding update and
the MN to register with a Home Agent on a dynamically discovered Home Binding acknowledgment messages between the Mobile node and Home
Link. This sort of Dynamic Home Link assignments will allow the agent using an authentication option which is included in these
operators to leverage the true benefit of dynamic Home Agent messages. Such a mechanism enables IPv6 mobility in hosts without
assignment. For example the operator may assign a Home Link or Home having to establish an IPsec SA with its home agent. A mobile node
Agent for the user that is closest to the subnet of attachment of the can implement Mobile IPv6 without having to integrate it with the
user. There may be various other reasons for opportunistic Home IPsec module, in which case the Binding update and Binding
Agent assignment. The mechanisms described in the draft allows the Acknowldegement messages (between MN-HA) are secured with the
MN to register with any Home Agent in the home network as long as the authentication option. It should be noted that it does not imply
MN user shares security association with an entity in the home that the availability of such a solution deprecates the use of IPsec
network such as a AAA server. for securing Mobile IPv6 signaling between MNs and HAs. Home agents
however have to implement and support registrations from mobile nodes
that are secured via IPsec as well as with the authentication option.
2. Overview 2. Overview
This document presents a lightweight mechanism to authenticate the MN This document presents a lightweight mechanism to authenticate the MN
at the HA or at the Home AAA based on a shared security association at the HA or at the Home AAA based on a shared security association
between the MN and the respective authenticating entity. between the MN and the respective authenticating entity.
This document introduces new mobility options to aid in This document introduces new mobility options to aid in
authentication of the MN to the HA or AAA server. The authentication of the MN to the HA or AAA server. The
confidentiality protection of the Mobile Prefix Discovery (MPD) and confidentiality protection of Return Routability messages and
Return Routability (Home KeyGen token) messages is outside the scope authentication/integrity protection of Mobile Prefix Discovery (MPD)
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.
4. General Terms 4. Operational flow
MN Mobile Node
HA Home Agent
SA Security Association
IPsec IP Security protocol
ESP Encapsulating security protocol
BU Binding Update
BA Binding Acknowledgement
SPI Security Parameter Index
MH Mobility Header
HAAA Home Authentication Authorization Accounting server
CHAP CHallenge Authentication Protocol
HoA Home Address
AVP Attribute Value Pair
AAA Authentication Authorization Accounting
NAI Network Address Identifier
5. Operational flow
MN HA/HAAA MN HA/HAAA
| BU to HA | | BU to HA |
(a) |---------------------------------------------------->| (a) |----------------------------------------------------->|
| (HoA option, NAI[optional], ID option, auth option) | | (HoA option, MN-ID option [optional], |
| Message ID option [optional], authentication option)|
| |
| | | |
| HA/HAAA authenticates MN | HA/HAAA authenticates MN
| | | |
| | | |
| BA to MN | | BA to MN |
(b) |<----------------------------------------------------| (b) |<-----------------------------------------------------|
| (HoA option, NAI[optional], ID option, auth option) | | (RH-2 option, MN-ID option [optional], |
| | | Message ID option [optional], auth option) |
| | | |
MN may use NAI option as defined in [NAI] to identify itself to the MN MAY use NAI option as defined in [MN_Ident] to identify itself
HA while authenticating with the HA. The MN SHOULD use NAI option while authenticating with the HA or AAA infrastructure.
[NAI] while authenticating with the AAA infrastructure.
6. Mobility message authentication option MN MAY use Message Identifier option as defined in Section 6 for
replay protection.
5. Mobility message authentication option
This section defines the message authentication mobility option that This section defines the 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 extension can be used along with IPsec or preferably messages. This extension can be used along with IPsec or preferably
as an alternate mechanism to authenticate binding update and binding as an alternate mechanism to authenticate Binding Update and Binding
acknowledgement messages in absence of IPsec. This document also Acknowledgement messages in absence of IPsec.
defines subtype numbers, which identify the mode of authentication
and the peer entity to authenticate the message. Two subtype numbers This document also defines subtype numbers, which identify the mode
are specified in this document. It is expected that other subtypes of authentication and the peer entity to authenticate the message.
will be defined by other documents in the future. Two subtype numbers are specified in this document. It is expected
that other subtypes will be defined by other documents in the future.
Only one instance of an authentication option of a particular subtype
can be present in the message. One message may contain multiple
instances of authentication options with different subtype values.
When a Binding Update or Binding Acknowledgement is received without
an authentication option and the entity receiving it is configured to
use authentication option or has the security association for
authentication option, the entity should 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 | | Option Type | Option Length | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | SPI | | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI | Authenticator . . . | Authenticator . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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, SPI and authenticator, not including the Option the Sub-type, Security Parameter Index (SPI) and Authenticator
Type and Option Length fields. fields.
Subtype: Subtype:
A number assigned to identify the entity and/or mechanism to be A number assigned to identify the entity and/or mechanism to be
used to authenticate the message. used to authenticate the message.
SPI: SPI:
Used to identify the particular security association to use to Used to identify the particular security association to use to
authenticate the message. authenticate the message.
Authenticator: Authenticator:
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 :
MUST be aligned on an 8-octet boundary. The alignment requirement for this option is 4n + 1 octets.
6.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 6. This option uses the subtype value of 1. The MN-HA in Section 5. 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 Update and Binding Acknowledgement messages based on the shared
security association between the MN and the HA. security association between the MN and the HA.
This must be the last option in a message with mobility header. The This must be the last option in a message with mobility header if it
authenticator is calculated on the message starting from the mobility is the only authentication option in the message. It must occur
header till the SPI value of this option. before the MN-AAA authentication option if both options are present
in the message.
Authenticator = First (96,HMAC_SHA1(MN-HA Shared key, Mobility The authenticator is calculated on the message starting from the
Data)) mobility header till (including) the SPI value of this option.
Mobility Data = care-of address | home address | MH Data Authenticator = First (96,HMAC_SHA1(MN-HA Shared key, Mobility Data))
MH Data is the content of the Mobility Header till the SPI field of Mobility Data = care-of address | home address | Mobility Header(MH)
this extension. Data
The first 96 bits from the MAC result are used as the MH Data is the content of the Mobility Header till (including) the
Authenticator field. SPI field of this extension.
6.2 MN-AAA authentication mobility option The first 96 bits from the MAC result are used as the Authenticator
field.
5.1.1 Processing Considerations
MN MUST include this option in a BU if it shares a security
association with the HA. HA MUST include this option in the BA if
IPsec is not used and it has a security association with the MN.
MN or HA receiving this option MUST verify the authenticator in the
option. If authentication fails, HA MUST discard the BU and send BA
with Status Code MIPV6-AUTH-FAIL, if the HA has a SA with the MN.
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 6. This option uses the subtype value of 2. The MN-AAA in Section 5. 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 and binding acknowledgement messages based on the shared Update message based on the shared security association between MN
security association between MN and HAAA. and Home Authentication, Authorization and Accounting (AAA) server.
It is not used in Binding Acknowledgement message.
This must be the last option in a message with mobility header. The This must be the last option in a message with mobility header. If
authenticator is calculated on the message starting from the mobility both Mobile-Home and Mobile-AAA authentication mobility options are
header till the SPI value of this option. present, the Mobile-Home Authentication Extension MUST appear prior
to the Mobile-AAA Authentication extension. The corresponding
response MUST include the Mobile-Home Authentication Extension, and
MUST NOT include the Mobile-AAA Authentication Extension.
The MN SHOULD use NAI option [NAI] to enable the Home Agent to make The MN MAY use NAI option [MN_Ident] to enable the Home Agent to make
use of available AAA infrastructure which requires NAI. use of available AAA infrastructure which requires NAI.
The MN MUST use either CHAP_SPI or HMAC_CHAP_SPI as defined in The authenticator is calculated on the message starting from the
[3012bis] to indicate CHAP style authentication. The authenticator mobility header till (including) the SPI value of this option.
shall be calculated as follows:
Authenticator = First (96, HMAC_SHA1 (MN-AAA Shared key, MAC_Mobility The authenticator shall be calculated as follows:
Data))).
Authenticator = hash_fn(MN-AAA Shared key, MAC_Mobility Data)
hash_fn() is decided by the value of SPI field in the authentication
option. The SPI field in the MN-AAA authentication option also
defines how the mobility options in BU are mapped to AAA attributes
for authentication.
SPI = CHAP_SPI: SPI = CHAP_SPI:
MAC_Mobility Data = MD5 (care-of address | home address | MH Data). hash_fn() is MD5. When CHAP_SPI is used, the BU is authenticated via
AAA using Challenge Handshake Authentication Protocol (CHAP)
authentication. Specifics of how CHAP authentication is done using
RADIUS ([RFC2865]) is described in Appendix A.
SPI = HMAC_CHAP_SPI: MAC_Mobility Data = MD5(care-of address | home address | MH Data)
MAC_Mobility Data = HMAC_MD5 (care-of address | home address | MH MH Data is the content of the Mobility Header till (including) the
Data). SPI field of this extension.
6.2.1 Processing considerations 5.2.1 Processing Considerations
The MN-AAA authentication mobility option MUST be verified by the AAA The MN-AAA authentication mobility option MUST be verified by the AAA
infrastructure that has the shared secret with the MN. The HA relays infrastructure that has the shared secret with the MN. The HA relays
the authenticating information to the HAAA. The HA relies on the the authenticating information to the home AAA. The HA relies on the
HAAA to admit or reject the home registration request from the MN. home AAA to admit or reject the Binding Update from the MN.
6.2.1.1 Home Agent Considerations 5.2.1.1 Home Agent Considerations
Upon receiving a BU from the MN the HA SHALL extract the MN-AAA Upon receiving a BU from the MN, the HA SHALL extract the MN-AAA
authenticator and the SPI from the MN-AAA authentication mobility authenticator and the SPI from the MN-AAA authentication mobility
option and extract the NAI from the NAI option [NAI]. The HA SHALL option and extract the NAI from the NAI option [MN_Ident].
include the extracted MN-AAA authenticator, SPI and the NAI in AAA
specific AVPs while initiating the authentication procedure via AAA
infrastructure.
7. Mobility message identification option The HA SHALL include the extracted MN-AAA authenticator, SPI and the
NAI in AAA specific Attribute-Value Pairs (AVPs) while initiating the
authentication procedure via AAA infrastructure. Specifics of how
authentication is done using RADIUS ([RFC2865]) when CHAP_SPI is
used, are described in Appendix A.
The identification option is used to prevent replay protection. The 5.3 Authentication Failure Detection at the MN
Identification field carries timestamp for replay protection. This
option can be used in binding update and binding acknowledgement
messages.
The default method for this purpose is the timestamp method; some In case of authentication failure, the HA MUST send a Binding
other methods may be utilized as well. If the MN uses 'timestamp' as Acknowledgement with error code MIPV6-AUTH-FAIL to the MN, if an SA
a measure against replay protection, it SHOULD insert the current to be used between MN and HA for authentication exists. This MAY
time of day. When the destination node receives the Binding Update, need administrative intervention to resolve the cause of the
it will make sure that the 'timestamp' (as included by the sender) is authentication failure.
close enough to its own time of the day. A default value of 500
milliseconds MAY be used as a reasonable offset (the time difference
between the sender and the receiver).
The low-order 32 bits of the identification option represents Upon receiving a Binding Acknowledgement with error code
fractional seconds, the rest of the bits SHOULD be generated from a MIPV6-AUTH-FAIL, the MN SHOULD stop sending new Binding Updates to
good source of randomness. the responding HA.
For the identification field to be valid, the 'timestamp' contained 6. Mobility message identification option
in the Identification field MUST be close enough (as determined by
the system implementers) and greater than the HA's and/or HAAA's time The Mobility message identification option MAY be used in a Binding
of day clock. Update/Binding Acknowledgement messages when authenticated using the
mobility authentication option as described in Section 5.
The Identification 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
identification option when included is used by the MN 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 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 style of replay protection in effect between a mobile node and
the HA and/or the HAAA is part of the mobile security association. A the HA is part of the mobility security association. A mobile node
mobile node and the HA and/or the HAAA MUST agree on which method of and the HA MUST agree on which method of replay protection will be
replay protection will be used. used. If the policy at HA mandates replay protection using this
option (as opposed to the sequence number in Mobility Header in
Binding Update) and the Binding Update from MN does not include this
option, HA discards the BU and sets the Status Code in BA to
MIPV6-MESG-ID-REQD.
When mobility message identification option is used along with
authentication option, the MN SHOULD set the Sequence Number in the
mobility header in Binding Update to 0 and SHOULD ignore the Sequence
Number in Mobility Header in BA. Appendix B provides details
regarding why message identification option MAY be used when using
the authentication option.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | | Option Type | Option Length | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification ... | Identification ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type: Option Type:
IDENT-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 Identification field. the Subtype and Identification field.
Subtype:
8-bit unsigned integer indicating the style of replay
protection in use.
Identification: Identification:
The Identification field carries timestamp for replay The Identification field carries Subtype specific data for
protection. replay protection.
Alignment requirements : Alignment requirements :
MUST be aligned on an 8-octet boundary. This option does not have any specific alignment requirements.
7.1 Processing considerations 6.1 Timestamp option
The Identification field is used to let the HA and/or the HAAA verify The format of the timestamp mobility option is as defined in Section
that a Binding Update message has been generated recently by the MN, 6. This option uses the subtype value of 1. The Identification
and it is not replayed by an attacker from some older registrations. field carries timestamp for replay protection.
7.1.1 Home Agent Considerations The basic principle of timestamp replay protection is that the node
generating a message inserts the current time of day, and the node
receiving the message checks that this timestamp is sufficiently
close to its own time of day. Unless specified differently in the
security association between the nodes, a default 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 have adequately
synchronized time-of-day clocks.
The HA processes this option only when MN-HA authentication mobility The mobile node MUST set the Identification field to a 64-bit value
option is used in the BU. In this case: formatted as specified by the Network Time Protocol [RFC1305]. The
low-order 32 bits of the NTP format represent fractional seconds, and
those bits which are not available from a time source SHOULD be
generated from a good source of randomness. Note, however, that when
using timestamps, the 64-bit Identification used in a Binding Update
from the mobile node MUST be greater than that used in any previous
Binding Update.
After successful authentication of Binding Update, the Home Agent After successful authentication of Binding Update (either locally at
must verify that the Identification field falls within the replay the HA or when a success indication is received from the AAA server),
protection window. If Identification field is not within this window the home agent MUST check the Identification field for validity. In
but the authentication of the BU succeeds, HA MUST send a Binding order to be valid, the timestamp contained in the Identification
Acknowledgement with error code "TBD by IANA" MIPV6-ID-MISMATCH. In field MUST be close enough to the home agent's time of day clock and
this case, HA must include the correct identification field in the the timestamp MUST be greater than all previously accepted timestamps
Binding Acknowledgement message. for the requesting mobile node.
MN-HA Timestamp: If timestamp based replay check is successful and If the timestamp is valid, the home agent copies the entire
the authentication succeeds, the HA MUST include the received Identification field into the Identification field in the BA it
Identification value in the corresponding field of the Mobility returns to the mobile node. If the timestamp is not valid, the home
message identification option in the BA. agent copies only the low-order 32 bits into the BA, and supplies the
high-order 32 bits from its own time of day. If the timestamp field
is not valid but the authentication of the BU succeeds, HA MUST send
a Binding Acknowledgement with error code MIPV6-ID-MISMATCH. HA does
not create a binding cache entry if the timestamp check fails.
7.1.2 Mobile Node Considerations If the MN receives a Binding Acknowledgement with the code
MIPV6-ID-MISMATCH, the MN MUST authenticate the BA by processing the
MN-HA authentication mobility option. If authentication succeeds,
the MN MUST adjust its timestamp and send subsequent Binding Update
using the updated value. Upon receiving a BA that does not contain
the MIPV6-ID-MISMATCH error code, the MN MUST compare the
Identification value in the BA to the Identification value it sent in
the corresponding BU. If the values match, the MN proceeds to
process the MN-HA authenticator in the BA. If the values do not
match, the MN silently discards the BA.
The MN MUST process the Mobility message identification option. 7. Security Considerations
MN-HA Timestamp and MN-AAA Timestamp: The MN MUST set the This document proposes new authentication options to authenticate the
Identification value in the Mobility message identification option in control message between MN, HA and/or home AAA (as an alternative to
the BU message according to its own clock. If the MN receives a IPsec). The new options provide for authentication of Binding Update
Binding Acknowledgement with the code MIPV6-ID-MISMATCH, MN must and Binding Acknowledgement messages. The MN-AAA authentication
adjust its timestamp and send subsequent Binding Update using the options provides for authentication with AAA infrastructure. It can
updated value. be used to generate a per session key between MN and HA for
subsequent authentication of BU/BA between MN and HA via the MN-HA
authentication option.
7.1.3 AAA server Considerations This memo also introduces an optional replay protection mechanism
Section 6, to prevent replay attacks. The sequence number field in
the Binding Update is not used if this mechanism is used. This memo
defines the timestamp option to be used for message identification.
The HAAA processes this option only when MN-AAA authentication 8. IANA Considerations
mobility option is used in the BU. In this case:
After successful authentication of MN's credentials contained in the IANA services are required for this document. The values for new
AVPs, the Home AAA server MUST verify that the Identification field mobility options and error codes must be assigned from the Mobile
falls within the replay protection window. If Identification field IPv6 [RFC3775] numbering space.
is not within this window, HAAA MUST reject the authentication and
authorization request. Upon receiving the reject message from HAAA
server, the HA MUST send a Binding Acknowledgement with error code
"TBD by IANA" MIPV6-ID-MISMATCH. In this case, HA must include the
correct identification field in the Mobility message identification
option in the Binding Acknowledgement message.
MN-AAA Timestamp: If timestamp based replay check is successful and The values for Mobility Option types AUTH-OPTION-TYPE and
the authentication and authorization succeeds, the HAAA does not MESG-ID-OPTION-TYPE, as defined in Section 5 and Section 6 need to be
include any updated Identification value in the accept message. In assigned. The suggested values are 8 for the AUTH-OPTION-TYPE and 9
this case, the HA copies the Identification value from the BU into for the MESG-ID-OPTION-TYPE Mobility Option.
the corresponding field in the BA. If the replay check fails but
authentication succeeds, in the reject message the HAAA MUST include
the latest timestamp according to it's own clock.
8. Security Considerations 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
5.3 also need to be assigned. The suggested values are 144 for
MIPV6-ID-MISMATCH 145 for MIPV6-MESG-ID-REQD and 146 for
MIPV6-AUTH-FAIL.
This document proposes new authentication options to authenticate the IANA should record values for these new Mobility Options and the new
control message between MN, HA and/or HAAA (as an alternative to Status Codes.
IPsec). The new options provide for authentication of Binding Update
and Binding Acknowledgement messages
9. IANA Considerations A new section for enumerating algorithms identified by specific SPIs
within the range 0-255 is to be added to
The option types AUTH-OPTION-TYPE, IDENT-OPTION-TYPE, as defined in http://www.isi.edu/in-notes/iana/assignments/mobility-parameters
section 6 and 7 respectively are new mobility options. The
MIPV6-ID-MISMATCH error code also needs to be defined. IANA should
record values for these new mobility options and the new error code.
10. Acknowledgements The value 0 should not be assigned.
TBD. The value 2 is suggested for CHAP_SPI as defined in section Section
5.2.
11 Normative References The value 3 is suggested for HMAC_SHA1.
The value 5 is reserved for use by 3GPP2.
9. Acknowledgements
The authors would like to thank Basavaraj Patil, Charlie Perkins and
Vijay Devarapalli for their suggestions and comments on the draft.
The authors would like to acknowledge the fact that a similar
authentication method was considered in base protocol [RFC3775] at
one time.
10 Normative References
[3012bis] Perkins et. al., C., "Mobile IPv4 Challenge/Response [3012bis] Perkins et. al., C., "Mobile IPv4 Challenge/Response
Extensions (revised)", draft-ietf-mip4-rfc3012bis-01 (work Extensions (revised)", draft-ietf-mip4-rfc3012bis-01 (work
in progress), April 2004. in progress), April 2004.
[NAI] Patel et. al., A., "Network Access Identifier Option for [MN_Ident]
Mobile IPv6", draft-ietf-mipv6-nai-option-00.txt (work in Patel et. al., A., "MN Identifier Option for Mobile IPv6",
progress), February 2004. draft-ietf-mip6-mn-ident-option-01.txt (work in progress),
December 2004.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", [RFC1305] Mills, D., "Network Time Protocol (Version 3)
RFC 2486, January 1999. Specification, Implementation", RFC 1305, March 1992.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
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 Authors' Addresses
Alpesh Patel Alpesh Patel
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
skipping to change at page 18, line 5 skipping to change at page 18, line 5
Kuntal Chowdhury Kuntal Chowdhury
Nortel Networks Nortel Networks
2221 Lakeside Blvd. 2221 Lakeside Blvd.
Richardson, TX 75082 Richardson, TX 75082
US US
Phone: +1 972 685 7788 Phone: +1 972 685 7788
EMail: chowdury@nortelnetworks.com EMail: chowdury@nortelnetworks.com
Appendix A. Authentication using CHAP
A.1 Processing considerations
The HA acts as a Radius client in accordance with ([RFC2865]) when
MN-AAA mobility option is received in a BU. On receipt of the BU
from the MN, and if SPI in the MN-AAA mobility option is set to
CHAP-SPI, the HA shall create a Radius Access-Request message to
authenticate the BU.
If the SPI in the MN-AAA Authentication Extension is set to CHAP-SPI,
the HA shall use MD5 when computing the CHAP challenge.
A.2 Mapping BU to Radius Attributes
The home agent maps the mobility options to the Radius attributes as
follows:
User-Name(1):
obtained from NAI mobility option in BU.
Chap-Password(3):
CHAP Ident field:
High-order byte of the identification field in the
Identification mobility option
String field:
Authenticator field from the MN-AAA Authentication option
Chap-Challenge(60):
MD5(care-of address | home address | Mobility header till
(including) SPI field in MN-AAA mobility option), followed by the
Identification field in the identification mobility option.
NAS-IP-Address:
NAS-IPv6-Address:
Address of the HA. HA uses the v4/v6 address or both if
available.
A.3 Processing of Radius response
If the authentication succeeds, the Home Radius server sends a Radius
Access-Accept message to the HA. HA proceeds to process the BU
message and sends a BA with appropriate code.
If the authentication fails, the Home Radius server sends a Radius
Access-Reject message to the HA. If Access-Reject is received from
AAA, HA drops the BU. HA does not send a BA to the MN in response to
this BU. An existing binding cache entry from a previous successful
Binding Update MUST not be modified due to this authentication
failure.
Appendix B. Rationale for message identification option
Mobile IPv6 [RFC3775] defines a Sequence Number in the mobility
header to prevent replay attacks. There are two aspects that stand
out in regards to using the Sequence Number to prevent replay
attacks.
Firstly, the specification states that HA should accept a BU with a
Sequence Number greater than the Sequence Number from previous
Binding Update. This implicitly assumes that the HA has some
information regarding the Sequence Number from previous BU (even when
the binding cache entry is not present). Secondly, the specification
states that if the HA has no binding cache entry for the indicated
home address, it MUST accept any Sequence Number value in a received
Binding Update from this mobile node.
With the mechanism defined in this draft, it is possible for the MN
to register with a different home agent during each mobility session.
Thus, it is unreasonable to expect each HA in the network to maintain
state about the MN. Also, if the HA does not cache information
regarding sequence number, as per the second point above, a replayed
BU can cause a Home Agent to create a binding cache entry for the MN.
Thus, when authentication option is used, Sequence Number does not
provide protection against replay attack.
One solution to this problem would be for the HA to reject the first
BU and assign a starting sequence number for the session and force
the MN to send a fresh BU with the suggested sequence number. While
this would work in most cases, it would require an additional round
trip and this extra signalling and latency is not acceptable in
certain deployments (3GPP2). Also, this rejection and using sequence
number as a nonce in rejection is a new behavior that is not
specified in [RFC3775].
Thus, this specification uses the message identification option to
prevent replay attacks. Specifically, timestamps are used for
message identification to prevent replay attacks as described in
Section 6.1.
It is important to note that as per Mobile IPv6 [RFC3775] this
problem with sequence number exists. Since the base specification
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
of BU/BA between MN and CN, the liveness proof is provided 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
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.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/