idnits 2.17.1 draft-xia-csi-symmetric-key-00.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 491. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 502. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 509. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 515. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 325 has weird spacing: '...red key encry...' -- 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 (June 20, 2008) is 5781 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) == Unused Reference: 'RFC5121' is defined on line 411, but no explicit reference was found in the text == Unused Reference: 'RFC3314' is defined on line 416, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3314 -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) == Outdated reference: A later version (-05) exists of draft-chakrabarti-6lowpan-ipv6-nd-04 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Xia 3 Internet-Draft Huawei 4 Expires: December 22, 2008 S. Krishnan 5 Ericsson Research 6 W. Haddad 7 Qualcomm 8 J-M. Combes 9 Orange Labs R&D 10 Chunqiang. Li 11 Huawei 12 June 20, 2008 14 Distributing a Symmetric Neighbor Discovery Key Using SEND 15 draft-xia-csi-symmetric-key-00.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on December 22, 2008. 42 Abstract 44 In this document, a method for provisioning a shared key from the 45 router to the host is defined to protect Neighbor Discovery(ND) 46 signaling between the router and the host. The host sends a Router 47 Solicitation(RS) message with ND Shared Key Request Option to the 48 router. The router encrypts a ND shared key using the host's SEcure 49 Neighbor Discovery(SEND) public key and sends it back to the host 50 through a Router Advertisement(RA) message. The host decrypts the ND 51 shared key using the matching private key. The Neighbor Discovery 52 shared key is then used for protecting the following Neighbor 53 Discovery signaling between the router and the host. The Router 54 Solicitation and Router Advertisement message exchanges are required 55 to have SEND security. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Operation Description . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Sending Router Solicitations . . . . . . . . . . . . . . . 4 63 3.2. Receiving Router Solicitations and Sending Router 64 Advertisements . . . . . . . . . . . . . . . . . . . . . . 4 65 3.3. Receiving Router Advertisements . . . . . . . . . . . . . 5 66 3.4. ND operation secured by a shared key . . . . . . . . . . . 5 67 3.5. Key Generation and Lifetime . . . . . . . . . . . . . . . 6 68 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. ND Shared Key Request Option . . . . . . . . . . . . . . . 6 70 4.2. ND Shared Key Reply Option . . . . . . . . . . . . . . . . 7 71 4.3. Neighbor Discovery Authenticator Option . . . . . . . . . 8 72 5. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 9 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 77 8.2. Informative references . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 79 Intellectual Property and Copyright Statements . . . . . . . . . . 13 81 1. Introduction 83 IPv6 nodes use Neighbor Discovery(ND) protocol [RFC4861] to discover 84 other nodes on the link, to determine their link-layer addresses, to 85 find routers, and to maintain reachability information about the 86 paths to active neighbors. [RFC3971] specifies security mechanisms 87 for ND, that is, Secure Neighbor Discovery (SEND) protocol in which 88 Cryptographically Generated Addresses (CGA) [RFC3972] are used. 90 The construction and verification of the RSA Signature option in SEND 91 operation is computationally expensive. In the ND context, however, 92 hosts typically only have to perform a few signature operations as 93 they enter a link, a few operations as they find a new on-link peer 94 with which to communicate, or Neighbor Unreachability Detection with 95 existing neighbors. Routers are required to perform a larger number 96 of operations, particularly when the frequency of router 97 advertisements is high due to mobility requirements. Scalability 98 issue arises when hundreds , even thousands of hosts attach to a 99 router. 101 In the same way, IPv6 over Low-Power Wireless Personal Area Networks 102 (6LoWPANs) have similar constraints. It is recommended that ND 103 signalling exchanges occur between the 6lowpan host and the PAN 104 coordinator, which is a router in [I-D.chakrabarti-6lowpan-ipv6-nd]. 105 Another point is 6lowpan hosts may not be able to do asymmetric 106 cryptography all the time because of power/computing consumption. 108 In this document, a lightweight mechanism is defined by which a 109 shared key for securing ND exchanges between the host and the router 110 is provisioned on the host by the router. The mechanism described in 111 the document utilizes SEND [RFC3971] public/private key pair to 112 encrypt/decrypt a ND shared key sent from the router to the host. 113 Once the ND shared key is provisioned, all ND exchanges occurring 114 between the host and the router are protected by Message 115 Authentication Codes (MAC) which generally requires much less 116 computational operation. This main idea of the document is in line 117 with [I-D.ietf-mipshop-handover-key] in which shared handover key is 118 used for protecting handover signaling between a mobile node and an 119 access router. 121 The solution is based on and compatible with SEND operation. 123 2. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 The terminology and messages in this document are based on the 130 definitions in [RFC3971], in addition to the ones defined below. 131 ND shared key : A key is shared between a router and a host, and 132 used to protect ND signaling between the router and the host. 134 3. Operation Description 136 3.1. Sending Router Solicitations 138 According to SEND [RFC3971], the CGA option MUST be present in Router 139 Solicitation(RS) messages unless they are sent with the unspecified 140 source address. In this document, RS message with a CGA source 141 address is used for a ND shared key request. 143 The host MUST send a RS containing a ND Shared Key Request Option 144 defined in Section 4.1 with the SEND's public key. A CGA for the 145 host MUST be the source address of the packet, and the host MUST 146 include the SEND CGA Option and SEND Signature Option with the 147 packet, as specified in [RFC3971]. The SEND signature covers all 148 fields in the RS, including the 128 bit source and destination 149 addresses and ICMP checksum as described in [RFC3971], except for the 150 Signature Option itself. The host also sets the authentication 151 Algorithm Type (AT) field in the ND Shared Key Request Option to the 152 host's preferred authentication algorithm. The SEND Nonce MUST also 153 be included for anti-replay protection. 155 3.2. Receiving Router Solicitations and Sending Router Advertisements 157 When the router receives a RS from the host protected with SEND and 158 including a ND Shared Key Request Option, the router MUST first 159 validate the RS using SEND as described in [RFC3971]. If the RS can 160 not be validated, the router MUST NOT include a ND Shared Key Reply 161 Option Section 4.2 in the reply. 163 If the RS is validated, the router MUST then determine whether the 164 CGA is already associated with a ND shared key. If the CGA is 165 associated with an existing key, the router MUST return the existing 166 key to the host. If the CGA does not have a ND shared key, the 167 router MUST construct a ND shared key as described in Section 3.5. 168 The router MUST encrypt the key with the host's SEND public key. The 169 router MUST insert the encrypted ND shared key into a ND Shared Key 170 Reply Option and MUST attach the option to the RA. The lifetime of 171 the key MUST also be included in the ND Shared Key Reply Option. The 172 router SHOULD set the AT field of the ND Shared Key Option to the 173 MN's preferred algorithm type indicated in the AT field of the ND 174 Shared Key Request Option, if it is supported; otherwise, the router 175 MUST select an authentication algorithm which is of equivalent 176 strength or stronger and set the field to that. The router MUST also 177 include the SEND nonce from the RS for anti- replay protection. The 178 router MUST use the CGA constructed from its certified key as the 179 source address for the RA and include a SEND CGA Option and a SEND 180 Signature Option with the SEND signature of the message. The SEND 181 signature covers all fields in the RA, including the 128 bit source 182 and destination addresses and ICMP checksum as described in 183 [RFC3971], except for the Signature Option itself. The RA is then 184 unicast back to the host. The ND shared key MUST be stored by the 185 router for future use, indexed by the host's CGA, and the 186 authentication AT and a lifetime MUST be recorded with the key. 188 3.3. Receiving Router Advertisements 190 Upon receipt of one or more RA secured with SEND and having the ND 191 Shared Key Reply Option, the host MUST first validate the RA as 192 described in [RFC3971]. Normally the host will have obtained the 193 router's certification path to validate an RA prior to sending the RS 194 and the host MUST check to ensure that the key used to sign the RA is 195 the router's certified public key. If the host does not have the 196 router's certification path cached, it MUST use the SEND 197 Certification Path Solicitation (CPS) / Certification Path 198 Advertisement (CPA) messages to obtain the certification path to 199 validate the key. If the message is not signed by a certified key , 200 the message MUST be dropped. 202 The host MUST use it's private key to decrypt the ND shared key. The 203 host MUST use the returned authentication AT indicated in the RA. 204 The host MUST index the ND shared keys with the router's CGA, and the 205 algorithm type and the lifetime are also stored. 207 When the host moves from a router to another router, it is possible 208 that the new router has no any idea about the ND Shared Key which is 209 provided by the old one. A solution is that the host erases the ND 210 shared key and re-use CGA after a certain number of NS 211 retransmissions. 213 3.4. ND operation secured by a shared key 215 When the host sends Neighbor Solicitation (NS), Neighbor 216 Advertisement (NA), Router Solicitation(RS) to the router, the host 217 SHOULD check if there is a ND shared key for the router. The host 218 SHOULD utilize the shared key and the corresponding authentication 219 algorithm type to generate an authenticator for the message if a ND 220 shared key exists; otherwise, the host behaves according to[RFC3971], 221 or requests a ND shared key using the procedure defined in this 222 document. The authenticator is conveyed in Neighbor Discovery 223 Authenticator Option defined in Section 4.3. 225 When the router sends Neighbor Solicitation (NS), Neighbor 226 Advertisement (NA), Router Solicitation(RS), Redirect, Router 227 Advertisement(RA) to the host, the router SHOULD check if there is a 228 ND shared key for the host. The router SHOULD utilize the shared key 229 and the corresponding authentication algorithm to generate an 230 authenticator for the message if a ND shared key exists; 231 otherwise,the router behaves according to [RFC3971]. The 232 authenticator is conveyed in Neighbor Discovery Authenticator Option 233 defined in Section 4.3. 235 3.5. Key Generation and Lifetime 237 The router MUST randomly generate a key having sufficient strength to 238 match the authentication algorithm. Some authentication algorithms 239 specify a required key size. The router MUST generate a unique key 240 along with a lifetime for each CGA public key of a host. 242 Before the lifetime expires, the host SHOULD apply for a new ND 243 shared key using the procedure defined in this document. Once the ND 244 shared key expires, the host and the router SHOULD discard the key. 246 4. Message Formats 248 4.1. ND Shared Key Request Option 250 The ND Shared Key Request Option is a IPv6 Neighbor Discovery 251 [RFC4861] option in TLV format. The ND Shared Key Request Option is 252 included in the RS message along with the SEND CGA Option, RSA 253 Signature Option, and Nonce Option. 255 0 1 2 3 256 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Type | Length | AT | Reserved | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Reserved | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Fields: 265 Type: To be assigned by IANA. 267 Length: The length of the option in units of 8 octets, 268 including the Type and Length fields. The value 0 269 is invalid. The receiver MUST discard a message 270 that contains this value. 272 AT: authentication Algorithm Type 273 1 HMAC_SHA1 274 2 HMAC_SHA256 275 3 MD5 277 Reserved: A 40-bit field reserved for future use. 279 4.2. ND Shared Key Reply Option 281 ND Shared Key Reply Option is a IPv6 Neighbor Discovery [RFC4861] 282 option in TLV format. The Reply Option is included in the RA message 283 along with the SEND CGA Option, RSA Signature Option, and Nonce 284 Option. 286 0 1 2 3 287 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Type | Length | AT | Reserved | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Key Lifetime | | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | | 294 | | 295 . . 296 . Encrypted ND Shared Key . 297 . . 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Fields: 303 Type: To be assigned by IANA. 305 Length: The length of the option in units of 8 octets, 306 including the Type and Length fields. The value 0 307 is invalid. The receiver MUST discard a message 308 that contains this value. 310 AT: authentication Algorithm Type 311 1 HMAC_SHA1 312 2 HMAC_SHA256 313 3 MD5 315 Reserved: A 8-bit field reserved for future use. The value 316 MUST be initialized to zero by the sender and MUST 317 be ignored by the receiver. 319 Key Lifetime: 320 lifetime of the ND shared key, in seconds. 322 Encrypted ND Shared Key: 324 The shared key, encrypted with the host's 325 ND shared key encryption public key, using the 326 RSAES-PKCS1-v1_5 format [RFC3447]. 328 4.3. Neighbor Discovery Authenticator Option 330 This option MUST be present all ND signaling between the host and the 331 router. This option specifies how to compute and verify a MAC using 332 the established ND shared key. 334 0 1 2 3 335 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Type | Length | Reserved | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | | 340 . . 341 . Authenticator . 342 . . 343 | | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 Fields: 348 Type: To be assigned by IANA. 350 Length: The length of the option in units of 8 octets, 351 including the Type and Length fields. The value 0 352 is invalid. The receiver MUST discard a message 353 that contains this value. 355 Reserved: A 8-bit field reserved for future use. The value 356 MUST be initialized to zero by the sender and MUST 357 be ignored by the receiver. 359 Authenticator: 361 cryptographic value which can be used to determine 362 that the message in question comes from the right 363 authority 365 Rules for calculating the Authenticator value are the following: 367 ND Data = host's source address | router's address | ICMP Data 368 Authenticator = First (96, Algorithm( ND Shared Key, ND Data)) 370 The algorithm type for authenticator is negotiated between the host 371 and the router through ND Shared Key Request Option and ND Shared Key 372 Reply Option. 374 5. IANA consideration 376 Three new IPv6 Neighbor Discovery options, the ND Shared Key Request 377 Option, ND Shared Key Reply Option, and Neighbor Discovery 378 Authenticator Option, are defined, and require IPv6 Neighbor 379 Discovery option type codes from IANA. 381 6. Security Considerations 383 This document describes a shared key provisioning protocol for the 384 Neighbor Discovery protocol. The key provisioning protocol utilizes 385 a public key of SEND. General security considerations involving CGAs 386 apply to the protocol described in this document, see [RFC4861] for a 387 discussion of security considerations around CGAs. 389 7. Acknowledgements 391 Jean-Michel Combes is partly funded by MobiSEND, a research project 392 supported by the French 'National Research Agency' (ANR). 394 8. References 396 8.1. Normative References 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, March 1997. 401 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 402 Neighbor Discovery (SEND)", RFC 3971, March 2005. 404 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 405 RFC 3972, March 2005. 407 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 408 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 409 September 2007. 411 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 412 Madanapalli, "Transmission of IPv6 via the IPv6 413 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 414 February 2008. 416 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 417 Generation Partnership Project (3GPP) Standards", 418 RFC 3314, September 2002. 420 8.2. Informative references 422 [I-D.ietf-mipshop-handover-key] 423 Kempf, J., "Distributing a Symmetric FMIPv6 Handover Key 424 using SEND", draft-ietf-mipshop-handover-key-03 (work in 425 progress), October 2007. 427 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 428 Standards (PKCS) #1: RSA Cryptography Specifications 429 Version 2.1", RFC 3447, February 2003. 431 [I-D.chakrabarti-6lowpan-ipv6-nd] 432 Chakrabarti, S. and E. Nordmark, "LowPan Neighbor 433 Discovery Extensions", 434 draft-chakrabarti-6lowpan-ipv6-nd-04 (work in progress), 435 November 2007. 437 Authors' Addresses 439 Frank Xia 440 Huawei 441 1700 Alma Dr. Suite 500 442 Plano, TX 75075 444 Phone: +1 972-509-5599 445 Email: xiayangsong@huawei.com 447 Suresh Krishnan 448 Ericsson Research 449 8400 Decarie Blvd. 450 Town of Mount Royal, QC Canada 452 Phone: +1 514 345 7900 453 Email: Suresh.Krishnan@ericsson.com 455 Wassim Haddad 456 Qualcomm 458 Phone: 459 Email: whaddad@qualcomm.com 461 Jean-Michel Combes 462 Orange Labs R&D 463 38 rue du General Leclerc 464 Issy-les-Moulineaux Cedex 9, France 92794 466 Phone: 467 Email: jeanmichel.combes@gmail.com 469 Chunqiang Li 470 Huawei 471 No.91 BaiXia Rd. 472 Nanjing, China 210001 474 Phone: 475 Email: li.chunqiang@huawei.com 477 Full Copyright Statement 479 Copyright (C) The IETF Trust (2008). 481 This document is subject to the rights, licenses and restrictions 482 contained in BCP 78, and except as set forth therein, the authors 483 retain all their rights. 485 This document and the information contained herein are provided on an 486 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 487 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 488 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 489 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 490 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 491 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 493 Intellectual Property 495 The IETF takes no position regarding the validity or scope of any 496 Intellectual Property Rights or other rights that might be claimed to 497 pertain to the implementation or use of the technology described in 498 this document or the extent to which any license under such rights 499 might or might not be available; nor does it represent that it has 500 made any independent effort to identify any such rights. Information 501 on the procedures with respect to rights in RFC documents can be 502 found in BCP 78 and BCP 79. 504 Copies of IPR disclosures made to the IETF Secretariat and any 505 assurances of licenses to be made available, or the result of an 506 attempt made to obtain a general license or permission for the use of 507 such proprietary rights by implementers or users of this 508 specification can be obtained from the IETF on-line IPR repository at 509 http://www.ietf.org/ipr. 511 The IETF invites any interested party to bring to its attention any 512 copyrights, patents or patent applications, or other proprietary 513 rights that may cover technology that may be required to implement 514 this standard. Please address the information to the IETF at 515 ietf-ipr@ietf.org.