Network Working Group A. Muhanna
Internet-Draft M. Khalil
Intended status: Informational Nortel
Expires: April 30, 2009 A. Yegin
Samsung
F. Xia
Huawei USA
October 27, 2008
Client MIP6 Binding Revocation Using Auth Option
draft-muhanna-mext-revocation-using-authoption-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 30, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document describes the use of the Authentication Protocol in
protecting binding revocation signaling messages between the home
agent and the mobile node. The home agent uses this mechanism to
revoke a client mobile IPv6 binding cache entry that was created
Muhanna, et al. Expires April 30, 2009 [Page 1]
Internet-Draft Client MIP6 Revocation Using Auth Option October 2008
using Client Mobile IPv6 protocol signaling with authentication
protocol.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3
2.1. Conventions used in this document . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protecting Binding Revocation Signaling Using
Authentication Protocol . . . . . . . . . . . . . . . . . . . 4
3.1. Integrity Protection for Binding Revocation Signaling . . 4
3.2. Replay Protection for Binding Revocation Signaling . . . . 4
4. Binding Revocation Processing . . . . . . . . . . . . . . . . 5
4.1. Home Agent Operation . . . . . . . . . . . . . . . . . . . 5
4.1.1. Home Agent Sending Binding Revocation Indication . . . 5
4.1.2. Home Agent Receiving Binding Revocation
Acknowledgement . . . . . . . . . . . . . . . . . . . 6
4.2. Mobile Node Operation . . . . . . . . . . . . . . . . . . 6
4.2.1. Mobile Node Receiving Binding Revocation Indication . 6
4.2.2. MN Sending Binding Revocation Acknowledgement . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Muhanna, et al. Expires April 30, 2009 [Page 2]
Internet-Draft Client MIP6 Revocation Using Auth Option October 2008
1. Introduction
Binding Revocation for IPv6 Mobility [BCE-Revocation] describe how
Binding Revocation signaling can be used to revoke a mobile node BCE
that was created using Client Mobile IPv6 Protocol [RFC3775], Proxy
Mobile IPv6 protocol [RFC5213], Dual Stack MIP6 protocol [ID-DSMIP6],
or according to Multi Care-of Address protocol [ID-MCoA]. In all of
these protocols, IPsec is the default and main protocol that is used
to protect and secure the IP Mobility header and signaling. In
addition, Binding Revocation for IPv6 Mobility as in
[BCE-Revocation]requires the use of IPsec to protect and secure the
Binding Revocation signaling between the home agent and the mobile
node.
On the other hand, Authentication Protocol for Mobile IPv6 [RFC4285]
defined how the authentication protocol can be used to protect and
secure the Client MIP6 signaling. In some systems the Authentication
Protocol as specified in [RFC4285] has been used for providing Mobile
IPv6 services. In this case, if the home agent needs to revoke a
mobile node BCE, the home agent must have an IPsec SA with the mobile
node to protect the binding revocation signaling messages according
to [BCE-Revocation]. This is quite an impossible task because the
mobile node BCE was created using a security association between the
mobile node and the home agent based on Authentication Protocol.
In order to allow such systems to leverage the benefits of Binding
Revocation mechanism when Client Mobile IPv6 signaling is protected
using Authentication Protocol, there is a need to define how the
binding revocation signaling messages can be secured and protected
using the Authentication Protocol.
This document describe how Binding Revocation signaling messages (BRI
and BRA) is secured and protected using the Authentication Protocol
as in [RFC4285]. This document does not provide any new security
features on the top of those identified and supported in [RFC4285].
Additionally, this document does not propose any modification to the
format and structure of the BRI or BRA messages as described in
[BCE-Revocation].
2. Conventions & Terminology
2.1. Conventions used in this document
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 [RFC2119].
Muhanna, et al. Expires April 30, 2009 [Page 3]
Internet-Draft Client MIP6 Revocation Using Auth Option October 2008
2.2. Terminology
All the general mobility related terminology and abbreviations are to
be interpreted as defined in Mobile IPv6 specification [RFC3775] and
Authentication Protocol for Mobile IPv6 [RFC4285].
3. Protecting Binding Revocation Signaling Using Authentication
Protocol
According to [RFC4285], the mobile node and its home agent will share
a valid MN-HA security association after the exchange of the initial
BU and BA messages. This active MN-HA SA which is based on MN-HA
Mobility Message Authentication Option as described in [RFC4285] will
be used to protect and secure the Binding Revocation messages between
the home agent and the mobile node as described in this document.
The following two subsections describe how the Authentication
Protocol is used to provide integrity protection and replay
protection to the BRI and BRA exchange using MN-HA Authentication and
timestamp options.
3.1. Integrity Protection for Binding Revocation Signaling
In order to provide an integrity protection to the BRI, the home
agent MUST use the MN-HA SA that was used to protect the latest BU/BA
messages between the mobile node and the home agent to build the
MN-HA Mobility Message Authentication Option . The MN-HA Mobility
Message Authentication Option MUST be the last mobility option in the
BRI message in order to provide integrity protection to all of the
BRI message content. The home agent MUST include MN-HA Mobility
Message Authentication Option with the MN-HA SPI that index the MN-HA
SA the mobile node and the home agent share to secure the Client
Mobile IPv6 signaling of the current active binding cache entry.
Similarly, when the mobile node send a BRA message, the mobile node
MUST protect the BRA message using the MN-HA Mobility Message
Authentication Option as the last mobility option in the BRA message.
Additionally, If the timestamp option as described in [RFC4285] is
included in the BRI or BRA message, the MN-HA Mobility Message
Authentication Option must protect the Mobility Message Replay
Protection Option too.
3.2. Replay Protection for Binding Revocation Signaling
In order to protect the BRI and BRA messages against replay attack
the home agent and the mobile node MUST include its current timestamp
in the Mobility Message Replay Protection Option as described in
Muhanna, et al. Expires April 30, 2009 [Page 4]
Internet-Draft Client MIP6 Revocation Using Auth Option October 2008
[RFC4285]. The receiving node will use the included timestamp to
make sure that the message has been sent not later than the allowed
time interval.
4. Binding Revocation Processing
The full details of the use of the Binding Revocation protocol is
defined in [BCE-Revocation]. This document only specifies how to
protect the BRI and BRA messages between the home agent and the
mobile node using Authentication Protocol. If the Mobile Node
Identifier Option for Mobile IPv6 as in [RFC4283] was used in the
exchange of the Client MIP6 BU and BA signaling, the home agent MUST
include this option in the BRI message sent to the mobile node. This
option MUST be protected by the MN-HA Mobility Message Authentication
Option.
4.1. Home Agent Operation
4.1.1. Home Agent Sending Binding Revocation Indication
When an event requires the home agent to terminate a mobile node
mobile IPv6 registration, e.g. for administrative reason, the home
agent sends a Binding Revocation Indication message to the mobile
node to inform the mobile node that its specified binding has been
revoked and it will no longer be able to receive an IP connectivity
via its binding with the home agent.
To terminate a mobile node registration and its current binding with
the home agent, the home agent sends a packet to the mobile node
containing a Binding Revocation Indication, with the packet
constructed as described in [BCE-Revocation] and this specification.
The home agent MUST protect the BRI message using the Authentication
Protocol as follows:
o The home agent MUST include the Mobility Message Replay Protection
Option in the BRI message after setting the timestamp field of
this option to its current timestamp as specified in [RFC4285].
o The packet MUST contain a Home Address destination option, which
contains the mobile node's registered home address for the binding
being revoked.
o The care-of address for the binding SHOULD be used as the Source
Address in the packet's IPv6 header. Additionally, the home agent
MUST include the mobile node current Care-of Address in the
Alternate Care-of Address mobility option and then include the
Muhanna, et al. Expires April 30, 2009 [Page 5]
Internet-Draft Client MIP6 Revocation Using Auth Option October 2008
option in the Binding Revocation Indication.
o The home Agent MUST construct the MN-HA Mobility Message
Authentication Option using the currently active MN-HA SA as
defined in [RFC4285] and ensure that this option is the last
mobility option in the BRI message.
4.1.2. Home Agent Receiving Binding Revocation Acknowledgement
When the home agent receives a packet carrying a BRA for an
outstanding BRI message that belongs to a Mobile node that is secure
using Authentication Protocol, the home SHOULD examine the BRA as
follows:
o The home agent MUST validate the authentication data of the MN-HA
Mobility Message Authentication Option using the MN-HA SA that is
indexed using the MN-HA SPI as defined in [RFC4285].
o If the validation of the MN-HA Mobility Message Authentication
Option is successful, the home agent MUST validate the timestamp
in the Mobility Message Replay Protection Option before accepting
the BRA as a valid message.
o If the validation of the MN-HA Mobility Message Authentication
Option is NOT successful, the home agent MUST discard the BRA
message and MAY log an event.
4.2. Mobile Node Operation
4.2.1. Mobile Node Receiving Binding Revocation Indication
Upon receiving a packet carrying a Binding Revocation Indication that
include the MN-HA Mobility Message Authentication Option, the mobile
node MUST identify the MN-HA SA that it shares with the home agent
and then validate the authentication data as in [RFC4285].
If the MN-HA Mobility Message Authentication Option validation is
successful, the mobile node MUST validate the timestamp in the
Mobility Message Replay Protection Option.
If the MN-HA Mobility Message Authentication Option validation is
successful, the mobile node MUST ensure that the Alternate Care-of
Address option and the home destination option are included in the
BRI and protected by the MN-HA Mobility Message Authentication
Option.
Muhanna, et al. Expires April 30, 2009 [Page 6]
Internet-Draft Client MIP6 Revocation Using Auth Option October 2008
If the MN-HA Mobility Message Authentication Option validation is
successful and the Alternate Care-of Address option is not included
in the BRI message, the MN MUST send a BRA message with status code,
Session Unknown.
If the MN-HA Mobility Message Authentication Option validation is
successful and the Home Destination Option is not included in the BRI
message, the MN MUST send a BRA message with a status code, Session
Unknown.
If the MN-HA Mobility Message Authentication Option validation
failed, the mobile node MUST discard the BRI message.
4.2.2. MN Sending Binding Revocation Acknowledgement
When the mobile node receive a BRI message which successfully
validated and the mobile node has an active BCE for the specified
binding, the mobile node MUST send a BRA message with a status code
'SUCCESS' following [BCE-Revocation] and this specification.
The mobile node MUST protect the BRA message using the Authentication
Protocol as follows:
o The mobile node MUST include the Mobility Message Replay
Protection Option in the BRI message after setting the timestamp
field of this option to its current timestamp as specified in
[RFC4285].
o The home Agent MUST construct the MN-HA Mobility Message
Authentication Option using the currently active MN-HA SA as
defined in [RFC4285] and ensure that this option is the last
mobility option in the BRI message.
5. IANA Considerations
This document does not have any IANA requirements.
6. Security Considerations
This document uses the same security mechanism as defined in the
Authentication Protocol for Mobile IPv6 in [RFC4285]. However, this
document require that the care-of address and the home address which
have been assigned to the mobile node during the Client MIP6
registration MUST be included in the BRI message and protected by the
MN-HA Mobility Message Authentication Option.
Muhanna, et al. Expires April 30, 2009 [Page 7]
Internet-Draft Client MIP6 Revocation Using Auth Option October 2008
7. Acknowledgements
The author would like to thank the folks involved in the discussion
on the MEXT mailing list on the topic of protecting Binding
Revocation Messages using authentication protocol.
8. References
8.1. Normative References
[BCE-Revocation]
Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K.,
and P. Yegani, "Binding Revocation for IPv6 Mobility",
draft-ietf-mext-binding-revocation-01 (work in progress),
August 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
(MIPv6)", RFC 4283, November 2005.
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Authentication Protocol for Mobile IPv6",
RFC 4285, January 2006.
8.2. Informative References
[ID-DSMIP6]
Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", draft-ietf-mext-nemo-v4traversal-04 (work in
progress), June 2008.
[ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-08 (work in progress),
May 2008.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
Muhanna, et al. Expires April 30, 2009 [Page 8]
Internet-Draft Client MIP6 Revocation Using Auth Option October 2008
Authors' Addresses
Ahmad Muhanna
Nortel
2221 Lakeside Blvd.
Richardson, TX 75082
USA
Email: amuhanna@nortel.com
Mohamed Khalil
Nortel
2221 Lakeside Blvd.
Richardson, TX 75082
USA
Email: mkhalil@nortel.com
Alper E. Yegin
Samsung
Istanbul,
Turkey
Email: a.yegin@partner.samsung.com
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
USA
Email: xiayangsong@huawei.com
Muhanna, et al. Expires April 30, 2009 [Page 9]
Internet-Draft Client MIP6 Revocation Using Auth Option October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Muhanna, et al. Expires April 30, 2009 [Page 10]