draft-ietf-mip6-precfgkbm-01.txt   draft-ietf-mip6-precfgkbm-02.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 October 2004 21 May 2005
Precomputable Binding Management Key Kbm for Mobile IPv6 Securing Mobile IPv6 Route Optimization Using a Static Shared Key
<draft-ietf-mip6-precfgkbm-01.txt> <draft-ietf-mip6-precfgkbm-02.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
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she becomes aware will be disclosed, in accordance with
RFC 3668. 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 45 skipping to change at page 1, line 45
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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.
1. Precomputing a Binding Management Key (Kbm) 1. Introduction
This specification introduces an alternative, low-latency security
mechanism for protecting signaling related to the route optimization
in Mobile IPv6. The default mechanism specified in [1] uses a
periodic return routability test to verify both the "right" of
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
configuration and no trusted entities beyond the mobile node's home
agent.
The mechanism specified in this document, however, requires
the configuration of a shared secret between mobile node and
its correspondent node. As a result, messages relating to the
routability tests can be omitted, leading to significantly smaller
latency. In addition, the right to use a specific address is
assured in a stronger manner than in [1]. On the other hand, the
applicability of this mechanisms is limited due to the need for
pre-configuration. This mechanism is also limited to use only in
scenarios where mobile nodes can be trusted to not misbehave, as the
validity of the claimed care-of addresses is not verified.
2. 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
skipping to change at page 1, line 85 skipping to change at page 2, line 16
using the precomputable Kbm value. using the precomputable Kbm value.
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].
2. Applicability Statement 3. Applicability Statement
Preconfigured shared keys (such as Kcn) between a mobile node and a Preconfigured shared keys (such as Kcn) between a mobile node and a
correspondent node are useful in several specific scenarios: correspondent node are useful in several specific scenarios:
- 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, and the correspondent node has good reason to trust
the actions of the mobile node the actions of the mobile node
- the correspondent node has some guarantee that the mobile node - the correspondent node has some guarantee that the mobile node
will behave properly (perhaps by contractual agreement) will behave properly (perhaps by contractual agreement)
- the method of assignment for keys between the correspondent node - the method of assignment for keys between the correspondent node
and mobile node results in a stronger security association than and mobile node results in a stronger security association than
what can be provided by the Return Routability procedure. what can be provided by the Return Routability procedure.
- diagnostic procedures - diagnostic procedures
- software development and testing - software development and testing
skipping to change at page 2, line 21 skipping to change at page 2, line 42
- diagnostic procedures - diagnostic procedures
- software development and testing - software development and testing
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, or who
have some external basis for establishing trustworthy interactions. have some external basis for establishing trustworthy interactions.
3. 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
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
the user explicitly overrides this by entering the abovementioned the 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 the Binding Update. This method of providing replay protection of the Binding Update. This method of providing replay protection
fails when the Binding Update sequence numbers cycle through the 16 fails when the Binding Update sequence numbers cycle through the 16
bit counter (i.e., not more than 65,536 distinct uses of Kbm for bit counter (i.e., not more than 65,536 distinct uses of Kbm), or
any particular care-of address), or if the sequence numbers are not if the sequence numbers are not protected against reboots. If the
protected against reboots. If the mobile node were to send a fresh mobile node were to send a fresh Binding Update to its correspondent
Binding Update to its correspondent node every hour, 24 hours a day, node every hour, 24 hours a day, every day of the year, this would
every day of the year, and utilize the same care-of address every require changing keys every 7 years. Even if the mobile node were to
time, this would require changing keys every 7 years. Even if the do so every minute, this would provide protection for over a month.
mobile node were to do so every minute, this would provide protection Given typical mobility patterns, there is little danger of replay
for over a month. Given typical mobility patterns, there is little problems; nodes for which problems might arise are expected to use
danger of replay problems; nodes for which problems might arise are methods other than manual configuration for Kcn and the associated
expected to use methods other than manual configuration for Kcn and nonces. When the sequence number field rolls over, the parties
the associated nonces. When the sequence number field rolls over, SHOULD configure a new value for Kcn, so that new Kbm values will be
the parties SHOULD configure a new value for Kcn, so that new Kbm computed.
values will be 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 are mandated to keep track of the most recent
Sequence Number value in a Binding Update message from the mobile Sequence Number value in a Binding Update message from the mobile
node. node.
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, very likely to be quite secure Kbm. As noted, the key is very likely to be quite secure over the
over the lifetime of the security association and usefulness of lifetime of the security association and usefulness of applications
applications between a mobile node and correspondent node that fit between a mobile node and correspondent node that fit the terms
the terms specified in section 2. specified in section 3.
4. IANA Considerations 5. IANA Considerations
No new protocol numbers are required. No new protocol numbers are required.
5. 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.
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 IPv6.
(work in progress). Internet Draft, Internet Engineering Task Request for Comments (Proposed Standard), Internet Engineering
Force, May 2003. Task Force, July 2004.
[2] P. Nikander, T. Aura, J. Arkko, G. Montenegro, and E. Nordmark. [2] 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 citation is normative, and the second citation is
informative only. informative only.
Intellectual Property Statement Intellectual Property Statement
skipping to change at page 4, line 41 skipping to change at page 5, line 41
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Author's Address Author's Address
Questions about this document can also be directed to the author: Questions about this document can also be directed to the author:
Charles E. Perkins Charles E. Perkins
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
 End of changes. 

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