Mobile IP Working Group Alpesh Patel
INTERNET DRAFT Kent Leung
February 2004 Cisco System Inc.
Haseeb Akhtar
Mohamed Khalil
Kuntal Chowdhury
Nortel Networks
Authentication Protocol for Mobile IPv6
draft-patel-mipv6-auth-protocol-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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.
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 [1].
Expires 13 July, 2004 [Page 1]
Internet Draft Authentication Protocol for MIPv6 14 February 2004
Table of Contents
1. Motivation......................................................2
2. Overview........................................................3
3. Terminology.....................................................3
3.1 General Terms..................................................3
4. Operational flow................................................4
5. Mobility message authentication option..........................4
6. Mobility message identification option..........................6
6.1 Processing considerations......................................7
6.1.1 Home Agent Considerations....................................7
6.1.2 Mobile Node Considerations...................................7
7. Encrypted Home KeyGen Token Option..............................7
7.1 Processing Considerations......................................9
7.1.1 Home Agent Considerations....................................9
7.1.2 Mobile Node Considerations..................................10
8. IANA Considerations............................................10
10. Intellectual Property Rights..................................10
11. Acknowledgements..............................................11
12. References....................................................11
13. Contact Information...........................................11
Full Copyright Statement..........................................12
1. Motivation
The base specification of Mobile IPv6 [1] 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
IP address does not permit the mobility entity to derive a
dynamic address based on the configured prefix. If the MNÆs
address is dynamically configured based on a fixed prefix,
IPsec will most likely not work as the IPsec SAÆs are tied to
the address. The mechanism described in this draft is not tied
with mobility entityÆs IP address and so does not mandate SA
relationship with an IP address.
Expires 13 July 2004 [Page 2]
Internet Draft Authentication Protocol for MIPv6 14 February 2004
2. Overview
This document presents a lightweight mechanism to authenticate
the MN and HA based on a shared security association between MN
and HA.
As per the specification in the current MIPv6 draft [1], 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 the same MN/HA shared secret as used to
authenticate the BU/BA messages). 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 of return
routability messages.
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 [2].
3.1 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
Expires 13 July 2004 [Page 3]
Internet Draft Authentication Protocol for MIPv6 14 February 2004
4. Operational flow
MN HA
| BU to HA |
(a) |---------------------------------------------------->|
| (HoA option, NAI[optional], ID option, auth option) |
| |
| HA authenticates MN and
| allocates Home Address
| |
| BA to MN |
(b) |<----------------------------------------------------|
| (HoA option, NAI[optional], ID option, auth option) |
| |
| |
MN may use NAI option as defined in [5] to identify itself to
the HA or some authentication infrastructure.
5. 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. One subtype number is 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.
Expires 13 July 2004 [Page 4]
Internet Draft Authentication Protocol for MIPv6 14 February 2004
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
Mobility Header upto and including the SPI field.
Alignment requirements
<TBD>
5.1 MN-HA authentication mobility option
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 authentication mobility option is used to authenticate
the binding update and binding acknowledgement messages based on
the shared security association between MN and HA. Note that the
security association may actually be between MN and the home
domain but used by HA for authentication purpose.
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.
Expires 13 July 2004 [Page 5]
Internet Draft Authentication Protocol for MIPv6 14 February 2004
The first 96 bits from the MAC result are used as the
Authenticator field.
6. 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
time of day clock.
The style of replay protection in effect between a mobile node
and its home agent is part of the mobile security association. A
mobile node and its home agent 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.
Expires 13 July 2004 [Page 6]
Internet Draft Authentication Protocol for MIPv6 14 February 2004
Option Length
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>
6.1 Processing considerations
The Identification field is used to let the HA 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.
6.1.1 Home Agent Considerations
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>
6.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. 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 [1], this processing does not apply.
Expires 13 July 2004 [Page 7]
Internet Draft Authentication Protocol for MIPv6 14 February 2004
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. Encrypting the Home KeyGen token is as per password
encryption as defined in [4], section 3.5.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt | String . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
reserved, salt and String fields, not including the Option Type
and Option Length fields.
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.
Salt
The Salt field is two 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 Salt field in a given HoT message MUST be
unique.
String
The plaintext String field consists of three logical sub-fields:
the Data-Length and token sub-fields (both of which are
required), and the optional Padding sub-field. The Data-Length
Expires 13 July 2004 [Page 8]
Internet Draft Authentication Protocol for MIPv6 14 February 2004
sub-field is one octet in length and contains the length of the
unencrypted token sub-field. The token sub-field contains
the actual Home KeyGen token. If the combined length (in octets)
of the unencrypted Data-Length and token sub-fields is not an
even multiple of 16, then the Padding sub-field MUST be present.
If it is present, the length of the Padding sub-field is
variable, between 1 and 15 octets. The String field MUST be
encrypted as follows, prior to transmission:
Construct a plaintext version of the String field by
concatenating the Data-Length and Token sub-fields. If
necessary, pad the resulting string until its length (in
octets) is an even multiple of 16. It is recommended that zero
octets (0x00) be used for padding. Call this plaintext P.
Call the shared secret (between MN and HA) S, the home init
cookie (from the HoT message) R, and the contents of the Salt
field A. Break P into 16 octet chunks p(1), p(2)...p(i), where
i = len(P)/16. Call the ciphertext blocks c(1), c(2)...c(i)
and the final ciphertext C. Intermediate values b(1),
b(2)...c(i) are required. Encryption is performed in the
following manner ('+' indicates concatenation):
b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1)
b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2)
. .
. .
. .
b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + (i)
The resulting encrypted String field will contain
c(1)+c(2)+...+c(i).
On receipt, the process is reversed to yield the plaintext
String.
Alignment requirements
<TBD>
7.1 Processing Considerations
7.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 [1] (for
authentication/encryption of control messages), MUST encrypt
the Home KeyGen token as described in section 7.
Expires 13 July 2004 [Page 9]
Internet Draft Authentication Protocol for MIPv6 14 February 2004
7.1.2 Mobile Node Considerations
When MN receives a HoT message, if IPsec is not in use between
MN and HA, MN must reverse the process as described in section
8 to retrieve the Home KeyGen token.
8. IANA Considerations
The option types AUTH-OPTION-TYPE, IDENT-OPTION-TYPE and KEYGEN-
OPTION-TYPE as defined in section 5, 6 and 7 respectively are new
mobility options.
IANA should record a value for these new mobility options.
9. Security Considerations
This document proposes a new authentication option to
authenticate the control message between MN and HA (as an
alternative to IPsec). The new option provides for authentication
of Binding Update and Binding Acknowledgement messages. It does
not provide for encrypting these messages.
In terms of protecting the return routability messages, this
mechanism provides to encrypt the Home KeyGen token from CN to MN
on the path between HA and MN.
10. Intellectual Property Rights
The IETF takes no position regarding the validity or scope of
any intellectual property 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; neither does
it represent that it has made any effort to identify any such
rights. Information on the IETF's procedures with respect to
rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made
available for publication 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 Secretariat.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights, which may cover technology that may be
Expires 13 July 2004 [Page 10]
Internet Draft Authentication Protocol for MIPv6 14 February 2004
required to practice this standard. Please address the
information to the IETF Executive Director.
11. Acknowledgements
12. References
[1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), June
2003.
[2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
[3] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999.
[4] Zorn, et al., RADIUS Tunnel Authentication Attributes, RFC
2868, June 2000
13. Contact Information
Questions and comments about this draft should be directed at
the Mobile IPv6 working group:
mip6@ietf.org
Questions and comments about this draft may also be directed to
the authors:
Alpesh Patel
Cisco Systems
170 W. Tasman Drive,
San Jose, CA 95134
USA
Email: alpesh@cisco.com
Phone: +1 408-853-9580
Kent Leung
Cisco Systems
170 W. Tasman Drive,
San Jose, CA 95134
USA
Expires 13 July 2004 [Page 11]
Internet Draft Authentication Protocol for MIPv6 14 February 2004
Email: kleung@cisco.com
Phone: +1 408-526-5030
Mohamed Khalil
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082
USA
Email: mkhalil@nortelnetworks.com
Phone: +1 972-685-0574
Haseeb Akhtar
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082
USA
Email: haseebak@nortelnetworks.com
Phone: +1 972-684-4732
Kuntal Chowdury
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082
USA
Email: chowdury@nortelnetworks.com
Phone: +1 972-685-7788
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
Expires 13 July 2004 [Page 12]
Internet Draft Authentication Protocol for MIPv6 14 February 2004
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by
the Internet Society.
Expires 13 July 2004 [Page 13]