idnits 2.17.00 (12 Aug 2021) /tmp/idnits53468/draft-ietf-6lo-ap-nd-21.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 (20 April 2020) is 761 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 6234 ** Downref: Normative reference to an Informational RFC: RFC 7748 ** Downref: Normative reference to an Informational RFC: RFC 8032 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-4' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' == Outdated reference: draft-ietf-6lo-backbone-router has been published as RFC 8929 == Outdated reference: A later version (-23) exists of draft-ietf-lwig-curve-representations-09 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: 22 October 2020 M. Sethi 7 Ericsson 8 R. Struik 9 Struik Security Consultancy 10 20 April 2020 12 Address Protected Neighbor Discovery for Low-power and Lossy Networks 13 draft-ietf-6lo-ap-nd-21 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 22 October 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. Additional References . . . . . . . . . . . . . . . . . . 4 67 2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 7 72 4.3. Crypto-ID Parameters Option . . . . . . . . . . . . . . . 8 73 4.4. NDP Signature Option . . . . . . . . . . . . . . . . . . 10 74 4.5. Extensions to the Capability Indication Option . . . . . 11 75 5. Protocol Scope . . . . . . . . . . . . . . . . . . . . . . . 12 76 6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 13 77 6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 14 78 6.2. NDPSO generation and verification . . . . . . . . . . . . 16 79 6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 17 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 81 7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 18 82 7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 19 83 7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 20 84 7.4. Implementation Attacks . . . . . . . . . . . . . . . . . 20 85 7.5. Cross-Algorithm and Cross-Protocol Attacks . . . . . . . 21 86 7.6. Compromised 6LR . . . . . . . . . . . . . . . . . . . . . 21 87 7.7. Correlating Registrations . . . . . . . . . . . . . . . . 21 88 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 89 8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 22 90 8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 22 91 8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 22 92 8.4. New Codepoints Associated to JWK Encoding . . . . . . . . 23 93 8.4.1. JOSE Elliptic Curves Registration . . . . . . . . . . 23 94 8.4.2. JOSE Algorithms Registration . . . . . . . . . . . . 24 96 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 97 10. Normative References . . . . . . . . . . . . . . . . . . . . 24 98 11. Informative references . . . . . . . . . . . . . . . . . . . 26 99 Appendix A. Requirements Addressed in this Document . . . . . . 28 100 Appendix B. Representation Conventions . . . . . . . . . . . . . 29 101 B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 29 102 B.2. Integer Representation for ECDSA signatures . . . . . . . 30 103 B.3. Alternative Representations of Curve25519 . . . . . . . . 30 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 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 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 transports alternate forms of ROVRs, and is a pre- 139 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. Additional References 179 The reader may get additional context for this specification from the 180 following references: 182 * "SEcure Neighbor Discovery (SEND)" [RFC3971], 184 * "Cryptographically Generated Addresses (CGA)" [RFC3972], 186 * "Neighbor Discovery for IP version 6" [RFC4861] , 188 * "IPv6 Stateless Address Autoconfiguration" [RFC4862], and 190 * "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 191 Overview, Assumptions, Problem Statement, and Goals " [RFC4919]. 193 2.3. Abbreviations 195 This document uses the following abbreviations: 197 6BBR: 6LoWPAN Backbone Router 198 6LBR: 6LoWPAN Border Router 199 6LN: 6LoWPAN Node 200 6LR: 6LoWPAN Router 201 CGA: Cryptographically Generated Address 202 EARO: Extended Address Registration Option 203 ECDH: Elliptic curve Diffie-Hellman 204 ECDSA: Elliptic Curve Digital Signature Algorithm 205 CIPO: Crypto-ID Parameters Option 206 LLN: Low-Power and Lossy Network 207 JSON: JavaScript Object Notation 208 JOSE: JavaScript Object Signing and Encryption 209 JWK: JSON Web Key 210 JWS: JSON Web Signature 211 NA: Neighbor Advertisement 212 ND: Neighbor Discovery 213 NDP: Neighbor Discovery Protocol 214 NDPSO: Neighbor Discovery Protocol Signature Option 215 NS: Neighbor Solicitation 216 ROVR: Registration Ownership Verifier 217 RA: Router Advertisement 218 RS: Router Solicitation 219 RSAO: RSA Signature Option 220 SHA: Secure Hash Algorithm 221 SLAAC: Stateless Address Autoconfiguration 222 TID: Transaction ID 224 3. Updating RFC 8505 226 Section 5.3 of [RFC8505] introduces the ROVR that is used to detect 227 and reject duplicate registrations in the DAD process. The ROVR is a 228 generic object that is designed for both backward compatibility and 229 the capability to introduce new computation methods in the future. 230 Using a Crypto-ID per this specification is the RECOMMENDED method. 231 Section 7.3 discusses collisions when heterogeneous methods to 232 compute the ROVR field coexist inside a same network. 234 This specification introduces a new token called a cryptographic 235 identifier (Crypto-ID) that is transported in the ROVR field and used 236 to prove indirectly the ownership of an address that is being 237 registered by means of [RFC8505]. The Crypto-ID is derived from a 238 cryptographic public key and additional parameters. 240 The overall mechanism requires the support of Elliptic Curve 241 Cryptography (ECC) and of a hash function as detailed in Section 6.2. 242 To enable the verification of the proof, the registering node needs 243 to supply certain parameters including a nonce and a signature that 244 will demonstrate that the node possesses the private-key 245 corresponding to the public-key used to build the Crypto-ID. 247 The elliptic curves and the hash functions listed in Table 2 in 248 Section 8.3 can be used with this specification; more may be added in 249 the future to the IANA registry. The signature scheme that specifies 250 which combination is used (including the curve and the representation 251 conventions) is signaled by a Crypto-Type in a new IPv6 ND Crypto-ID 252 Parameters Option (CIPO, see Section 4.3) that contains the 253 parameters that are necessary for the proof, a Nonce option 254 ([RFC3971]) and a NDP Signature option (Section 4.4). The NA(EARO) 255 is modified to enable a challenge and transport a Nonce option. 257 4. New Fields and Options 259 4.1. New Crypto-ID 261 The Crypto-ID is transported in the ROVR field of the EARO option and 262 the EDAR message, and is associated with the Registered Address at 263 the 6LR and the 6LBR. The ownership of a Crypto-ID can be 264 demonstrated by cryptographic mechanisms, and by association, the 265 ownership of the Registered Address can be ascertained. 267 A node in possession of the necessary cryptographic primitives SHOULD 268 use Crypto-ID by default as ROVR in its registrations. Whether a 269 ROVR is a Crypto-ID is indicated by a new "C" flag in the NS(EARO) 270 message. 272 The Crypto-ID is derived from the public key and a modifier as 273 follows: 275 1. The hash function indicated by the Crypto-Type is applied to the 276 CIPO. Note that all the reserved and padding bits MUST be set to 277 zero. 278 2. The leftmost bits of the resulting hash, up to the desired size, 279 are used as the Crypto-ID. 281 At the time of this writing, a minimal size for the Crypto-ID of 128 282 bits is RECOMMENDED unless backward compatibility is needed 283 [RFC8505]. This value is bound to augment in the future. 285 4.2. Updated EARO 287 This specification updates the EARO option to enable the use of the 288 ROVR field to transport the Crypto-ID. The resulting format is as 289 follows: 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Type | Length | Status | Opaque | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 |Rsvd |C| I |R|T| TID | Registration Lifetime | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | | 299 ... Registration Ownership Verifier (ROVR) ... 300 | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 1: Enhanced Address Registration Option 305 Type: 33 307 Length: Defined in [RFC8505] and copied in associated CIPO. 309 Status: Defined in [RFC8505]. 311 Opaque: Defined in [RFC8505]. 313 Rsvd (Reserved): 3-bit unsigned integer. It MUST be set to zero by 314 the sender and MUST be ignored by the receiver. 316 C: This "C" flag is set to indicate that the ROVR field contains a 317 Crypto-ID and that the 6LN MAY be challenged for ownership as 318 specified in this document. 320 I, R, T: Defined in [RFC8505]. 322 TID: Defined in [RFC8505]. 324 Registration Ownership Verifier (ROVR): When the "C" flag is set, 325 this field contains a Crypto-ID. 327 This specification uses Status values "Validation Requested" and 328 "Validation Failed", which are defined in [RFC8505]. 330 this specification does not define any new Status value. 332 4.3. Crypto-ID Parameters Option 334 This specification defines the Crypto-ID Parameters Option (CIPO). 335 The CIPO carries the parameters used to form a Crypto-ID. 337 In order to provide cryptographic agility [BCP 201], this 338 specification supports different elliptic curves, indicated by a 339 Crypto-Type field: 341 * NIST P-256 [FIPS186-4] MUST be supported by all implementations. 343 * The Edwards-Curve Digital Signature Algorithm (EdDSA) curve 344 Ed25519 (PureEdDSA) [RFC8032] MAY be supported as an alternative. 346 * This specification uses signature schemes that target similar 347 cryptographic strength but rely on different curves, hash 348 functions, signature algorithms, and/or representation 349 conventions. Future specification may extend this to different 350 cryptographic algorithms and key sizes, e.g., to provide better 351 security properties or a simpler implementation. 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Type | Length |Reserved1| Public Key Length | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Crypto-Type | Modifier | EARO Length | Reserved2 | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | | 361 . . 362 . Public Key (variable length) . 363 . . 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | | 367 . Padding . 368 | | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Figure 2: Crypto-ID Parameters Option 373 Type: 8-bit unsigned integer. to be assigned by IANA, see Table 1. 375 Length: 8-bit unsigned integer. The length of the option in units 376 of 8 octets. 378 Reserved1: 5-bit unsigned integer. It MUST be set to zero by the 379 sender and MUST be ignored by the receiver. 381 Public Key Length: 11-bit unsigned integer. The length of the 382 Public Key field in bytes. 384 Crypto-Type: 8-bit unsigned integer. The type of cryptographic 385 algorithm used in calculation Crypto-ID indexed by IANA in the 386 "Crypto-Type Subregistry" in the "Internet Control Message 387 Protocol version 6 (ICMPv6) Parameters" (see Section 8.3). 389 Modifier: 8-bit unsigned integer. Set to an arbitrary value by the 390 creator of the Crypto-ID. The role of the modifier is to enable 391 the formation of multiple Crypto-IDs from a same key pair, which 392 reduces the traceability and thus improves the privacy of a 393 constrained node that could not maintain many key-pairs. 395 EARO Length: 8-bit unsigned integer. The option length of the EARO 396 that contains the Crypto-ID associated with the CIPO. 398 Reserved2: 8-bit unsigned integer. It MUST be set to zero by the 399 sender and MUST be ignored by the receiver. 401 Public Key: A variable-length field, size indicated in the Public 402 Key Length field. JWK-encoded Public Key [RFC7517]. 404 Padding: A variable-length field completing the Public Key field to 405 align to the next 8-bytes boundary. It MUST be set to zero by the 406 sender and MUST be ignored by the receiver. 408 The implementation of multiple hash functions in a constrained 409 devices may consume excessive amounts of program memory. This 410 specification enables the use of SHA-256 [RFC6234] for all the 411 supported ECC curves. 413 Some code factorization is also possible for the ECC computation 414 itself. [CURVE-REPR] provides information on how to represent 415 Montgomery curves and (twisted) Edwards curves as curves in short- 416 Weierstrass form and illustrates how this can be used to implement 417 elliptic curve computations using existing implementations that 418 already provide, e.g., ECDSA and ECDH using NIST [FIPS186-4] prime 419 curves. For more details on representation conventions, we refer to 420 Appendix B. 422 4.4. NDP Signature Option 424 This specification defines the NDP Signature Option (NDPSO). The 425 NDPSO carries the signature that proves the ownership of the Crypto- 426 ID. The format of the NDPSO is illustrated in Figure 3. 428 As opposed to the RSA Signature Option (RSAO) defined in section 5.2. 429 of SEND [RFC3971], the NDPSO does not have a key hash field. 430 Instead, the leftmost 128 bits of the ROVR field in the EARO are used 431 as hash to retrieve the CIPO that contains the key material used for 432 signature verification, left-padded if needed. 434 Another difference is that the NDPSO signs a fixed set of fields as 435 opposed to all options that appear prior to it in the ND message that 436 bears the signature. This allows to elide a CIPO that the 6LR 437 already received, at the expense of the capability to add arbitrary 438 options that would signed with a RSAO. 440 An ND message that carries an NDPSO MUST have one and only one EARO. 441 The EARO MUST contain a Crypto-ID in the ROVR field, and the Crypto- 442 ID MUST be associated with the keypair used for the Digital Signature 443 in the NDPSO. 445 The CIPO may be present in the same message as the NDPSO. If it is 446 not present, it can be found in an abstract table that was created by 447 a previous message and indexed by the hash. 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Type | Length |Reserved1| Signature Length | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Reserved2 | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | | 457 . . 458 . Digital Signature (variable length) . 459 . . 460 | | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | | 463 . Padding . 464 | | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Figure 3: NDP signature Option 469 Type: to be assigned by IANA, see Table 1. 471 Length: 8-bit unsigned integer. The length of the option in units 472 of 8 octets. 474 Reserved1: 5-bit unsigned integer. It MUST be set to zero by the 475 sender and MUST be ignored by the receiver. 477 Digital Signature Length: 11-bit unsigned integer. The length of 478 the Digital Signature field in bytes. 480 Reserved2: 32-bit unsigned integer. It MUST be set to zero by the 481 sender and MUST be ignored by the receiver. 483 Digital Signature: A variable-length field containing the JWS- 484 encoded digital signature[RFC7515]. The length and computation of 485 the digital signature both depend on the Crypto-Type which is 486 found in the associated CIPO, see Appendix B.2. For the values of 487 the Crypto-Type defined in this specification, and for future 488 values of the Crypto-Type unless specified otherwise, the 489 signature is computed as detailed in Section 6.2. 491 Padding: A variable-length field completing the Digital Signature 492 field to align to the next 8-bytes boundary. It MUST be set to 493 zero by the sender and MUST be ignored by the receiver. 495 4.5. Extensions to the Capability Indication Option 497 This specification defines 2 new capability bits in the 6CIO, defined 498 by [RFC7400] for use by the 6LR and 6LBR in IPv6 ND RA messages. 500 The "A" flag indicates that AP-ND is enabled in the network. It is 501 set by the 6LBR that serves the network and propagated by the 6LRs. 503 The "J" flag indicates that the 6LR supports JWK-encoded keys in the 504 CIPO option. 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Type | Length = 1 | Reserved |J|A|D|L|B|P|E|G| 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Reserved | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Figure 4: New Capability Bits in the 6CIO 516 New Option Fields: 518 J: 1-bit flag. This 6LR supports AP-ND with JWK encoding 520 A: 1-bit flag. This network supports AP-ND 522 5. Protocol Scope 524 The scope of the protocol specified here is a 6LoWPAN LLN, typically 525 a stub network connected to a larger IP network via a Border Router 526 called a 6LBR per [RFC6775]. A 6LBR has sufficient capability to 527 satisfy the needs of duplicate address detection. 529 The 6LBR maintains registration state for all devices in its attached 530 LLN. Together with the first-hop router (the 6LR), the 6LBR assures 531 uniqueness and grants ownership of an IPv6 address before it can be 532 used in the LLN. This is in contrast to a traditional network that 533 relies on IPv6 address auto-configuration [RFC4862], where there is 534 no guarantee of ownership from the network, and each IPv6 Neighbor 535 Discovery packet must be individually secured [RFC3971]. 537 ---+-------- ............ 538 | External Network 539 | 540 +-----+ 541 | | 6LBR 542 +-----+ 543 o o o 544 o o o o 545 o o LLN o o o 546 o o o (6LR) 547 o (6LN) 549 Figure 5: Basic Configuration 551 In a mesh network, the 6LR is directly connected to the host device. 552 This specification mandates that the peer-wise layer-2 security is 553 deployed so that all the packets from a particular host are securely 554 identifiable by the 6LR. The 6LR may be multiple hops away from the 555 6LBR. Packets are routed between the 6LR and the 6LBR via other 556 6LRs. 558 This specification mandates that a chain of trust is established so 559 that a packet that was validated by the first 6LR can be safely 560 routed by other on-path 6LRs to the 6LBR. 562 6. Protocol Flows 564 The 6LR/6LBR ensures first-come/first-serve by storing the ROVR 565 associated to the address being registered upon the first 566 registration and rejecting a registration with a different ROVR 567 value. A 6LN can claim any address as long as it is the first to 568 make that claim. After a successful registration, the 6LN becomes 569 the owner of the registered address and the address is bound to the 570 ROVR value in the 6LR/6LBR registry. 572 This specification protects the ownership of the address. Its use in 573 a network is signaled by the 6LBR by setting the 'A' flag in the 574 6CIO. This is echoed by the 6LRs, that also indicate the key 575 encoding format that they support in another 6CIO flag, currently the 576 'J' flag for JWK. 578 When using a ROVR that is a Crypto-ID, a 6LN MUST use a 6LR that 579 supports the key encoding used in the CIPO. If the 6LR does not 580 support the Crypto-Type, it MUST reply with an EARO Status 10 581 "Validation Failed" without a challenge. In that case, the 6LN may 582 try another Crypto-Type until it falls back to Crypto-Type 0 that 583 MUST be supported by all 6LRs. 585 This specification enables the 6LR to challenge the 6LN to verify its 586 ownership of the binding by placing a Crypto-ID in the ROVR. The 587 challenge can happen at any time at the discretion of the 6LR. The 588 6LR MUST challenge the 6LN when it creates a binding and when a new 589 registration attempts to change a parameter of the binding that 590 identifies the 6LN, for instance its Source Link-Layer Address. The 591 verification protects against a rogue that would steal an address and 592 attract its traffic, or use it as source address. 594 The challenge can also triggered by the 6LBR, e.g., to enforce a 595 global policy. In that case, the 6LBR returns a status of 596 "Validation Requested" in the DAR/DAC exchange, which is echoed by 597 the 6LR in the NA (EARO) back to the registering node. A valid 598 registration in the 6LR or the 6LBR MUST NOT be altered until the 599 challenge is complete. 601 A node may use more than one IPv6 address at the same time. The 602 separation of the address and the cryptographic material avoids the 603 need for the constrained device to compute multiple keys for multiple 604 addresses. The 6LN MAY use the same Crypto-ID to prove the ownership 605 of multiple IPv6 addresses. The 6LN MAY also derive multiple Crypto- 606 IDs from a same key. 608 6.1. First Exchange with a 6LR 610 A 6LN registers to a 6LR that is one hop away from it with the "C" 611 flag set in the EARO, indicating that the ROVR field contains a 612 Crypto-ID. The Target Address in the NS message indicates the IPv6 613 address that the 6LN is trying to register [RFC8505]. The on-link 614 (local) protocol interactions are shown in Figure 6. If the 6LR does 615 not have a state with the 6LN that is consistent with the NS(EARO), 616 then it replies with a challenge NA (EARO, status=Validation 617 Requested) that contains a Nonce Option (shown as NonceLR in 618 Figure 6). 620 6LN 6LR 621 | | 622 |<------------------------- RA -------------------------| 623 | | ^ 624 |---------------- NS with EARO (Crypto-ID) ------------>| | 625 | | option 626 |<- NA with EARO (status=Validation Requested), NonceLR-| | 627 | | v 628 |------- NS with EARO, CIPO, NonceLN and NDPSO -------->| 629 | | 630 |<------------------- NA with EARO ---------------------| 631 | | 632 ... 633 | | 634 |--------------- NS with EARO (Crypto-ID) ------------->| 635 | | 636 |<------------------- NA with EARO ---------------------| 637 | | 638 ... 639 | | 640 |--------------- NS with EARO (Crypto-ID) ------------->| 641 | | 642 |<------------------- NA with EARO ---------------------| 643 | | 645 Figure 6: On-link Protocol Operation 647 The Nonce option contains a nonce value that, to the extent possible 648 for the implementation, was never employed in association with the 649 key pair used to generate the Crypto-ID. This specification inherits 650 from [RFC3971] that simply indicates that the nonce is a random 651 value. Ideally, an implementation uses an unpredictable 652 cryptographically random value [BCP 106]. But that may be 653 impractical in some LLN scenarios where the devices do not have a 654 guaranteed sense of time and for which computing complex hashes is 655 detrimental to the battery lifetime. 657 Alternatively, the device may use an always-incrementing value saved 658 in the same stable storage as the key, so they are lost together, and 659 starting at a best effort random value, either as the nonce value or 660 as a component to its computation. 662 The 6LN replies to the challenge with an NS(EARO) that includes a new 663 Nonce option (shown as NonceLN in Figure 6), the CIPO (Section 4.3), 664 and the NDPSO containing the signature. Both Nonces are included in 665 the signed material. This provides a "contributory behavior", so 666 that either party that knows it generates a good quality nonce knows 667 that the protocol will be secure. 669 The 6LR MUST store the information associated to a Crypto-ID on the 670 first NS exchange where it appears in a fashion that the CIPO 671 parameters can be retrieved from the Crypto-ID alone. 673 The steps for the registration to the 6LR are as follows: 675 * Upon the first exchange with a 6LR, a 6LN will be challenged to 676 prove ownership of the Crypto-ID and the Target Address being 677 registered in the Neighbor Solicitation message. When a 6LR 678 receives a NS(EARO) registration with a new Crypto-ID as a ROVR, 679 and unless the registration is rejected for another reason, it 680 MUST challenge by responding with a NA(EARO) with a status of 681 "Validation Requested". 683 * Upon receiving a first NA(EARO) with a status of "Validation 684 Requested" from a 6LR, the registering node SHOULD retry its 685 registration with a Crypto-ID Parameters Option (CIPO) 686 (Section 4.3) that contains all the necessary material for 687 building the Crypto-ID, the NonceLN that it generated, and the NDP 688 signature (Section 4.4) option that proves its ownership of the 689 Crypto-ID and intent of registering the Target Address. In 690 subsequent revalidation with the same 6LR, the 6LN MAY try to omit 691 the CIPO to save bandwidth, with the expectation that the 6LR 692 saved it. If the validation fails and it gets challenged again, 693 then it SHOULD add the CIPO again. 695 * In order to validate the ownership, the 6LR performs the same 696 steps as the 6LN and rebuilds the Crypto-ID based on the 697 parameters in the CIPO. If the rebuilt Crypto-ID matches the 698 ROVR, the 6LN also verifies the signature contained in the NDPSO 699 option. If at that point the signature in the NDPSO option can be 700 verified, then the validation succeeds. Otherwise the validation 701 fails. 703 * If the 6LR fails to validate the signed NS(EARO), it responds with 704 a status of "Validation Failed". After receiving a NA(EARO) with 705 a status of "Validation Failed", the registering node SHOULD try 706 and alternate Crypto-Type and if even Crypto-Type 0 fails, it may 707 try to register a different address in the NS message. 709 6.2. NDPSO generation and verification 711 The signature generated by the 6LN to provide proof-of-ownership of 712 the private-key is carried in the NDP Signature Option (NDPSO). It 713 is generated by the 6LN in a fashion that depends on the Crypto-Type 714 (see Table 2 in Section 8.3) chosen by the 6LN as follows: 716 * Concatenate the following in the order listed: 718 1. The 128-bit Message Type tag [RFC3972] (in network byte 719 order). For this specification the tag is 0x8701 55c8 0cca 720 dd32 6ab7 e415 f148 84d0. (The tag value has been generated 721 by the editor of this specification on random.org). 722 2. the CIPO 723 3. the 16-byte Target Address (in network byte order) sent in the 724 Neighbor Solicitation (NS) message. It is the address which 725 the 6LN is registering with the 6LR and 6LBR. 726 4. NonceLR received from the 6LR (in network byte order) in the 727 Neighbor Advertisement (NA) message. The nonce is at least 6 728 bytes long as defined in [RFC3971]. 729 5. NonceLN sent from the 6LN (in network byte order). The nonce 730 is at least 6 bytes long as defined in [RFC3971]. 731 6. 1-byte Option Length of the EARO containing the Crypto-ID. 733 * Apply the hash function (if any) specified by the Crypto-Type to 734 the concatenated data, e.g., hash the resulting data using SHA- 735 256. 737 * Apply the signature algorithm specified by the Crypto-Type, e.g., 738 sign the hash output with ECDSA (if curve P-256 is used) or sign 739 the hash with EdDSA (if curve Ed25519 (PureEdDSA)). 741 The 6LR on receiving the NDPSO and CIPO options first checks that the 742 EARO Length in the CIPO matches the length of the EARO. If so it 743 regenerates the Crypto-ID based on the CIPO to make sure that the 744 leftmost bits up to the size of the ROVR match. 746 If and only if the check is successful, it tries to verify the 747 signature in the NDPSO option using the following: 749 * Concatenate the following in the order listed: 751 1. The 128-bit Message Type tag specified above (in network byte 752 order) 753 2. the CIPO 754 3. the 16-byte Target Address (in network byte order) received in 755 the Neighbor Solicitation (NS) message. It is the address 756 which the 6LN is registering with the 6LR and 6LBR. 757 4. NonceLR sent in the Neighbor Advertisement (NA) message. The 758 nonce is at least 6 bytes long as defined in [RFC3971]. 759 5. NonceLN received from the 6LN (in network byte order) in the 760 NS message. The nonce is at least 6 bytes long as defined in 761 [RFC3971]. 762 6. 1-byte EARO Length received in the CIPO. 764 * Apply the hash function (if any) specified by the Crypto-Type 765 indicated by the 6LN in the CIPO to the concatenated data. 767 * Verify the signature with the public-key in the CIPO and the 768 locally computed values using the signature algorithm specified by 769 the Crypto-Type. If the verification succeeds, the 6LR propagates 770 the information to the 6LBR using a EDAR/EDAC flow. 772 * Due to the first-come/first-serve nature of the registration, if 773 the address is not registered to the 6LBR, then flow succeeds and 774 both the 6LR and 6LBR add the state information about the Crypto- 775 ID and Target Address being registered to their respective 776 abstract database. 778 6.3. Multihop Operation 780 A new 6LN that joins the network auto-configures an address and 781 performs an initial registration to a neighboring 6LR with an NS 782 message that carries an Address Registration Option (EARO) [RFC8505]. 784 In a multihop 6LoWPAN, the registration with Crypto-ID is propagated 785 to 6LBR as shown in Figure 7, which illustrates the registration flow 786 all the way to a 6LowPAN Backbone Router (6BBR) [BACKBONE-ROUTER]. 788 The 6LR and the 6LBR communicate using ICMPv6 Extended Duplicate 789 Address Request (EDAR) and Extended Duplicate Address Confirmation 790 (EDAC) messages [RFC8505] as shown in Figure 7. This specification 791 extends EDAR/EDAC messages to carry cryptographically generated ROVR. 793 The assumption is that the 6LR and the 6LBR maintain a security 794 association to authenticate and protect the integrity of the EDAR and 795 EDAC messages, so there is no need to propagate the proof of 796 ownership to the 6LBR. The 6LBR implicitly trusts that the 6LR 797 performs the verification when the 6LBR requires it, and if there is 798 no further exchange from the 6LR to remove the state, that the 799 verification succeeded. 801 6LN 6LR 6LBR 6BBR 802 | | | | 803 | NS(EARO) | | | 804 |--------------->| | | 805 | | Extended DAR | | 806 | |-------------->| | 807 | | | | 808 | | | proxy NS(EARO) | 809 | | |--------------->| 810 | | | | NS(DAD) 811 | | | | ------> 812 | | | | 813 | | | | 814 | | | | 815 | | | proxy NA(EARO) | 816 | | |<---------------| 817 | | Extended DAC | | 818 | |<--------------| | 819 | NA(EARO) | | | 820 |<---------------| | | 821 | | | | 823 Figure 7: (Re-)Registration Flow 825 7. Security Considerations 827 7.1. Inheriting from RFC 3971 829 Observations regarding the following threats to the local network in 830 [RFC3971] also apply to this specification. 832 Neighbor Solicitation/Advertisement Spoofing: Threats in section 833 9.2.1 of RFC3971 apply. AP-ND counters the threats on NS(EARO) 834 messages by requiring that the NDP Signature and CIPO options be 835 present in these solicitations. 837 Duplicate Address Detection DoS Attack: Inside the LLN, Duplicate 838 Addresses are sorted out using the ROVR, which differentiates it 839 from a movement. A different ROVR for the same Registered address 840 entails a rejection of the second registration [RFC8505]. DAD 841 coming from the backbone are not forwarded over the LLN, which 842 provides some protection against DoS attacks inside the resource- 843 constrained part of the network. Over the backbone, the EARO 844 option is present in NS/NA messages. This protects against 845 misinterpreting a movement for a duplication, and enables the 846 backbone routers to determine which one has the freshest 847 registration [RFC8505] and is thus the best candidate to validate 848 the registration for the device attached to it [BACKBONE-ROUTER]. 849 But this specification does not guarantee that the backbone router 850 claiming an address over the backbone is not an attacker. 852 Router Solicitation and Advertisement Attacks: This specification 853 does not change the protection of RS and RA which can still be 854 protected by SEND. 856 Replay Attacks A nonce should never repeat for a single key, but 857 nonces do not need to be unpredictable for secure operation. 858 Using nonces (NonceLR and NonceLN) generated by both the 6LR and 859 6LN ensure a contributory behavior that provides an efficient 860 protection against replay attacks of the challenge/response flow. 861 The quality of the protection by a random nonce depends on the 862 random number generator and its parameters (e.g., sense of time). 864 Neighbor Discovery DoS Attack: A rogue node that managed to access 865 the L2 network may form many addresses and register them using AP- 866 ND. The perimeter of the attack is all the 6LRs in range of the 867 attacker. The 6LR MUST protect itself against overflows and 868 reject excessive registration with a status 2 "Neighbor Cache 869 Full". This effectively blocks another (honest) 6LN from 870 registering to the same 6LR, but the 6LN may register to other 871 6LRs that are in its range but not in that of the rogue. 873 7.2. Related to 6LoWPAN ND 875 The threats and mediations discussed in 6LoWPAN ND [RFC6775][RFC8505] 876 also apply here, in particular denial-of-service attacks against the 877 registry at the 6LR or 6LBR. 879 Secure ND [RFC3971] forces the IPv6 address to be cryptographic since 880 it integrates the CGA as the IID in the IPv6 address. In contrast, 881 this specification saves about 1Kbyte in every NS/NA message. Also, 882 this specification separates the cryptographic identifier from the 883 registered IPv6 address so that a node can have more than one IPv6 884 address protected by the same cryptographic identifier. 886 With this specification the 6LN can freely form its IPv6 address(es) 887 in any fashion, thereby enabling either 6LoWPAN compression for IPv6 888 addresses that are derived from Layer-2 addresses, or temporary 889 addresses, e.g., formed pseudo-randomly and released in relatively 890 short cycles for privacy reasons [RFC8064][RFC8065], that cannot be 891 compressed. 893 This specification provides added protection for addresses that are 894 obtained following due procedure [RFC8505] but does not constrain the 895 way the addresses are formed or the number of addresses that are used 896 in parallel by a same entity. A rogue may still perform denial-of- 897 service attack against the registry at the 6LR or 6LBR, or attempt to 898 deplete the pool of available addresses at Layer-2 or Layer-3. 900 7.3. ROVR Collisions 902 A collision of Registration Ownership Verifiers (ROVR) (i.e., the 903 Crypto-ID in this specification) is possible, but it is a rare event. 904 Assuming in the calculations/discussion below that the hash used for 905 calculating the Crypto-ID is a well-behaved cryptographic hash and 906 thus that random collisions are the only ones possible, the formula 907 (birthday paradox) for calculating the probability of a collision is 908 1 - e^{-k^2/(2n)} where n is the maximum population size (2^64 here, 909 1.84E19) and k is the actual population (number of nodes, assuming 910 one Crypto-ID per node). 912 If the Crypto-ID is 64-bits (the least possible size allowed), the 913 chance of a collision is 0.01% for network of 66 million nodes. 914 Moreover, the collision is only relevant when this happens within one 915 stub network (6LBR). In the case of such a collision, a third party 916 node would be able to claim the registered address of an another 917 legitimate node, provided that it wishes to use the same address. To 918 prevent address disclosure and avoid the chances of collision on both 919 the ROVR and the address, it is RECOMMENDED that nodes do not derive 920 the address being registered from the ROVR. 922 7.4. Implementation Attacks 924 The signature schemes referenced in this specification comply with 925 NIST [FIPS186-4] or Crypto Forum Research Group (CFRG) standards 926 [RFC8032] and offer strong algorithmic security at roughly 128-bit 927 security level. These signature schemes use elliptic curves that 928 were either specifically designed with exception-free and constant- 929 time arithmetic in mind [RFC7748] or where one has extensive 930 implementation experience of resistance to timing attacks 931 [FIPS186-4]. However, careless implementations of the signing 932 operations could nevertheless leak information on private keys. For 933 example, there are micro-architectural side channel attacks that 934 implementors should be aware of [breaking-ed25519]. Implementors 935 should be particularly aware that a secure implementation of Ed25519 936 requires a protected implementation of the hash function SHA-512, 937 whereas this is not required with implementations of SHA-256 used 938 with ECDSA. 940 7.5. Cross-Algorithm and Cross-Protocol Attacks 942 The keypair used in this specification can be self-generated and the 943 public key does not need to be exchanged, e.g., through certificates, 944 with a third party before it is used. New keypairs can be formed for 945 new registration as the node desires. On the other hand, it is safer 946 to allocate a keypair that is used only for the address protection 947 and only for one instantiation of the signature scheme (which 948 includes choice of elliptic curve domain parameters, used hash 949 function, and applicable representation conventions). The same 950 private key MUST NOT be reused with more than one instantiation of 951 the signature scheme in this specification. The same private key 952 MUST NOT be used for anything other than computing NDPSO signatures 953 per this specification. 955 7.6. Compromised 6LR 957 This specification distributes the challenge and its validation at 958 the edge of the network, between the 6LN and its 6LR. This protects 959 against DOS attacks targeted at that central 6LBR. This also saves 960 back and forth exchanges across a potentially large and constrained 961 network. The downside is that the 6LBR needs to trust the 6LR for 962 performing the checking adequately, and the communication between the 963 6LR and the 6LBR must be protected to avoid tempering with the result 964 of the test. If a 6LR is compromised, and provided that it knows the 965 ROVR field used by the real owner of the address, the 6LR may pretend 966 that the owner has moved, is now attached to it and has successfully 967 passed the Crpto-ID validation. The 6LR may then attract and inject 968 traffic at will on behalf of that address or let a rogue take 969 ownership of the address. 971 7.7. Correlating Registrations 973 The ROVR field in the EARO introduced in [RFC8505] extends the EUI-64 974 field of the ARO defined in [RFC6775]. One of the drawbacks of using 975 an EUI-64 as ROVR is that an attacker that is aware of the 976 registrations can correlate traffic for a same 6LN across multiple 977 addresses. Section 3 of [RFC8505] indicates that the ROVR and the 978 address being registered are decoupled. A 6LN may use a same ROVR 979 for multiple registrations or a different ROVR per registration, and 980 the IID must not derive from the ROVR. In theory different 6LNs 981 could use a same ROVR as long as they do not attempt to register the 982 same address. 984 The Modifier used in the computation of the Crypto-ID enables a 6LN 985 to build different Crypto-IDs for different addresses with a same 986 keypair. Using that facility improves the privacy of the 6LN as the 987 expense of storage in the 6LR, which will need to store multiple 988 CIPOs that contain the same public key. Note that if the attacker is 989 the 6LR, then the Modifier alone does not provide a protection, and 990 the 6LN would need to use different keys and MAC addresses in an 991 attempt to obfuscate its multiple ownership. 993 8. IANA considerations 995 8.1. CGA Message Type 997 This document defines a new 128-bit value under the CGA Message Type 998 [RFC3972] name space: 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0. 1000 8.2. IPv6 ND option types 1002 This document registers two new ND option types under the subregistry 1003 "IPv6 Neighbor Discovery Option Formats": 1005 +------------------------------+-----------------+---------------+ 1006 | Option Name | Suggested Value | Reference | 1007 +==============================+=================+===============+ 1008 | NDP Signature Option (NDPSO) | 38 | This document | 1009 +------------------------------+-----------------+---------------+ 1010 | Crypto-ID Parameters Option | 39 | This document | 1011 | (CIPO) | | | 1012 +------------------------------+-----------------+---------------+ 1014 Table 1: New ND options 1016 8.3. Crypto-Type Subregistry 1018 IANA is requested to create a new subregistry "Crypto-Type 1019 Subregistry" in the "Internet Control Message Protocol version 6 1020 (ICMPv6) Parameters". The registry is indexed by an integer in the 1021 interval 0..255 and contains an Elliptic Curve, a Hash Function, a 1022 Signature Algorithm, and Representation Conventions, as shown in 1023 Table 2, which together specify a signature scheme. The following 1024 Crypto-Type values are defined in this document: 1026 +----------------+----------------+----------------+----------------+ 1027 | Crypto-Type | 0 (ECDSA256) | 1 (Ed25519) | 2 | 1028 | value | | | (ECDSA25519) | 1029 +================+================+================+================+ 1030 | Elliptic curve | NIST P-256 | Curve25519 | Curve25519 | 1031 | | [FIPS186-4] | [RFC7748] | [RFC7748] | 1032 +----------------+----------------+----------------+----------------+ 1033 | Hash function | SHA-256 | SHA-512 | SHA-256 | 1034 | | [RFC6234] | [RFC6234] | [RFC6234] | 1035 +----------------+----------------+----------------+----------------+ 1036 | Signature | ECDSA | Ed25519 | ECDSA | 1037 | algorithm | [FIPS186-4] | [RFC8032] | [FIPS186-4] | 1038 +----------------+----------------+----------------+----------------+ 1039 | Representation | Weierstrass, | Edwards, | Weierstrass, | 1040 | conventions | uncompressed, | compressed, | compressed, | 1041 | | MSB/msb first, | LSB/lsb first, | MSB/msb | 1042 | | [RFC7518] | [RFC8037] | first, | 1043 | | | | [CURVE-REPR] | 1044 +----------------+----------------+----------------+----------------+ 1045 | Defining | This document | This document | This | 1046 | specification | | | document | 1047 +----------------+----------------+----------------+----------------+ 1049 Table 2: Crypto-Types 1051 New Crypto-Type values providing similar or better security may be 1052 defined in the future. 1054 Assignment of new values for new Crypto-Type MUST be done through 1055 IANA with either "Specification Required" or "IESG Approval" as 1056 defined in BCP 26 [RFC8126]. 1058 The "Defining specification" column indicates the document that 1059 defines the length and computation of the digital signature, which 1060 could be this for values defined through "IESG Approval". 1062 8.4. New Codepoints Associated to JWK Encoding 1064 Code points are requested for curve Wei25519 and its use with ECDSA, 1065 using the representation conventions of this document. 1067 8.4.1. JOSE Elliptic Curves Registration 1069 This section registers the following value in the IANA "JSON Web Key 1070 Elliptic Curve" registry [IANA.JOSE.Curves]. 1072 Curve Name: Wei25519 1073 Curve Description: short-Weierstrass curve Wei25519 1075 JOSE Implementation Requirements: Optional 1077 Change Controller: IESG 1079 Reference: Appendix E.3 of [CURVE-REPR] 1081 8.4.2. JOSE Algorithms Registration 1083 This section registers the following value in the IANA "JSON Web 1084 Signature and Encryption Algorithms" registry [IANA.JOSE.Algorithms]. 1086 Algorithm Name: ECDSA25519 1088 Algorithm Description: ECDSA using SHA-256 and curve Wei25519 1090 Algorithm Usage Locations: alg 1092 JOSE Implementation Requirements: Optional 1094 Change Controller: IESG 1096 Reference: Section 4.3 of [CURVE-REPR] 1098 Algorithm Analysis Document(s): Section 4.3 of [CURVE-REPR] 1100 9. Acknowledgments 1102 Many thanks to Charlie Perkins for his in-depth review and 1103 constructive suggestions. The authors are also especially grateful 1104 to Robert Moskowitz and Benjamin Kaduk for their comments and 1105 discussions that led to many improvements. The authors wish to also 1106 thank Roman Danyliw, Alissa Cooper, Mirja Kuhlewind, Eric Vyncke, 1107 Vijay Gurbani, Al Morton and Adam Montville for their constructive 1108 reviews during the IESG process. 1110 10. Normative References 1112 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1113 Requirement Levels", BCP 14, RFC 2119, 1114 DOI 10.17487/RFC2119, March 1997, 1115 . 1117 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1118 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1119 DOI 10.17487/RFC3971, March 2005, 1120 . 1122 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1123 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1124 DOI 10.17487/RFC6234, May 2011, 1125 . 1127 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1128 Bormann, "Neighbor Discovery Optimization for IPv6 over 1129 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1130 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1131 . 1133 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 1134 IPv6 over Low-Power Wireless Personal Area Networks 1135 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 1136 2014, . 1138 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1139 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1140 2015, . 1142 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 1143 DOI 10.17487/RFC7517, May 2015, 1144 . 1146 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1147 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1148 2016, . 1150 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1151 Signature Algorithm (EdDSA)", RFC 8032, 1152 DOI 10.17487/RFC8032, January 2017, 1153 . 1155 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1156 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1157 May 2017, . 1159 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 1160 Perkins, "Registration Extensions for IPv6 over Low-Power 1161 Wireless Personal Area Network (6LoWPAN) Neighbor 1162 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 1163 . 1165 [FIPS186-4] 1166 FIPS 186-4, "Digital Signature Standard (DSS), Federal 1167 Information Processing Standards Publication 186-4", US 1168 Department of Commerce/National Institute of Standards and 1169 Technology , July 2013. 1171 [SEC1] SEC1, "SEC 1: Elliptic Curve Cryptography, Version 2.0", 1172 Standards for Efficient Cryptography , June 2009. 1174 11. Informative references 1176 [IANA.JOSE.Algorithms] 1177 IANA, "JSON Web Signature and Encryption Algorithms", 1178 IANA, 1179 https://www.iana.org/assignments/jose/jose.xhtml#web- 1180 signature-encryption-algorithms. 1182 [IANA.JOSE.Curves] 1183 IANA, "JSON Web Key Elliptic Curve", IANA, 1184 https://www.iana.org/assignments/jose/jose.xhtml#web-key- 1185 elliptic-curve. 1187 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1188 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1189 . 1191 [BCP 106] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1192 "Randomness Requirements for Security", BCP 106, RFC 4086, 1193 DOI 10.17487/RFC4086, June 2005, 1194 . 1196 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1197 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1198 DOI 10.17487/RFC4861, September 2007, 1199 . 1201 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1202 Address Autoconfiguration", RFC 4862, 1203 DOI 10.17487/RFC4862, September 2007, 1204 . 1206 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1207 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1208 Overview, Assumptions, Problem Statement, and Goals", 1209 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1210 . 1212 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1213 "Transmission of IPv6 Packets over IEEE 802.15.4 1214 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1215 . 1217 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1218 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1219 DOI 10.17487/RFC6282, September 2011, 1220 . 1222 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 1223 "Source Address Validation Improvement (SAVI) Framework", 1224 RFC 7039, DOI 10.17487/RFC7039, October 2013, 1225 . 1227 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1228 Interface Identifiers with IPv6 Stateless Address 1229 Autoconfiguration (SLAAC)", RFC 7217, 1230 DOI 10.17487/RFC7217, April 2014, 1231 . 1233 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 1234 DOI 10.17487/RFC7518, May 2015, 1235 . 1237 [BCP 201] Housley, R., "Guidelines for Cryptographic Algorithm 1238 Agility and Selecting Mandatory-to-Implement Algorithms", 1239 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1240 . 1242 [RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) 1243 and Signatures in JSON Object Signing and Encryption 1244 (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, 1245 . 1247 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 1248 "Recommendation on Stable IPv6 Interface Identifiers", 1249 RFC 8064, DOI 10.17487/RFC8064, February 2017, 1250 . 1252 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 1253 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 1254 February 2017, . 1256 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1257 Writing an IANA Considerations Section in RFCs", BCP 26, 1258 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1259 . 1261 [BACKBONE-ROUTER] 1262 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 1263 Backbone Router", Work in Progress, Internet-Draft, draft- 1264 ietf-6lo-backbone-router-20, 23 March 2020, 1265 . 1268 [CURVE-REPR] 1269 Struik, R., "Alternative Elliptic Curve Representations", 1270 Work in Progress, Internet-Draft, draft-ietf-lwig-curve- 1271 representations-09, 9 March 2020, 1272 . 1275 [breaking-ed25519] 1276 Samwel, N., Batina, L., Bertoni, G., Daemen, J., and R. 1277 Susella, "Breaking Ed25519 in WolfSSL", Cryptographers' 1278 Track at the RSA Conference , 2018, 1279 . 1282 Appendix A. Requirements Addressed in this Document 1284 In this section we state requirements of a secure neighbor discovery 1285 protocol for low-power and lossy networks. 1287 * The protocol MUST be based on the Neighbor Discovery Optimization 1288 for Low-power and Lossy Networks protocol defined in [RFC6775]. 1289 RFC6775 utilizes optimizations such as host-initiated interactions 1290 for sleeping resource-constrained hosts and elimination of 1291 multicast address resolution. 1292 * New options to be added to Neighbor Solicitation messages MUST 1293 lead to small packet sizes, especially compared with existing 1294 protocols such as SEcure Neighbor Discovery (SEND). Smaller 1295 packet sizes facilitate low-power transmission by resource- 1296 constrained nodes on lossy links. 1297 * The support for this registration mechanism SHOULD be extensible 1298 to more LLN links than IEEE 802.15.4 only. Support for at least 1299 the LLN links for which a 6lo "IPv6 over foo" specification 1300 exists, as well as Low-Power Wi-Fi SHOULD be possible. 1301 * As part of this extension, a mechanism to compute a unique 1302 Identifier should be provided with the capability to form a Link 1303 Local Address that SHOULD be unique at least within the LLN 1304 connected to a 6LBR. 1305 * The Address Registration Option used in the ND registration SHOULD 1306 be extended to carry the relevant forms of Unique Interface 1307 Identifier. 1309 * The Neighbor Discovery should specify the formation of a site- 1310 local address that follows the security recommendations from 1311 [RFC7217]. 1313 Appendix B. Representation Conventions 1315 B.1. Signature Schemes 1317 The signature scheme ECDSA256 corresponding to Crypto-Type 0 is 1318 ECDSA, as specified in [FIPS186-4], instantiated with the NIST prime 1319 curve P-256, as specified in Appendix B of [FIPS186-4], and the hash 1320 function SHA-256, as specified in [RFC6234], where points of this 1321 NIST curve are represented as points of a short-Weierstrass curve 1322 (see [FIPS186-4]) and are encoded as octet strings in most- 1323 significant-bit first (msb) and most-significant-byte first (MSB) 1324 order. The signature itself consists of two integers (r and s), 1325 which are each encoded as fixed-size octet strings in most- 1326 significant-bit first and most-significant-byte first order. For 1327 details on ECDSA, see [FIPS186-4]; for details on the integer 1328 encoding, see Appendix B.2. 1330 The signature scheme Ed25519 corresponding to Crypto-Type 1 is EdDSA, 1331 as specified in [RFC8032], instantiated with the Montgomery curve 1332 Curve25519, as specified in [RFC7748], and the hash function SHA-512, 1333 as specified in [RFC6234], where points of this Montgomery curve are 1334 represented as points of the corresponding twisted Edwards curve (see 1335 Appendix B.3) and are encoded as octet strings in least-significant- 1336 bit first (lsb) and least-significant-byte first (LSB) order. The 1337 signature itself consists of a bit string that encodes a point of 1338 this twisted Edwards curve, in compressed format, and an integer 1339 encoded in least-significant-bit first and least-significant-byte 1340 first order. For details on EdDSA and on the encoding conversions, 1341 see the specification of pure Ed25519 in [RFC8032]. 1343 The signature scheme ECDSA25519 corresponding to Crypto-Type 2 is 1344 ECDSA, as specified in [FIPS186-4], instantiated with the Montgomery 1345 curve Curve25519, as specified in [RFC7748], and the hash function 1346 SHA-256, as specified in [RFC6234], where points of this Montgomery 1347 curve are represented as points of a corresponding curve in short- 1348 Weierstrass form (see Appendix B.3) and are encoded as octet strings 1349 in most-significant-bit first and most-significant-byte first order. 1350 The signature itself consists of a bit string that encodes two 1351 integers, each encoded as fixed-size octet strings in most- 1352 significant-bit first and most-significant-byte first order. For 1353 details on ECDSA, see [FIPS186-4]; for details on the integer 1354 encoding, see Appendix B.2 1356 B.2. Integer Representation for ECDSA signatures 1358 With ECDSA, each signature is an ordered pair (r, s) of integers 1359 [FIPS186-4]. Each integer is encoded as a fixed-size 256-bit bit 1360 string, where each integer is represented according to the Field 1361 Element to Octet String and Octet String to Bit String conversion 1362 rules in [SEC1] and where the ordered pair of integers is represented 1363 as the rightconcatenation of the resulting representation values. 1364 The inverse operation follows the corresponding Bit String to Octet 1365 String and Octet String to Field Element conversion rules of [SEC1]. 1367 B.3. Alternative Representations of Curve25519 1369 The elliptic curve Curve25519, as specified in [RFC7748], is a so- 1370 called Montgomery curve. Each point of this curve can also be 1371 represented as a point of a twisted Edwards curve or as a point of an 1372 elliptic curve in short-Weierstrass form, via a coordinate 1373 transformation (a so-called isomorphic mapping). The parameters of 1374 the Montgomery curve and the corresponding isomorphic curves in 1375 twisted Edwards curve and short-Weierstrass form are as indicated 1376 below. Here, the domain parameters of the Montgomery curve 1377 Curve25519 and of the twisted Edwards curve Edwards25519 are as 1378 specified in [RFC7748]; the domain parameters of the elliptic curve 1379 Wei25519 in short-Weierstrass curve comply with Section 6.1.1 of 1380 [FIPS186-4]. For details of the coordinate transformations 1381 referenced above, see [RFC7748] and [CURVE-REPR]. 1383 General parameters (for all curve models): 1385 p 2^{255}-19 1386 (=0x7fffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 1387 ffffffed) 1388 h 8 1389 n 1390 723700557733226221397318656304299424085711635937990760600195093828 1391 5454250989 1392 (=2^{252} + 0x14def9de a2f79cd6 5812631a 5cf5d3ed) 1394 Montgomery curve-specific parameters (for Curve25519): 1396 A 486662 1397 B 1 1398 Gu 9 (=0x9) 1399 Gv 1400 147816194475895447910205935684099868872646061346164752889648818377 1401 55586237401 1402 (=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2 1403 7eced3d9) 1405 Twisted Edwards curve-specific parameters (for Edwards25519): 1407 a -1 (-0x01) 1408 d -121665/121666 1409 (=3709570593466943934313808350875456518954211387984321901638878553 1410 3085940283555) 1411 (=0x52036cee 2b6ffe73 8cc74079 7779e898 00700a4d 4141d8ab 75eb4dca 1412 135978a3) 1413 Gx 1414 151122213495354007725011514095885315114540126930418572060461132839 1415 49847762202 1416 (=0x216936d3 cd6e53fe c0a4e231 fdd6dc5c 692cc760 9525a7b2 c9562d60 1417 8f25d51a) 1418 Gy 4/5 1419 (=4631683569492647816942839400347516314130799386625622561578303360 1420 3165251855960) 1421 (=0x66666666 66666666 66666666 66666666 66666666 66666666 66666666 1422 66666658) 1424 Weierstrass curve-specific parameters (for Wei25519): 1426 a 1427 192986815395526992372618308347813179755449974442734273399095973345 1428 73241639236 1429 (=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaa98 1430 4914a144) 1431 b 1432 557517466698189089076452890782571408182411037279010123152944008379 1433 56729358436 1434 (=0x7b425ed0 97b425ed 097b425e d097b425 ed097b42 5ed097b4 260b5e9c 1435 7710c864) 1436 GX 1437 192986815395526992372618308347813179755449974442734273399095973346 1438 52188435546 1439 (=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa 1440 aaad245a) 1441 GY 1442 147816194475895447910205935684099868872646061346164752889648818377 1443 55586237401 1444 (=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2 1445 7eced3d9) 1447 Authors' Addresses 1449 Pascal Thubert (editor) 1450 Cisco Systems, Inc 1451 Building D 1452 45 Allee des Ormes - BP1200 1453 06254 MOUGINS - Sophia Antipolis 1454 France 1456 Phone: +33 497 23 26 34 1457 Email: pthubert@cisco.com 1459 Behcet Sarikaya 1461 Email: sarikaya@ieee.org 1463 Mohit Sethi 1464 Ericsson 1465 FI-02420 Jorvas 1466 Finland 1468 Email: mohit@piuha.net 1470 Rene Struik 1471 Struik Security Consultancy 1473 Email: rstruik.ext@gmail.com