idnits 2.17.00 (12 Aug 2021) /tmp/idnits62293/draft-haddad-mip6-cga-bub-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 90 has weird spacing: '...te that an at...' == Line 92 has weird spacing: '...address since...' == Line 113 has weird spacing: '... This memo ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (April 2004) is 6603 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) == Outdated reference: draft-ietf-mobileip-ipv6 has been published as RFC 3775 == Outdated reference: draft-ietf-send-cga has been published as RFC 3972 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Wassim Haddad 2 Internet Draft Lila Madour 3 Expires in October 2004 Jari Arkko 4 Ericsson Research 5 Francis Dupont 6 GET/ENST Bretagne 7 April 2004 9 Applying Cryptographically Generated Addresses to BUB (BUB+) 11 draft-haddad-mip6-cga-bub-00 13 Status of this Memo 15 This document is an Internet Draft and is in full conformance with 16 all provisions of Section 10 of RFC 2026. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working groups. Note that other groups may also 21 distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as 26 "work in progress." 28 The list of current Internet Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Distribution of this memo is unlimited. 36 Abstract 38 This memo describes a method to exploit the Cryptographically 39 Generated Address (CGA) features in highly mobile environment. 40 The draft introduces a new optimization to the "Binding Update 41 Backhauling (BUB)" proposal, which eliminates the need for 42 running a return routability (RR) procedure at the beginning 43 and improves its security. 45 1. Introduction 47 The Binding Update Backhauling [BUB] proposal is a new mode, 48 which has been designed to address scenarios involving two 49 mobile endpoints. BUB offers a highly efficient solution, and 50 substantially reduces the amount of signaling messages. 52 This draft describes a method, which incorporates the security 53 features provided by the CGA in the BUB mode. The suggested 54 solution adopts the same procedure described in [OMIPv6+]. 56 2. Terminology 58 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" 59 in this document are to be interpreted as described in RFC 2219 60 [TERM]. 62 3. Glossary 64 This draft uses the Key option, the Timestamp (TiST) option, 65 the Key Nonce Index (KeNI) option and the Shared Secret (S) bit 66 defined [OMIPv6+]. In addition, this draft defines a new bit 67 called the BUB (B) bit, which will be used in the BU and BA 68 messages to test the other endpoint's willingness to switch to 69 the BUB mode. 71 4. Quick Overview of CGA 73 As described in [CGA] and [Aura], a Cryptographically Generated 74 Address (CGA) is an IPv6 address in which the interface 75 identifier is generated from hashing the address owner's public 76 key. The address owner can then use the corresponding private 77 key to provide a "proof of ownership" of its IPv6 address. 78 The CGA offers three main advantages: it makes the spoofing 79 attack against the IPv6 address much harder, allows to sign 80 messages with the owner's private key and does not require any 81 additional security infrastructure. 83 The CGA offers a method for binding a public signature key to an 84 IPv6 address. The binding between the public key and the address 85 can be verified by re-computing and comparing the hash value of 86 the public key and other parameters sent in the specific message 87 with the interface identifier in the IPv6 address belonging to 88 the owner. If the verification succeeds, the verifier knows that 89 the public key in the CGA parameters is the authentic public key 90 of the address owner. Note that an attacker can always create 91 its own CGA address but he won't be able to spoof someone else's 92 CGA address since he needs to sign the message with the 93 corresponding private key, which is supposed to be known only 94 by the real owner. 96 5. Quick Overview of BUB 98 BUB is a new mode, which has been especially designed to deal 99 with scenarios involving two mobile endpoints. For this purpose, 100 BUB uses the RR procedure defined in [MIPv6] to allow one MN to 101 check the willingness of the other mobile node about switching 102 to the BUB mode (i.e., defined as BUB procedure). After a 103 successful BUB procedure, the two MNs compute a strong shared 104 secret by running a Diffie-Hellman (DH) exchange. The shared 105 secret is then used it to sign subsequent binding updates (BU) 106 and binding acknowledgments (BA) messages. 107 After computing a shared secret, the RR procedure is eliminated 108 and the two MNs exchange only BU/BA messages when switching to 109 new links. 111 6. Applying CGA to BUB 113 This memo assumes that the two MNs use CGAs as their home 114 addresses. By providing a proof of ownership, incorporating CGA 115 in the BUB mode (i.e., BUB+), allows signing the BU messages 116 carrying the BUB test and the BA messages carrying the shared 117 secret with the MN's private keys. As a result, return 118 routability tests associated with the home address can be 119 eliminated during the initialization phase of BUB+. 121 In BUB+, the two MNs MUST sign with their private keys, any BU 122 message sent with the bit "S" set, in order to create/refresh 123 the shared secret. For this purpose, a MN SHOULD launch a BUB 124 test in the first BU message sent to the other MN. In BUB+, 125 launching a BUB test consists on setting the BUB "B" bit in the 126 BU message. In response to a BUB test, the receiver MUST set the 127 "B" bit in the BA message ONLY if it is willing to switch to 128 the BUB mode. Otherwise, the bit MUST always be cleared. 130 In the following, MN1 is using its first BU message to run a 131 BUB test in parallel with sending a request to MN2 to send a 132 new Kbm: 134 MN1 sends the first BU message to MN2's home address. The BU 135 message SHOULD go through MN2's HA and SHOULD use the new MN1's 136 CoA as its IPv6 source address. As it has been described in 137 [OMIPv6+], MN1 MUST insert in the first BU message a Timestamp 138 (TiST) option and set the "S" bit and sign the message with its 139 private key. In addition, MN1 MUST set the "B" bit. Note that 140 MN1 SHOULD also send its public key in the first BU message. 142 When MN2 receives such BU message, it MUST reply by sending a 143 BA message on the direct path between the two MNs. If MN2 is 144 willing to switch to the BUB mode, then, in addition to sending 145 a shared secret and a Key Nonce Index (KeNI), it MUST set the 146 "B" bit in the BA message and send its public key. In BUB+, MN2 147 MUST sign the BA message carrying a shared secret with its CGA 148 private key and MUST encrypt the key field in the key option 149 with MN1's public key as described in [OMIPv6+]. 151 After receiving a BA message from MN2 with the "B" bit set, both 152 nodes will start using the path going through the two HAs as the 153 main path to exchange the BU messages. However, BUB+ recommends 154 that both nodes duplicates their BU messages and send another 155 copy on the direct path in order to reduce the latency. Note 156 that when duplicating the BU messages, both messages MUST carry 157 the same sequence number. The BA messages SHOULD be exchanged 158 only on the direct path. 160 If MN2 is not willing to switch to the BUB mode, it MUST clear 161 the "B" bit in the BA and proceed in the same way as described 162 in [OMIPv6+]. Note that in such scenario, MN2 MUST use its 163 private key to sign the BA message carrying a new shared secret. 165 A particular case arises when the two MNs exchange BU messages 166 with the bit "S" set, at the same time. In such scenario, the 167 two MNs' home IPv6 addresses SHOULD be compared by each MN, and 168 only the owner of the lower address MUST create the Kbm and send 169 it to the other endpoint. 171 7. The BUB (B) bit 173 BUB+ introduces a new bit called the BUB (B) bit in the BU/BA 174 messages, which replaces the BUB procedure used in [BUB]. This 175 bit MUST be set only to ask the receiver about switching to the 176 BUB mode. Otherwise, the "B" bit MUST always be cleared. 178 The format of the BU message with the new bit is as follows: 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Sequence # | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 |A|H|L|K|S|B| Reserved | Lifetime | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | | 186 . . 187 . Mobility options . 189 . . 190 | | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 If the sender of the BA message is willing to switch to the BUB 194 mode, then it MUST set the "B" bit in the BA message. Otherwise, 195 the "B" bit MUST always be cleared. 197 The format of the BA message with the new bit is as follows: 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Status |K|B| Reserved | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Sequence # | Lifetime | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | | 205 . . 206 . Mobility options . 207 . . 208 | | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 8. Security Considerations 213 This memo explains how to use CGA in order to switch to the BUB 214 mode. When both endpoints are mobile, it is recommended that 215 both MNs agree on switching to the BUB mode after the first BUB 216 test. 218 9. Normative References 220 [MIPv6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in 221 IPv6", draft-ietf-mobileip-ipv6-24.txt, June 2003. 223 [TERM] S. Bradner, "Key words for use in RFCs to Indicate 224 Requirement Levels", BCP 14, RFC 2119. 226 10. Informative References 228 [Aura] Aura, T. "Cryptographically Generated Address (CGA)", 229 6th Information Security Conference (ISC'03), Bristol, 230 UK, October 2003. 232 [BUB] Haddad, W., Dupont, F., Kavanagh, A., Krishnan, S., 233 Madour, L., Park, SD., "Binding Update Backhauling", 234 draft-haddad-mipv6-bub-01, Februray 2004. 236 [CGA] Aura, T. "Cryptographically Generated Address (CGA)", 237 draft-ietf-send-cga-06, April, 2004. 239 [OMIPv6+] Haddad, W., Arkko, J., Dupont, F., "Applying 240 Cryptographically Generated Address (CGA) to OMIPv6", 241 draft-haddad-mipv6-cga-omipv6-01, May 2004. 243 11. Authors' Addresses 245 Wassim Haddad 246 Ericsson Research Canada 247 8400, Decarie Blvd 248 Town of Mount Royal 249 Quebec H4P 2N2 250 Canada 251 Tel: +1 514 345 7900 252 Fax: +1 514 345 6105 253 E-mail: Wassim.Haddad@ericsson.com 255 Lila Madour 256 Ericsson Research Canada 257 8400, Decarie Blvd 258 Town of Mount Royal 259 Quebec H4P 2N2 260 CANADA 261 Phone: +1 514 345 7900 262 Fax: +1 514 345 6195 263 E-Mail: Lila.Madour@ericsson.com 265 Jari Arkko 266 Ericsson Research Nomadic Laboratory 267 Jorvas 02420 268 Finland 269 E-mail: Jari.Arkko@ericsson.com 271 Francis Dupont 272 ENST Bretagne 273 Campus de Rennes 274 2, rue de la Chataigneraie 275 CS 17607 276 35576 Cesson-Sevigne Cedex 277 FRANCE 278 Fax: +33 2 99 12 70 30 279 E-mail: Francis.Dupont@enst-bretagne.fr 281 Intellectual Property Statement 283 The IETF takes no position regarding the validity or scope of 284 any intellectual property or other rights that might be claimed 285 to pertain to the implementation or use of the technology 286 described in this document or the extent to which any license 287 under such rights might or might not be available; neither does 288 it represent that it has made any effort to identify any such 289 rights. Information on the IETF's procedures with respect to 290 rights in standards-track and standards-related documentation 291 can be found in BCP-11. Copies of claims of rights made 292 available for publication and any assurances of licenses to be 293 made available, or the result of an attempt made to obtain a 294 general license or permission for the use of such proprietary 295 rights by implementors or users of this specification can be 296 obtained from the IETF Secretariat. 298 The IETF invites any interested party to bring to its attention 299 any copyrights, patents or patent applications, or other 300 proprietary rights which may cover technology that may be 301 required to practice this standard. Please address the 302 information to the IETF Executive Director. 304 The IETF has been notified of intellectual property rights 305 claimed in regard to some or all of the specification contained 306 in this document. For more information consult the online list 307 of claimed rights. 309 Full Copyright Statement 311 Copyright (C) The Internet Society (2003). All Rights Reserved. 312 This document and translations of it may be copied and furnished 313 to others, and derivative works that comment on or otherwise 314 explain it or assist in its implementation may be prepared, 315 copied, published and distributed, in whole or in part, without 316 restriction of any kind, provided that the above copyright 317 notice and this paragraph are included on all such copies and 318 derivative works. However, this document itself may not be 319 modified in any way, such as by removing the copyright notice or 320 references to the Internet Society or other Internet 321 organizations, except as needed for the purpose of developing 322 Internet standards in which case the procedures for copyrights 323 defined in the Internet Standards process must be followed, or 324 as required to translate it into languages other than English. 325 The limited permissions granted above are perpetual and will not 326 be revoked by the Internet Society or its successors or 327 assignees. 328 This document and the information contained herein is provided 329 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 330 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 331 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 332 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 333 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 334 PARTICULAR PURPOSE.