draft-ietf-mip6-precfgkbm-03.txt   draft-ietf-mip6-precfgkbm-04.txt 
IETF Mobile IP Working Group Charles E. Perkins IETF Mobile IP Working Group Charles E. Perkins
INTERNET-DRAFT Nokia Research Center INTERNET-DRAFT Nokia Research Center
30 June 2005 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-03.txt> <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 is a submission by the IETF MIPv6 Working Group Working
Group of the Internet Engineering Task Force (IETF). Comments should Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the mip6@ietf.org mailing list. be submitted to the mip6@ietf.org mailing list.
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note Task Force (IETF), its areas, and its working groups. Note
that other groups may also distribute working documents as that other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
skipping to change at page 1, line 60 skipping to change at page 1, line 58
periodic return routability test to verify both the "right" of periodic return routability test to verify both the "right" of
the mobile node to a use a specific home address, as well as the the mobile node to a use a specific home address, as well as the
validity of the claimed care-of address. This mechanism requires no validity of the claimed care-of address. This 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 configuration of a shared secret between mobile node and the configuration of a shared secret between mobile node and
its correspondent node. As a result, messages relating to the its 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 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 assured 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 pre-configuration. 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 to not misbehave, as the
validity of the claimed care-of addresses is not verified. validity of the claimed care-of addresses is not verified.
2. Precomputing a Binding Management Key (Kbm) 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]. Other
terminology is used as already defined in [1].
2. Applicability Statement
This mechanism is useful in scenarios where the following conditions
are all met:
- Mobile node and correspondent node are administered within the
same domain.
- The correspondent node has good reason to trust the actions of
the mobile node. In particular, the correspondent node needs to
be certain that the mobile node will not launch flooding attacks
against a third party as described in [5].
- The configuration effort related to this mechanism is acceptable.
Users MUST be able to generate/select a sufficiently good value
for Kcn (see [3])
- There is a desire to take advantage of higher efficiency or
greater assurance with regards to the correctness of the home
address offered via this mechanism.
- This mechanism is used only for authenticating Binding Update
messages (and not e.g., data) so the total volume of traffic is
low (see RFC 4107 [4], and the discussion in section 4).
This mechanism can also be useful in software development, testing,
and diagnostics related to mobility signaling.
Generally speaking, the required level of trust that the
correspondent node needs for enabling a precomputable Kbm with a
mobile node is more often found within relatively small, closed
groups of users who are personally familiar with each other,
or who have some external basis for establishing trustworthy
interactions. A typical example scenario where this mechanism is
applicable is within a corporation, or between specific users.
Application in the general Internet use is typically not possible
due to the configuration effort. Application at a public network
operator is typically not possible due to requirements placed on the
trustworthiness of mobile nodes.
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
octets long octets long
- A nonce for use when generating the care-of keygen token - A nonce for use when generating the care-of keygen token
- 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]).
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 towards an old care-of address. For this reason, a correspondent
node that uses a precomputable Kbm also MUST keep track of the most node that uses a precomputable Kbm also MUST keep track of the most
recent value of the Sequence Number field of Binding Update messages recent value of the Sequence Number field of Binding Update messages
using the precomputable Kbm value. using the precomputable Kbm value (for example, by committing it to
stable 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 suboption MUST be present. The Nonce Indices option SHOULD NOT be
be present. If it is present, the nonce indices supplied MAY 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 carried exactly as specified
in [1]. in [1].
3. Applicability Statement
This mechanism is useful in scenarios where the following conditions
are all met:
- Mobile node and correspondent node are administered within the
same domain.
- The correspondent node has good reason to trust the actions of
the mobile node. In particular, the correspondent node needs to
be certain that the mobile node will not launch flooding attacks
against a third party as described in [2].
- The configuration effort related to this mechanism is acceptable.
- There is a desire to take advantage of higher efficiency or
greater assurance with regards to the correctness of the home
address offered via this mechanism.
This mechanism can also be useful in software development, testing,
and diagnostics related to mobility signaling.
Generally speaking, the required level of trust that the
correspondent node needs for enabling a precomputable Kbm with a
mobile node is more often found within relatively small, closed
groups of users who are personally familiar with each other,
or who have some external basis for establishing trustworthy
interactions. A typical example scenario where this mechanism is
applicable is within a corporation, or between specific users.
Application in the general Internet use is typically not possible
due to the configuration effort. Application at a public network
operator is typically not possible due to requirements placed on the
trustworthiness of mobile nodes.
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 [2]. outlined in [5]. Many requirements listed in this document are
intended to insure the safety of the manual configuration. In
particular, Kcn MUST be generated with sufficient randomness (see RFC
4086 [3]).
Manually configured keys MUST be used in conformance with RFC
4107 [4]. Used according to the applicability statement, and with
the other security measures mandated in this specification, the
keys will satisfy the properties in that document. In order to
assure protection against dictionary attacks, the configured security
information is intended to be used ONLY for authenticating Binding
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 Binding Update List, and a correspondent node MUST ensure that its Binding Update List, and a correspondent node MUST ensure that
every mobile node uses a different value of Kcn. This ensures that every mobile node uses a different value of Kcn. This ensures that
the sender of a Binding Update can always be uniquely determined. the sender of a Binding Update can always be uniquely determined.
This is necessary, as this authorization method does not provide any This 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 reason, this method SHOULD only be applied between nodes that same reason, this method SHOULD only be applied between nodes that
are under the same administration. The return routability procedure are under the same administration. The return routability procedure
is RECOMMENDED for all general use and MUST be the default, unless is RECOMMENDED for all general use and MUST be the default, unless
skipping to change at page 4, line 11 skipping to change at page 4, line 33
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 claims to not support the mechanism in this document. This is or claims to not 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 3. specified in section 2.
5. IANA Considerations 5. IANA Considerations
No new protocol numbers are required. No new protocol numbers are required.
6. Acknowledgement 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 References
[1] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6. [1] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in
Request for Comments (Proposed Standard), Internet Engineering IPv6. Request for Comments (Proposed Standard) 3775, Internet
Task Force, July 2004. Engineering Task Force, July 2004.
[2] P. Nikander, T. Aura, J. Arkko, G. Montenegro, and E. Nordmark. [2] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[3] D. Eastlake, 3rd, J. Schiller, and S. Crocker. Randomness
Requirements for Security. Request for Comments (Proposed
Standard) 4086, Internet Engineering Task Force, June 2005.
[4] S. Bellovin and R. Housley. Guidelines for Cryptographic Key
Management. Request for Comments (Proposed Standard) 4107,
Internet Engineering Task Force, June 2005.
[5] P. Nikander, T. Aura, J. Arkko, G. Montenegro, and E. Nordmark.
Mobile IP version 6 Route Optimization Security Design Mobile IP version 6 Route Optimization Security Design
Background. Internet Draft, Internet Engineering Task Force, Background. Internet Draft, Internet Engineering Task Force,
June 2003. June 2003.
The first citation is normative, and the second citation is The first four citations are normative, and the fifth citation is
informative only. informative only.
Intellectual Property Statement Intellectual Property Statement
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
 End of changes. 15 change blocks. 
55 lines changed or deleted 89 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/