draft-ietf-mip6-precfgkbm-02.txt   draft-ietf-mip6-precfgkbm-03.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
21 May 2005 30 June 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-02.txt> <draft-ietf-mip6-precfgkbm-03.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 This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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 present. If it is present, the nonce indices supplied MAY be be present. If it is present, the nonce indices supplied MAY 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 3. Applicability Statement
Preconfigured shared keys (such as Kcn) between a mobile node and a This mechanism is useful in scenarios where the following conditions
correspondent node are useful in several specific scenarios: are all met:
- mobile node and correspondent node are administered within the - Mobile node and correspondent node are administered within the
same domain, and the correspondent node has good reason to trust same domain.
the actions of the mobile node
- the correspondent node has some guarantee that the mobile node - The correspondent node has good reason to trust the actions of
will behave properly (perhaps by contractual agreement) 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 method of assignment for keys between the correspondent node - The configuration effort related to this mechanism is acceptable.
and mobile node results in a stronger security association than
what can be provided by the Return Routability procedure.
- diagnostic procedures - 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.
- software development and testing 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 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, or who groups of users who are personally familiar with each other,
have some external basis for establishing trustworthy interactions. 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 [2].
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
skipping to change at page 3, line 37 skipping to change at page 3, line 49
SHOULD configure a new value for Kcn, so that new Kbm values will be SHOULD 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. In order to circumvent this possibility,
correspondent nodes are mandated to keep track of the most recent correspondent nodes SHOULD keep track of the most recent Sequence
Sequence Number value in a Binding Update message from the mobile Number value in a Binding Update message from the mobile node.
node.
Note that where a node has been configured to use the mechanism
specified in this document with a particular peer, it SHOULD NOT
attempt to use another mechanism, even if the peer requests this
or claims to not support the mechanism in this document. This is
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 3.
5. IANA Considerations 5. IANA Considerations
No new protocol numbers are required. No new protocol numbers are required.
 End of changes. 

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