Internet DRAFT - draft-narayanan-mipshop-mn-ar-auth-option
draft-narayanan-mipshop-mn-ar-auth-option
Mipshop N. Venkitaraman
Internet-Draft V. Narayanan
Expires: April 17, 2006 Motorola
October 14, 2005
Mobile Node-Access Router Authentication Option
draft-narayanan-mipshop-mn-ar-auth-option-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 April 17, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
FMIPv6 [4] requires signalling messages to be exchanged between a
mobile node and its access router. For secure interaction, these
messages must be authenticated using a security association between
the access router and the mobile node. To enable the mobile node and
the access router unambiguously identify the correct security
association this document extends the mobility header authentication
option by defining a subtype to indicate a mobile node - access
router SPI. Also, this option can be used in signaling messages used
Venkitaraman & Narayanan Expires April 17, 2006 [Page 1]
Internet-Draft MN-AR Auth Option October 2005
to derive handover keys between the MN and AR, as described in HK_AAA
[5]. The idea here is to re-use the existing mobility option for
authentication and only define an additional sub-type for MN-AR
authentication.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. MN-AR Authentication Mobility Option . . . . . . . . . . . . . 4
4.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Processing Considerations . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Venkitaraman & Narayanan Expires April 17, 2006 [Page 2]
Internet-Draft MN-AR Auth Option October 2005
1. Introduction
Fast Handovers for MIPv6 [4] specifies a protocol to improve handover
latency due to Mobile IPv6 procedures by enabling a mobile node bind
its CoA with its previous Access Router via a Fast Binding Update
(FBU) message. To enable the PAR determine that the FBU is generated
by a genuine MN the FBU message must be protected. Mechanisms to
create a shared key between the MN and the AR have been proposed in
HK_AAA [5] and HK_SEND [6]. This document specifies a means of
securing the FBU using shared keys that exist between the MN and PAR
using a MN-AR authentication option. It extends the mobility message
authentication option defined in [MIP6_Auth] by defining a subtype to
indicate a mobile node - access router Security Association. The
authentication option enables the mobile node and access router to
transfer authentication data and utilize an SPI to index between
multiple MN-AR security associations. The option defined in this
document is also used in HK_AAA [5] to exchange the SPI and secure
MN-AR communication as applicable.
2. Terminology
The key words "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 [1].
In addition, this document uses the following terms:
MN-AR Mobility Security Association
Security relation between Mobile Node and its Access Router, used
to authenticate the Mobile Node for mobility service. The MN-AR
Security Association between Mobile Node and Access Router
consists of a MN-AR mobility SPI, a shared-key, an authentication
algorithm and the replay protection mechanism in use.
MN-AR Mobility SPI A number in the range [0-4294967296] used to index
into the shared-key based MN-AR security associations to protect
mobility messages.
3. Applicability
The MN-AR Authentication Mobility Option is expected to be used in
FMIPv6 for securing the Fast Binding Update between the MN and the
old AR. Also, this option is used in securing the MN-AR Handover Key
Request/Response messages between the MN and AR in the proposed AAA-
based handover key derivation model, as described in HK_AAA [5].
Venkitaraman & Narayanan Expires April 17, 2006 [Page 3]
Internet-Draft MN-AR Auth Option October 2005
This document itself does not provide guidelines on the exact usage
of this option in these protocols. The exact usage of this option
for an applicable protocol is expected to be defined as part of the
appropriate protocol specification. This document only defines the
type and values for the option itself.
4. MN-AR Authentication Mobility Option
This section defines a subtype for the message authentication
mobility option defined in MIP6_AUTH [2]. The assumption is that
Mobile Node has a shared-key based security association with the
Access Router.
4.1. Format
The format of the MN-AR authentication mobility option is as defined
in Figure 2 in [MIP6_Auth]. It has been reproduced here only for
ease of reference.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-AR Mobility SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MN-AR Authentication Option
The MN-AR authentication mobility option uses the subtype value of 3.
This option should be used to authenticate the Fast Binding Update
and Fast Binding Acknowledgement messages in FMIPv6 [4] when a
shared-key based security association exists between the Mobile Node
and the Access Router. Also, this option should be used in securing
the Handover Key Request and Response messages described in HK_AAA
[5].
This MUST be the last option in a message with mobility header if it
is the only authentication option in the message.
The authentication data is calculated on the message starting from
the mobility header up to and including the mobility SPI value of
this option.
Venkitaraman & Narayanan Expires April 17, 2006 [Page 4]
Internet-Draft MN-AR Auth Option October 2005
Authentication Data = First (96, HMAC_SHA1(MN-AR Shared key, Mobility
Data))
Mobility Data = care-of address | home address | Mobility Header(MH)
Data
MH Data is the content of the Mobility Header up to and including the
mobility SPI field of this option. The Checksum field in Mobility
Header MUST be set to 0 to calculate the Mobility Data.
The first 96 bits from the MAC result are used as the Authentication
Data field.
4.2. Processing Considerations
The Mobile Node should include this option in to secure messages
exchanged with an access router, if it has a shared-key based
mobility security association with the Access Router. While
including this option the Mobile Node SHOULD use the Mobile Node
Identifier Option, specifically the MN-NAI mobility option as defined
in MN_ID_OPT [3] to identify itself while authenticating with the
Access Router.
Mobile Node MAY use Message Identifier option as defined in MIP6_AUTH
[2] for additional replay protection.
The Access Router should include this option in to secure messages
exchanged with a mobile node, if it has a shared-key based mobility
security association with the Mobile Node.
The Mobile Node or Access Router receiving this option MUST verify
the authentication data in the option. If authentication fails, the
Access Router MUST send an error to the other entity. The Access
Router Agent MAY log such events.
The detailed processing rules for messages that contain this option
will be defined by the documents specifying the corresponding
messages. For instance, the use of this option in FMIPv6 will be
defined in the protocol specification for FMIPv6.
5. Security Considerations
This document assumes the existence of a shared key between the
Mobile Node and the Access Router. It proposes new authentication
options to authenticate the control message between Mobile Node and
an Access Router. Given that this option is based on the
authentication protocol defined in MIP6_AUTH [2], any security
Venkitaraman & Narayanan Expires April 17, 2006 [Page 5]
Internet-Draft MN-AR Auth Option October 2005
considerations that apply to the authentication protocol also apply
to this option.
6. IANA Considerations
IANA services are required for this specification. The value for
MN-AR authentication mobility option must be assigned.
7. Acknowledgments
The authors would like to acknowledge that
draft-perkins-mobileip-spi-00 described the use of an SPI option for
Mobile IP.
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Patel, A., "Authentication Protocol for Mobile IPv6",
draft-ietf-mip6-auth-protocol-07 (work in progress),
September 2005.
[3] Patel, A., "Mobile Node Identifier Option for MIPv6",
draft-ietf-mip6-mn-ident-option-03 (work in progress),
September 2005.
8.2. Informative References
[4] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[5] Narayanan, V., "Handover Keys using AAA",
draft-vidya-mipshop-handover-keys-aaa-01 (work in progress),
October 2005.
[6] Kempf, J., "Bootstrapping a Symmetric IPv6 Handover Key from
SEND", draft-kempf-mobopts-handover-key-01 (work in progress),
July 2005.
Venkitaraman & Narayanan Expires April 17, 2006 [Page 6]
Internet-Draft MN-AR Auth Option October 2005
Authors' Addresses
Narayanan Venkitaraman
Motorola
1301 E. Algonquin Road
Schaumburg, IL 60196
US
Email: narayanan.venkitaraman@motorola.com
Vidya Narayanan
Motorola
1301 E. Algonquin Road
Schaumburg, IL 60196
US
Email: vidya@motorola.com
Venkitaraman & Narayanan Expires April 17, 2006 [Page 7]
Internet-Draft MN-AR Auth Option October 2005
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 (2005). 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.
Venkitaraman & Narayanan Expires April 17, 2006 [Page 8]
