draft-ietf-mip6-auth-protocol-03.txt   draft-ietf-mip6-auth-protocol-04.txt 
Network Working Group A. Patel Network Working Group A. Patel
Internet-Draft K. Leung Internet-Draft K. Leung
Expires: July 19, 2005 Cisco Systems Expires: August 11, 2005 Cisco Systems
M. Khalil M. Khalil
H. Akhtar H. Akhtar
Nortel Networks Nortel Networks
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
January 18, 2005 February 10, 2005
Authentication Protocol for Mobile IPv6 Authentication Protocol for Mobile IPv6
draft-ietf-mip6-auth-protocol-03.txt draft-ietf-mip6-auth-protocol-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 19, 2005. This Internet-Draft will expire on August 11, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
IPsec is specified as the sole means of securing all signaling IPsec is specified as the sole means of securing all signaling
messages between the Mobile Node and Home agent for Mobile IPv6. A messages between the Mobile Node and Home agent for Mobile IPv6. A
flexible model for security between the Mobile Node and Home Agent is flexible model for security between the Mobile Node and Home Agent is
skipping to change at page 3, line 14 skipping to change at page 3, line 14
1. Introduction 1. Introduction
The base Mobile IPv6 specification [RFC3775] specifies the signaling The base Mobile IPv6 specification [RFC3775] specifies the signaling
messages, Binding Update (BU) and Binding Acknowledgement (BA), messages, Binding Update (BU) and Binding Acknowledgement (BA),
between the Mobile Node and Home agent to be secured by the IPsec between the Mobile Node and Home agent to be secured by the IPsec
Security Associations (IPsec SAs) that are established between these Security Associations (IPsec SAs) that are established between these
two entities. This security model for Mobile IPv6 does not fit in two entities. This security model for Mobile IPv6 does not fit in
very well for deployment scenarios which: very well for deployment scenarios which:
1. rely on the use of a Authentication, Authorization and Accounting 1. rely on the use of an Authentication, Authorization and
(AAA) infrastructure for authenticating the subscriber Accounting (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
IPsec SAs IPsec SAs
4. include Mobile Nodes that do not support IKEv1 4. include Mobile Nodes that do not support IKEv1
This indicates the need for a solution that does not necessarily This indicates the need for a solution that does not necessarily
require an IPsec SA for securing the signaling messages that deal require an IPsec SA for securing the signaling messages that deal
with the Registration process of a Mobile Node with a home agent. with the Registration process of a Mobile Node with a home agent.
This document proposes a solution for securing the Binding Update and This document proposes a solution for securing the Binding Update and
skipping to change at page 4, line 17 skipping to change at page 4, line 17
This document presents a lightweight mechanism to authenticate the This document presents a lightweight mechanism to authenticate the
Mobile Node at the Home Agent or at the Authentication, Authorization Mobile Node at the Home Agent or at the Authentication, Authorization
and Accounting (AAA) server in Home network (AAAH) based on a shared and Accounting (AAA) server in Home network (AAAH) based on a shared
key based security association between the Mobile Node and the key based security association between the Mobile Node and the
respective authenticating entity. This shared key based security respective authenticating entity. This shared key based security
association (shared-key based SA) may be statically provisioned or association (shared-key based SA) may be statically provisioned or
dynamically created. The term "security association" referred to in dynamically created. The term "security association" referred to in
this document is understood to be a "shared-key based Mobile IPv6 this document is understood to be a "shared-key based Mobile IPv6
authentication" security association. The Mobile Node MUST use only authentication" security association. The Mobile Node MUST use only
one means of authentication, based on either the shared key based one means of authentication, based on either the shared key based
authentication or IPsec security association. Home agents still have authentication or IPsec security association with a selected Home
to implement and support registrations from Mobile Nodes that are Agent at any given time. However a MN that implements both schemes
secured via IPsec as well as with the authentication option. of authentication may choose any appropriate scheme with the chosen
HA. The determination of what authentication scheme to use is beyond
the scope of this document. Home agents still have to implement and
support registrations from Mobile Nodes that are secured via IPsec as
well as with the authentication option.
This document introduces new mobility options to aid in This document introduces new mobility options to aid in
authentication of the Mobile Node to the Home Agent or AAAH server. authentication of the Mobile Node to the Home Agent or AAAH server.
The confidentiality protection of Return Routability messages and The confidentiality protection of Return Routability messages and
authentication/integrity protection of Mobile Prefix Discovery (MPD) authentication/integrity protection of Mobile Prefix Discovery (MPD)
is outside the scope of this document. is outside the scope of this document.
3. Terminology 3. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 6, line 7 skipping to change at page 6, line 7
3.1 General Terms 3.1 General Terms
First (size, input) First (size, input)
Some formulas in this specification use a functional form "First Some formulas in this specification use a functional form "First
(size, input)" to indicate truncation of the "input" data so that (size, input)" to indicate truncation of the "input" data so that
only the first "size" bits remain to be used. only the first "size" bits remain to be used.
4. Operational flow 4. Operational flow
The figure below describes the sequence of messages sent and received
between the MN and HA in the registration process. Binding Update
(BU) and Binding Acknowledgement (BA) messages are used in the
registration process.
MN HA/AAAH MN HA/AAAH
| BU to HA | | BU to HA |
(a) |----------------------------------------------------->| (a) |----------------------------------------------------->|
| (including MN-ID option [optional], | | (including MN-ID option [optional], |
| Message ID option [optional], authentication option)| | Message ID option [optional], authentication option)|
| | | |
| | | |
| HA/AAAH authenticates MN | HA/AAAH authenticates MN
| | | |
| | | |
skipping to change at page 6, line 34 skipping to change at page 6, line 39
Mobile Node MAY use Mobile Node Identifier Option as defined in Mobile Node MAY use Mobile Node Identifier Option as defined in
[MN_Ident] or Home Address to identify itself while authenticating [MN_Ident] or Home Address to identify itself while authenticating
with the Home Agent. The mobile node uses the Mobile Node Identifier with the Home Agent. The mobile node uses the Mobile Node Identifier
option as defined in [MN_Ident] to identify itself as may be required option as defined in [MN_Ident] to identify itself as may be required
for use with some existing AAA infrastructure designs. for use with some existing AAA infrastructure designs.
Mobile Node MAY use Message Identifier option as defined in Section 6 Mobile Node MAY use Message Identifier option as defined in Section 6
for additional replay protection. for additional replay protection.
The authentication option in this document Section 5 may be used by The authentication option described in Section 5 may be used by the
the mobile node to transfer authentication data when the mobile node mobile node to transfer authentication data when the mobile node and
and the home agent are utilizing an SPI to index between multiple the home agent are utilizing an SPI to index between multiple
security associations. For the case when there is only one such security associations. For the case when there is only one such
security association, and no SPI is needed, the Mobile Node and Home security association, and no SPI is needed, the Mobile Node and Home
Agent can use the Binding Authorization Data option as defined in the Agent can use the Binding Authorization Data option as defined in the
base Mobile IPv6 specification [RFC3775] for this same purpose. base Mobile IPv6 specification [RFC3775] for this same purpose.
Since that option does not have any SPI, the Mobile Node and the Home Since that option does not have any SPI, the Mobile Node and the Home
Agent implicitly agree that the security association to be used is Agent implicitly agree that the security association to be used is
the only mobility security association that is defined for their the only mobility security association that is defined for their
mutual authentication needs. mutual authentication needs.
5. Mobility message authentication option 5. Mobility message authentication option
This section defines a message authentication mobility option that This section defines a message authentication mobility option that
may be used to secure Binding Update and Binding Acknowledgement may be used to secure Binding Update and Binding Acknowledgement
messages. This option can be used along with IPsec or preferably as messages. This option can be used along with IPsec or preferably as
an alternate mechanism to authenticate Binding Update and Binding an alternate mechanism to authenticate Binding Update and Binding
Acknowledgement messages in absence of IPsec. Acknowledgement messages in the absence of IPsec.
This document also defines subtype numbers, which identify the mode This document also defines subtype numbers, which identify the mode
of authentication and the peer entity to authenticate the message. of authentication and the peer entity to authenticate the message.
Two subtype numbers are specified in this document. It is expected Two subtype numbers are specified in this document. Other subtypes
that other subtypes will be defined by other documents in the future. may be defined for use in the future.
Only one instance of an authentication option of a particular subtype Only one instance of an authentication option of a particular subtype
can be present in the message. One message may contain multiple can be present in the message. One message may contain multiple
instances of authentication options with different subtype values. instances of authentication options with different subtype values.
When a Binding Update or Binding Acknowledgement is received without When a Binding Update or Binding Acknowledgement is received without
an authentication option and the entity receiving it is configured to an authentication option and the entity receiving it is configured to
use authentication option or has the shared-key based security use authentication option or has the shared-key based security
association for authentication option, the entity should silently association for authentication option, the entity should silently
discard the received message. discard the received message.
skipping to change at page 10, line 29 skipping to change at page 10, line 29
AAA using HMAC_SHA1 authentication. In that case, MAC_Mobility Data AAA using HMAC_SHA1 authentication. In that case, MAC_Mobility Data
is calculated as follows: is calculated as follows:
MAC_Mobility Data = SHA1(care-of address | home address | MH Data) MAC_Mobility Data = SHA1(care-of address | home address | MH Data)
MH Data is the content of the Mobility Header upto and including the MH Data is the content of the Mobility Header upto and including the
SPI field of this option. SPI field of this option.
5.2.1 Processing Considerations 5.2.1 Processing Considerations
Interaction between the HA and the AAA server is beyond the scope of
this document.
When the Home Agent receives a Binding Update with the Mobile-AAA When the Home Agent receives a Binding Update with the Mobile-AAA
authentication option, the Binding Update is authenticated by an authentication option, the Binding Update is authenticated by an
entity external to the Home Agent, typically a AAA server. entity external to the Home Agent, typically a AAA server.
5.3 Authentication Failure Detection at the Mobile Node 5.3 Authentication Failure Detection at the Mobile Node
In case of authentication failure, the Home Agent MUST send a Binding In case of authentication failure, the Home Agent MUST send a Binding
Acknowledgement with status code MIPV6-AUTH-FAIL to the Mobile Node, Acknowledgement with status code MIPV6-AUTH-FAIL to the Mobile Node,
if an SA to be used between Mobile Node and Home Agent for if an SA to be used between Mobile Node and Home Agent for
authentication exists. authentication exists.
skipping to change at page 14, line 17 skipping to change at page 14, line 17
This document proposes new authentication options to authenticate the This document proposes new authentication options to authenticate the
control message between Mobile Node, Home Agent and/or home AAA (as control message between Mobile Node, Home Agent and/or home AAA (as
an alternative to IPsec). The new options provide for authentication an alternative to IPsec). The new options provide for authentication
of Binding Update and Binding Acknowledgement messages. The MN-AAA of Binding Update and Binding Acknowledgement messages. The MN-AAA
authentication options provides for authentication with AAA authentication options provides for authentication with AAA
infrastructure. It can be used to generate a per session key between infrastructure. It can be used to generate a per session key between
Mobile Node and Home Agent for subsequent authentication of BU/BA Mobile Node and Home Agent for subsequent authentication of BU/BA
between Mobile Node and Home Agent via the MN-HA authentication between Mobile Node and Home Agent via the MN-HA authentication
option. option.
This memo also introduces an optional replay protection mechanism This specification also introduces an optional replay protection
Section 6, to prevent replay attacks. The sequence number field in mechanism in Section 6, to prevent replay attacks. The sequence
the Binding Update is not used if this mechanism is used. This memo number field in the Binding Update is not used if this mechanism is
defines the timestamp option to be used for mobility message replay used. This memo defines the timestamp option to be used for mobility
protection. message replay protection.
8. IANA Considerations 8. IANA Considerations
IANA services are required for this specification. The values for IANA services are required for this specification. The values for
new mobility options and status codes must be assigned from the new mobility options and status codes must be assigned from the
Mobile IPv6 [RFC3775] numbering space. Mobile IPv6 [RFC3775] numbering space.
The values for Mobility Option types AUTH-OPTION-TYPE and The values for Mobility Option types AUTH-OPTION-TYPE and
MESG-ID-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
 End of changes. 

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