idnits 2.17.1 draft-ietf-mip6-precfgkbm-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 240. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 224. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 230. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 80: '...he keygen tokens MUST be generated fro...' RFC 2119 keyword, line 93: '...putable Kbm also MUST keep track of th...' RFC 2119 keyword, line 99: '... suboption MUST be present. The Non...' RFC 2119 keyword, line 100: '...ent, the nonce indices supplied MAY be...' RFC 2119 keyword, line 133: '...nd a mobile node MAY use a precomputab...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (21 May 2005) is 6908 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Mobile IP Working Group Charles E. Perkins 2 INTERNET-DRAFT Nokia Research Center 3 21 May 2005 5 Securing Mobile IPv6 Route Optimization Using a Static Shared Key 6 8 Status of This Memo 10 This document is a submission by the IETF MIPv6 Working Group Working 11 Group of the Internet Engineering Task Force (IETF). Comments should 12 be submitted to the mip6@ietf.org mailing list. 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she becomes aware will be disclosed, in accordance with 19 Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note 23 that other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at 28 any time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 A mobile node and a correspondent node may preconfigure data useful 40 for precomputing a Binding Management Key that can subsequently be 41 used for authorizing Binding Updates. 43 1. Introduction 45 This specification introduces an alternative, low-latency security 46 mechanism for protecting signaling related to the route optimization 47 in Mobile IPv6. The default mechanism specified in [1] uses a 48 periodic return routability test to verify both the "right" of 49 the mobile node to a use a specific home address, as well as the 50 validity of the claimed care-of address. This mechanism requires no 51 configuration and no trusted entities beyond the mobile node's home 52 agent. 54 The mechanism specified in this document, however, requires 55 the configuration of a shared secret between mobile node and 56 its correspondent node. As a result, messages relating to the 57 routability tests can be omitted, leading to significantly smaller 58 latency. In addition, the right to use a specific address is 59 assured in a stronger manner than in [1]. On the other hand, the 60 applicability of this mechanisms is limited due to the need for 61 pre-configuration. This mechanism is also limited to use only in 62 scenarios where mobile nodes can be trusted to not misbehave, as the 63 validity of the claimed care-of addresses is not verified. 65 2. Precomputing a Binding Management Key (Kbm) 67 A mobile node and a correspondent node may preconfigure data useful 68 for creating a Binding Management Key (Kbm), which can then be used 69 for authorizing binding management messages, especially Binding 70 Update and Binding Acknowledgement messages. This data is as 71 follows: 73 - A shared key (Kcn) used to generate keygen tokens, at least 20 74 octets long 76 - A nonce for use when generating the care-of keygen token 78 - A nonce for use when generating the home keygen token 80 The keygen tokens MUST be generated from Kcn and the nonces as 81 specified in Mobile IPv6 [1] return routability. Likewise, the 82 binding management key Kbm must subsequently be generated from the 83 keygen tokens in the same way as specified in Mobile IPv6 [1]. The 84 preconfigured data is associated to the mobile node's home address. 86 Replay protection for Binding Update messages using Kbm computed from 87 the preconfigured data depends upon the value of the sequence number 88 field in the Binding Update. If the correspondent node does not 89 maintain information about the recently used values of that field, 90 then there may be an opportunity for a malicious node to replay old 91 Binding Update messages and fool the correspondent node into routing 92 towards an old care-of address. For this reason, a correspondent 93 node that uses a precomputable Kbm also MUST keep track of the most 94 recent value of the Sequence Number field of Binding Update messages 95 using the precomputable Kbm value. 97 When a Binding Update is to be authenticated using such a 98 precomputable binding key (Kbm), the Binding Authorization Data 99 suboption MUST be present. The Nonce Indices option SHOULD NOT 100 be present. If it is present, the nonce indices supplied MAY be 101 ignored and are not included as part of the calculation for the 102 authentication data, which is to be carried exactly as specified 103 in [1]. 105 3. Applicability Statement 107 Preconfigured shared keys (such as Kcn) between a mobile node and a 108 correspondent node are useful in several specific scenarios: 110 - mobile node and correspondent node are administered within the 111 same domain, and the correspondent node has good reason to trust 112 the actions of the mobile node 114 - the correspondent node has some guarantee that the mobile node 115 will behave properly (perhaps by contractual agreement) 117 - the method of assignment for keys between the correspondent node 118 and mobile node results in a stronger security association than 119 what can be provided by the Return Routability procedure. 121 - diagnostic procedures 123 - software development and testing 125 Generally speaking, the required level of trust that the 126 correspondent node needs for enabling a precomputable Kbm with a 127 mobile node is more often found within relatively small, closed 128 groups of users who are personally familiar with each other, or who 129 have some external basis for establishing trustworthy interactions. 131 4. Security Considerations 133 A correspondent node and a mobile node MAY use a precomputable 134 binding management key (Kbm) to manage the authentication 135 requirements for binding cache management messages. Such keys must 136 be handled carefully to avoid inadvertent exposure to the threats 137 outlined in [2]. 139 A mobile node MUST use a different value for Kcn for each node in 140 its Binding Update List, and a correspondent node MUST ensure that 141 every mobile node uses a different value of Kcn. This ensures that 142 the sender of a Binding Update can always be uniquely determined. 143 This is necessary, as this authorization method does not provide any 144 guarantee that the given care-of address is legitimate. For the 145 same reason, this method SHOULD only be applied between nodes that 146 are under the same administration. The return routability procedure 147 is RECOMMENDED for all general use and MUST be the default, unless 148 the user explicitly overrides this by entering the aforementioned 149 preconfigured data for a particular peer. 151 Replay protection for the Binding Authorization Data option 152 authentication mechanism is provided by the Sequence Number field 153 of the Binding Update. This method of providing replay protection 154 fails when the Binding Update sequence numbers cycle through the 16 155 bit counter (i.e., not more than 65,536 distinct uses of Kbm), or 156 if the sequence numbers are not protected against reboots. If the 157 mobile node were to send a fresh Binding Update to its correspondent 158 node every hour, 24 hours a day, every day of the year, this would 159 require changing keys every 7 years. Even if the mobile node were to 160 do so every minute, this would provide protection for over a month. 161 Given typical mobility patterns, there is little danger of replay 162 problems; nodes for which problems might arise are expected to use 163 methods other than manual configuration for Kcn and the associated 164 nonces. When the sequence number field rolls over, the parties 165 SHOULD configure a new value for Kcn, so that new Kbm values will be 166 computed. 168 If a correspondent node does NOT keep track of the Sequence Number 169 for Binding Update messages from a particular mobile node, then the 170 correspondent node could be fooled into accepting an old value for 171 the mobile node's care-of address. In the unlikely event that this 172 address was reallocated to another IPv6 node in the meantime, that 173 IPv6 node would then be vulnerable to unwanted traffic emanating from 174 the correspondent node. In order to circumvent this possibility, 175 correspondent nodes are mandated to keep track of the most recent 176 Sequence Number value in a Binding Update message from the mobile 177 node. 179 There is no upper bound on the lifetime defined for the precomputable 180 Kbm. As noted, the key is very likely to be quite secure over the 181 lifetime of the security association and usefulness of applications 182 between a mobile node and correspondent node that fit the terms 183 specified in section 3. 185 5. IANA Considerations 187 No new protocol numbers are required. 189 6. Acknowledgement 191 Thanks are due to everyone who reviewed the discussion of issue #146. 192 Thanks to Jari Arkko for supplying text for the Introduction. 194 References 196 [1] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6. 197 Request for Comments (Proposed Standard), Internet Engineering 198 Task Force, July 2004. 200 [2] P. Nikander, T. Aura, J. Arkko, G. Montenegro, and E. Nordmark. 201 Mobile IP version 6 Route Optimization Security Design 202 Background. Internet Draft, Internet Engineering Task Force, 203 June 2003. 205 The first citation is normative, and the second citation is 206 informative only. 208 Intellectual Property Statement 210 The IETF takes no position regarding the validity or scope of any 211 Intellectual Property Rights or other rights that might be claimed to 212 pertain to the implementation or use of the technology described in 213 this document or the extent to which any license under such rights 214 might or might not be available; nor does it represent that it has 215 made any independent effort to identify any such rights. Information 216 on the procedures with respect to rights in RFC documents can be 217 found in BCP 78 and BCP 79. 219 Copies of IPR disclosures made to the IETF Secretariat and any 220 assurances of licenses to be made available, or the result of an 221 attempt made to obtain a general license or permission for the 222 use of such proprietary rights by implementers or users of this 223 specification can be obtained from the IETF on-line IPR repository at 224 http://www.ietf.org/ipr. 226 The IETF invites any interested party to bring to its attention any 227 copyrights, patents or patent applications, or other proprietary 228 rights that may cover technology that may be required to implement 229 this standard. Please address the information to the IETF at 230 ietf-ipr@ietf.org. 232 Disclaimer of Validity 234 This document and the information contained herein are provided 235 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 236 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 237 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 238 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 239 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 240 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 242 Copyright Statement 244 Copyright (C) The Internet Society (2005). This document is subject 245 to the rights, licenses and restrictions contained in BCP 78, and 246 except as set forth therein, the authors retain all their rights. 248 Author's Address 250 Questions about this document can also be directed to the author: 252 Charles E. Perkins 253 Nokia Research Center 254 313 Fairchild Drive 255 Mountain View, CA 94043 256 USA 258 Phone: +1 650 625-2986 259 Fax: +1 650 625-2502 260 E-mail: charles.perkins@nokia.com