draft-ietf-mip6-auth-protocol-01.txt   draft-ietf-mip6-auth-protocol-02.txt 
Network Working Group A. Patel Network Working Group A. Patel
Internet-Draft K. Leung Internet-Draft K. Leung
Expires: May 2, 2005 Cisco Systems Expires: June 23, 2005 Cisco Systems
M. Khalil M. Khalil
H. Akhtar H. Akhtar
K. Chowdhury
Nortel Networks Nortel Networks
November 2004 K. Chowdhury
Starent Networks
December 23, 2004
Authentication Protocol for Mobile IPv6 Authentication Protocol for Mobile IPv6
draft-ietf-mip6-auth-protocol-01.txt draft-ietf-mip6-auth-protocol-02.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 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 May 2, 2005. This Internet-Draft will expire on June 23, 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
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
skipping to change at page 2, line 20 skipping to change at page 2, line 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 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 MN . . . . . . . . 10 5.3 Authentication Failure Detection at the Mobile Node . . . 10
6. Mobility message identification option . . . . . . . . . . . . 11 6. Mobility message replay protection option . . . . . . . . . . 11
6.1 Timestamp option . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . 16
10. Normative References . . . . . . . . . . . . . . . . . . . . 16 10. Normative References . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
A. Authentication using CHAP . . . . . . . . . . . . . . . . . . 18 A. Rationale for message identification option . . . . . . . . . 18
A.1 Processing considerations . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19
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
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 Acknowledegment (BA), messages, Binding Update (BU) and Binding Acknowledgement (BA),
between the Mobile node and Home agent to be secured by the IPsec SA between the Mobile node and Home agent to be secured by the IPsec
that is established between these two entities. This security model Security Associations (IPsec SAs) that are established between these
for Mobile IPv6 does not fit in very well for deployment scenarios two entities. This security model for Mobile IPv6 does not fit in
which: very well for deployment scenarios which:
1. rely on the use of a AAA infrastructure for authenticating the 1. rely on the use of a Authentication, Authorization and Accounting
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 security association using protocols like IKEv1 a IPsec SAs using protocols like IKEv1
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 The conclusion drawn thereby is the need for a solution that does not
necessarily require an IPsec SA for securing the signaling messages necessarily require an IPsec SA for securing the signaling messages
that deal with the Registration process of a mobile node with a home that deal 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
skipping to change at page 4, line 7 skipping to change at page 4, line 7
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 should be noted that it does not imply
that the availability of such a solution deprecates the use of IPsec that the availability of such a solution deprecates the use of IPsec
for securing Mobile IPv6 signaling between MNs and HAs. Home agents for securing Mobile IPv6 signaling between MNs and HAs. Home agents
however have to implement and support registrations from mobile nodes however have to implement and support registrations from mobile nodes
that are secured via IPsec as well as with the authentication option. 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
at the HA or at the Home AAA based on a shared security association mobile node at the HA or at the Authentication, Authorization and
between the MN and the respective authenticating entity. Accounting (AAA) server in Home network (AAAH) based on a shared key
based security association between the mobile node and the respective
authenticating entity. This shared key based security association
(shared-key based SA) may be statically provisioned or dynamically
created. The term "security association" referred to in this
document is understood to be a "shared-key based Mobile IPv6
authentication" security association.
This document introduces new mobility options to aid in This document introduces new mobility options to aid in
authentication of the MN to the HA or AAA server. The authentication of the mobile node to the HA or AAAH server. The
confidentiality protection of Return Routability messages and 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.
4. Operational flow 4. Operational flow
MN HA/HAAA MN HA/AAAH
| BU to HA | | BU to HA |
(a) |----------------------------------------------------->| (a) |----------------------------------------------------->|
| (HoA option, MN-ID option [optional], | | (including MN-ID option [optional], |
| Message ID option [optional], authentication option)| | Message ID option [optional], authentication option)|
| | | |
| | | |
| HA/HAAA authenticates MN | HA/AAAH authenticates MN
| | | |
| | | |
| BA to MN | | BA to MN |
(b) |<-----------------------------------------------------| (b) |<-----------------------------------------------------|
| (RH-2 option, MN-ID option [optional], | | (including MN-ID option [optional], |
| Message ID option [optional], auth option) | | Message ID option [optional], authentication option)|
| | | |
MN MAY use NAI option as defined in [MN_Ident] to identify itself Mobile Node MAY use Mobile Node Identifier Option as defined in
while authenticating with the HA or AAA infrastructure. [MN_Ident] to identify itself while authenticating with the HA. The
mobile node MUST use the Mobile Node Identifier option as defined in
[MN_Ident] to identify itself while authenticating with the AAA
infrastructure.
MN MAY use Message Identifier option as defined in Section 6 for MN MAY use Message Identifier option as defined in Section 6 for
replay protection. replay protection.
5. Mobility message authentication option 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 option can be used along with IPsec or preferably as
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.
Only one instance of an authentication option of a particular subtype Only one instance of an authentication option of a particular subtype
can be present in the message. One message may contain multiple can be present in the message. One message may contain multiple
instances of authentication options with different subtype values. instances of authentication options with different subtype values.
When a Binding Update or Binding Acknowledgement is received without When a Binding Update or Binding Acknowledgement is received without
an authentication option and the entity receiving it is configured to an authentication option and the entity receiving it is configured to
use authentication option or has the security association for use authentication option or has the shared-key based security
authentication option, the entity should silently discard the association for authentication option, the entity should silently
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator . . . | Authentication Data . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Authenticator the Sub-type, Security Parameter Index (SPI) and Authentication
fields. Data fields.
Subtype: Subtype:
A number assigned to identify the entity and/or mechanism to be A number assigned to identify the entity and/or mechanism to be
used to authenticate the message. used to authenticate the message.
SPI: SPI:
Used to identify the particular security association to use to Security Parameter Index
authenticate the message.
Authenticator: 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 octets.
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 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-key
security association between the MN and the HA. based security association between the mobile node and the HA.
The shared-key based security association between MN and HA as per
this specification consists of a SPI, a key, an authentication
algorithm and the replay protection mechanism in use. The SPI is a
number in range [0-4294967296], where the range [0-255] is reserved.
The key consists of an arbitrary value and is 16 octets in length.
The authentication algorithm is HMAC_SHA1. The replay protection
mechanism may use the Sequence number as specified in [RFC3775] or
the option as defined in Section 6.
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 authentication option if both options are present
in the message. in the message.
The authenticator is calculated on the message starting from the The authentication data is calculated on the message starting from
mobility header till (including) the SPI value of this option. the mobility header till (including) the SPI value of this option.
Authenticator = First (96,HMAC_SHA1(MN-HA Shared key, Mobility Data)) Authentication Data = First (96, HMAC_SHA1(MN-HA Shared key, Mobility
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 MH Data is the content of the Mobility Header till (including) the
SPI field of this extension. SPI field of this option.
The first 96 bits from the MAC result are used as the Authenticator The first 96 bits from the MAC result are used as the Authentication
field. Data field.
5.1.1 Processing Considerations 5.1.1 Processing Considerations
MN MUST include this option in a BU if it shares a security MN MUST include this option in a BU if it has a shared-key based
association with the HA. HA MUST include this option in the BA if security association with the HA. The HA MUST include this option in
IPsec is not used and it has a security association with the MN. the BA if IPsec is not used and it has a shared-key based security
association with the mobile node.
MN or HA receiving this option MUST verify the authenticator in the MN or HA receiving this option MUST verify the authentication data in
option. If authentication fails, HA MUST discard the BU and send BA the option. If authentication fails, HA MUST discard the BU and send
with Status Code MIPV6-AUTH-FAIL, if the HA has a SA with the MN. BA with Status Code MIPV6-AUTH-FAIL, if the HA has a SA with the
mobile node.
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 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 message based on the shared security association between MN Update message based on the shared security association between MN
and Home Authentication, Authorization and Accounting (AAA) server. and AAA server in Home network (AAAH). It is not used in Binding
It is not used in Binding Acknowledgement message. Acknowledgement message. The corresponding Binding Acknowledgement
messages must be authenticated using the MN-HA authentication option.
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 Extension MUST appear prior
to the Mobile-AAA Authentication extension. The corresponding to the Mobile-AAA Authentication option. The corresponding response
response MUST include the Mobile-Home Authentication Extension, and MUST include the Mobile-Home Authentication Extension, and MUST NOT
MUST NOT include the Mobile-AAA Authentication Extension. include the Mobile-AAA Authentication Extension.
The MN MAY use NAI option [MN_Ident] to enable the Home Agent to make The mobile node MAY use Mobile Node Identifier option [MN_Ident] to
use of available AAA infrastructure which requires NAI. enable the Home Agent to make use of available AAA infrastructure.
The authenticator is calculated on the message starting from the The authentication data is calculated on the message starting from
mobility header till (including) the SPI value of this option. the mobility header till (including) the SPI value of this option.
The authenticator shall be calculated as follows: The authentication data shall be calculated as follows:
Authenticator = 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. The SPI field in the MN-AAA authentication option also
defines how the mobility options in BU are mapped to AAA attributes defines how the mobility options in BU are mapped to AAA attributes
for authentication. for authentication.
SPI = CHAP_SPI: SPI = HMAC_SHA1_SPI:
hash_fn() is MD5. When CHAP_SPI is used, the BU is authenticated via hash_fn() is HMAC_SHA1. When HMAC_SHA1_SPI is used, the BU is
AAA using Challenge Handshake Authentication Protocol (CHAP) authenticated by AAA using HMAC_SHA1 authentication.
authentication. Specifics of how CHAP authentication is done using
RADIUS ([RFC2865]) is described in Appendix A.
MAC_Mobility Data = MD5(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 till (including) the
SPI field of this extension. 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 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 mobile node. The
the authenticating information to the home AAA. The HA relies on the HA relays the authenticating information to the home AAA. The HA
home AAA to admit or reject the Binding Update from the MN. relies on the home AAA to admit or reject the Binding Update from the
mobile node.
5.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 mobile node, the HA MUST extract the
authenticator and the SPI from the MN-AAA authentication mobility MN-AAA authentication data and the SPI from the MN-AAA authentication
option and extract the NAI from the NAI option [MN_Ident]. mobility option and extract the Mobile Node Identifier from the
Mobile Node Identifier mobility option [MN_Ident] (if present).
The HA SHALL include the extracted MN-AAA authenticator, SPI and the The HA MUST include the extracted MN-AAA authentication data, SPI and
NAI in AAA specific Attribute-Value Pairs (AVPs) while initiating the the Mobile Node Identifier in AAA specific Attribute-Value Pairs
authentication procedure via AAA infrastructure. Specifics of how (AVPs) while initiating the authentication procedure via AAA
authentication is done using RADIUS ([RFC2865]) when CHAP_SPI is infrastructure.
used, are described in Appendix A.
5.3 Authentication Failure Detection at the MN 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 HA MUST send a Binding
Acknowledgement with error code MIPV6-AUTH-FAIL to the MN, if an SA Acknowledgement with status code MIPV6-AUTH-FAIL to the mobile node,
to be used between MN and HA for authentication exists. This MAY if an SA to be used between MN and HA for authentication exists.
need administrative intervention to resolve the cause of the This MAY need administrative intervention to resolve the cause of the
authentication failure. authentication failure.
Upon receiving a Binding Acknowledgement with error code Upon receiving a Binding Acknowledgement with status code
MIPV6-AUTH-FAIL, the MN SHOULD stop sending new Binding Updates to MIPV6-AUTH-FAIL, the mobile node SHOULD stop sending new Binding
the responding HA. Updates to the responding HA.
6. Mobility message identification option 6. Mobility message replay protection option
The Mobility message identification option MAY be used in a Binding The Mobility message replay protection option MAY be used in a
Update/Binding Acknowledgement messages when authenticated using the Binding Update/Binding Acknowledgement messages when authenticated
mobility authentication option as described in Section 5. using the mobility authentication option as described in Section 5.
The Identification option is used to let the home agent verify that a The Replay Protection option is used to let the home agent verify
Binding Update has been freshly generated by the mobile node, not that a Binding Update has been freshly generated by the mobile node,
replayed by an attacker from some previous Binding Update. The not replayed by an attacker from some previous Binding Update. The
identification option when included is used by the MN for matching BA Replay Protection option when included is used by the mobile node for
with BU. matching BA with BU.
The subtype field in the identification option specifies the style of The subtype field in the identification option specifies the style of
replay protection used. This document specifies timestamps as one replay protection used. This document specifies timestamps as one
style of replay protection, as described in Section 6.1. The 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 Identification field in the Replay Protection option in a new Binding
immediately preceding Binding Update. 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 is part of the mobility security association. A mobile node the HA is part of the shared-key based mobility security association.
and the HA MUST agree on which method of replay protection will be A mobile node and the HA MUST agree on which method of replay
used. If the policy at HA mandates replay protection using this protection will be used (even though the security association may be
option (as opposed to the sequence number in Mobility Header in dynamically derived. This can be done as part of policy at the HA).
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 If the policy at HA mandates replay protection using this option (as
MIPV6-MESG-ID-REQD. 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 When mobility message identification option is used along with
authentication option, the MN SHOULD set the Sequence Number in the authentication option, the mobile node SHOULD set the Sequence Number
mobility header in Binding Update to 0 and SHOULD ignore the Sequence in the mobility header in Binding Update to 0 and SHOULD ignore the
Number in Mobility Header in BA. Appendix B provides details Sequence Number in Mobility Header in BA. Appendix A provides
regarding why message identification option MAY be used when using details regarding why message identification option MAY be used when
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 | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification ... | Identification ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Subtype and Identification field.
skipping to change at page 12, line 37 skipping to change at page 12, line 38
6.1 Timestamp option 6.1 Timestamp option
The format of the timestamp mobility option is as defined in Section The format of the timestamp mobility option is as defined in Section
6. This option uses the subtype value of 1. The Identification 6. This option uses the subtype value of 1. The Identification
field carries timestamp for replay protection. 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
security association between the nodes, a default value of 7 seconds shared-key based security association between the nodes, a default
MAY be used to limit the time difference. This value SHOULD be value of 7 seconds MAY be used to limit the time difference. This
greater than 3 seconds. Obviously the two nodes must have adequately value SHOULD be greater than 3 seconds. Obviously the two nodes must
synchronized time-of-day clocks. have 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 Identification 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 Identification used in a Binding Update
from the mobile node MUST be greater than that used in any previous from the mobile node MUST be greater than that used in any previous
Binding Update. Binding Update.
skipping to change at page 13, line 16 skipping to change at page 13, line 19
field MUST be close enough to the home agent's time of day clock and field MUST be close enough to the home agent's time of day clock and
the timestamp MUST be greater than all previously accepted timestamps the timestamp MUST be greater than all previously accepted timestamps
for the requesting mobile node. for 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
Identification field into the Identification field in the BA it Identification field into the Identification field in the BA it
returns to the mobile node. If the timestamp is not valid, the home returns to the mobile node. If the timestamp is not valid, the home
agent copies only the low-order 32 bits into the BA, and supplies the 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 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 is not valid but the authentication of the BU succeeds, HA MUST send
a Binding Acknowledgement with error code MIPV6-ID-MISMATCH. HA does a Binding Acknowledgement with status code MIPV6-ID-MISMATCH. HA
not create a binding cache entry if the timestamp check fails. does not create a binding cache entry if the timestamp check fails.
If the MN receives a Binding Acknowledgement with the code If the mobile node receives a Binding Acknowledgement with the code
MIPV6-ID-MISMATCH, the MN MUST authenticate the BA by processing the MIPV6-ID-MISMATCH, the mobile node MUST authenticate the BA by
MN-HA authentication mobility option. If authentication succeeds, processing the MN-HA authentication mobility option. If
the MN MUST adjust its timestamp and send subsequent Binding Update authentication succeeds, the mobile node MUST adjust its timestamp
using the updated value. Upon receiving a BA that does not contain and send subsequent Binding Update using the updated value. Upon
the MIPV6-ID-MISMATCH error code, the MN MUST compare the receiving a BA that does not contain the MIPV6-ID-MISMATCH status
Identification value in the BA to the Identification value it sent in code, the mobile node MUST compare the Identification value in the BA
the corresponding BU. If the values match, the MN proceeds to to the Identification value it sent in the corresponding BU. If the
process the MN-HA authenticator in the BA. If the values do not values match, the mobile node proceeds to process the MN-HA
match, the MN silently discards the BA. authentication data in the BA. If the values do not match, the MN
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 MN, HA and/or home AAA (as an alternative to
IPsec). The new options provide for authentication of Binding Update IPsec). The new options provide for authentication of Binding Update
and Binding Acknowledgement messages. The MN-AAA authentication and Binding Acknowledgement messages. The MN-AAA authentication
options provides for authentication with AAA infrastructure. It can options provides for authentication with AAA infrastructure. It can
be used to generate a per session key between MN and HA for 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 subsequent authentication of BU/BA between MN and HA via the MN-HA
authentication option. 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 message identification.
8. IANA Considerations 8. IANA Considerations
IANA services are required for this document. The values for new IANA services are required for this document. The values for new
mobility options and error codes must be assigned from the Mobile mobility options and status codes must be assigned from the Mobile
IPv6 [RFC3775] numbering space. 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.1, Section 6 and Section
5.3 also need to be assigned. The suggested values are 144 for 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-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 value 0 should not be assigned. The currently defined values are as follows:
The value 2 is suggested for CHAP_SPI as defined in section Section The value 0 should not be assigned.
5.2.
The value 3 is suggested for HMAC_SHA1. The value 3 is suggested for HMAC_SHA1_SPI as defined in section
Section 5.2.
The value 5 is reserved for use by 3GPP2. The value 5 is reserved for use by 3GPP2.
In addition, IANA needs to create a new namespace for the subtype
field of the MN-HA and MN-AAA authentication mobility options under
http://www.isi.edu/in-notes/iana/assignments/mobility-parameters
The currently allocated values are as follows:
MN-HA authentication mobility option Section 5.1 [1]
MN-AAA authentication mobility option Section 5.2 [2]
New values for this namespace can be allocated using Standards Action
[RFC2434].
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Basavaraj Patil, Charlie Perkins and The authors would like to thank Basavaraj Patil, Charlie Perkins
Vijay Devarapalli for their suggestions and comments on the draft. Vijay Devarapalli and Jari Arkko for their thorough review and
The authors would like to acknowledge the fact that a similar suggestions on the document. The authors would like to acknowledge
authentication method was considered in base protocol [RFC3775] at the fact that a similar authentication method was considered in base
one time. protocol [RFC3775] at one time.
10 Normative References 10 Normative References
[3012bis] Perkins et. al., C., "Mobile IPv4 Challenge/Response
Extensions (revised)", draft-ietf-mip4-rfc3012bis-01 (work
in progress), April 2004.
[MN_Ident] [MN_Ident]
Patel et. al., A., "MN Identifier Option for Mobile IPv6", Patel et. al., A., "MN Identifier Option for Mobile IPv6",
draft-ietf-mip6-mn-ident-option-01.txt (work in progress), draft-ietf-mip6-mn-ident-option-01.txt (work in progress),
December 2004. 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
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
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
2865, June 2000. 2865, June 2000.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
skipping to change at page 17, line 32 skipping to change at page 17, line 32
Haseeb Akhtar Haseeb Akhtar
Nortel Networks Nortel Networks
2221 Lakeside Blvd. 2221 Lakeside Blvd.
Richardson, TX 75082 Richardson, TX 75082
US US
Phone: +1 972-684-4732 Phone: +1 972-684-4732
EMail: haseebak@nortelnetworks.com EMail: haseebak@nortelnetworks.com
Kuntal Chowdhury Kuntal Chowdhury
Nortel Networks Starent Networks
2221 Lakeside Blvd. 2540 Coolwater Dr.
Richardson, TX 75082 Plano, TX 75025
US US
Phone: +1 972 685 7788 Phone: +1 214 550 1416
EMail: chowdury@nortelnetworks.com EMail: kchowdury@starentnetworks.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 Appendix A. Rationale for message identification 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 HA should accept a BU with a
Sequence Number greater than the Sequence Number from previous 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 HA 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 HA has no binding cache entry for the indicated
home address, it MUST accept any Sequence Number value in a received home address, it MUST accept any Sequence Number value in a received
Binding Update from this mobile node. 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 MN
to register with a different home agent during each mobility session. to register with a different home agent during each mobility session.
Thus, it is unreasonable to expect each HA in the network to maintain 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 state about the mobile node. Also, if the HA does not cache
regarding sequence number, as per the second point above, a replayed information regarding sequence number, as per the second point above,
BU can cause a Home Agent to create a binding cache entry for the MN. a replayed BU can cause a Home Agent to create a binding cache entry
Thus, when authentication option is used, Sequence Number does not for the mobile node. Thus, when authentication option is used,
provide protection against replay attack. Sequence Number does not provide protection against replay attack.
One solution to this problem would be for the HA to reject the first One solution to this problem (when HA does not save state information
BU and assign a starting sequence number for the session and force for every MN) would be for the HA to reject the first BU and assign a
the MN to send a fresh BU with the suggested sequence number. While (randomly generated) starting sequence number for the session and
this would work in most cases, it would require an additional round force the MN to send a fresh BU with the suggested sequence number.
trip and this extra signalling and latency is not acceptable in 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 certain deployments (3GPP2). Also, this rejection and using sequence
number as a nonce in rejection is a new behavior that is not number as a nonce in rejection is a new behavior that is not
specified in [RFC3775]. specified in [RFC3775].
Thus, this specification uses the message identification option to Thus, this specification uses the message identification option to
prevent replay attacks. Specifically, timestamps are used for prevent replay attacks. Specifically, timestamps are used for
message identification to prevent replay attacks as described in message identification to prevent replay attacks as described in
Section 6.1. 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
 End of changes. 

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