idnits 2.17.1 draft-ietf-mip6-precfgkbm-03.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 253. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 230. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 243. ** 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 141: '...nd a mobile node MAY use a precomputab...' (7 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 (30 June 2005) is 6875 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 30 June 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 This mechanism is useful in scenarios where the following conditions 108 are all met: 110 - Mobile node and correspondent node are administered within the 111 same domain. 113 - The correspondent node has good reason to trust the actions of 114 the mobile node. In particular, the correspondent node needs to 115 be certain that the mobile node will not launch flooding attacks 116 against a third party as described in [2]. 118 - The configuration effort related to this mechanism is acceptable. 120 - There is a desire to take advantage of higher efficiency or 121 greater assurance with regards to the correctness of the home 122 address offered via this mechanism. 124 This mechanism can also be useful in software development, testing, 125 and diagnostics related to mobility signaling. 127 Generally speaking, the required level of trust that the 128 correspondent node needs for enabling a precomputable Kbm with a 129 mobile node is more often found within relatively small, closed 130 groups of users who are personally familiar with each other, 131 or who have some external basis for establishing trustworthy 132 interactions. A typical example scenario where this mechanism is 133 applicable is within a corporation, or between specific users. 134 Application in the general Internet use is typically not possible 135 due to the configuration effort. Application at a public network 136 operator is typically not possible due to requirements placed on the 137 trustworthiness of mobile nodes. 139 4. Security Considerations 141 A correspondent node and a mobile node MAY use a precomputable 142 binding management key (Kbm) to manage the authentication 143 requirements for binding cache management messages. Such keys must 144 be handled carefully to avoid inadvertent exposure to the threats 145 outlined in [2]. 147 A mobile node MUST use a different value for Kcn for each node in 148 its Binding Update List, and a correspondent node MUST ensure that 149 every mobile node uses a different value of Kcn. This ensures that 150 the sender of a Binding Update can always be uniquely determined. 151 This is necessary, as this authorization method does not provide any 152 guarantee that the given care-of address is legitimate. For the 153 same reason, this method SHOULD only be applied between nodes that 154 are under the same administration. The return routability procedure 155 is RECOMMENDED for all general use and MUST be the default, unless 156 the user explicitly overrides this by entering the aforementioned 157 preconfigured data for a particular peer. 159 Replay protection for the Binding Authorization Data option 160 authentication mechanism is provided by the Sequence Number field 161 of the Binding Update. This method of providing replay protection 162 fails when the Binding Update sequence numbers cycle through the 16 163 bit counter (i.e., not more than 65,536 distinct uses of Kbm), or 164 if the sequence numbers are not protected against reboots. If the 165 mobile node were to send a fresh Binding Update to its correspondent 166 node every hour, 24 hours a day, every day of the year, this would 167 require changing keys every 7 years. Even if the mobile node were to 168 do so every minute, this would provide protection for over a month. 169 Given typical mobility patterns, there is little danger of replay 170 problems; nodes for which problems might arise are expected to use 171 methods other than manual configuration for Kcn and the associated 172 nonces. When the sequence number field rolls over, the parties 173 SHOULD configure a new value for Kcn, so that new Kbm values will be 174 computed. 176 If a correspondent node does NOT keep track of the Sequence Number 177 for Binding Update messages from a particular mobile node, then the 178 correspondent node could be fooled into accepting an old value for 179 the mobile node's care-of address. In the unlikely event that this 180 address was reallocated to another IPv6 node in the meantime, that 181 IPv6 node would then be vulnerable to unwanted traffic emanating from 182 the correspondent node. In order to circumvent this possibility, 183 correspondent nodes SHOULD keep track of the most recent Sequence 184 Number value in a Binding Update message from the mobile node. 186 Note that where a node has been configured to use the mechanism 187 specified in this document with a particular peer, it SHOULD NOT 188 attempt to use another mechanism, even if the peer requests this 189 or claims to not support the mechanism in this document. This is 190 necessary in order to prevent bidding down attacks. 192 There is no upper bound on the lifetime defined for the precomputable 193 Kbm. As noted, the key is very likely to be quite secure over the 194 lifetime of the security association and usefulness of applications 195 between a mobile node and correspondent node that fit the terms 196 specified in section 3. 198 5. IANA Considerations 200 No new protocol numbers are required. 202 6. Acknowledgement 204 Thanks are due to everyone who reviewed the discussion of issue #146. 205 Thanks to Jari Arkko for supplying text for the Introduction. 207 References 209 [1] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6. 210 Request for Comments (Proposed Standard), Internet Engineering 211 Task Force, July 2004. 213 [2] P. Nikander, T. Aura, J. Arkko, G. Montenegro, and E. Nordmark. 214 Mobile IP version 6 Route Optimization Security Design 215 Background. Internet Draft, Internet Engineering Task Force, 216 June 2003. 218 The first citation is normative, and the second citation is 219 informative only. 221 Intellectual Property Statement 223 The IETF takes no position regarding the validity or scope of any 224 Intellectual Property Rights or other rights that might be claimed to 225 pertain to the implementation or use of the technology described in 226 this document or the extent to which any license under such rights 227 might or might not be available; nor does it represent that it has 228 made any independent effort to identify any such rights. Information 229 on the procedures with respect to rights in RFC documents can be 230 found in BCP 78 and BCP 79. 232 Copies of IPR disclosures made to the IETF Secretariat and any 233 assurances of licenses to be made available, or the result of an 234 attempt made to obtain a general license or permission for the 235 use of such proprietary rights by implementers or users of this 236 specification can be obtained from the IETF on-line IPR repository at 237 http://www.ietf.org/ipr. 239 The IETF invites any interested party to bring to its attention any 240 copyrights, patents or patent applications, or other proprietary 241 rights that may cover technology that may be required to implement 242 this standard. Please address the information to the IETF at 243 ietf-ipr@ietf.org. 245 Disclaimer of Validity 247 This document and the information contained herein are provided 248 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 249 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 250 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 251 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 252 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 253 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 255 Copyright Statement 257 Copyright (C) The Internet Society (2005). This document is subject 258 to the rights, licenses and restrictions contained in BCP 78, and 259 except as set forth therein, the authors retain all their rights. 261 Author's Address 263 Questions about this document can also be directed to the author: 265 Charles E. Perkins 266 Nokia Research Center 267 313 Fairchild Drive 268 Mountain View, CA 94043 269 USA 271 Phone: +1 650 625-2986 272 Fax: +1 650 625-2502 273 E-mail: charles.perkins@nokia.com