idnits 2.17.1 draft-ietf-mip6-precfgkbm-01.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 219. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 196. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 203. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 209. ** 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 0) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 59: '...he keygen tokens MUST be generated fro...' RFC 2119 keyword, line 72: '...putable Kbm also MUST keep track of th...' RFC 2119 keyword, line 78: '... suboption MUST be present. The Non...' RFC 2119 keyword, line 79: '...ent, the nonce indices supplied MAY be...' RFC 2119 keyword, line 112: '...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 October 2004) is 7126 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: 9 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Mobile IP Working Group Charles E. Perkins 3 INTERNET-DRAFT Nokia Research Center 4 21 October 2004 6 Precomputable Binding Management Key Kbm for Mobile IPv6 7 9 Status of This Memo 11 This document is a submission by the IETF MIPv6 Working Group Working 12 Group of the Internet Engineering Task Force (IETF). Comments should 13 be submitted to the mip6@ietf.org mailing list. 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note 24 that other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at 29 any time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 A mobile node and a correspondent node may preconfigure data useful 41 for precomputing a Binding Management Key that can subsequently be 42 used for authorizing Binding Updates. 44 1. Precomputing a Binding Management Key (Kbm) 46 A mobile node and a correspondent node may preconfigure data useful 47 for creating a Binding Management Key (Kbm), which can then be used 48 for authorizing binding management messages, especially Binding 49 Update and Binding Acknowledgement messages. This data is as 50 follows: 52 - A shared key (Kcn) used to generate keygen tokens, at least 20 53 octets long 55 - A nonce for use when generating the care-of keygen token 57 - A nonce for use when generating the home keygen token 59 The keygen tokens MUST be generated from Kcn and the nonces as 60 specified in Mobile IPv6 [1] return routability. Likewise, the 61 binding management key Kbm must subsequently be generated from the 62 keygen tokens in the same way as specified in Mobile IPv6 [1]. The 63 preconfigured data is associated to the mobile node's home address. 65 Replay protection for Binding Update messages using Kbm computed from 66 the preconfigured data depends upon the value of the sequence number 67 field in the Binding Update. If the correspondent node does not 68 maintain information about the recently used values of that field, 69 then there may be an opportunity for a malicious node to replay old 70 Binding Update messages and fool the correspondent node into routing 71 towards an old care-of address. For this reason, a correspondent 72 node that uses a precomputable Kbm also MUST keep track of the most 73 recent value of the Sequence Number field of Binding Update messages 74 using the precomputable Kbm value. 76 When a Binding Update is to be authenticated using such a 77 precomputable binding key (Kbm), the Binding Authorization Data 78 suboption MUST be present. The Nonce Indices option SHOULD NOT 79 be present. If it is present, the nonce indices supplied MAY be 80 ignored and are not included as part of the calculation for the 81 authentication data, which is to be carried exactly as specified 82 in [1]. 84 2. Applicability Statement 86 Preconfigured shared keys (such as Kcn) between a mobile node and a 87 correspondent node are useful in several specific scenarios: 89 - mobile node and correspondent node are administered within the 90 same domain, and the correspondent node has good reason to trust 91 the actions of the mobile node 93 - the correspondent node has some guarantee that the mobile node 94 will behave properly (perhaps by contractual agreement) 96 - the method of assignment for keys between the correspondent node 97 and mobile node results in a stronger security association than 98 what can be provided by the Return Routability procedure. 100 - diagnostic procedures 102 - software development and testing 104 Generally speaking, the required level of trust that the 105 correspondent node needs for enabling a precomputable Kbm with a 106 mobile node is more often found within relatively small, closed 107 groups of users who are personally familiar with each other, or who 108 have some external basis for establishing trustworthy interactions. 110 3. Security Considerations 112 A correspondent node and a mobile node MAY use a precomputable 113 binding management key (Kbm) to manage the authentication 114 requirements for binding cache management messages. Such keys must 115 be handled carefully to avoid inadvertent exposure to the threats 116 outlined in [2]. 118 A mobile node MUST use a different value for Kcn for each node in 119 its Binding Update List, and a correspondent node MUST ensure that 120 every mobile node uses a different value of Kcn. This ensures that 121 the sender of a Binding Update can always be uniquely determined. 122 This is necessary, as this authorization method does not provide any 123 guarantee that the given care-of address is legitimate. For the 124 same reason, this method SHOULD only be applied between nodes that 125 are under the same administration. The return routability procedure 126 is RECOMMENDED for all general use and MUST be the default, unless 127 the user explicitly overrides this by entering the abovementioned 128 preconfigured data for a particular peer. 130 Replay protection for the Binding Authorization Data option 131 authentication mechanism is provided by the Sequence Number field 132 of the Binding Update. This method of providing replay protection 133 fails when the Binding Update sequence numbers cycle through the 16 134 bit counter (i.e., not more than 65,536 distinct uses of Kbm for 135 any particular care-of address), or if the sequence numbers are not 136 protected against reboots. If the mobile node were to send a fresh 137 Binding Update to its correspondent node every hour, 24 hours a day, 138 every day of the year, and utilize the same care-of address every 139 time, this would require changing keys every 7 years. Even if the 140 mobile node were to do so every minute, this would provide protection 141 for over a month. Given typical mobility patterns, there is little 142 danger of replay problems; nodes for which problems might arise are 143 expected to use methods other than manual configuration for Kcn and 144 the associated nonces. When the sequence number field rolls over, 145 the parties SHOULD configure a new value for Kcn, so that new Kbm 146 values will be computed. 148 If a correspondent node does NOT keep track of the Sequence Number 149 for Binding Update messages from a particular mobile node, then the 150 correspondent node could be fooled into accepting an old value for 151 the mobile node's care-of address. In the unlikely event that this 152 address was reallocated to another IPv6 node in the meantime, that 153 IPv6 node would then be vulnerable to unwanted traffic emanating from 154 the correspondent node. In order to circumvent this possibility, 155 correspondent nodes are mandated to keep track of the most recent 156 Sequence Number value in a Binding Update message from the mobile 157 node. 159 There is no upper bound on the lifetime defined for the precomputable 160 Kbm. As noted, the key is very, very likely to be quite secure 161 over the lifetime of the security association and usefulness of 162 applications between a mobile node and correspondent node that fit 163 the terms specified in section 2. 165 4. IANA Considerations 167 No new protocol numbers are required. 169 5. Acknowledgement 171 Thanks are due to everyone who reviewed the discussion of issue #146. 173 References 175 [1] D. Johnson, C. Perkins, and J. Arkko. Mobility support in IPv6 176 (work in progress). Internet Draft, Internet Engineering Task 177 Force, May 2003. 179 [2] P. Nikander, T. Aura, J. Arkko, G. Montenegro, and E. Nordmark. 180 Mobile IP version 6 Route Optimization Security Design 181 Background. Internet Draft, Internet Engineering Task Force, 182 June 2003. 184 The first citation is normative, and the second citation is 185 informative only. 187 Intellectual Property Statement 189 The IETF takes no position regarding the validity or scope of any 190 Intellectual Property Rights or other rights that might be claimed to 191 pertain to the implementation or use of the technology described in 192 this document or the extent to which any license under such rights 193 might or might not be available; nor does it represent that it has 194 made any independent effort to identify any such rights. Information 195 on the procedures with respect to rights in RFC documents can be 196 found in BCP 78 and BCP 79. 198 Copies of IPR disclosures made to the IETF Secretariat and any 199 assurances of licenses to be made available, or the result of an 200 attempt made to obtain a general license or permission for the 201 use of such proprietary rights by implementers or users of this 202 specification can be obtained from the IETF on-line IPR repository at 203 http://www.ietf.org/ipr. 205 The IETF invites any interested party to bring to its attention any 206 copyrights, patents or patent applications, or other proprietary 207 rights that may cover technology that may be required to implement 208 this standard. Please address the information to the IETF at 209 ietf-ipr@ietf.org. 211 Disclaimer of Validity 213 This document and the information contained herein are provided 214 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 215 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 216 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 217 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 218 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 219 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 221 Copyright Statement 223 Copyright (C) The Internet Society (2004). This document is subject 224 to the rights, licenses and restrictions contained in BCP 78, and 225 except as set forth therein, the authors retain all their rights. 227 Author's Address 229 Questions about this document can also be directed to the author: 231 Charles E. Perkins 232 Nokia Research Center 233 313 Fairchild Drive 234 Mountain View, CA 94043 235 USA 237 Phone: +1 650 625-2986 238 Fax: +1 650 625-2502 239 E-mail: charles.perkins@nokia.com