draft-ietf-mip6-precfgkbm-04.txt   rfc4449.txt 
IETF Mobile IP Working Group Charles E. Perkins Network Working Group C. Perkins
INTERNET-DRAFT Nokia Research Center Request for Comments: 4449 Nokia Research Center
20 October 2005
Securing Mobile IPv6 Route Optimization Using a Static Shared Key Securing Mobile IPv6 Route Optimization Using a Static Shared Key
<draft-ietf-mip6-precfgkbm-04.txt>
Status of This Memo Status of This Memo
This document is a submission by the IETF MIPv6 Working Group Working This document specifies an Internet standards track protocol for the
Group of the Internet Engineering Task Force (IETF). Comments should Internet community, and requests discussion and suggestions for
be submitted to the mip6@ietf.org mailing list. improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
By submitting this Internet-Draft, each author represents that any and status of this protocol. Distribution of this memo is unlimited.
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 Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2006).
http://www.ietf.org/shadow.html.
Abstract Abstract
A mobile node and a correspondent node may preconfigure data useful A mobile node and a correspondent node may preconfigure data useful
for precomputing a Binding Management Key that can subsequently be for precomputing a Binding Management Key that can subsequently be
used for authorizing Binding Updates. used for authorizing Binding Updates.
Table of Contents
1. Introduction ....................................................1
2. Applicability Statement .........................................2
3. Precomputing a Binding Management Key (Kbm) .....................3
4. Security Considerations .........................................4
5. Acknowledgement .................................................5
6. References ......................................................5
6.1. Normative References .......................................5
6.2. Informative References .....................................6
1. Introduction 1. Introduction
This specification introduces an alternative, low-latency security This specification introduces an alternative, low-latency security
mechanism for protecting signaling related to the route optimization mechanism for protecting signaling related to the route optimization
in Mobile IPv6. The default mechanism specified in [1] uses a in Mobile IPv6. The default mechanism specified in [1] uses a
periodic return routability test to verify both the "right" of periodic return routability test to verify both the "right" of the
the mobile node to a use a specific home address, as well as the mobile node to use a specific home address, as well as the validity
validity of the claimed care-of address. This mechanism requires no of the claimed care-of address. That mechanism requires no
configuration and no trusted entities beyond the mobile node's home configuration and no trusted entities beyond the mobile node's home
agent. agent.
The mechanism specified in this document, however, requires The mechanism specified in this document, however, requires the
the configuration of a shared secret between mobile node and configuration of a shared secret between mobile node and its
its correspondent node. As a result, messages relating to the correspondent node. As a result, messages relating to the
routability tests can be omitted, leading to significantly smaller routability tests can be omitted, leading to significantly smaller
latency. In addition, the right to use a specific home address is latency. In addition, the right to use a specific home address is
assured in a stronger manner than in [1]. On the other hand, the ensured in a stronger manner than in [1]. On the other hand, the
applicability of this mechanisms is limited due to the need for applicability of this mechanisms is limited due to the need for
pre-configuration. This mechanism is also limited to use only in preconfiguration. This mechanism is also limited to use only in
scenarios where mobile nodes can be trusted to not misbehave, as the scenarios where mobile nodes can be trusted not to misbehave, as the
validity of the claimed care-of addresses is not verified. validity of the claimed care-of addresses is not verified.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2]. Other document are to be interpreted as described in RFC 2119 [2]. Other
terminology is used as already defined in [1]. terminology is used as already defined in [1].
2. Applicability Statement 2. Applicability Statement
This mechanism is useful in scenarios where the following conditions This mechanism is useful in scenarios where the following conditions
skipping to change at page 2, line 6 skipping to change at page 2, line 43
- The configuration effort related to this mechanism is acceptable. - The configuration effort related to this mechanism is acceptable.
Users MUST be able to generate/select a sufficiently good value Users MUST be able to generate/select a sufficiently good value
for Kcn (see [3]) for Kcn (see [3])
- There is a desire to take advantage of higher efficiency or - There is a desire to take advantage of higher efficiency or
greater assurance with regards to the correctness of the home greater assurance with regards to the correctness of the home
address offered via this mechanism. address offered via this mechanism.
- This mechanism is used only for authenticating Binding Update - This mechanism is used only for authenticating Binding Update
messages (and not e.g., data) so the total volume of traffic is messages (and not, e.g., data), so the total volume of traffic is
low (see RFC 4107 [4], and the discussion in section 4). low (see RFC 4107 [4], and the discussion in section 4).
This mechanism can also be useful in software development, testing, This mechanism can also be useful in software development, testing,
and diagnostics related to mobility signaling. and diagnostics related to mobility signaling.
Generally speaking, the required level of trust that the Generally speaking, the required level of trust that the
correspondent node needs for enabling a precomputable Kbm with a correspondent node needs for enabling a precomputable Kbm with a
mobile node is more often found within relatively small, closed mobile node is more often found within relatively small, closed
groups of users who are personally familiar with each other, groups of users who are personally familiar with each other, or who
or who have some external basis for establishing trustworthy have some external basis for establishing trustworthy interactions.
interactions. A typical example scenario where this mechanism is A typical example scenario where this mechanism is applicable is
applicable is within a corporation, or between specific users. within a corporation, or between specific users. Application in the
Application in the general Internet use is typically not possible general Internet is typically not possible due to the effort that is
due to the configuration effort. Application at a public network required to manually configure the correspondent nodes. Application
operator is typically not possible due to requirements placed on the at a public network operator is typically not possible due to
trustworthiness of mobile nodes. requirements placed on the trustworthiness of mobile nodes.
3. Precomputing a Binding Management Key (Kbm) 3. Precomputing a Binding Management Key (Kbm)
A mobile node and a correspondent node may preconfigure data useful A mobile node and a correspondent node may preconfigure data useful
for creating a Binding Management Key (Kbm), which can then be used for creating a Binding Management Key (Kbm), which can then be used
for authorizing binding management messages, especially Binding for authorizing binding management messages, especially Binding
Update and Binding Acknowledgement messages. This data is as Update and Binding Acknowledgement messages. This data is as
follows: follows:
- A shared key (Kcn) used to generate keygen tokens, at least 20 - A shared key (Kcn) used to generate keygen tokens, at least 20
skipping to change at page 2, line 47 skipping to change at page 3, line 35
- A nonce for use when generating the home keygen token - A nonce for use when generating the home keygen token
The keygen tokens MUST be generated from Kcn and the nonces as The keygen tokens MUST be generated from Kcn and the nonces as
specified in Mobile IPv6 [1] return routability. Likewise, the specified in Mobile IPv6 [1] return routability. Likewise, the
binding management key Kbm must subsequently be generated from the binding management key Kbm must subsequently be generated from the
keygen tokens in the same way as specified in Mobile IPv6 [1]. The keygen tokens in the same way as specified in Mobile IPv6 [1]. The
preconfigured data is associated to the mobile node's home address. preconfigured data is associated to the mobile node's home address.
Kcn MUST be generated with sufficient randomness (see RFC 4086 [3]). Kcn MUST be generated with sufficient randomness (see RFC 4086 [3]).
Replay protection for Binding Update messages using Kbm computed from Replay protection for Binding Update messages using Kbm computed from
the preconfigured data depends upon the value of the sequence number the preconfigured data depends upon the value of the Sequence Number
field in the Binding Update. If the correspondent node does not field in the Binding Update. If the correspondent node does not
maintain information about the recently used values of that field, maintain information about the recently used values of that field,
then there may be an opportunity for a malicious node to replay old then there may be an opportunity for a malicious node to replay old
Binding Update messages and fool the correspondent node into routing Binding Update messages and fool the correspondent node into routing
towards an old care-of address. For this reason, a correspondent toward an old care-of address. For this reason, a correspondent node
node that uses a precomputable Kbm also MUST keep track of the most that uses a precomputable Kbm also MUST keep track of the most recent
recent value of the Sequence Number field of Binding Update messages value of the Sequence Number field of Binding Update messages using
using the precomputable Kbm value (for example, by committing it to the precomputable Kbm value (for example, by committing it to stable
stable storage). storage).
When a Binding Update is to be authenticated using such a When a Binding Update is to be authenticated using such a
precomputable binding key (Kbm), the Binding Authorization Data precomputable binding key (Kbm), the Binding Authorization Data
suboption MUST be present. The Nonce Indices option SHOULD NOT be suboption MUST be present. The Nonce Indices option SHOULD NOT be
present. If it is present, the nonce indices supplied SHOULD be present. If it is present, the nonce indices supplied SHOULD be
ignored and are not included as part of the calculation for the ignored and are not included as part of the calculation for the
authentication data, which is to be carried exactly as specified authentication data, which is to be performed exactly as specified in
in [1]. [1].
4. Security Considerations 4. Security Considerations
A correspondent node and a mobile node may use a precomputable A correspondent node and a mobile node may use a precomputable
binding management key (Kbm) to manage the authentication binding management key (Kbm) to manage the authentication
requirements for binding cache management messages. Such keys must requirements for binding cache management messages. Such keys must
be handled carefully to avoid inadvertent exposure to the threats be handled carefully to avoid inadvertent exposure to the threats
outlined in [5]. Many requirements listed in this document are outlined in [5]. Many requirements listed in this document are
intended to insure the safety of the manual configuration. In intended to ensure the safety of the manual configuration. In
particular, Kcn MUST be generated with sufficient randomness (see RFC particular, Kcn MUST be generated with sufficient randomness (see RFC
4086 [3]). 4086 [3]), as noted in Section 3.
Manually configured keys MUST be used in conformance with RFC Manually configured keys MUST be used in conformance with RFC 4107
4107 [4]. Used according to the applicability statement, and with [4]. Used according to the applicability statement, and with the
the other security measures mandated in this specification, the other security measures mandated in this specification, the keys will
keys will satisfy the properties in that document. In order to satisfy the properties in that document. In order to ensure
assure protection against dictionary attacks, the configured security protection against dictionary attacks, the configured security
information is intended to be used ONLY for authenticating Binding information is intended to be used ONLY for authenticating Binding
Update messages. Update messages.
A mobile node MUST use a different value for Kcn for each node in A mobile node MUST use a different value for Kcn for each node in its
its Binding Update List, and a correspondent node MUST ensure that Binding Update List, and a correspondent node MUST ensure that every
every mobile node uses a different value of Kcn. This ensures that mobile node uses a different value of Kcn. This ensures that the
the sender of a Binding Update can always be uniquely determined. sender of a Binding Update can always be uniquely determined. This
This is necessary, as this authorization method does not provide any is necessary, as this authorization method does not provide any
guarantee that the given care-of address is legitimate. For the guarantee that the given care-of address is legitimate. For the same
same reason, this method SHOULD only be applied between nodes that reason, this method SHOULD only be applied between nodes that are
are under the same administration. The return routability procedure under the same administration. The return routability procedure is
is RECOMMENDED for all general use and MUST be the default, unless RECOMMENDED for all general use and MUST be the default, unless the
the user explicitly overrides this by entering the aforementioned user explicitly overrides this by entering the aforementioned
preconfigured data for a particular peer. preconfigured data for a particular peer.
Replay protection for the Binding Authorization Data option Replay protection for the Binding Authorization Data option
authentication mechanism is provided by the Sequence Number field authentication mechanism is provided by the Sequence Number field of
of the Binding Update. This method of providing replay protection the Binding Update. This method of providing replay protection fails
fails when the Binding Update sequence numbers cycle through the 16 when the Binding Update sequence numbers cycle through the 16 bit
bit counter (i.e., not more than 65,536 distinct uses of Kbm), or counter (i.e., not more than 65,536 distinct uses of Kbm), or if the
if the sequence numbers are not protected against reboots. If the sequence numbers are not protected against reboots. If the mobile
mobile node were to send a fresh Binding Update to its correspondent node were to send a fresh Binding Update to its correspondent node
node every hour, 24 hours a day, every day of the year, this would every hour, 24 hours a day, every day of the year, this would require
require changing keys every 7 years. Even if the mobile node were to changing keys every 7 years. Even if the mobile node were to do so
do so every minute, this would provide protection for over a month. every minute, this would provide protection for over a month. Given
Given typical mobility patterns, there is little danger of replay typical mobility patterns, there is little danger of replay problems;
problems; nodes for which problems might arise are expected to use nodes for which problems might arise are expected to use methods
methods other than manual configuration for Kcn and the associated other than manual configuration for Kcn and the associated nonces.
nonces. When the sequence number field rolls over, the parties When the Sequence Number field rolls over, the parties SHOULD
SHOULD configure a new value for Kcn, so that new Kbm values will be configure a new value for Kcn, so that new Kbm values will be
computed. computed.
If a correspondent node does NOT keep track of the Sequence Number If a correspondent node does NOT keep track of the sequence number
for Binding Update messages from a particular mobile node, then the for Binding Update messages from a particular mobile node, then the
correspondent node could be fooled into accepting an old value for correspondent node could be fooled into accepting an old value for
the mobile node's care-of address. In the unlikely event that this the mobile node's care-of address. In the unlikely event that this
address was reallocated to another IPv6 node in the meantime, that address was reallocated to another IPv6 node in the meantime, that
IPv6 node would then be vulnerable to unwanted traffic emanating from IPv6 node would then be vulnerable to unwanted traffic emanating from
the correspondent node. In order to circumvent this possibility, the correspondent node.
correspondent nodes SHOULD keep track of the most recent Sequence
Number value in a Binding Update message from the mobile node.
Note that where a node has been configured to use the mechanism Note that where a node has been configured to use the mechanism
specified in this document with a particular peer, it SHOULD NOT specified in this document with a particular peer, it SHOULD NOT
attempt to use another mechanism, even if the peer requests this attempt to use another mechanism, even if the peer requests this or
or claims to not support the mechanism in this document. This is claims not to support the mechanism in this document. This is
necessary in order to prevent bidding down attacks. necessary in order to prevent bidding down attacks.
There is no upper bound on the lifetime defined for the precomputable There is no upper bound on the lifetime defined for the precomputable
Kbm. As noted, the key is very likely to be quite secure over the Kbm. As noted, the key is very likely to be quite secure over the
lifetime of the security association and usefulness of applications lifetime of the security association and usefulness of applications
between a mobile node and correspondent node that fit the terms between a mobile node and correspondent node that fit the terms
specified in section 2. specified in section 2.
5. IANA Considerations 5. Acknowledgement
No new protocol numbers are required.
6. Acknowledgement
Thanks are due to everyone who reviewed the discussion of issue #146. Thanks are due to everyone who reviewed the discussion of issue #146.
Thanks to Jari Arkko for supplying text for the Introduction. Thanks to Jari Arkko for supplying text for the Introduction.
References 6. References
[1] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in 6.1. Normative References
IPv6. Request for Comments (Proposed Standard) 3775, Internet
Engineering Task Force, July 2004.
[2] S. Bradner. Key words for use in RFCs to Indicate Requirement [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
Levels. Request for Comments (Best Current Practice) 2119, IPv6", RFC 3775, June 2004.
Internet Engineering Task Force, March 1997.
[3] D. Eastlake, 3rd, J. Schiller, and S. Crocker. Randomness [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Requirements for Security. Request for Comments (Proposed Levels", BCP 14, RFC 2119, March 1997.
Standard) 4086, Internet Engineering Task Force, June 2005.
[4] S. Bellovin and R. Housley. Guidelines for Cryptographic Key [3] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness
Management. Request for Comments (Proposed Standard) 4107, Requirements for Security", BCP 106, RFC 4086, June 2005.
Internet Engineering Task Force, June 2005.
[5] P. Nikander, T. Aura, J. Arkko, G. Montenegro, and E. Nordmark. [4] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key
Mobile IP version 6 Route Optimization Security Design Management", BCP 107, RFC 4107, June 2005.
Background. Internet Draft, Internet Engineering Task Force,
June 2003.
The first four citations are normative, and the fifth citation is 6.2. Informative References
informative only.
Intellectual Property Statement [5] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security Design
Background", RFC 4226, December 2005.
Author's Address
Charles E. Perkins
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043
USA
Phone: +1 650 625-2986
Fax: +1 650 625-2502
EMail: charles.perkins@nokia.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the attempt made to obtain a general license or permission for the use of
use of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
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.
Author's Address
Questions about this document can also be directed to the author:
Charles E. Perkins
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043
USA
Phone: +1 650 625-2986 Funding for the RFC Editor function is provided by the IETF
Fax: +1 650 625-2502 Administrative Support Activity (IASA).
E-mail: charles.perkins@nokia.com
 End of changes. 35 change blocks. 
142 lines changed or deleted 129 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/