idnits 2.17.1 draft-ietf-6lo-ap-nd-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC8505, but the abstract doesn't seem to directly say this. It does mention RFC8505 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 March 2020) is 1509 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) ** Downref: Normative reference to an Informational RFC: RFC 7748 ** Downref: Normative reference to an Informational RFC: RFC 8032 ** Downref: Normative reference to an Informational RFC: RFC 6234 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-4' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-19 == Outdated reference: A later version (-23) exists of draft-ietf-lwig-curve-representations-08 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo P. Thubert, Ed. 3 Internet-Draft Cisco 4 Updates: 8505 (if approved) B. Sarikaya 5 Intended status: Standards Track 6 Expires: 10 September 2020 M. Sethi 7 Ericsson 8 R. Struik 9 Struik Security Consultancy 10 9 March 2020 12 Address Protected Neighbor Discovery for Low-power and Lossy Networks 13 draft-ietf-6lo-ap-nd-20 15 Abstract 17 This document updates the 6LoWPAN Neighbor Discovery (ND) protocol 18 defined in RFC 6775 and RFC 8505. The new extension is called 19 Address Protected Neighbor Discovery (AP-ND) and it protects the 20 owner of an address against address theft and impersonation attacks 21 in a low-power and lossy network (LLN). Nodes supporting this 22 extension compute a cryptographic identifier (Crypto-ID) and use it 23 with one or more of their Registered Addresses. The Crypto-ID 24 identifies the owner of the Registered Address and can be used to 25 provide proof of ownership of the Registered Addresses. Once an 26 address is registered with the Crypto-ID and a proof-of-ownership is 27 provided, only the owner of that address can modify the registration 28 information, thereby enforcing Source Address Validation. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 10 September 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. Additional References . . . . . . . . . . . . . . . . . . 5 68 3. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 5 69 4. New Fields and Options . . . . . . . . . . . . . . . . . . . 6 70 4.1. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 6 71 4.2. Updated EARO . . . . . . . . . . . . . . . . . . . . . . 6 72 4.3. Crypto-ID Parameters Option . . . . . . . . . . . . . . . 7 73 4.4. NDP Signature Option . . . . . . . . . . . . . . . . . . 9 74 5. Protocol Scope . . . . . . . . . . . . . . . . . . . . . . . 11 75 6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 12 76 6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 13 77 6.2. NDPSO generation and verification . . . . . . . . . . . . 15 78 6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 16 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 17 81 7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 18 82 7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 19 83 7.4. Implementation Attacks . . . . . . . . . . . . . . . . . 19 84 7.5. Cross-Algorithm and Cross-Protocol Attacks . . . . . . . 20 85 7.6. Compromised 6LR . . . . . . . . . . . . . . . . . . . . . 20 86 7.7. Correlating Registrations . . . . . . . . . . . . . . . . 21 87 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21 88 8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 21 89 8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 21 90 8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 22 91 8.4. New Codepoints Associated to JWK Encoding . . . . . . . . 22 92 8.4.1. COSE Elliptic Curves Registration . . . . . . . . . . 23 93 8.4.2. COSE Algorithms Registration . . . . . . . . . . . . 23 94 8.4.3. JOSE Elliptic Curves Registration . . . . . . . . . . 23 95 8.4.4. JOSE Algorithms Registration . . . . . . . . . . . . 24 96 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 97 10. Normative References . . . . . . . . . . . . . . . . . . . . 24 98 11. Informative references . . . . . . . . . . . . . . . . . . . 25 99 Appendix A. Requirements Addressed in this Document . . . . . . 28 100 Appendix B. Representation Conventions . . . . . . . . . . . . . 28 101 B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 28 102 B.2. Integer Representation for ECDSA signatures . . . . . . . 29 103 B.3. Alternative Representations of Curve25519 . . . . . . . . 30 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 106 1. Introduction 108 Neighbor Discovery Optimizations for 6LoWPAN networks [RFC6775] 109 (6LoWPAN ND) adapts the original IPv6 Neighbor Discovery (IPv6 ND) 110 protocols defined in [RFC4861] and [RFC4862] for constrained low- 111 power and lossy network (LLN). In particular, 6LoWPAN ND introduces 112 a unicast host Address Registration mechanism that reduces the use of 113 multicast compared to the Duplicate Address Detection (DAD) mechanism 114 defined in IPv6 ND. 6LoWPAN ND defines a new Address Registration 115 Option (ARO) that is carried in the unicast Neighbor Solicitation 116 (NS) and Neighbor Advertisement (NA) messages exchanged between a 117 6LoWPAN Node (6LN) and a 6LoWPAN Router (6LR). It also defines the 118 Duplicate Address Request (DAR) and Duplicate Address Confirmation 119 (DAC) messages between the 6LR and the 6LoWPAN Border Router (6LBR). 120 In LLN networks, the 6LBR is the central repository of all the 121 registered addresses in its domain. 123 The registration mechanism in "Neighbor Discovery Optimization for 124 Low-power and Lossy Networks" [RFC6775] (aka 6LoWPAN ND) prevents the 125 use of an address if that address is already registered in the subnet 126 (first come first serve). In order to validate address ownership, 127 the registration mechanism enables the 6LR and 6LBR to validate the 128 association between the registered address of a node, and its 129 Registration Ownership Verifier (ROVR). The ROVR is defined in 130 "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] 131 and it can be derived from the MAC address of the device (using the 132 64-bit Extended Unique Identifier EUI-64 address format specified by 133 IEEE). However, the EUI-64 can be spoofed, and therefore, any node 134 connected to the subnet and aware of a registered-address-to-ROVR 135 mapping could effectively fake the ROVR. This would allow the an 136 attacker to steal the address and redirect traffic for that address. 137 [RFC8505] defines an Extended Address Registration Option (EARO) 138 option that allows to transport alternate forms of ROVRs, and is a 139 pre-requisite for this specification. 141 In this specification, a 6LN generates a cryptographic ID (Crypto-ID) 142 and places it in the ROVR field during the registration of one (or 143 more) of its addresses with the 6LR(s). Proof of ownership of the 144 Crypto-ID is passed with the first registration exchange to a new 145 6LR, and enforced at the 6LR. The 6LR validates ownership of the 146 cryptographic ID before it creates any new registration state, or 147 changes existing information. 149 The protected address registration protocol proposed in this document 150 provides the same conceptual benefit as Source Address Validation 151 (SAVI) [RFC7039] that only the owner of an IPv6 address may source 152 packets with that address. As opposed to [RFC7039], which relies on 153 snooping protocols, the protection is based on a state that is 154 installed and maintained in the network by the owner of the address. 155 With this specification, a 6LN may use a 6LR for forwarding an IPv6 156 packets if and only if it has registered the address used as source 157 of the packet with that 6LR. 159 With the 6lo adaptation layer in [RFC4944] and [RFC6282], a 6LN can 160 obtain a better compression for an IPv6 address with an Interface ID 161 (IID) that is derived from a Layer-2 address. As a side note, this 162 is incompatible with Secure Neighbor Discovery (SeND) [RFC3971] and 163 Cryptographically Generated Addresses (CGAs) [RFC3972], since they 164 derive the IID from cryptographic keys, whereas this specification 165 separates the IID and the key material. 167 2. Terminology 169 2.1. BCP 14 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 173 "OPTIONAL" in this document are to be interpreted as described in BCP 174 14 [RFC2119] [RFC8174] when, and only when, they appear in all 175 capitals, as shown here. 177 2.2. Abbreviations 179 This document uses the following abbreviations: 181 6BBR: 6LoWPAN Backbone Router 182 6LBR: 6LoWPAN Border Router 183 6LN: 6LoWPAN Node 184 6LR: 6LoWPAN Router 185 EARO: Extended Address Registration Option 186 CIPO: Crypto-ID Parameters Option 187 LLN: Low-Power and Lossy Network 188 NA: Neighbor Advertisement 189 ND: Neighbor Discovery 190 NDPSO: Neighbor Discovery Protocol Signature Option 191 NS: Neighbor Solicitation 192 ROVR: Registration Ownership Verifier 193 RA: Router Advertisement 194 RS: Router Solicitation 195 RSAO: RSA Signature Option 196 TID: Transaction ID 198 2.3. Additional References 200 The reader may get additional context for this specification from the 201 following references: 203 * "SEcure Neighbor Discovery (SEND)" [RFC3971], 205 * "Cryptographically Generated Addresses (CGA)" [RFC3972], 207 * "Neighbor Discovery for IP version 6" [RFC4861] , 209 * "IPv6 Stateless Address Autoconfiguration" [RFC4862], and 211 * "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 212 Overview, Assumptions, Problem Statement, and Goals " [RFC4919]. 214 3. Updating RFC 8505 216 Section 5.3 of [RFC8505] introduces the ROVR that is used to detect 217 and reject duplicate registrations in the DAD process. The ROVR is a 218 generic object that is designed for both backward compatibility and 219 the capability to introduce new computation methods in the future. 220 Using a Crypto-ID per this specification is the RECOMMENDED method. 221 Section 7.3 discusses collisions when heterogeneous methods to 222 compute the ROVR field coexist inside a same network. 224 This specification introduces a new token called a cryptographic 225 identifier (Crypto-ID) that is transported in the ROVR field and used 226 to prove indirectly the ownership of an address that is being 227 registered by means of [RFC8505]. The Crypto-ID is derived from a 228 cryptographic public key and additional parameters. 230 The overall mechanism requires the support of Elliptic Curve 231 Cryptography (ECC) and of a hash function as detailed in Section 6.2. 232 To enable the verification of the proof, the registering node needs 233 to supply certain parameters including a nonce and a signature that 234 will demonstrate that the node possesses the private-key 235 corresponding to the public-key used to build the Crypto-ID. 237 The elliptic curves and the hash functions listed in Table 2 in 238 Section 8.3 can be used with this specification; more may be added in 239 the future to the IANA registry. The signature scheme that specifies 240 which combination is used (including the curve and the representation 241 conventions) is signaled by a Crypto-Type in a new IPv6 ND Crypto-ID 242 Parameters Option (CIPO, see Section 4.3) that contains the 243 parameters that are necessary for the proof, a Nonce option 244 ([RFC3971]) and a NDP Signature option (Section 4.4). The NA(EARO) 245 is modified to enable a challenge and transport a Nonce option. 247 4. New Fields and Options 249 4.1. New Crypto-ID 251 The Crypto-ID is transported in the ROVR field of the EARO option and 252 the EDAR message, and is associated with the Registered Address at 253 the 6LR and the 6LBR. The ownership of a Crypto-ID can be 254 demonstrated by cryptographic mechanisms, and by association, the 255 ownership of the Registered Address can be ascertained. 257 A node in possession of the necessary cryptographic primitives SHOULD 258 use Crypto-ID by default as ROVR in its registrations. Whether a 259 ROVR is a Crypto-ID is indicated by a new "C" flag in the NS(EARO) 260 message. 262 The Crypto-ID is derived from the public key and a modifier as 263 follows: 265 1. The hash function indicated by the Crypto-Type is applied to the 266 CIPO. Note that all the reserved and padding bits MUST be set to 267 zero. 268 2. The leftmost bits of the resulting hash, up to the desired size, 269 are used as the Crypto-ID. 271 At the time of this writing, a minimal size for the Crypto-ID of 128 272 bits is RECOMMENDED unless backward compatibility is needed 273 [RFC8505]. This value is bound to augment in the future. 275 4.2. Updated EARO 277 This specification updates the EARO option to enable the use of the 278 ROVR field to transport the Crypto-ID. The resulting format is as 279 follows: 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Type | Length | Status | Opaque | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 |Rsvd |C| I |R|T| TID | Registration Lifetime | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | | 289 ... Registration Ownership Verifier (ROVR) ... 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Figure 1: Enhanced Address Registration Option 295 Type: 33 297 Length: Defined in [RFC8505] and copied in associated CIPO. 299 Status: Defined in [RFC8505]. 301 Opaque: Defined in [RFC8505]. 303 Rsvd (Reserved): 3-bit unsigned integer. It MUST be set to zero by 304 the sender and MUST be ignored by the receiver. 306 C: This "C" flag is set to indicate that the ROVR field contains a 307 Crypto-ID and that the 6LN MAY be challenged for ownership as 308 specified in this document. 310 I, R, T: Defined in [RFC8505]. 312 TID: Defined in [RFC8505]. 314 Registration Ownership Verifier (ROVR): When the "C" flag is set, 315 this field contains a Crypto-ID. 317 This specification uses Status values "Validation Requested" and 318 "Validation Failed", which are defined in [RFC8505]. 320 this specification does not define any new Status value. 322 4.3. Crypto-ID Parameters Option 324 This specification defines the Crypto-ID Parameters Option (CIPO). 325 The CIPO carries the parameters used to form a Crypto-ID. 327 In order to provide cryptographic agility [BCP 201], this 328 specification supports different elliptic curves, indicated by a 329 Crypto-Type field: 331 * NIST P-256 [FIPS186-4] MUST be supported by all implementations. 333 * The Edwards-Curve Digital Signature Algorithm (EdDSA) curve 334 Ed25519 (PureEdDSA) [RFC8032] MAY be supported as an alternative. 336 * This specification uses signature schemes that target similar 337 cryptographic strength but rely on different curves, hash 338 functions, signature algorithms, and/or representation 339 conventions. Future specification may extend this to different 340 cryptographic algorithms and key sizes, e.g., to provide better 341 security properties or a simpler implementation. 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Type | Length |Reserved1| Public Key Length | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Crypto-Type | Modifier | EARO Length | Reserved2 | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | | 351 . . 352 . Public Key (variable length) . 353 . . 354 | | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | | 357 . Padding . 358 | | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 Figure 2: Crypto-ID Parameters Option 363 Type: 8-bit unsigned integer. to be assigned by IANA, see Table 1. 365 Length: 8-bit unsigned integer. The length of the option in units 366 of 8 octets. 368 Reserved1: 5-bit unsigned integer. It MUST be set to zero by the 369 sender and MUST be ignored by the receiver. 371 Public Key Length: 11-bit unsigned integer. The length of the 372 Public Key field in bytes. 374 Crypto-Type: 8-bit unsigned integer. The type of cryptographic 375 algorithm used in calculation Crypto-ID indexed by IANA in the 376 "Crypto-Type Subregistry" in the "Internet Control Message 377 Protocol version 6 (ICMPv6) Parameters" (see Section 8.3). 379 Modifier: 8-bit unsigned integer. Set to an arbitrary value by the 380 creator of the Crypto-ID. The role of the modifier is to enable 381 the formation of multiple Crypto-IDs from a same key pair, which 382 reduces the traceability and thus improves the privacy of a 383 constrained node that could not maintain many key-pairs. 385 EARO Length: 8-bit unsigned integer. The option length of the EARO 386 that contains the Crypto-ID associated with the CIPO. 388 Reserved2: 16-bit unsigned integer. It MUST be set to zero by the 389 sender and MUST be ignored by the receiver. 391 Public Key: A variable-length field, size indicated in the Public 392 Key Length field. JWK-Encoded Public Key [RFC7517]. 394 Padding: A variable-length field completing the Public Key field to 395 align to the next 8-bytes boundary. It MUST be set to zero by the 396 sender and MUST be ignored by the receiver. 398 The implementation of multiple hash functions in a constrained 399 devices may consume excessive amounts of program memory. This 400 specification enables the use of SHA-256 [RFC6234] for all the 401 supported ECC curves. 403 Some code factorization is also possible for the ECC computation 404 itself. [CURVE-REPRESENTATIONS] provides information on how to 405 represent Montgomery curves and (twisted) Edwards curves as curves in 406 short-Weierstrass form and illustrates how this can be used to 407 implement elliptic curve computations using existing implementations 408 that already provide, e.g., ECDSA and ECDH using NIST [FIPS186-4] 409 prime curves. For more details on representation conventions, we 410 refer to Appendix B. 412 4.4. NDP Signature Option 414 This specification defines the NDP Signature Option (NDPSO). The 415 NDPSO carries the signature that proves the ownership of the Crypto- 416 ID. The format of the NDPSO is illustrated in Figure 3. 418 As opposed to the RSA Signature Option (RSAO) defined in section 5.2. 419 of SEND [RFC3971], the NDPSO does not have a key hash field. 420 Instead, the leftmost 128 bits of the ROVR field in the EARO are used 421 as hash to retrieve the CIPO that contains the key material used for 422 signature verification, left-padded if needed. 424 Another difference is that the NDPSO signs a fixed set of fields as 425 opposed to all options that appear prior to it in the ND message that 426 bears the signature. This allows to elide a CIPO that the 6LR 427 already received, at the expense of the capability to add arbitrary 428 options that would signed with a RSAO. 430 An ND message that carries an NDPSO MUST have one and only one EARO. 431 The EARO MUST contain a Crypto-ID in the ROVR field, and the Crypto- 432 ID MUST be associated with the keypair used for the Digital Signature 433 in the NDPSO. 435 The CIPO may be present in the same message as the NDPSO. If it is 436 not present, it can be found in an abstract table that was created by 437 a previous message and indexed by the hash. 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Type | Length |Reserved1| Signature Length | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Reserved2 | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | | 447 . . 448 . Digital Signature (variable length) . 449 . . 450 | | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | | 453 . Padding . 454 | | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Figure 3: NDP signature Option 459 Type: to be assigned by IANA, see Table 1. 461 Length: 8-bit unsigned integer. The length of the option in units 462 of 8 octets. 464 Reserved1: 5-bit unsigned integer. It MUST be set to zero by the 465 sender and MUST be ignored by the receiver. 467 Digital Signature Length: 11-bit unsigned integer. The length of 468 the Digital Signature field in bytes. 470 Reserved2: 32-bit unsigned integer. It MUST be set to zero by the 471 sender and MUST be ignored by the receiver. 473 Digital Signature: A variable-length field containing a digital 474 signature. The length and computation of the digital signature 475 both depend on the Crypto-Type which is found in the associated 476 CIPO. For the values of the Crypto-Type that are defined in this 477 specification, and unless specified otherwise for a future value 478 of the Crypto-Type, the signature is computed as detailed in 479 Section 6.2. 481 Padding: A variable-length field completing the Digital Signature 482 field to align to the next 8-bytes boundary. It MUST be set to 483 zero by the sender and MUST be ignored by the receiver. 485 5. Protocol Scope 487 The scope of the protocol specified here is a 6LoWPAN LLN, typically 488 a stub network connected to a larger IP network via a Border Router 489 called a 6LBR per [RFC6775]. A 6LBR has sufficient capability to 490 satisfy the needs of duplicate address detection. 492 The 6LBR maintains registration state for all devices in its attached 493 LLN. Together with the first-hop router (the 6LR), the 6LBR assures 494 uniqueness and grants ownership of an IPv6 address before it can be 495 used in the LLN. This is in contrast to a traditional network that 496 relies on IPv6 address auto-configuration [RFC4862], where there is 497 no guarantee of ownership from the network, and each IPv6 Neighbor 498 Discovery packet must be individually secured [RFC3971]. 500 ---+-------- ............ 501 | External Network 502 | 503 +-----+ 504 | | 6LBR 505 +-----+ 506 o o o 507 o o o o 508 o o LLN o o o 509 o o o (6LR) 510 o (6LN) 512 Figure 4: Basic Configuration 514 In a mesh network, the 6LR is directly connected to the host device. 515 This specification mandates that the peer-wise layer-2 security is 516 deployed so that all the packets from a particular host are securely 517 identifiable by the 6LR. The 6LR may be multiple hops away from the 518 6LBR. Packets are routed between the 6LR and the 6LBR via other 519 6LRs. This specification mandates that a chain of trust is 520 established so that a packet that was validated by the first 6LR can 521 be safely routed by other on-path 6LRs to the 6LBR. 523 6. Protocol Flows 525 The 6LR/6LBR ensures first-come/first-serve by storing the ROVR 526 associated to the address being registered upon the first 527 registration and rejecting a registration with a different ROVR 528 value. A 6LN can claim any address as long as it is the first to 529 make that claim. After a successful registration, the 6LN becomes 530 the owner of the registered address and the address is bound to the 531 ROVR value in the 6LR/6LBR registry. 533 This specification enables the 6LR to challenge the 6LN to verify its 534 ownership of the binding by placing a Crypto-ID in the ROVR. The 535 challenge can happen at any time at the discretion of the 6LR. The 536 6LR MUST challenge the 6LN when it creates a binding and when a new 537 registration attempts to change a parameter of the binding that 538 identifies the 6LN, for instance its Source Link-Layer Address. The 539 verification protects against a rogue that would steal an address and 540 attract its traffic, or use it as source address. 542 The challenge can also triggered by the 6LBR, e.g., to enforce a 543 global policy. In that case, the 6LBR returns a status of 544 "Validation Requested" in the DAR/DAC exchange, which is echoed by 545 the 6LR in the NA (EARO) back to the registering node. A valid 546 registration in the 6LR or the 6LBR MUST NOT be altered until the 547 challenge is complete. 549 A node may use more than one IPv6 address at the same time. The 550 separation of the address and the cryptographic material avoids the 551 need for the constrained device to compute multiple keys for multiple 552 addresses. The 6LN MAY use the same Crypto-ID to prove the ownership 553 of multiple IPv6 addresses. The 6LN MAY also derive multiple Crypto- 554 IDs from a same key. 556 6.1. First Exchange with a 6LR 558 A 6LN registers to a 6LR that is one hop away from it with the "C" 559 flag set in the EARO, indicating that the ROVR field contains a 560 Crypto-ID. The Target Address in the NS message indicates the IPv6 561 address that the 6LN is trying to register [RFC8505]. The on-link 562 (local) protocol interactions are shown in Figure 5. If the 6LR does 563 not have a state with the 6LN that is consistent with the NS(EARO), 564 then it replies with a challenge NA (EARO, status=Validation 565 Requested) that contains a Nonce Option (shown as NonceLR in 566 Figure 5). 568 The Nonce option contains a nonce value that, to the extent possible 569 for the implementation, was never employed in association with the 570 key pair used to generate the Crypto-ID. This specification inherits 571 from [RFC3971] that simply indicates that the nonce is a random 572 value. Ideally, an implementation uses an unpredictable 573 cryptographically random value [BCP 106]. But that may be 574 impractical in some LLN scenarios where the devices do not have a 575 guaranteed sense of time and for which computing complex hashes is 576 detrimental to the battery lifetime. Alternatively, the device may 577 use an always-incrementing value saved in the same stable storage as 578 the key, so they are lost together, and starting at a best effort 579 random value, either as the nonce value or as a component to its 580 computation. 582 The 6LN replies to the challenge with an NS(EARO) that includes a new 583 Nonce option (shown as NonceLN in Figure 5), the CIPO (Section 4.3), 584 and the NDPSO containing the signature. Both Nonces are included in 585 the signed material. This provides a "contributory behavior", so 586 that either party that knows it generates a good quality nonce knows 587 that the protocol will be secure. 589 The 6LR MUST store the information associated to a Crypto-ID on the 590 first NS exchange where it appears in a fashion that the CIPO 591 parameters can be retrieved from the Crypto-ID alone. 593 6LN 6LR 594 | | 595 |<------------------------- RA -------------------------| 596 | | ^ 597 |---------------- NS with EARO (Crypto-ID) ------------>| | 598 | | option 599 |<- NA with EARO (status=Validation Requested), NonceLR-| | 600 | | v 601 |------- NS with EARO, CIPO, NonceLN and NDPSO -------->| 602 | | 603 |<------------------- NA with EARO ---------------------| 604 | | 605 ... 606 | | 607 |--------------- NS with EARO (Crypto-ID) ------------->| 608 | | 609 |<------------------- NA with EARO ---------------------| 610 | | 611 ... 612 | | 613 |--------------- NS with EARO (Crypto-ID) ------------->| 614 | | 615 |<------------------- NA with EARO ---------------------| 616 | | 618 Figure 5: On-link Protocol Operation 620 The steps for the registration to the 6LR are as follows: 622 * Upon the first exchange with a 6LR, a 6LN will be challenged to 623 prove ownership of the Crypto-ID and the Target Address being 624 registered in the Neighbor Solicitation message. When a 6LR 625 receives a NS(EARO) registration with a new Crypto-ID as a ROVR, 626 and unless the registration is rejected for another reason, it 627 MUST challenge by responding with a NA(EARO) with a status of 628 "Validation Requested". 630 * Upon receiving a first NA(EARO) with a status of "Validation 631 Requested" from a 6LR, the registering node SHOULD retry its 632 registration with a Crypto-ID Parameters Option (CIPO) 633 (Section 4.3) that contains all the necessary material for 634 building the Crypto-ID, the NonceLN that it generated, and the NDP 635 signature (Section 4.4) option that proves its ownership of the 636 Crypto-ID and intent of registering the Target Address. In 637 subsequent revalidation with the same 6LR, the 6LN MAY try to omit 638 the CIPO to save bandwidth, with the expectation that the 6LR 639 saved it. If the validation fails and it gets challenged again, 640 then it SHOULD add the CIPO again. 642 * In order to validate the ownership, the 6LR performs the same 643 steps as the 6LN and rebuilds the Crypto-ID based on the 644 parameters in the CIPO. If the rebuilt Crypto-ID matches the 645 ROVR, the 6LN also verifies the signature contained in the NDPSO 646 option. If at that point the signature in the NDPSO option can be 647 verified, then the validation succeeds. Otherwise the validation 648 fails. 650 * If the 6LR fails to validate the signed NS(EARO), it responds with 651 a status of "Validation Failed". After receiving a NA(EARO) with 652 a status of "Validation Failed", the registering node SHOULD try 653 to register an alternate target address in the NS message. 655 6.2. NDPSO generation and verification 657 The signature generated by the 6LN to provide proof-of-ownership of 658 the private-key is carried in the NDP Signature Option (NDPSO). It 659 is generated by the 6LN in a fashion that depends on the Crypto-Type 660 (see Table 2 in Section 8.3) chosen by the 6LN as follows: 662 * Concatenate the following in the order listed: 664 1. The 128-bit Message Type tag [RFC3972] (in network byte 665 order). For this specification the tag is 0x8701 55c8 0cca 666 dd32 6ab7 e415 f148 84d0. (The tag value has been generated 667 by the editor of this specification on random.org). 668 2. JWK-encoded public key 669 3. the 16-byte Target Address (in network byte order) sent in the 670 Neighbor Solicitation (NS) message. It is the address which 671 the 6LN is registering with the 6LR and 6LBR. 672 4. NonceLR received from the 6LR (in network byte order) in the 673 Neighbor Advertisement (NA) message. The nonce is at least 6 674 bytes long as defined in [RFC3971]. 675 5. NonceLN sent from the 6LN (in network byte order). The nonce 676 is at least 6 bytes long as defined in [RFC3971]. 677 6. 1-byte Option Length of the EARO containing the Crypto-ID. 678 7. 1-byte Crypto-Type value sent in the CIPO. 680 * Apply the hash function (if any) specified by the Crypto-Type to 681 the concatenated data, e.g., hash the resulting data using SHA- 682 256. 684 * Apply the signature algorithm specified by the Crypto-Type, e.g., 685 sign the hash output with ECDSA (if curve P-256 is used) or sign 686 the hash with EdDSA (if curve Ed25519 (PureEdDSA)). 688 The 6LR on receiving the NDPSO and CIPO options first checks that the 689 EARO Length in the CIPO matches the length of the EARO. If so it 690 regenerates the Crypto-ID based on the CIPO to make sure that the 691 leftmost bits up to the size of the ROVR match. 693 If and only if the check is successful, it tries to verify the 694 signature in the NDPSO option using the following: 696 * Concatenate the following in the order listed: 698 1. 128-bit type tag (in network byte order) 699 2. JWK-encoded public key received in the CIPO 700 3. the 16-byte Target Address (in network byte order) received in 701 the Neighbor Solicitation (NS) message. It is the address 702 which the 6LN is registering with the 6LR and 6LBR. 703 4. NonceLR sent in the Neighbor Advertisement (NA) message. The 704 nonce is at least 6 bytes long as defined in [RFC3971]. 705 5. NonceLN received from the 6LN (in network byte order) in the 706 NS message. The nonce is at least 6 bytes long as defined in 707 [RFC3971]. 708 6. 1-byte EARO Length received in the CIPO. 709 7. 1-byte Crypto-Type value received in the CIPO. 711 * Apply the hash function (if any) specified by the Crypto-Type 712 indicated by the 6LN in the CIPO to the concatenated data. 714 * Verify the signature with the public-key in the CIPO and the 715 locally computed values using the signature algorithm specified by 716 the Crypto-Type. If the verification succeeds, the 6LR propagates 717 the information to the 6LBR using a EDAR/EDAC flow. 719 * Due to the first-come/first-serve nature of the registration, if 720 the address is not registered to the 6LBR, then flow succeeds and 721 both the 6LR and 6LBR add the state information about the Crypto- 722 ID and Target Address being registered to their respective 723 abstract database. 725 6.3. Multihop Operation 727 A new 6LN that joins the network auto-configures an address and 728 performs an initial registration to a neighboring 6LR with an NS 729 message that carries an Address Registration Option (EARO) [RFC8505]. 731 In a multihop 6LoWPAN, the registration with Crypto-ID is propagated 732 to 6LBR as shown in Figure 6, which illustrates the registration flow 733 all the way to a 6LowPAN Backbone Router (6BBR) [BACKBONE-ROUTER]. 735 The 6LR and the 6LBR communicate using ICMPv6 Extended Duplicate 736 Address Request (EDAR) and Extended Duplicate Address Confirmation 737 (EDAC) messages [RFC8505] as shown in Figure 6. This specification 738 extends EDAR/EDAC messages to carry cryptographically generated ROVR. 740 The assumption is that the 6LR and the 6LBR maintain a security 741 association to authenticate and protect the integrity of the EDAR and 742 EDAC messages, so there is no need to propagate the proof of 743 ownership to the 6LBR. The 6LBR implicitly trusts that the 6LR 744 performs the verification when the 6LBR requires it, and if there is 745 no further exchange from the 6LR to remove the state, that the 746 verification succeeded. 748 6LN 6LR 6LBR 6BBR 749 | | | | 750 | NS(EARO) | | | 751 |--------------->| | | 752 | | Extended DAR | | 753 | |-------------->| | 754 | | | | 755 | | | proxy NS(EARO) | 756 | | |--------------->| 757 | | | | NS(DAD) 758 | | | | ------> 759 | | | | 760 | | | | 761 | | | | 762 | | | proxy NA(EARO) | 763 | | |<---------------| 764 | | Extended DAC | | 765 | |<--------------| | 766 | NA(EARO) | | | 767 |<---------------| | | 768 | | | | 770 Figure 6: (Re-)Registration Flow 772 7. Security Considerations 774 7.1. Inheriting from RFC 3971 776 Observations regarding the following threats to the local network in 777 [RFC3971] also apply to this specification. 779 Neighbor Solicitation/Advertisement Spoofing: Threats in section 780 9.2.1 of RFC3971 apply. AP-ND counters the threats on NS(EARO) 781 messages by requiring that the NDP Signature and CIPO options be 782 present in these solicitations. 784 Duplicate Address Detection DoS Attack: Inside the LLN, Duplicate 785 Addresses are sorted out using the ROVR, which differentiates it 786 from a movement. A different ROVR for the same Registered address 787 entails a rejection of the second registration [RFC8505]. DAD 788 coming from the backbone are not forwarded over the LLN, which 789 provides some protection against DoS attacks inside the resource- 790 constrained part of the network. Over the backbone, the EARO 791 option is present in NS/NA messages. This protects against 792 misinterpreting a movement for a duplication, and enables the 793 backbone routers to determine which one has the freshest 794 registration [RFC8505] and is thus the best candidate to validate 795 the registration for the device attached to it [BACKBONE-ROUTER]. 796 But this specification does not guarantee that the backbone router 797 claiming an address over the backbone is not an attacker. 799 Router Solicitation and Advertisement Attacks: This specification 800 does not change the protection of RS and RA which can still be 801 protected by SEND. 803 Replay Attacks A nonce should never repeat for a single key, but 804 nonces do not need to be unpredictable for secure operation. 805 Using nonces (NonceLR and NonceLN) generated by both the 6LR and 806 6LN ensure a contributory behavior that provides an efficient 807 protection against replay attacks of the challenge/response flow. 808 The quality of the protection by a random nonce depends on the 809 random number generator and its parameters (e.g., sense of time). 811 Neighbor Discovery DoS Attack: A rogue node that managed to access 812 the L2 network may form many addresses and register them using AP- 813 ND. The perimeter of the attack is all the 6LRs in range of the 814 attacker. The 6LR MUST protect itself against overflows and 815 reject excessive registration with a status 2 "Neighbor Cache 816 Full". This effectively blocks another (honest) 6LN from 817 registering to the same 6LR, but the 6LN may register to other 818 6LRs that are in its range but not in that of the rogue. 820 7.2. Related to 6LoWPAN ND 822 The threats and mediations discussed in 6LoWPAN ND [RFC6775][RFC8505] 823 also apply here, in particular denial-of-service attacks against the 824 registry at the 6LR or 6LBR. 826 Secure ND [RFC3971] forces the IPv6 address to be cryptographic since 827 it integrates the CGA as the IID in the IPv6 address. In contrast, 828 this specification saves about 1Kbyte in every NS/NA message. Also, 829 this specification separates the cryptographic identifier from the 830 registered IPv6 address so that a node can have more than one IPv6 831 address protected by the same cryptographic identifier. 833 With this specification the 6LN can freely form its IPv6 address(es) 834 in any fashion, thereby enabling either 6LoWPAN compression for IPv6 835 addresses that are derived from Layer-2 addresses, or temporary 836 addresses, e.g., formed pseudo-randomly and released in relatively 837 short cycles for privacy reasons [RFC8064][RFC8065], that cannot be 838 compressed. 840 This specification provides added protection for addresses that are 841 obtained following due procedure [RFC8505] but does not constrain the 842 way the addresses are formed or the number of addresses that are used 843 in parallel by a same entity. A rogue may still perform denial-of- 844 service attack against the registry at the 6LR or 6LBR, or attempt to 845 deplete the pool of available addresses at Layer-2 or Layer-3. 847 7.3. ROVR Collisions 849 A collision of Registration Ownership Verifiers (ROVR) (i.e., the 850 Crypto-ID in this specification) is possible, but it is a rare event. 851 Assuming in the calculations/discussion below that the hash used for 852 calculating the Crypto-ID is a well-behaved cryptographic hash and 853 thus that random collisions are the only ones possible, the formula 854 (birthday paradox) for calculating the probability of a collision is 855 1 - e^{-k^2/(2n)} where n is the maximum population size (2^64 here, 856 1.84E19) and k is the actual population (number of nodes, assuming 857 one Crypto-ID per node). 859 If the Crypto-ID is 64-bits (the least possible size allowed), the 860 chance of a collision is 0.01% for network of 66 million nodes. 861 Moreover, the collision is only relevant when this happens within one 862 stub network (6LBR). In the case of such a collision, a third party 863 node would be able to claim the registered address of an another 864 legitimate node, provided that it wishes to use the same address. To 865 prevent address disclosure and avoid the chances of collision on both 866 the ROVR and the address, it is RECOMMENDED that nodes do not derive 867 the address being registered from the ROVR. 869 7.4. Implementation Attacks 871 The signature schemes referenced in this specification comply with 872 NIST [FIPS186-4] or Crypto Forum Research Group (CFRG) standards 873 [RFC8032] and offer strong algorithmic security at roughly 128-bit 874 security level. These signature schemes use elliptic curves that 875 were either specifically designed with exception-free and constant- 876 time arithmetic in mind [RFC7748] or where one has extensive 877 implementation experience of resistance to timing attacks 878 [FIPS186-4]. However, careless implementations of the signing 879 operations could nevertheless leak information on private keys. For 880 example, there are micro-architectural side channel attacks that 881 implementors should be aware of [breaking-ed25519]. Implementors 882 should be particularly aware that a secure implementation of Ed25519 883 requires a protected implementation of the hash function SHA-512, 884 whereas this is not required with implementations of SHA-256 used 885 with ECDSA. 887 7.5. Cross-Algorithm and Cross-Protocol Attacks 889 The keypair used in this specification can be self-generated and the 890 public key does not need to be exchanged, e.g., through certificates, 891 with a third party before it is used. New keypairs can be formed for 892 new registration as the node desires. On the other hand, it is safer 893 to allocate a keypair that is used only for the address protection 894 and only for one instantiation of the signature scheme (which 895 includes choice of elliptic curve domain parameters, used hash 896 function, and applicable representation conventions). The same 897 private key MUST NOT be reused with more than one instantiation of 898 the signature scheme in this specification. The same private key 899 MUST NOT be used for anything other than computing NDPSO signatures 900 per this specification. 902 7.6. Compromised 6LR 904 This specification distributes the challenge and its validation at 905 the edge of the network, between the 6LN and its 6LR. This protects 906 against DOS attacks targeted at that central 6LBR. This also saves 907 back and forth exchanges across a potentially large and constrained 908 network. The downside is that the 6LBR needs to trust the 6LR for 909 performing the checking adequately, and the communication between the 910 6LR and the 6LBR must be protected to avoid tempering with the result 911 of the test. If a 6LR is compromised, and provided that it knows the 912 ROVR field used by the real owner of the address, the 6LR may pretend 913 that the owner has moved, is now attached to it and has successfully 914 passed the Crpto-ID validation. The 6LR may then attract and inject 915 traffic at will on behalf of that address or let a rogue take 916 ownership of the address. 918 7.7. Correlating Registrations 920 The ROVR field in the EARO introduced in [RFC8505] extends the EUI-64 921 field of the ARO defined in [RFC6775]. One of the drawbacks of using 922 an EUI-64 as ROVR is that an attacker that is aware of the 923 registrations can correlate traffic for a same 6LN across multiple 924 addresses. Section 3 of [RFC8505] indicates that the ROVR and the 925 address being registered are decoupled. A 6LN may use a same ROVR 926 for multiple registrations or a different ROVR per registration, and 927 the IID must not derive from the ROVR. In theory different 6LNs 928 could use a same ROVR as long as they do not attempt to register the 929 same address. 931 The Modifier used in the computation of the Crypto-ID enables a 6LN 932 to build different Crypto-IDs for different addresses with a same 933 keypair. Using that facility improves the privacy of the 6LN as the 934 expense of storage in the 6LR, which will need to store multiple 935 CIPOs that contain the same public key. Note that if the attacker is 936 the 6LR, then the Modifier alone does not provide a protection, and 937 the 6LN would need to use different keys and MAC addresses in an 938 attempt to obfuscate its multiple ownership. 940 8. IANA considerations 942 8.1. CGA Message Type 944 This document defines a new 128-bit value under the CGA Message Type 945 [RFC3972] name space: 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0. 947 8.2. IPv6 ND option types 949 This document registers two new ND option types under the subregistry 950 "IPv6 Neighbor Discovery Option Formats": 952 +------------------------------+-----------------+---------------+ 953 | Option Name | Suggested Value | Reference | 954 +==============================+=================+===============+ 955 | NDP Signature Option (NDPSO) | 38 | This document | 956 +------------------------------+-----------------+---------------+ 957 | Crypto-ID Parameters Option | 39 | This document | 958 | (CIPO) | | | 959 +------------------------------+-----------------+---------------+ 961 Table 1: New ND options 963 8.3. Crypto-Type Subregistry 965 IANA is requested to create a new subregistry "Crypto-Type 966 Subregistry" in the "Internet Control Message Protocol version 6 967 (ICMPv6) Parameters". The registry is indexed by an integer in the 968 interval 0..255 and contains an Elliptic Curve, a Hash Function, a 969 Signature Algorithm, and Representation Conventions, as shown in 970 Table 2, which together specify a signature scheme. The following 971 Crypto-Type values are defined in this document: 973 +----------------+---------------+---------------+---------------+ 974 | Crypto-Type | 0 (ECDSA256) | 1 (Ed25519) | 2 | 975 | value | | | (ECDSA25519) | 976 +================+===============+===============+===============+ 977 | Elliptic curve | NIST P-256 | Curve25519 | Curve25519 | 978 | | [FIPS186-4] | [RFC7748] | [RFC7748] | 979 +----------------+---------------+---------------+---------------+ 980 | Hash function | SHA-256 | SHA-512 | SHA-256 | 981 | | [RFC6234] | [RFC6234] | [RFC6234] | 982 +----------------+---------------+---------------+---------------+ 983 | Signature | ECDSA | Ed25519 | ECDSA | 984 | algorithm | [FIPS186-4] | [RFC8032] | [FIPS186-4] | 985 +----------------+---------------+---------------+---------------+ 986 | Representation | Weierstrass, | Edwards, | Weierstrass, | 987 | conventions | uncompressed, | compressed, | compressed, | 988 | | MSB/msb first | LSB/lsb first | MSB/msb first | 989 +----------------+---------------+---------------+---------------+ 990 | Defining | This document | This document | This document | 991 | specification | | | | 992 +----------------+---------------+---------------+---------------+ 994 Table 2: Crypto-Types 996 New Crypto-Type values providing similar or better security may be 997 defined in the future. 999 Assignment of new values for new Crypto-Type MUST be done through 1000 IANA with either "Specification Required" or "IESG Approval" as 1001 defined in BCP 26 [RFC8126]. 1003 The "Defining specification" column indicates the document that 1004 defines the length and computation of the digital signature, which 1005 could be this for values defined through "IESG Approval". 1007 8.4. New Codepoints Associated to JWK Encoding 1009 Code points are requested for curve Wei25519 and its use with ECDSA, 1010 using the representation conventions of this document. 1012 8.4.1. COSE Elliptic Curves Registration 1014 This section registers the following value in the IANA "COSE Elliptic 1015 Curves" registry [IANA.COSE.Curves]. 1017 Name: Wei25519 1019 Value: TBD (Requested value: -1) 1021 Key Type: EC2 or OKP (where OKP uses the MSB/msb representation of 1022 this specification) 1024 Description: short-Weierstrass curve Wei25519 1026 Change Controller: IESG 1028 Reference: Appendix E.3 of [CURVE-REPRESENTATIONS] 1030 Recommended: Yes. 1032 (Note that The "kty" value for Wei25519 may be "OKP" or "EC2".) 1034 8.4.2. COSE Algorithms Registration 1036 This section registers the following value in the IANA "COSE 1037 Algorithms" registry [IANA.COSE.Algorithms]. 1039 Name: ECDSA25519 1041 Value: TBD (Requested value: -1) 1043 Description: ECDSA using SHA-256 and curve Wei25519 1045 Change Controller: IESG 1047 Reference: Section 4.3 of [CURVE-REPRESENTATIONS] 1049 Recommended: Yes. 1051 8.4.3. JOSE Elliptic Curves Registration 1053 This section registers the following value in the IANA "JSON Web Key 1054 Elliptic Curve" registry [IANA.JOSE.Curves]. 1056 Curve Name: Wei25519 1058 Curve Description: short-Weierstrass curve Wei25519 1059 JOSE Implementation Requirements: Optional 1061 Change Controller: IESG 1063 Reference: Appendix E.3 of [CURVE-REPRESENTATIONS] 1065 8.4.4. JOSE Algorithms Registration 1067 This section registers the following value in the IANA "JSON Web 1068 Signature and Encryption Algorithms" registry [IANA.JOSE.Algorithms]. 1070 Algorithm Name: ECDSA25519 1072 Algorithm Description: ECDSA using SHA-256 and curve Wei25519 1074 Algorithm Usage Locations: alg 1076 JOSE Implementation Requirements: Optional 1078 Change Controller: IESG 1080 Reference: Section 4.3 of [CURVE-REPRESENTATIONS] 1082 Algorithm Analysis Document(s): Section 4.3 of 1083 [CURVE-REPRESENTATIONS] 1085 9. Acknowledgments 1087 Many thanks to Charlie Perkins for his in-depth review and 1088 constructive suggestions. The authors are also especially grateful 1089 to Robert Moskowitz and Benjamin Kaduk for their comments and 1090 discussions that led to many improvements. The authors wish to also 1091 thank Roman Danyliw, Alissa Cooper, Mirja Kuhlewind, Eric Vyncke, 1092 Vijay Gurbani, Al Morton and Adam Montville for their constructive 1093 reviews during the IESG process. 1095 10. Normative References 1097 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1098 Requirement Levels", BCP 14, RFC 2119, 1099 DOI 10.17487/RFC2119, March 1997, 1100 . 1102 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1103 Bormann, "Neighbor Discovery Optimization for IPv6 over 1104 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1105 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1106 . 1108 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 1109 DOI 10.17487/RFC7517, May 2015, 1110 . 1112 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1113 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1114 May 2017, . 1116 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1117 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1118 DOI 10.17487/RFC3971, March 2005, 1119 . 1121 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1122 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1123 2016, . 1125 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1126 Signature Algorithm (EdDSA)", RFC 8032, 1127 DOI 10.17487/RFC8032, January 2017, 1128 . 1130 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 1131 Perkins, "Registration Extensions for IPv6 over Low-Power 1132 Wireless Personal Area Network (6LoWPAN) Neighbor 1133 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 1134 . 1136 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1137 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1138 DOI 10.17487/RFC6234, May 2011, 1139 . 1141 [FIPS186-4] 1142 FIPS 186-4, "Digital Signature Standard (DSS), Federal 1143 Information Processing Standards Publication 186-4", US 1144 Department of Commerce/National Institute of Standards and 1145 Technology , July 2013. 1147 [SEC1] SEC1, "SEC 1: Elliptic Curve Cryptography, Version 2.0", 1148 Standards for Efficient Cryptography , June 2009. 1150 11. Informative references 1152 [IANA.COSE.Algorithms] 1153 IANA, "COSE Algorithms", IANA, 1154 https://www.iana.org/assignments/cose/ 1155 cose.xhtml#algorithms. 1157 [IANA.COSE.Curves] 1158 IANA, "COSE Elliptic Curves", IANA, 1159 https://www.iana.org/assignments/cose/cose.xhtml#elliptic- 1160 curves. 1162 [IANA.JOSE.Algorithms] 1163 IANA, "JSON Web Signature and Encryption Algorithms", 1164 IANA, 1165 https://www.iana.org/assignments/jose/jose.xhtml#web- 1166 signature-encryption-algorithms. 1168 [IANA.JOSE.Curves] 1169 IANA, "JSON Web Key Elliptic Curve", IANA, 1170 https://www.iana.org/assignments/jose/jose.xhtml#web-key- 1171 elliptic-curve. 1173 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1174 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1175 . 1177 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1178 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1179 DOI 10.17487/RFC4861, September 2007, 1180 . 1182 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1183 Address Autoconfiguration", RFC 4862, 1184 DOI 10.17487/RFC4862, September 2007, 1185 . 1187 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1188 "Transmission of IPv6 Packets over IEEE 802.15.4 1189 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1190 . 1192 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1193 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1194 DOI 10.17487/RFC6282, September 2011, 1195 . 1197 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1198 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1199 Overview, Assumptions, Problem Statement, and Goals", 1200 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1201 . 1203 [BCP 106] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1204 "Randomness Requirements for Security", BCP 106, RFC 4086, 1205 DOI 10.17487/RFC4086, June 2005, 1206 . 1208 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1209 Writing an IANA Considerations Section in RFCs", BCP 26, 1210 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1211 . 1213 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 1214 "Source Address Validation Improvement (SAVI) Framework", 1215 RFC 7039, DOI 10.17487/RFC7039, October 2013, 1216 . 1218 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1219 Interface Identifiers with IPv6 Stateless Address 1220 Autoconfiguration (SLAAC)", RFC 7217, 1221 DOI 10.17487/RFC7217, April 2014, 1222 . 1224 [BCP 201] Housley, R., "Guidelines for Cryptographic Algorithm 1225 Agility and Selecting Mandatory-to-Implement Algorithms", 1226 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1227 . 1229 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 1230 "Recommendation on Stable IPv6 Interface Identifiers", 1231 RFC 8064, DOI 10.17487/RFC8064, February 2017, 1232 . 1234 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 1235 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 1236 February 2017, . 1238 [BACKBONE-ROUTER] 1239 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 1240 Backbone Router", Work in Progress, Internet-Draft, draft- 1241 ietf-6lo-backbone-router-19, 3 March 2020, 1242 . 1245 [CURVE-REPRESENTATIONS] 1246 Struik, R., "Alternative Elliptic Curve Representations", 1247 Work in Progress, Internet-Draft, draft-ietf-lwig-curve- 1248 representations-08, 24 July 2019, 1249 . 1252 [breaking-ed25519] 1253 Samwel, N., Batina, L., Bertoni, G., Daemen, J., and R. 1254 Susella, "Breaking Ed25519 in WolfSSL", Cryptographers' 1255 Track at the RSA Conference , 2018, 1256 . 1259 Appendix A. Requirements Addressed in this Document 1261 In this section we state requirements of a secure neighbor discovery 1262 protocol for low-power and lossy networks. 1264 * The protocol MUST be based on the Neighbor Discovery Optimization 1265 for Low-power and Lossy Networks protocol defined in [RFC6775]. 1266 RFC6775 utilizes optimizations such as host-initiated interactions 1267 for sleeping resource-constrained hosts and elimination of 1268 multicast address resolution. 1269 * New options to be added to Neighbor Solicitation messages MUST 1270 lead to small packet sizes, especially compared with existing 1271 protocols such as SEcure Neighbor Discovery (SEND). Smaller 1272 packet sizes facilitate low-power transmission by resource- 1273 constrained nodes on lossy links. 1274 * The support for this registration mechanism SHOULD be extensible 1275 to more LLN links than IEEE 802.15.4 only. Support for at least 1276 the LLN links for which a 6lo "IPv6 over foo" specification 1277 exists, as well as Low-Power Wi-Fi SHOULD be possible. 1278 * As part of this extension, a mechanism to compute a unique 1279 Identifier should be provided with the capability to form a Link 1280 Local Address that SHOULD be unique at least within the LLN 1281 connected to a 6LBR. 1282 * The Address Registration Option used in the ND registration SHOULD 1283 be extended to carry the relevant forms of Unique Interface 1284 Identifier. 1285 * The Neighbor Discovery should specify the formation of a site- 1286 local address that follows the security recommendations from 1287 [RFC7217]. 1289 Appendix B. Representation Conventions 1291 B.1. Signature Schemes 1293 The signature scheme ECDSA256 corresponding to Crypto-Type 0 is 1294 ECDSA, as specified in [FIPS186-4], instantiated with the NIST prime 1295 curve P-256, as specified in Appendix B of [FIPS186-4], and the hash 1296 function SHA-256, as specified in [RFC6234], where points of this 1297 NIST curve are represented as points of a short-Weierstrass curve 1298 (see [FIPS186-4]) and are encoded as octet strings in most- 1299 significant-bit first (msb) and most-significant-byte first (MSB) 1300 order. The signature itself consists of two integers (r and s), 1301 which are each encoded as fixed-size octet strings in most- 1302 significant-bit first and most-significant-byte first order. For 1303 details on ECDSA, see [FIPS186-4]; for details on the integer 1304 encoding, see Appendix B.2. 1306 The signature scheme Ed25519 corresponding to Crypto-Type 1 is EdDSA, 1307 as specified in [RFC8032], instantiated with the Montgomery curve 1308 Curve25519, as specified in [RFC7748], and the hash function SHA-512, 1309 as specified in [RFC6234], where points of this Montgomery curve are 1310 represented as points of the corresponding twisted Edwards curve (see 1311 Appendix B.3) and are encoded as octet strings in least-significant- 1312 bit first (lsb) and least-significant-byte first (LSB) order. The 1313 signature itself consists of a bit string that encodes a point of 1314 this twisted Edwards curve, in compressed format, and an integer 1315 encoded in least-significant-bit first and least-significant-byte 1316 first order. For details on EdDSA and on the encoding conversions, 1317 see the specification of pure Ed25519 in [RFC8032]. 1319 The signature scheme ECDSA25519 corresponding to Crypto-Type 2 is 1320 ECDSA, as specified in [FIPS186-4], instantiated with the Montgomery 1321 curve Curve25519, as specified in [RFC7748], and the hash function 1322 SHA-256, as specified in [RFC6234], where points of this Montgomery 1323 curve are represented as points of a corresponding curve in short- 1324 Weierstrass form (see Appendix B.3) and are encoded as octet strings 1325 in most-significant-bit first and most-significant-byte first order. 1326 The signature itself consists of a bit string that encodes two 1327 integers, each encoded as fixed-size octet strings in most- 1328 significant-bit first and most-significant-byte first order. For 1329 details on ECDSA, see [FIPS186-4]; for details on the integer 1330 encoding, see Appendix B.2 1332 B.2. Integer Representation for ECDSA signatures 1334 With ECDSA, each signature is an ordered pair (r, s) of integers 1335 [FIPS186-4]. Each integer is encoded as a fixed-size 256-bit bit 1336 string, where each integer is represented according to the Field 1337 Element to Octet String and Octet String to Bit String conversion 1338 rules in [SEC1] and where the ordered pair of integers is represented 1339 as the rightconcatenation of the resulting representation values. 1340 The inverse operation follows the corresponding Bit String to Octet 1341 String and Octet String to Field Element conversion rules of [SEC1]. 1343 B.3. Alternative Representations of Curve25519 1345 The elliptic curve Curve25519, as specified in [RFC7748], is a so- 1346 called Montgomery curve. Each point of this curve can also be 1347 represented as a point of a twisted Edwards curve or as a point of an 1348 elliptic curve in short-Weierstrass form, via a coordinate 1349 transformation (a so-called isomorphic mapping). The parameters of 1350 the Montgomery curve and the corresponding isomorphic curves in 1351 twisted Edwards curve and short-Weierstrass form are as indicated 1352 below. Here, the domain parameters of the Montgomery curve 1353 Curve25519 and of the twisted Edwards curve Edwards25519 are as 1354 specified in [RFC7748]; the domain parameters of the elliptic curve 1355 Wei25519 in short-Weierstrass curve comply with Section 6.1.1 of 1356 [FIPS186-4]. For details of the coordinate transformations 1357 referenced above, see [RFC7748] and [CURVE-REPRESENTATIONS]. 1359 General parameters (for all curve models): 1361 p 2^{255}-19 1362 (=0x7fffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 1363 ffffffed) 1364 h 8 1365 n 1366 723700557733226221397318656304299424085711635937990760600195093828 1367 5454250989 1368 (=2^{252} + 0x14def9de a2f79cd6 5812631a 5cf5d3ed) 1370 Montgomery curve-specific parameters (for Curve25519): 1372 A 486662 1373 B 1 1374 Gu 9 (=0x9) 1375 Gv 1376 147816194475895447910205935684099868872646061346164752889648818377 1377 55586237401 1378 (=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2 1379 7eced3d9) 1381 Twisted Edwards curve-specific parameters (for Edwards25519): 1383 a -1 (-0x01) 1384 d -121665/121666 1385 (=3709570593466943934313808350875456518954211387984321901638878553 1386 3085940283555) 1387 (=0x52036cee 2b6ffe73 8cc74079 7779e898 00700a4d 4141d8ab 75eb4dca 1388 135978a3) 1390 Gx 1391 151122213495354007725011514095885315114540126930418572060461132839 1392 49847762202 1393 (=0x216936d3 cd6e53fe c0a4e231 fdd6dc5c 692cc760 9525a7b2 c9562d60 1394 8f25d51a) 1395 Gy 4/5 1396 (=4631683569492647816942839400347516314130799386625622561578303360 1397 3165251855960) 1398 (=0x66666666 66666666 66666666 66666666 66666666 66666666 66666666 1399 66666658) 1401 Weierstrass curve-specific parameters (for Wei25519): 1403 a 1404 192986815395526992372618308347813179755449974442734273399095973345 1405 73241639236 1406 (=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaa98 1407 4914a144) 1408 b 1409 557517466698189089076452890782571408182411037279010123152944008379 1410 56729358436 1411 (=0x7b425ed0 97b425ed 097b425e d097b425 ed097b42 5ed097b4 260b5e9c 1412 7710c864) 1413 GX 1414 192986815395526992372618308347813179755449974442734273399095973346 1415 52188435546 1416 (=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa 1417 aaad245a) 1418 GY 1419 147816194475895447910205935684099868872646061346164752889648818377 1420 55586237401 1421 (=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2 1422 7eced3d9) 1424 Authors' Addresses 1426 Pascal Thubert (editor) 1427 Cisco Systems, Inc 1428 Building D 1429 45 Allee des Ormes - BP1200 1430 06254 MOUGINS - Sophia Antipolis 1431 France 1433 Phone: +33 497 23 26 34 1434 Email: pthubert@cisco.com 1435 Behcet Sarikaya 1437 Email: sarikaya@ieee.org 1439 Mohit Sethi 1440 Ericsson 1441 FI-02420 Jorvas 1442 Finland 1444 Email: mohit@piuha.net 1446 Rene Struik 1447 Struik Security Consultancy 1449 Email: rstruik.ext@gmail.com