Network Working Group A. Patel
Internet-Draft K. Leung
Expires: November 22, 2004 Cisco Systems
M. Khalil
H. Akhtar
K. Chowdhury
Nortel Networks
May 24, 2004
Authentication Protocol for Mobile IPv6
draft-patel-mipv6-auth-protocol-01.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 November 22, 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 November 22, 2004 [Page 1]
Internet-Draft Authentication Protocol for Mobile IPv6 May 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 . . . . . . . . . . . . . . 12
8. Encrypted Home KeyGen Token Option . . . . . . . . . . . . . . 14
8.1 Processing Considerations . . . . . . . . . . . . . . . . 15
8.1.1 Home Agent Considerations . . . . . . . . . . . . . . 15
8.1.2 Mobile Node Considerations . . . . . . . . . . . . . . 15
9. Securing The Mobile Prefix Solicitation and Mobile Prefix
Advertisement messages . . . . . . . . . . . . . . . . . . . . 16
9.1 Prefix Encryption Option . . . . . . . . . . . . . . . . . 16
9.1.1 Processing Considerations . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
13. Normative References . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . 23
Patel, et al. Expires November 22, 2004 [Page 2]
Internet-Draft Authentication Protocol for Mobile IPv6 May 2004
1. Motivation
The base specification of Mobile IPv6 [BASE] 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).
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 November 22, 2004 [Page 3]
Internet-Draft Authentication Protocol for Mobile IPv6 May 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.
As per the specification in the current MIPv6 draft [BASE], the
return routability messages are protected by IPsec between MN and HA.
Specifically, the Home KeyGen token sent by the CN to the MN (via) HA
needs to be protected to secure the messages from an eves-dropper on
the path between MN and HA. The extensions in this draft encrypts
the Home KeyGen token from the HA to MN (based on a shared secret
that is either derived, distributed or preconfigured between the MN
and the HA). Thus, the integrity of the HoT message is preserved.
This document introduces new mobility options to aid in
authentication of the MN and to protect the integrity and
confidentiality of return routability and mobile prefix solicitation
and advertisement messages.
Patel, et al. Expires November 22, 2004 [Page 4]
Internet-Draft Authentication Protocol for Mobile IPv6 May 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 November 22, 2004 [Page 5]
Internet-Draft Authentication Protocol for Mobile IPv6 May 2004
4. General Terms
MN Mobile Node
HA Home Agent
SA Security Association
CN Correspondent Node
IPsec IP Security protocol
ESP Encapsulating security protocol
BU Binding Update
BA Binding Acknowledgement
HoT Home Test Message (part of Return Routability test)
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
AES Advanced Encryption Standard
IV Initialization Vector
Patel, et al. Expires November 22, 2004 [Page 6]
Internet-Draft Authentication Protocol for Mobile IPv6 May 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 November 22, 2004 [Page 7]
Internet-Draft Authentication Protocol for Mobile IPv6 May 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 November 22, 2004 [Page 8]
Internet-Draft Authentication Protocol for Mobile IPv6 May 2004
Mobility Header upto and including the SPI field.
Alignment requirements :
TBD.
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 November 22, 2004 [Page 9]
Internet-Draft Authentication Protocol for Mobile IPv6 May 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).
Nonces: TBD
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 November 22, 2004 [Page 10]
Internet-Draft Authentication Protocol for Mobile IPv6 May 2004
7. Mobility message identification option
The identification option is used to prevent replay protection. The
Identification field carries either timestamps or nonces for replay
protection (support for timestamps is mandatory). 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 November 22, 2004 [Page 11]
Internet-Draft Authentication Protocol for Mobile IPv6 May 2004
8-bit unsigned integer, representing the length in octets of
the Identification field.
Identification:
The Identification field carries either timestamps or nonces
for replay protection (support for timestamps is mandatory).
Alignment requirements :
TBD.
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:
MN-HA Timestamps: 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, 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.
Nonces: TBD
7.1.2 Mobile Node Considerations
Timestamps: If 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.
Nonces: TBD
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:
MN-AAA Timestamps: After successful authentication of MN's
Patel, et al. Expires November 22, 2004 [Page 12]
Internet-Draft Authentication Protocol for Mobile IPv6 May 2004
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. In the reject
message the HAAA MUST include the latest timestamp. 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
Binding Acknowledgement message
Nonces: TBD
Patel, et al. Expires November 22, 2004 [Page 13]
Internet-Draft Authentication Protocol for Mobile IPv6 May 2004
8. Encrypted Home KeyGen Token Option
This option is inserted by the HA in the HoT message if MN and HA are
using the authentication option defined in this document. If IPsec
is used as per [BASE], this processing does not apply.
HA must use the Home KeyGen token from the HoT message and encrypt it
as described below. The encrypted token is included in the HoT
message. HA must set the Home KeyGen token in the HoT message to
zero.
Encrypting the Home KeyGen token provides similar level of security
as provided by using IPsec for protecting the HoT messages. The Home
KeyGen Token is encrypted using AES [AES].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| IV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type:
KEYGEN-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 SPI, Nonce, IV and the payload data fields, not including
the Option Type and Option Length field.
Patel, et al. Expires November 22, 2004 [Page 14]
Internet-Draft Authentication Protocol for Mobile IPv6 May 2004
SPI:
The SPI corresponds to the SPI of the security associations
between MN and HA. It is used to associate the right shared
key to decrypt the Home KeyGen token.
Nonce:
The Nonce field is 4 octets in length and is used to ensure the
uniqueness of the encryption key used to encrypt each instance
of the Home KeyGen Token option occurring in a given HoT
message. The contents of each Nonce field in a given HoT
message MUST be unique.
IV:
The Initialization Vector (IV) field is 16 octets in length.
This value is required to encrypt the first block of plaintext
data.
Payload data:
AES (Home KeyGen Token).
Alignment requirements:
TBD.
8.1 Processing Considerations
8.1.1 Home Agent Considerations
Home Agent must intercept the HoT message and if IPsec is not in use
between MN and HA as described in [BASE] (for authentication/
encryption of control messages), MUST encrypt the Home KeyGen token
as described in section 8.
8.1.2 Mobile Node Considerations
When MN receives a HoT message, if IPsec is not in use between MN and
HA, MN must extract the Home KeyGen Token by decrypting the payload
data field with the IV, Nonce and the key.
Patel, et al. Expires November 22, 2004 [Page 15]
Internet-Draft Authentication Protocol for Mobile IPv6 May 2004
9. Securing The Mobile Prefix Solicitation and Mobile Prefix
Advertisement messages
The [BASE] allows the MN to solicit home prefix from the HA. This
solicitation message SHOULD be authenticated at the HA before the HA
gives out home prefix details to the MN. In order to authenticate
the message The MN-HA authentication mobility option SHALL be used.
If IPsec is used as per [BASE], this processing does not apply.
In response to the prefix solicitation message, the HA sends Prefix
Advertisement Message back the MN. These prefixes SHOULD be
encrypted to protect the network from attacks. The prefixes
[RFC2461], section 4.6.2 SHOULD be encrypted using a suitable
encryption method such as AES [AES]. Encrypting the prefixes
provides similar level of security as provided by IPsec using ESP.
9.1 Prefix Encryption Option
to send encrypted prefixes the HA MUST use the following destination
option:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| IV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Patel, et al. Expires November 22, 2004 [Page 16]
Internet-Draft Authentication Protocol for Mobile IPv6 May 2004
Type:
PREFIX-OPTION-TYPE to be defined by IANA. An 8-bit identifier
of the type mobility option.
Length, Prefix Length, L and A-bit, Reserved1, Valid Lifetime,
Preferred Lifetime, Reserved2 are as defined in [RFC2461], section
4.6.2.
SPI:
The SPI corresponds to the SPI of the security associations
between MN and HA. It is used to associate the right shared
key to decrypt the Encrypted Prefix.
Nonce:
The Nonce field is 4 octets in length and is used to ensure the
uniqueness of the encryption key used to encrypt each instance
of the prefix encryption option occurring in a given prefix
advertisement message. The contents of each Nonce field in a
given prefix advertisement message MUST be unique.
IV:
The Initialization Vector (IV) field is 16 octets in length.
This value is required to encrypt the first block of plaintext
data.
Payload data:
AES (Prefix).
Alignment requirements:
TBD.
9.1.1 Processing Considerations
9.1.1.1 Home Agent Considerations
Upon receiving the Mobile Prefix Solicitation message from a MN, the
HA SHOULD authenticate the MN using the MN-HA authentication mobility
option that is included in the message. The processing consideration
for the MN-HA authentication mobility option is as described in
section 6.1.
While sending the Mobile Prefix Advertisement message back to the MN
Patel, et al. Expires November 22, 2004 [Page 17]
Internet-Draft Authentication Protocol for Mobile IPv6 May 2004
in response to a solicitation or unsolicited but unicast way, the HA
SHOULD encrypt the prefix with a shared secret that is either derived
or provisioned between the HA and the MN and use IV and nonce. The
encrypted data should be included in the payload data field of the
prefix encryption option defined in 9.1. The IV and the nonce used
by the HA MUST be included in the respective fields in the prefix
encryption option. The HA SHOULD encrypt the prefix using the shared
secret, IV and Nonce and the AES mode as indexed by SPI.
9.1.1.2 Mobile Node Considerations
While sending a Mobile Prefix Solicitation message the MN SHOULD
include the MN-HA authentication mobility option. The calculation of
the authenticator can be performed as:
Authenticator = First (96,HMAC_SHA1(MN-HA Shared key, Data)).
Data = All fields in the IP header and the message body.
Upon receiving a Mobile Prefix Advertisement message from the HA in a
solicited or unsolicited manner, the MN SHOULD decrypt the prefix
using the shared secret, IV and Nonce and the AES mode as indexed by
SPI.
Patel, et al. Expires November 22, 2004 [Page 18]
Internet-Draft Authentication Protocol for Mobile IPv6 May 2004
10. 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. These do not provide ways for
encrypting these messages.
In terms of protecting the return routability messages, this
mechanism provides a way to encrypt the Home KeyGen token from CN to
MN on the path between HA and MN.
In terms of protecting Prefix Solicitation and Prefix Advertisement
messages this specification provides ways to calculate and include
message authenticators and provides ways to send encrypted prefixes
to the MN.
Patel, et al. Expires November 22, 2004 [Page 19]
Internet-Draft Authentication Protocol for Mobile IPv6 May 2004
11. IANA Considerations
The option types AUTH-OPTION-TYPE, IDENT-OPTION-TYPE, KEYGEN-
OPTION-TYPE and PREFIX-OPTION-TYPE as defined in section 6, 7 and 8
respectively are new mobility options. 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 November 22, 2004 [Page 20]
Internet-Draft Authentication Protocol for Mobile IPv6 May 2004
12. Acknowledgements
TBD.
13 Normative References
[3012bis] Perkins et. al., C., "Mobile IPv4 Challenge/Response
Extensions (revised)", draft-ietf-mip4-rfc3012bis-01 (work
in progress), April 2004.
[AES] "National Institute of Standards. FIPS Pub 197: Advanced
Encryption Standard (AES).", 26 November 2001.
[BASE] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support
in IPv6", draft-ietf-mobileip-ipv6-24 (work in progress),
June 2003.
[NAI] Patel et. al., A., "Network Access Identifier Option for
Mobile IPv6", draft-patel-mipv6-nai-option-00.txt (work in
progress), February 2004.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994.
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
Authors' Addresses
Alpesh Patel
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
US
Phone: +1 408-853-9580
EMail: alpesh@cisco.com
Patel, et al. Expires November 22, 2004 [Page 21]
Internet-Draft Authentication Protocol for Mobile IPv6 May 2004
Kent Leung
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
US
Phone: +1 408-526-5030
EMail: kleung@cisco.com
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 November 22, 2004 [Page 22]
Internet-Draft Authentication Protocol for Mobile IPv6 May 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 November 22, 2004 [Page 23]