idnits 2.17.1 draft-ietf-mip6-precfgkbm-04.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 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 264. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 277. ** 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. 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 82: '... Users MUST be able to generate/...' RFC 2119 keyword, line 123: '...he keygen tokens MUST be generated fro...' RFC 2119 keyword, line 128: '... Kcn MUST be generated with sufficient randomness (see RFC 4086 [3])....' RFC 2119 keyword, line 137: '...putable Kbm also MUST keep track of th...' RFC 2119 keyword, line 144: '... suboption MUST be present. The Non...' (10 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 (20 October 2005) is 6753 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) ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 8 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 20 October 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 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note 21 that other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 A mobile node and a correspondent node may preconfigure data useful 38 for precomputing a Binding Management Key that can subsequently be 39 used for authorizing Binding Updates. 41 1. Introduction 43 This specification introduces an alternative, low-latency security 44 mechanism for protecting signaling related to the route optimization 45 in Mobile IPv6. The default mechanism specified in [1] uses a 46 periodic return routability test to verify both the "right" of 47 the mobile node to a use a specific home address, as well as the 48 validity of the claimed care-of address. This mechanism requires no 49 configuration and no trusted entities beyond the mobile node's home 50 agent. 52 The mechanism specified in this document, however, requires 53 the configuration of a shared secret between mobile node and 54 its correspondent node. As a result, messages relating to the 55 routability tests can be omitted, leading to significantly smaller 56 latency. In addition, the right to use a specific home address is 57 assured in a stronger manner than in [1]. On the other hand, the 58 applicability of this mechanisms is limited due to the need for 59 pre-configuration. This mechanism is also limited to use only in 60 scenarios where mobile nodes can be trusted to not misbehave, as the 61 validity of the claimed care-of addresses is not verified. 63 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC 2119 [2]. Other 66 terminology is used as already defined in [1]. 68 2. Applicability Statement 70 This mechanism is useful in scenarios where the following conditions 71 are all met: 73 - Mobile node and correspondent node are administered within the 74 same domain. 76 - The correspondent node has good reason to trust the actions of 77 the mobile node. In particular, the correspondent node needs to 78 be certain that the mobile node will not launch flooding attacks 79 against a third party as described in [5]. 81 - The configuration effort related to this mechanism is acceptable. 82 Users MUST be able to generate/select a sufficiently good value 83 for Kcn (see [3]) 85 - There is a desire to take advantage of higher efficiency or 86 greater assurance with regards to the correctness of the home 87 address offered via this mechanism. 89 - This mechanism is used only for authenticating Binding Update 90 messages (and not e.g., data) so the total volume of traffic is 91 low (see RFC 4107 [4], and the discussion in section 4). 93 This mechanism can also be useful in software development, testing, 94 and diagnostics related to mobility signaling. 96 Generally speaking, the required level of trust that the 97 correspondent node needs for enabling a precomputable Kbm with a 98 mobile node is more often found within relatively small, closed 99 groups of users who are personally familiar with each other, 100 or who have some external basis for establishing trustworthy 101 interactions. A typical example scenario where this mechanism is 102 applicable is within a corporation, or between specific users. 103 Application in the general Internet use is typically not possible 104 due to the configuration effort. Application at a public network 105 operator is typically not possible due to requirements placed on the 106 trustworthiness of mobile nodes. 108 3. Precomputing a Binding Management Key (Kbm) 110 A mobile node and a correspondent node may preconfigure data useful 111 for creating a Binding Management Key (Kbm), which can then be used 112 for authorizing binding management messages, especially Binding 113 Update and Binding Acknowledgement messages. This data is as 114 follows: 116 - A shared key (Kcn) used to generate keygen tokens, at least 20 117 octets long 119 - A nonce for use when generating the care-of keygen token 121 - A nonce for use when generating the home keygen token 123 The keygen tokens MUST be generated from Kcn and the nonces as 124 specified in Mobile IPv6 [1] return routability. Likewise, the 125 binding management key Kbm must subsequently be generated from the 126 keygen tokens in the same way as specified in Mobile IPv6 [1]. The 127 preconfigured data is associated to the mobile node's home address. 128 Kcn MUST be generated with sufficient randomness (see RFC 4086 [3]). 130 Replay protection for Binding Update messages using Kbm computed from 131 the preconfigured data depends upon the value of the sequence number 132 field in the Binding Update. If the correspondent node does not 133 maintain information about the recently used values of that field, 134 then there may be an opportunity for a malicious node to replay old 135 Binding Update messages and fool the correspondent node into routing 136 towards an old care-of address. For this reason, a correspondent 137 node that uses a precomputable Kbm also MUST keep track of the most 138 recent value of the Sequence Number field of Binding Update messages 139 using the precomputable Kbm value (for example, by committing it to 140 stable storage). 142 When a Binding Update is to be authenticated using such a 143 precomputable binding key (Kbm), the Binding Authorization Data 144 suboption MUST be present. The Nonce Indices option SHOULD NOT be 145 present. If it is present, the nonce indices supplied SHOULD be 146 ignored and are not included as part of the calculation for the 147 authentication data, which is to be carried exactly as specified 148 in [1]. 150 4. Security Considerations 152 A correspondent node and a mobile node may use a precomputable 153 binding management key (Kbm) to manage the authentication 154 requirements for binding cache management messages. Such keys must 155 be handled carefully to avoid inadvertent exposure to the threats 156 outlined in [5]. Many requirements listed in this document are 157 intended to insure the safety of the manual configuration. In 158 particular, Kcn MUST be generated with sufficient randomness (see RFC 159 4086 [3]). 161 Manually configured keys MUST be used in conformance with RFC 162 4107 [4]. Used according to the applicability statement, and with 163 the other security measures mandated in this specification, the 164 keys will satisfy the properties in that document. In order to 165 assure protection against dictionary attacks, the configured security 166 information is intended to be used ONLY for authenticating Binding 167 Update messages. 169 A mobile node MUST use a different value for Kcn for each node in 170 its Binding Update List, and a correspondent node MUST ensure that 171 every mobile node uses a different value of Kcn. This ensures that 172 the sender of a Binding Update can always be uniquely determined. 173 This is necessary, as this authorization method does not provide any 174 guarantee that the given care-of address is legitimate. For the 175 same reason, this method SHOULD only be applied between nodes that 176 are under the same administration. The return routability procedure 177 is RECOMMENDED for all general use and MUST be the default, unless 178 the user explicitly overrides this by entering the aforementioned 179 preconfigured data for a particular peer. 181 Replay protection for the Binding Authorization Data option 182 authentication mechanism is provided by the Sequence Number field 183 of the Binding Update. This method of providing replay protection 184 fails when the Binding Update sequence numbers cycle through the 16 185 bit counter (i.e., not more than 65,536 distinct uses of Kbm), or 186 if the sequence numbers are not protected against reboots. If the 187 mobile node were to send a fresh Binding Update to its correspondent 188 node every hour, 24 hours a day, every day of the year, this would 189 require changing keys every 7 years. Even if the mobile node were to 190 do so every minute, this would provide protection for over a month. 191 Given typical mobility patterns, there is little danger of replay 192 problems; nodes for which problems might arise are expected to use 193 methods other than manual configuration for Kcn and the associated 194 nonces. When the sequence number field rolls over, the parties 195 SHOULD configure a new value for Kcn, so that new Kbm values will be 196 computed. 198 If a correspondent node does NOT keep track of the Sequence Number 199 for Binding Update messages from a particular mobile node, then the 200 correspondent node could be fooled into accepting an old value for 201 the mobile node's care-of address. In the unlikely event that this 202 address was reallocated to another IPv6 node in the meantime, that 203 IPv6 node would then be vulnerable to unwanted traffic emanating from 204 the correspondent node. In order to circumvent this possibility, 205 correspondent nodes SHOULD keep track of the most recent Sequence 206 Number value in a Binding Update message from the mobile node. 208 Note that where a node has been configured to use the mechanism 209 specified in this document with a particular peer, it SHOULD NOT 210 attempt to use another mechanism, even if the peer requests this 211 or claims to not support the mechanism in this document. This is 212 necessary in order to prevent bidding down attacks. 214 There is no upper bound on the lifetime defined for the precomputable 215 Kbm. As noted, the key is very likely to be quite secure over the 216 lifetime of the security association and usefulness of applications 217 between a mobile node and correspondent node that fit the terms 218 specified in section 2. 220 5. IANA Considerations 222 No new protocol numbers are required. 224 6. Acknowledgement 226 Thanks are due to everyone who reviewed the discussion of issue #146. 227 Thanks to Jari Arkko for supplying text for the Introduction. 229 References 231 [1] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in 232 IPv6. Request for Comments (Proposed Standard) 3775, Internet 233 Engineering Task Force, July 2004. 235 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 236 Levels. Request for Comments (Best Current Practice) 2119, 237 Internet Engineering Task Force, March 1997. 239 [3] D. Eastlake, 3rd, J. Schiller, and S. Crocker. Randomness 240 Requirements for Security. Request for Comments (Proposed 241 Standard) 4086, Internet Engineering Task Force, June 2005. 243 [4] S. Bellovin and R. Housley. Guidelines for Cryptographic Key 244 Management. Request for Comments (Proposed Standard) 4107, 245 Internet Engineering Task Force, June 2005. 247 [5] P. Nikander, T. Aura, J. Arkko, G. Montenegro, and E. Nordmark. 248 Mobile IP version 6 Route Optimization Security Design 249 Background. Internet Draft, Internet Engineering Task Force, 250 June 2003. 252 The first four citations are normative, and the fifth citation is 253 informative only. 255 Intellectual Property Statement 257 The IETF takes no position regarding the validity or scope of any 258 Intellectual Property Rights or other rights that might be claimed to 259 pertain to the implementation or use of the technology described in 260 this document or the extent to which any license under such rights 261 might or might not be available; nor does it represent that it has 262 made any independent effort to identify any such rights. Information 263 on the procedures with respect to rights in RFC documents can be 264 found in BCP 78 and BCP 79. 266 Copies of IPR disclosures made to the IETF Secretariat and any 267 assurances of licenses to be made available, or the result of an 268 attempt made to obtain a general license or permission for the 269 use of such proprietary rights by implementers or users of this 270 specification can be obtained from the IETF on-line IPR repository at 271 http://www.ietf.org/ipr. 273 The IETF invites any interested party to bring to its attention any 274 copyrights, patents or patent applications, or other proprietary 275 rights that may cover technology that may be required to implement 276 this standard. Please address the information to the IETF at 277 ietf-ipr@ietf.org. 279 Disclaimer of Validity 281 This document and the information contained herein are provided 282 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 283 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 284 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 285 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 286 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 287 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 289 Copyright Statement 291 Copyright (C) The Internet Society (2005). This document is subject 292 to the rights, licenses and restrictions contained in BCP 78, and 293 except as set forth therein, the authors retain all their rights. 295 Author's Address 297 Questions about this document can also be directed to the author: 299 Charles E. Perkins 300 Nokia Research Center 301 313 Fairchild Drive 302 Mountain View, CA 94043 303 USA 305 Phone: +1 650 625-2986 306 Fax: +1 650 625-2502 307 E-mail: charles.perkins@nokia.com