Network Working Group A. Patel
Internet-Draft K. Leung
Expires: December 31, 2004 Cisco Systems
M. Khalil
H. Akhtar
K. Chowdhury
Nortel Networks
July 2, 2004
Authentication Protocol for Mobile IPv6
draft-ietf-mip6-auth-protocol-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
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
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 31, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document defines new mobility options to enable authentication
between mobility entities. These options can be used in addition to
or in lieu of IPsec to authenticate mobility messages as defined in
the base Mobile IPv6 specification.
Patel, et al. Expires December 31, 2004 [Page 1]
Internet-Draft Authentication Protocol for Mobile IPv6 July 2004
Table of Contents
1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. General Terms . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Operational flow . . . . . . . . . . . . . . . . . . . . . . . 7
6. Mobility message authentication option . . . . . . . . . . . . 8
6.1 MN-HA authentication mobility option . . . . . . . . . . . 9
6.2 MN-AAA authentication mobility option . . . . . . . . . . 9
6.2.1 Processing considerations . . . . . . . . . . . . . . 10
7. Mobility message identification option . . . . . . . . . . . . 11
7.1 Processing considerations . . . . . . . . . . . . . . . . 12
7.1.1 Home Agent Considerations . . . . . . . . . . . . . . 12
7.1.2 Mobile Node Considerations . . . . . . . . . . . . . . 12
7.1.3 AAA server Considerations . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
11. Normative References . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 18
Patel, et al. Expires December 31, 2004 [Page 2]
Internet-Draft Authentication Protocol for Mobile IPv6 July 2004
1. Motivation
The base specification of Mobile IPv6 [RFC3775] mandates IPsec
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
algorithms used), use of IPsec may not be required/feasible in all
cases where Mobile IPv6 may be used. For small handheld devices, the
use of IPsec may be too taxing on battery and processor performance.
Also depending on the model of home agent deployment (HA deployed by
enterprise/service provider), MN may have to VPN back into the
enterprise (which may impose dual IPsec requirement on MN).
Moreover, IPsec/IKE based Mobile IPv6 over public wireless carrier's
networks may pose serious capacity and scalability challenge. The
multiple round trips to perform ISAKMP/IKE to establish IPsec SA may
be too taxing on the wireless link, not to mention increase in setup
latency during initial access and during handoffs. The use of manual
IPsec SA in these large public network deployments suffer from
scalability issue and involve provisioning nightmare.
Also, having an authentication mechanism tied to the Mobile's home IP
address does not permit the mobility entity to derive or acquire a
dynamic home address based on the configured prefix. If the MN's
home address is dynamically configured based on a fixed prefix or
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
the MN to register with a Home Agent on a dynamically discovered Home
Link. This sort of Dynamic Home Link assignments will allow the
operators to leverage the true benefit of dynamic Home Agent
assignment. For example the operator may assign a Home Link or Home
Agent for the user that is closest to the subnet of attachment of the
user. There may be various other reasons for opportunistic Home
Agent assignment. The mechanisms described in the draft allows the
MN to register with any Home Agent in the home network as long as the
MN user shares security association with an entity in the home
network such as a AAA server.
Patel, et al. Expires December 31, 2004 [Page 3]
Internet-Draft Authentication Protocol for Mobile IPv6 July 2004
2. Overview
This document presents a lightweight mechanism to authenticate the MN
at the HA or at the Home AAA based on a shared security association
between the MN and the respective authenticating entity.
This document introduces new mobility options to aid in
authentication of the MN to the HA or AAA server. The
confidentiality protection of the Mobile Prefix Discovery (MPD) and
Return Routability (Home KeyGen token) messages is outside the scope
of this document.
Patel, et al. Expires December 31, 2004 [Page 4]
Internet-Draft Authentication Protocol for Mobile IPv6 July 2004
3. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119.
Patel, et al. Expires December 31, 2004 [Page 5]
Internet-Draft Authentication Protocol for Mobile IPv6 July 2004
4. General Terms
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
Patel, et al. Expires December 31, 2004 [Page 6]
Internet-Draft Authentication Protocol for Mobile IPv6 July 2004
5. Operational flow
MN HA/HAAA
| BU to HA |
(a) |---------------------------------------------------->|
| (HoA option, NAI[optional], ID option, auth option) |
| |
| HA/HAAA authenticates MN
| |
| |
| BA to MN |
(b) |<----------------------------------------------------|
| (HoA option, NAI[optional], ID option, auth option) |
| |
| |
MN may use NAI option as defined in [NAI] to identify itself to the
HA while authenticating with the HA. The MN SHOULD use NAI option
[NAI] while authenticating with the AAA infrastructure.
Patel, et al. Expires December 31, 2004 [Page 7]
Internet-Draft Authentication Protocol for Mobile IPv6 July 2004
6. Mobility message authentication option
This section defines the message authentication mobility option that
may be used to secure Binding Update and Binding Acknowledgement
messages. This extension can be used along with IPsec or preferably
as an alternate mechanism to authenticate binding update and binding
acknowledgement messages in absence of IPsec. This document also
defines subtype numbers, which identify the mode of authentication
and the peer entity to authenticate the message. Two subtype numbers
are specified in this document. It is expected that other subtypes
will be defined by other documents in the future.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI | Authenticator . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type:
AUTH-OPTION-TYPE to be defined by IANA. An 8-bit identifier of
the type mobility option.
Option Length:
8-bit unsigned integer, representing the length in octets of
the sub-type, SPI and authenticator, not including the Option
Type and Option Length fields.
Subtype:
A number assigned to identify the entity and/or mechanism to be
used to authenticate the message.
SPI:
Used to identify the particular security association to use to
authenticate the message.
Authenticator:
This field has the information to authenticate the relevant
mobility entity. This protects the message beginning at the
Patel, et al. Expires December 31, 2004 [Page 8]
Internet-Draft Authentication Protocol for Mobile IPv6 July 2004
Mobility Header upto and including the SPI field.
Alignment requirements :
MUST be aligned on an 8-octet boundary.
6.1 MN-HA authentication mobility option
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
authentication mobility option is used to authenticate the binding
update and binding acknowledgement messages based on the shared
security association between the MN and the HA.
This must be the last option in a message with mobility header. The
authenticator is calculated on the message starting from the mobility
header till the SPI value of this option.
Authenticator = First (96,HMAC_SHA1(MN-HA Shared key, Mobility
Data))
Mobility Data = care-of address | home address | MH Data
MH Data is the content of the Mobility Header till the SPI field of
this extension.
The first 96 bits from the MAC result are used as the
Authenticator field.
6.2 MN-AAA authentication mobility option
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
authentication mobility option is used to authenticate the binding
update and binding acknowledgement messages based on the shared
security association between MN and HAAA.
This must be the last option in a message with mobility header. The
authenticator is calculated on the message starting from the mobility
header till the SPI value of this option.
The MN SHOULD use NAI option [NAI] to enable the Home Agent to make
use of available AAA infrastructure which requires NAI.
The MN MUST use either CHAP_SPI or HMAC_CHAP_SPI as defined in
[3012bis] to indicate CHAP style authentication. The authenticator
shall be calculated as follows:
Patel, et al. Expires December 31, 2004 [Page 9]
Internet-Draft Authentication Protocol for Mobile IPv6 July 2004
Authenticator = First (96, HMAC_SHA1 (MN-AAA Shared key, MAC_Mobility
Data))).
SPI = CHAP_SPI:
MAC_Mobility Data = MD5 (care-of address | home address | MH Data).
SPI = HMAC_CHAP_SPI:
MAC_Mobility Data = HMAC_MD5 (care-of address | home address | MH
Data).
6.2.1 Processing considerations
The MN-AAA authentication mobility option MUST be verified by the AAA
infrastructure that has the shared secret with the MN. The HA relays
the authenticating information to the HAAA. The HA relies on the
HAAA to admit or reject the home registration request from the MN.
6.2.1.1 Home Agent Considerations
Upon receiving a BU from the MN the HA SHALL extract the MN-AAA
authenticator and the SPI from the MN-AAA authentication mobility
option and extract the NAI from the NAI option [NAI]. The HA SHALL
include the extracted MN-AAA authenticator, SPI and the NAI in AAA
specific AVPs while initiating the authentication procedure via AAA
infrastructure.
Patel, et al. Expires December 31, 2004 [Page 10]
Internet-Draft Authentication Protocol for Mobile IPv6 July 2004
7. Mobility message identification option
The identification option is used to prevent replay protection. The
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
other methods may be utilized as well. If the MN uses 'timestamp' as
a measure against replay protection, it SHOULD insert the current
time of day. When the destination node receives the Binding Update,
it will make sure that the 'timestamp' (as included by the sender) is
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
fractional seconds, the rest of the bits SHOULD be generated from a
good source of randomness.
For the identification field to be valid, the 'timestamp' contained
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
of day clock.
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
mobile node and the HA and/or the HAAA MUST agree on which method of
replay protection will be used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type:
IDENT-OPTION-TYPE to be defined by IANA. An 8-bit identifier
of the type mobility option.
Option Length:
Patel, et al. Expires December 31, 2004 [Page 11]
Internet-Draft Authentication Protocol for Mobile IPv6 July 2004
8-bit unsigned integer, representing the length in octets of
the Identification field.
Identification:
The Identification field carries timestamp for replay
protection.
Alignment requirements :
MUST be aligned on an 8-octet boundary.
7.1 Processing considerations
The Identification field is used to let the HA and/or the HAAA verify
that a Binding Update message has been generated recently by the MN,
and it is not replayed by an attacker from some older registrations.
7.1.1 Home Agent Considerations
The HA processes this option only when MN-HA authentication mobility
option is used in the BU. In this case:
After successful authentication of Binding Update, the Home Agent
must verify that the Identification field falls within the replay
protection window. If Identification field is not within this window
but the authentication of the BU succeeds, 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
Binding Acknowledgement message.
MN-HA Timestamp: If timestamp based replay check is successful and
the authentication succeeds, the HA MUST include the received
Identification value in the corresponding field of the Mobility
message identification option in the BA.
7.1.2 Mobile Node Considerations
The MN MUST process the Mobility message identification option.
MN-HA Timestamp and MN-AAA Timestamp: The MN MUST set the
Identification value in the Mobility message identification option in
the BU message according to its own clock. If the MN receives a
Binding Acknowledgement with the code MIPV6-ID-MISMATCH, MN must
adjust its timestamp and send subsequent Binding Update using the
updated value.
Patel, et al. Expires December 31, 2004 [Page 12]
Internet-Draft Authentication Protocol for Mobile IPv6 July 2004
7.1.3 AAA server Considerations
The HAAA processes this option only when MN-AAA authentication
mobility option is used in the BU. In this case:
After successful authentication of MN's credentials contained in the
AVPs, the Home AAA server MUST verify that the Identification field
falls within the replay protection window. If Identification field
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 authentication and authorization succeeds, the HAAA does not
include any updated Identification value in the accept message. In
this case, the HA copies the Identification value from the BU into
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.
Patel, et al. Expires December 31, 2004 [Page 13]
Internet-Draft Authentication Protocol for Mobile IPv6 July 2004
8. Security Considerations
This document proposes new authentication options to authenticate the
control message between MN, HA and/or HAAA (as an alternative to
IPsec). The new options provide for authentication of Binding Update
and Binding Acknowledgement messages
Patel, et al. Expires December 31, 2004 [Page 14]
Internet-Draft Authentication Protocol for Mobile IPv6 July 2004
9. IANA Considerations
The option types AUTH-OPTION-TYPE, IDENT-OPTION-TYPE, as defined in
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.
Patel, et al. Expires December 31, 2004 [Page 15]
Internet-Draft Authentication Protocol for Mobile IPv6 July 2004
10. Acknowledgements
TBD.
11 Normative References
[3012bis] Perkins et. al., C., "Mobile IPv4 Challenge/Response
Extensions (revised)", draft-ietf-mip4-rfc3012bis-01 (work
in progress), April 2004.
[NAI] Patel et. al., A., "Network Access Identifier Option for
Mobile IPv6", draft-ietf-mipv6-nai-option-00.txt (work in
progress), February 2004.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Authors' Addresses
Alpesh Patel
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
US
Phone: +1 408-853-9580
EMail: alpesh@cisco.com
Kent Leung
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
US
Phone: +1 408-526-5030
EMail: kleung@cisco.com
Patel, et al. Expires December 31, 2004 [Page 16]
Internet-Draft Authentication Protocol for Mobile IPv6 July 2004
Mohamed Khalil
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082
US
Phone: +1 972-685-0574
EMail: mkhalil@nortelnetworks.com
Haseeb Akhtar
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082
US
Phone: +1 972-684-4732
EMail: haseebak@nortelnetworks.com
Kuntal Chowdhury
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082
US
Phone: +1 972 685 7788
EMail: chowdury@nortelnetworks.com
Patel, et al. Expires December 31, 2004 [Page 17]
Internet-Draft Authentication Protocol for Mobile IPv6 July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Patel, et al. Expires December 31, 2004 [Page 18]
