idnits 2.17.1 draft-ietf-6lo-ap-nd-17.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 (4 February 2020) is 1537 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-13 == 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.S. Sarikaya 5 Intended status: Standards Track 6 Expires: 7 August 2020 M.S. Sethi 7 Ericsson 8 R.S. Struik 9 Struik Security Consultancy 10 4 February 2020 12 Address Protected Neighbor Discovery for Low-power and Lossy Networks 13 draft-ietf-6lo-ap-nd-17 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 7 August 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 . . . . . . . . . . . . . . . . . . . . . . . 11 76 6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 12 77 6.2. NDPSO generation and verification . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . 18 83 7.4. Implementation Attacks . . . . . . . . . . . . . . . . . 19 84 7.5. Cross-Algorithm and Cross-Protocol Attacks . . . . . . . 19 85 7.6. Compromised 6LR . . . . . . . . . . . . . . . . . . . . . 19 86 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 87 8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 20 88 8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 20 89 8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 20 90 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 91 10. Normative References . . . . . . . . . . . . . . . . . . . . 21 92 11. Informative references . . . . . . . . . . . . . . . . . . . 23 93 Appendix A. Requirements Addressed in this Document . . . . . . 24 94 Appendix B. Representation Conventions . . . . . . . . . . . . . 25 95 B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 25 96 B.2. Integer Representation for ECDSA signatures . . . . . . . 26 97 B.3. Alternative Representations of Curve25519 . . . . . . . . 26 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 100 1. Introduction 102 Neighbor Discovery Optimizations for 6LoWPAN networks [RFC6775] 103 (6LoWPAN ND) adapts the original IPv6 Neighbor Discovery (IPv6 ND) 104 protocols defined in [RFC4861] and [RFC4862] for constrained low- 105 power and lossy network (LLN). In particular, 6LoWPAN ND introduces 106 a unicast host Address Registration mechanism that reduces the use of 107 multicast compared to the Duplicate Address Detection (DAD) mechanism 108 defined in IPv6 ND. 6LoWPAN ND defines a new Address Registration 109 Option (ARO) that is carried in the unicast Neighbor Solicitation 110 (NS) and Neighbor Advertisement (NA) messages exchanged between a 111 6LoWPAN Node (6LN) and a 6LoWPAN Router (6LR). It also defines the 112 Duplicate Address Request (DAR) and Duplicate Address Confirmation 113 (DAC) messages between the 6LR and the 6LoWPAN Border Router (6LBR). 114 In LLN networks, the 6LBR is the central repository of all the 115 registered addresses in its domain. 117 The registration mechanism in "Neighbor Discovery Optimization for 118 Low-power and Lossy Networks" [RFC6775] (aka 6LoWPAN ND) prevents the 119 use of an address if that address is already registered in the subnet 120 (first come first serve). In order to validate address ownership, 121 the registration mechanism enables the 6LR and 6LBR to validate the 122 association between the registered address of a node, and its 123 Registration Ownership Verifier (ROVR). The ROVR is defined in 124 "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] 125 and it can be derived from the MAC address of the device (using the 126 64-bit Extended Unique Identifier EUI-64 address format specified by 127 IEEE). However, the EUI-64 can be spoofed, and therefore, any node 128 connected to the subnet and aware of a registered-address-to-ROVR 129 mapping could effectively fake the ROVR. This would allow the an 130 attacker to steal the address and redirect traffic for that address. 131 [RFC8505] defines an Extended Address Registration Option (EARO) 132 option that allows to transport alternate forms of ROVRs, and is a 133 pre-requisite for this specification. 135 In this specification, a 6LN generates a cryptographic ID (Crypto-ID) 136 and places it in the ROVR field during the registration of one (or 137 more) of its addresses with the 6LR(s). Proof of ownership of the 138 Crypto-ID is passed with the first registration exchange to a new 139 6LR, and enforced at the 6LR. The 6LR validates ownership of the 140 cryptographic ID before it creates any new registration state, or 141 changes existing information. 143 The protected address registration protocol proposed in this document 144 provides the same conceptual benefit as Source Address Validation 145 (SAVI) [RFC7039] that only the owner of an IPv6 address may source 146 packets with that address. As opposed to [RFC7039], which relies on 147 snooping protocols, the protection is based on a state that is 148 installed and maintained in the network by the owner of the address. 149 With this specification, a 6LN may use a 6LR for forwarding an IPv6 150 packets if and only if it has registered the address used as source 151 of the packet with that 6LR. 153 With the 6lo adaptation layer in [RFC4944] and [RFC6282], a 6LN can 154 obtain a better compression for an IPv6 address with an Interface ID 155 (IID) that is derived from a Layer-2 address. As a side note, this 156 is incompatible with Secure Neighbor Discovery (SeND) [RFC3971] and 157 Cryptographically Generated Addresses (CGAs) [RFC3972], since they 158 derive the IID from cryptographic keys, whereas this specification 159 separates the IID and the key material. 161 2. Terminology 163 2.1. BCP 14 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in BCP 168 14 [RFC2119] [RFC8174] when, and only when, they appear in all 169 capitals, as shown here. 171 2.2. Abbreviations 173 This document uses the following abbreviations: 175 6BBR: 6LoWPAN Backbone Router 176 6LBR: 6LoWPAN Border Router 177 6LN: 6LoWPAN Node 178 6LR: 6LoWPAN Router 179 EARO: Extended Address Registration Option 180 CIPO: Crypto-ID Parameters Option 181 LLN: Low-Power and Lossy Network 182 NA: Neighbor Advertisement 183 ND: Neighbor Discovery 184 NDPSO: Neighbor Discovery Protocol Signature Option 185 NS: Neighbor Solicitation 186 ROVR: Registration Ownership Verifier 187 RA: Router Advertisement 188 RS: Router Solicitation 189 RSAO: RSA Signature Option 190 TID: Transaction ID 192 2.3. Additional References 194 The reader may get additional context for this specification from the 195 following references: 197 * "SEcure Neighbor Discovery (SEND)" [RFC3971], 199 * "Cryptographically Generated Addresses (CGA)" [RFC3972], 201 * "Neighbor Discovery for IP version 6" [RFC4861] , 203 * "IPv6 Stateless Address Autoconfiguration" [RFC4862], and 205 * "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 206 Overview, Assumptions, Problem Statement, and Goals " [RFC4919]. 208 3. Updating RFC 8505 210 Section 5.3 of [RFC8505] introduces the ROVR as a generic object that 211 is designed for backward compatibility with the capability to 212 introduce new computation methods in the future. Section 7.3 213 discusses collisions when heterogeneous methods to compute the ROVR 214 field coexist inside a same network. [RFC8505] was designed in 215 preparation for this specification, which is the RECOMMENDED method 216 for building a ROVR field. 218 This specification introduces a new token called a cryptographic 219 identifier (Crypto-ID) that is transported in the ROVR field and used 220 to prove indirectly the ownership of an address that is being 221 registered by means of [RFC8505]. The Crypto-ID is derived from a 222 cryptographic public key and additional parameters. 224 The overall mechanism requires the support of Elliptic Curve 225 Cryptography (ECC) and of a hash function as detailed in Section 6.2. 226 To enable the verification of the proof, the registering node needs 227 to supply certain parameters including a nonce and a signature that 228 will demonstrate that the node possesses the private-key 229 corresponding to the public-key used to build the Crypto-ID. 231 The elliptic curves and the hash functions listed in Table 2 in 232 Section 8.3 can be used with this specification; more may be added in 233 the future to the IANA registry. The signature scheme that specifies 234 which combination is used (including the curve and the representation 235 conventions) is signaled by a Crypto-Type in a new IPv6 ND Crypto-ID 236 Parameters Option (CIPO, see Section 4.3) that contains the 237 parameters that are necessary for the proof, a Nonce option 238 ([RFC3971]) and a NDP Signature option (Section 4.4). The NA(EARO) 239 is modified to enable a challenge and transport a Nonce option. 241 4. New Fields and Options 243 4.1. New Crypto-ID 245 The Crypto-ID is transported in the ROVR field of the EARO option and 246 the EDAR message, and is associated with the Registered Address at 247 the 6LR and the 6LBR. The ownership of a Crypto-ID can be 248 demonstrated by cryptographic mechanisms, and by association, the 249 ownership of the Registered Address can be acertained. 251 A node in possession of the necessary cryptographic primitives SHOULD 252 use Crypto-ID by default as ROVR in its registrations. Whether a 253 ROVR is a Crypto-ID is indicated by a new "C" flag in the NS(EARO) 254 message. 256 The Crypto-ID is derived from the public key and a modifier as 257 follows: 259 1. The hash function indicated by the Crypto-Type is applied to the 260 CIPO. Note that all the reserved and padding bits MUST be set to 261 zero. 262 2. The leftmost bits of the resulting hash, up to the desired size, 263 are used as the Crypto-ID. 265 At the time of this writing, a minimal size for the Crypto-ID of 128 266 bits is RECOMMENDED unless backward compatibility is needed 267 [RFC8505]. This value is bound to augment in the future. 269 4.2. Updated EARO 271 This specification updates the EARO option to enable the use of the 272 ROVR field to transport the Crypto-ID. The resulting format is as 273 follows: 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Type | Length | Status | Opaque | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 |Rsvd |C| I |R|T| TID | Registration Lifetime | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | 283 ... Registration Ownership Verifier (ROVR) ... 284 | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 1: Enhanced Address Registration Option 289 Type: 33 291 Length: Defined in [RFC8505] and copied in associated CIPO. 293 Status: Defined in [RFC8505]. 295 Opaque: Defined in [RFC8505]. 297 Rsvd (Reserved): 3-bit unsigned integer. It MUST be set to zero by 298 the sender and MUST be ignored by the receiver. 300 C: This "C" flag is set to indicate that the ROVR field contains a 301 Crypto-ID and that the 6LN MAY be challenged for ownership as 302 specified in this document. 304 I, R, T: Defined in [RFC8505]. 306 TID: Defined in [RFC8505]. 308 Registration Ownership Verifier (ROVR): When the "C" flag is set, 309 this field contains a Crypto-ID. 311 This specification uses Status values "Validation Requested" and 312 "Validation Failed", which are defined in [RFC8505]. 314 this specification does not define any new Status value. 316 4.3. Crypto-ID Parameters Option 318 This specification defines the Crypto-ID Parameters Option (CIPO). 319 The CIPO carries the parameters used to form a Crypto-ID. 321 In order to provide cryptographic agility [RFC7696], this 322 specification supports different elliptic curves, indicated by a 323 Crypto-Type field: 325 * NIST P-256 [FIPS186-4] MUST be supported by all implementations. 327 * The Edwards-Curve Digital Signature Algorithm (EdDSA) curve 328 Ed25519 (PureEdDSA) [RFC8032] MAY be supported as an alternate. 330 * This specification uses signature schemes which target similar 331 cryptographic strength but rely on different curves, hash 332 functions, signature algorithms, and/or representation 333 conventions. Future specification may extend this for different 334 cryptographic algorithms and longer keys, e.g., to provide a 335 better security properties or a simpler implementation. 337 0 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Type | Length |Reserved1| Public Key Length | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Crypto-Type | Modifier | EARO Length | Reserved2 | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | | 345 . . 346 . Public Key (variable length) . 347 . . 348 | | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | | 351 . Padding . 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Figure 2: Crypto-ID Parameters Option 357 Type: 8-bit unsigned integer. to be assigned by IANA, see Table 1. 359 Length: 8-bit unsigned integer. The length of the option in units 360 of 8 octets. 362 Reserved1: 5-bit unsigned integer. It MUST be set to zero by the 363 sender and MUST be ignored by the receiver. 365 Public Key Length: 11-bit unsigned integer. The length of the 366 Public Key field in bytes. 368 Crypto-Type: 8-bit unsigned integer. The type of cryptographic 369 algorithm used in calculation Crypto-ID (see Table 2 in 370 Section 8.3). 372 Modifier: 8-bit unsigned integer. Set to an arbitrary value by the 373 creator of the Crypto-ID. The role of the modifier is to enable 374 the formation of multiple Crypto-IDs from a same key pair, which 375 reduces the traceability and thus improves the privacy of a 376 constrained node that could not maintain many key-pairs. 378 EARO Length: 8-bit unsigned integer. The option length of the EARO 379 that contains the Crypto-ID associated with the CIPO. 381 Reserved2: 16-bit unsigned integer. It MUST be set to zero by the 382 sender and MUST be ignored by the receiver. 384 Public Key: A variable-length field, size indicated in the Public 385 Key Length field. JWK-Encoded Public Key [RFC7517]. 387 Padding: A variable-length field completing the Public Key field to 388 align to the next 8-bytes boundary. It MUST be set to zero by the 389 sender and MUST be ignored by the receiver. 391 The implementation of multiple hash functions in a constrained 392 devices may consume excessive amounts of program memory. This 393 specification enables the use of SHA-256 [RFC6234] for all the 394 supported ECC curves. 396 Some code factorization is also possible for the ECC computation 397 itself. [CURVE-REPRESENTATIONS] provides information on how to 398 represent Montgomery curves and (twisted) Edwards curves as curves in 399 short-Weierstrass form and illustrates how this can be used to 400 implement elliptic curve computations using existing implementations 401 that already provide, e.g., ECDSA and ECDH using NIST [FIPS186-4] 402 prime curves. For more details on representation conventions, we 403 refer to Appendix B. 405 4.4. NDP Signature Option 407 This specification defines the NDP Signature Option (NDPSO). The 408 NDPSO carries the signature that proves the ownership of the Crypto- 409 ID. The format of the NDPSO is illustrated in Figure 3. 411 As opposed to the RSA Signature Option (RSAO) defined in section 5.2. 412 of SEND [RFC3971], the NDPSO does not have a key hash field. 413 Instead, the leftmost 128 bits of the ROVR field in the EARO are used 414 to retrieve the CIPO that contains the key material used for 415 signature verification, left-padded if needed. 417 Another difference is that the NDPSO signs a fixed set of fields as 418 opposed to all options that appear prior to it in the ND message that 419 bears the signature. This allows to elide a CIPO that the 6LR 420 already received, at the expense of the capability to add arbitrary 421 options that would signed with a RSAO. 423 An ND message that carries an NDPSO MUST have one and only one EARO. 424 The EARO MUST contain a Crypto-ID in the ROVR field, and the Crypto- 425 ID MUST be associated with the keypair used for the Digital Signature 426 in the NDPSO. 428 The CIPO may be present in the same message as the NDPSO. If it is 429 not present, it can be found in an abstract table that was created by 430 a previous message and indexed by the hash. 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Type | Length |Reserved1| Signature Length | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Reserved2 | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | | 440 . . 441 . Digital Signature (variable length) . 442 . . 443 | | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | | 446 . Padding . 447 | | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Figure 3: NDP signature Option 452 Type: to be assigned by IANA, see Table 1. 454 Length: 8-bit unsigned integer. The length of the option in units 455 of 8 octets. 457 Reserved1: 5-bit unsigned integer. It MUST be set to zero by the 458 sender and MUST be ignored by the receiver. 460 Digital Signature Length: 11-bit unsigned integer. The length of 461 the Digital Signature field in bytes. 463 Reserved2: 32-bit unsigned integer. It MUST be set to zero by the 464 sender and MUST be ignored by the receiver. 466 Digital Signature: A variable-length field containing a digital 467 signature. The computation of the digital signature depends on 468 the Crypto-Type which is found in the associated CIPO. For the 469 values of the Crypto-Type that are defined in this specification, 470 and unless specified otherwise for a future value of the Crypto- 471 Type, the signature is computed as detailed in Section 6.2. 473 Padding: A variable-length field completing the Digital Signature 474 field to align to the next 8-bytes boundary. It MUST be set to 475 zero by the sender and MUST be ignored by the receiver. 477 5. Protocol Scope 479 The scope of the protocol specified here is a 6LoWPAN LLN, typically 480 a stub network connected to a larger IP network via a Border Router 481 called a 6LBR per [RFC6775]. A 6LBR has sufficient capability to 482 satisfy the needs of duplicate address detection. 484 The 6LBR maintains registration state for all devices in its attached 485 LLN. Together with the first-hop router (the 6LR), the 6LBR assures 486 uniqueness and grants ownership of an IPv6 address before it can be 487 used in the LLN. This is in contrast to a traditional network that 488 relies on IPv6 address auto-configuration [RFC4862], where there is 489 no guarantee of ownership from the network, and each IPv6 Neighbor 490 Discovery packet must be individually secured [RFC3971]. 492 ---+-------- ............ 493 | External Network 494 | 495 +-----+ 496 | | 6LBR 497 +-----+ 498 o o o 499 o o o o 500 o o LLN o o o 501 o o o (6LR) 502 o (6LN) 504 Figure 4: Basic Configuration 506 In a mesh network, the 6LR is directly connected to the host device. 507 This specification mandates that the peer-wise layer-2 security is 508 deployed so that all the packets from a particular host are securely 509 identifiable by the 6LR. The 6LR may be multiple hops away from the 510 6LBR. Packets are routed between the 6LR and the 6LBR via other 511 6LRs. This specification mandates that a chain of trust is 512 established so that a packet that was validated by the first 6LR can 513 be safely routed by other on-path 6LRs to the 6LBR. 515 6. Protocol Flows 517 The 6LR/6LBR ensures first-come/first-serve by storing the ROVR 518 associated to the address being registered upon the first 519 registration and rejecting a registration with a different ROVR 520 value. A 6LN can claim any address as long as it is the first to 521 make that claim. After a successful registration, the 6LN becomes 522 the owner of the registered address and the address is bound to the 523 ROVR value in the 6LR/6LBR registry. 525 This specification enables the 6LR to challenge the 6LN to verify its 526 ownership of the binding by placing a Crypto-ID in the ROVR. The 527 challenge can happen at any time at the discretion of the 6LR. The 528 6LR MUST challenge the 6LN when it creates a binding and when a new 529 registration attempts to change a parameter of the binding that 530 identifies the 6LN, for instance its Source Link-Layer Address. The 531 verification protects against a rogue that would steal an address and 532 attract its traffic, or use it as source address. 534 The challenge can also triggered by the 6LBR, e.g., to enforce a 535 global policy. In that case, the 6LBR returns a status of 536 "Validation Requested" in the DAR/DAC exchange, which is echoed by 537 the 6LR in the NA (EARO) back to the registering node. A valid 538 registration in the 6LR or the 6LBR MUST NOT be altered until the 539 challenge is complete. 541 A node may use more than one IPv6 address at the same time. The 542 separation of the address and the cryptographic material avoids the 543 need for the constrained device to compute multiple keys for multiple 544 addresses. The 6LN MAY use the same Crypto-ID to prove the ownership 545 of multiple IPv6 addresses. The 6LN MAY also derive multiple Crypto- 546 IDs from a same key. 548 6.1. First Exchange with a 6LR 550 A 6LN registers to a 6LR that is one hop away from it with the "C" 551 flag set in the EARO, indicating that the ROVR field contains a 552 Crypto-ID. The Target Address in the NS message indicates the IPv6 553 address that the 6LN is trying to register [RFC8505]. The on-link 554 (local) protocol interactions are shown in Figure 5. If the 6LR does 555 not have a state with the 6LN that is consistent with the NS(EARO), 556 then it replies with a challenge NA (EARO, status=Validation 557 Requested) that contains a Nonce Option (shown as NonceLR in 558 Figure 5). 560 The Nonce option contains a nonce value that, to the extent possible 561 for the implementation, was never employed in association with the 562 key pair used to generate the Crypto-ID. This specification inherits 563 from [RFC3971] that simply indicates that the nonce is a random 564 value. Ideally, an implementation uses an unpredictable 565 cryptographically random value [RFC4086]. But that may be 566 impractical in some LLN scenarios where the devices do not have a 567 guaranteed sense of time and for which computing complex hashes is 568 detrimental to the battery lifetime. Alternatively, the device may 569 use an always-incrementing value saved in the same stable storage as 570 the key, so they are lost together, and starting at a best effort 571 random value, either as the nonce value or as a component to its 572 computation. 574 The 6LN replies to the challenge with an NS(EARO) that includes a new 575 Nonce option (shown as NonceLN in Figure 5), the CIPO (Section 4.3), 576 and the NDPSO containing the signature. Both Nonces are included in 577 the signed material. This provides a "contributory behavior", so 578 that either party that knows it generates a good quality nonce knows 579 that the protocol will be secure. 581 The 6LR MUST store the information associated to a Crypto-ID on the 582 first NS exchange where it appears in a fashion that the CIPO 583 parameters can be retrieved from the Crypto-ID alone. 585 6LN 6LR 586 | | 587 |<------------------------- RA -------------------------| 588 | | ^ 589 |---------------- NS with EARO (Crypto-ID) ------------>| | 590 | | option 591 |<- NA with EARO (status=Validation Requested), NonceLR-| | 592 | | v 593 |------- NS with EARO, CIPO, NonceLN and NDPSO -------->| 594 | | 595 |<------------------- NA with EARO ---------------------| 596 | | 597 ... 598 | | 599 |--------------- NS with EARO (Crypto-ID) ------------->| 600 | | 601 |<------------------- NA with EARO ---------------------| 602 | | 603 ... 604 | | 605 |--------------- NS with EARO (Crypto-ID) ------------->| 606 | | 607 |<------------------- NA with EARO ---------------------| 608 | | 610 Figure 5: On-link Protocol Operation 612 The steps for the registration to the 6LR are as follows: 614 * Upon the first exchange with a 6LR, a 6LN will be challenged to 615 prove ownership of the Crypto-ID and the Target Address being 616 registered in the Neighbor Solicitation message. When a 6LR 617 receives a NS(EARO) registration with a new Crypto-ID as a ROVR, 618 and unless the registration is rejected for another reason, it 619 MUST challenge by responding with a NA(EARO) with a status of 620 "Validation Requested". 622 * Upon receiving a first NA(EARO) with a status of "Validation 623 Requested" from a 6LR, the registering node SHOULD retry its 624 registration with a Crypto-ID Parameters Option (CIPO) 625 (Section 4.3) that contains all the necessary material for 626 building the Crypto-ID, the NonceLN that it generated, and the NDP 627 signature (Section 4.4) option that proves its ownership of the 628 Crypto-ID and intent of registering the Target Address. In 629 subsequent revalidation with the same 6LR, the 6LN MAY try to omit 630 the CIPO to save bandwidth, with the expectation that the 6LR 631 saved it. If the validation fails and it gets challenged again, 632 then it SHOULD add the CIPO again. 634 * In order to validate the ownership, the 6LR performs the same 635 steps as the 6LN and rebuilds the Crypto-ID based on the 636 parameters in the CIPO. If the rebuilt Crypto-ID matches the 637 ROVR, the 6LN also verifies the signature contained in the NDPSO 638 option. If at that point the signature in the NDPSO option can be 639 verified, then the validation succeeds. Otherwise the validation 640 fails. 642 * If the 6LR fails to validate the signed NS(EARO), it responds with 643 a status of "Validation Failed". After receiving a NA(EARO) with 644 a status of "Validation Failed", the registering node SHOULD try 645 to register an alternate target address in the NS message. 647 6.2. NDPSO generation and verification 649 The signature generated by the 6LN to provide proof-of-ownership of 650 the private-key is carried in the NDP Signature Option (NDPSO). It 651 is generated by the 6LN in a fashion that depends on the Crypto-Type 652 (see Table 2 in Section 8.3) chosen by the 6LN as follows: 654 * Concatenate the following in the order listed: 656 1. The 128-bit Message Type tag [RFC3972] (in network byte order). 657 For this specification the tag is 0x8701 55c8 0cca dd32 6ab7 e415 658 f148 84d0. (The tag value has been generated by the editor of 659 this specification on random.org). 660 2. JWK-encoded public key 661 3. the 16-byte Target Address (in network byte order) sent in the 662 Neighbor Solicitation (NS) message. It is the address which the 663 6LN is registering with the 6LR and 6LBR. 664 4. NonceLR received from the 6LR (in network byte order) in the 665 Neighbor Advertisement (NA) message. The nonce is at least 6 666 bytes long as defined in [RFC3971]. 667 5. NonceLN sent from the 6LN (in network byte order). The nonce is 668 at least 6 bytes long as defined in [RFC3971]. 670 6. 1-byte Option Length of the EARO containing the Crypto-ID. 671 7. 1-byte Crypto-Type value sent in the CIPO. 673 * Apply the hash function (if any) specified by the Crypto-Type to 674 the concatenated data, e.g., hash the resulting data using SHA- 675 256. 677 * Apply the signature algorithm specified by the Crypto-Type, e.g., 678 sign the hash output with ECDSA (if curve P-256 is used) or sign 679 the hash with EdDSA (if curve Ed25519 (PureEdDSA)). 681 The 6LR on receiving the NDPSO and CIPO options first checks that the 682 EARO Length in the CIPO matches the length of the EARO. If so it 683 regenerates the Crypto-ID based on the CIPO to make sure that the 684 leftmost bits up to the size of the ROVR match. 686 If and only if the check is successful, it tries to verify the 687 signature in the NDPSO option using the following: 689 * Concatenate the following in the order listed: 691 1. 128-bit type tag (in network byte order) 692 2. JWK-encoded public key received in the CIPO 693 3. the 16-byte Target Address (in network byte order) received in 694 the Neighbor Solicitation (NS) message. It is the address which 695 the 6LN is registering with the 6LR and 6LBR. 696 4. NonceLR sent in the Neighbor Advertisement (NA) message. The 697 nonce is at least 6 bytes long as defined in [RFC3971]. 698 5. NonceLN received from the 6LN (in network byte order) in the NS 699 message. The nonce is at least 6 bytes long as defined in 700 [RFC3971]. 701 6. 1-byte EARO Length received in the CIPO. 702 7. 1-byte Crypto-Type value received in the CIPO. 704 * Apply the hash function (if any) specified by the Crypto-Type 705 indicated by the 6LN in the CIPO to the concatenated data. 707 * Verify the signature with the public-key in the CIPO and the 708 locally computed values using the signature algorithm specified by 709 the Crypto-Type. If the verification succeeds, the 6LR propagates 710 the information to the 6LBR using a EDAR/EDAC flow. 712 * Due to the first-come/first-serve nature of the registration, if 713 the address is not registered to the 6LBR, then flow succeeds and 714 both the 6LR and 6LBR add the state information about the Crypto- 715 ID and Target Address being registered to their respective 716 abstract database. 718 6.3. Multihop Operation 720 A new 6LN that joins the network auto-configures an address and 721 performs an initial registration to a neighboring 6LR with an NS 722 message that carries an Address Registration Option (EARO) [RFC8505]. 724 In a multihop 6LoWPAN, the registration with Crypto-ID is propagated 725 to 6LBR as shown in Figure 6, which illustrates the registration flow 726 all the way to a 6LowPAN Backbone Router (6BBR) [BACKBONE-ROUTER]. 728 The 6LR and the 6LBR communicate using ICMPv6 Extended Duplicate 729 Address Request (EDAR) and Extended Duplicate Address Confirmation 730 (EDAC) messages [RFC8505] as shown in Figure 6. This specification 731 extends EDAR/EDAC messages to carry cryptographically generated ROVR. 733 The assumption is that the 6LR and the 6LBR maintain a security 734 association to authenticate and protect the integrity of the EDAR and 735 EDAC messages, so there is no need to propagate the proof of 736 ownership to the 6LBR. The 6LBR implicitly trusts that the 6LR 737 performs the verification when the 6LBR requires it, and if there is 738 no further exchange from the 6LR to remove the state, that the 739 verification succeeded. 741 6LN 6LR 6LBR 6BBR 742 | | | | 743 | NS(EARO) | | | 744 |--------------->| | | 745 | | Extended DAR | | 746 | |-------------->| | 747 | | | | 748 | | | proxy NS(EARO) | 749 | | |--------------->| 750 | | | | NS(DAD) 751 | | | | ------> 752 | | | | 753 | | | | 754 | | | | 755 | | | proxy NA(EARO) | 756 | | |<---------------| 757 | | Extended DAC | | 758 | |<--------------| | 759 | NA(EARO) | | | 760 |<---------------| | | 761 | | | | 763 Figure 6: (Re-)Registration Flow 765 7. Security Considerations 767 7.1. Inheriting from RFC 3971 769 Observations regarding the following threats to the local network in 770 [RFC3971] also apply to this specification. 772 Neighbor Solicitation/Advertisement Spoofing: Threats in section 773 9.2.1 of RFC3971 apply. AP-ND counters the threats on NS(EARO) 774 messages by requiring that the NDP Signature and CIPO options be 775 present in these solicitations. 777 Duplicate Address Detection DoS Attack: Inside the LLN, Duplicate 778 Addresses are sorted out using the ROVR, which differentiates it 779 from a movement. A different ROVR for the same Registered address 780 entails a rejection of the second registration [RFC8505]. DAD 781 coming from the backbone are not forwarded over the LLN, which 782 provides some protection against DoS attacks inside the resource- 783 constrained part of the network. Over the backbone, the EARO 784 option is present in NS/NA messages. This protects against 785 misinterpreting a movement for a duplication, and enables the 786 backbone routers to determine which one has the freshest 787 registration [RFC8505] and is thus the best candidate to validate 788 the registration for the device attached to it [BACKBONE-ROUTER]. 789 But this specification does not guarantee that the backbone router 790 claiming an address over the backbone is not an attacker. 792 Router Solicitation and Advertisement Attacks: This specification 793 does not change the protection of RS and RA which can still be 794 protected by SEND. 796 Replay Attacks A nonce should never repeat for a single key, but 797 nonces do not need to be unpredictable for secure operation. 798 Using nonces (NonceLR and NonceLN) generated by both the 6LR and 799 6LN ensure a contributory behavior that provides an efficient 800 protection against replay attacks of the challenge/response flow. 801 The quality of the protection by a random nonce depends on the 802 random number generator and its parameters (e.g., sense of time). 804 Neighbor Discovery DoS Attack: A rogue node that managed to access 805 the L2 network may form many addresses and register them using AP- 806 ND. The perimeter of the attack is all the 6LRs in range of the 807 attacker. The 6LR MUST protect itself against overflows and 808 reject excessive registration with a status 2 "Neighbor Cache 809 Full". This effectively blocks another (honest) 6LN from 810 registering to the same 6LR, but the 6LN may register to other 811 6LRs that are in its range but not in that of the rogue. 813 7.2. Related to 6LoWPAN ND 815 The threats and mediations discussed in 6LoWPAN ND [RFC6775][RFC8505] 816 also apply here, in particular denial-of-service attacks against the 817 registry at the 6LR or 6LBR. 819 Secure ND [RFC3971] forces the IPv6 address to be cryptographic since 820 it integrates the CGA as the IID in the IPv6 address. In contrast, 821 this specification saves about 1Kbyte in every NS/NA message. Also, 822 this specification separates the cryptographic identifier from the 823 registered IPv6 address so that a node can have more than one IPv6 824 address protected by the same cryptographic identifier. 826 With this specification the 6LN can freely form its IPv6 address(es) 827 in any fashion, thereby enabling either 6LoWPAN compression for IPv6 828 addresses that are derived from Layer-2 addresses, or temporary 829 addresses, e.g., formed pseudo-randomly and released in relatively 830 short cycles for privacy reasons [RFC8064][RFC8065], that cannot be 831 compressed. 833 This specification provides added protection for addresses that are 834 obtained following due procedure [RFC8505] but does not constrain the 835 way the addresses are formed or the number of addresses that are used 836 in parallel by a same entity. A rogue may still perform denial-of- 837 service attack against the registry at the 6LR or 6LBR, or attempt to 838 deplete the pool of available addresses at Layer-2 or Layer-3. 840 7.3. ROVR Collisions 842 A collision of Registration Ownership Verifiers (ROVR) (i.e., the 843 Crypto-ID in this specification) is possible, but it is a rare event. 844 Assuming in the calculations/discussion below that the hash used for 845 calculating the Crypto-ID is a well-behaved cryptographic hash and 846 thus that random collisions are the only ones possible, the formula 847 (birthday paradox) for calculating the probability of a collision is 848 1 - e^{-k^2/(2n)} where n is the maximum population size (2^64 here, 849 1.84E19) and k is the actual population (number of nodes, assuming 850 one Crypto-ID per node). 852 If the Crypto-ID is 64-bits (the least possible size allowed), the 853 chance of a collision is 0.01% for network of 66 million nodes. 854 Moreover, the collision is only relevant when this happens within one 855 stub network (6LBR). In the case of such a collision, a third party 856 node would be able to claim the registered address of an another 857 legitimate node, provided that it wishes to use the same address. To 858 prevent address disclosure and avoid the chances of collision on both 859 the ROVR and the address, it is RECOMMENDED that nodes do not derive 860 the address being registered from the ROVR. 862 7.4. Implementation Attacks 864 The signature schemes referenced in this specification comply with 865 NIST [FIPS186-4] or Crypto Forum Research Group (CFRG) standards 866 [RFC8032] and offer strong algorithmic security at roughly 128-bit 867 security level. These signature schemes use elliptic curves that 868 were either specifically designed with exception-free and constant- 869 time arithmetic in mind [RFC7748] or where one has extensive 870 implementation experience of resistance to timing attacks 871 [FIPS186-4]. However, careless implementations of the signing 872 operations could nevertheless leak information on private keys. For 873 example, there are micro-architectural side channel attacks that 874 implementors should be aware of [breaking-ed25519]. Implementors 875 should be particularly aware that a secure implementation of Ed25519 876 requires a protected implementation of the hash function SHA-512, 877 whereas this is not required with implementations of SHA-256 used 878 with ECDSA. 880 7.5. Cross-Algorithm and Cross-Protocol Attacks 882 The keypair used in this specification can be self-generated and the 883 public key does not need to be exchanged, e.g., through certificates, 884 with a third party before it is used. New keypairs can be formed for 885 new registration as the node desires. On the other hand, it is safer 886 to allocate a keypair that is used only for the address protection 887 and only for one signature scheme. The same private key MUST NOT be 888 reused with more than one signature scheme in this specification. 889 The same private key MUST NOT be used for anything other than 890 computing NDPSO signatures per this specification. 892 7.6. Compromised 6LR 894 This specification distributes the challenge and its validation at 895 the edge of the network, between the 6LN and its 6LR. This protects 896 against DOS attacks targeted at that central 6LBR. This also saves 897 back and forth exchanges across a potentially large and constrained 898 network. The downside is that the 6LBR needs to trust the 6LR for 899 performing the checking adequately, and the communication between the 900 6LR and the 6LBR must be protected to avoid tempering with the result 901 of the test. 903 If a 6LR is compromised, and provided that it knows the ROVR field 904 used by the real owner of the address, the 6LR may pretend that the 905 owner has moved, is now attached to it and has successfully passed 906 the Crpto-ID validation. The 6LR may then attract and inject traffic 907 at will on behalf of that address. Similarly, the 6LR may admit any 908 rogue and let it take ownership of any address in the network for 909 which it knows the value of ROVR. 911 8. IANA considerations 913 8.1. CGA Message Type 915 This document defines a new 128-bit value under the CGA Message Type 916 [RFC3972] name space: 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0. 918 8.2. IPv6 ND option types 920 This document registers two new ND option types under the subregistry 921 "IPv6 Neighbor Discovery Option Formats": 923 +------------------------------+-----------------+---------------+ 924 | Option Name | Suggested Value | Reference | 925 +==============================+=================+===============+ 926 | NDP Signature Option (NDPSO) | 38 | This document | 927 +------------------------------+-----------------+---------------+ 928 | Crypto-ID Parameters Option | 39 | This document | 929 | (CIPO) | | | 930 +------------------------------+-----------------+---------------+ 932 Table 1: New ND options 934 8.3. Crypto-Type Subregistry 936 IANA is requested to create a new subregistry "Crypto-Type 937 Subregistry" in the "Internet Control Message Protocol version 6 938 (ICMPv6) Parameters". The registry is indexed by an integer in the 939 interval 0..255 and contains an Elliptic Curve, a Hash Function, a 940 Signature Algorithm, and Representation Conventions, as shown in 941 Table 2, which together specify a signature scheme. The following 942 Crypto-Type values are defined in this document: 944 +----------------+-----------------+-------------+-----------------+ 945 | Crypto-Type | 0 (ECDSA256) | 1 (Ed25519) | 2 (ECDSA25519) | 946 | value | | | | 947 +================+=================+=============+=================+ 948 | Elliptic curve | NIST P-256 | Curve25519 | Curve25519 | 949 | | [FIPS186-4] | [RFC7748] | [RFC7748] | 950 +----------------+-----------------+-------------+-----------------+ 951 | Hash function | SHA-256 | SHA-512 | SHA-256 | 952 | | [RFC6234] | [RFC6234] | [RFC6234] | 953 +----------------+-----------------+-------------+-----------------+ 954 | Signature | ECDSA | Ed25519 | ECDSA | 955 | algorithm | [FIPS186-4] | [RFC8032] | [FIPS186-4] | 956 +----------------+-----------------+-------------+-----------------+ 957 | Representation | Weierstrass, | Edwards, | Weierstrass, | 958 | conventions | (un)compressed, | compressed, | (un)compressed, | 959 | | MSB/msb first | LSB/lsb | MSB/msb first | 960 | | | first | | 961 +----------------+-----------------+-------------+-----------------+ 962 | Defining | This document | This | This document | 963 | specification | | document | | 964 +----------------+-----------------+-------------+-----------------+ 966 Table 2: Crypto-Types 968 New Crypto-Type values providing similar or better security may be 969 defined in the future. 971 Assignment of new values for new Crypto-Type MUST be done through 972 IANA with either "Specification Required" or "IESG Approval" as 973 defined in [RFC8126]. 975 9. Acknowledgments 977 Many thanks to Charlie Perkins for his in-depth review and 978 constructive suggestions. The authors are also especially grateful 979 to Robert Moskowitz for his comments that led to many improvements. 980 The authors wish to thank Benjamin Kaduk, Mirja Kuhlewind, Eric 981 Vyncke, Vijay Gurbani, Al Morton and Adam Montville for their 982 constructive reviews during the IESG process. 984 10. Normative References 986 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 987 Requirement Levels", BCP 14, RFC 2119, 988 DOI 10.17487/RFC2119, March 1997, 989 . 991 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 992 Bormann, "Neighbor Discovery Optimization for IPv6 over 993 Low-Power Wireless Personal Area Networks (6LoWPANs)", 994 RFC 6775, DOI 10.17487/RFC6775, November 2012, 995 . 997 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 998 DOI 10.17487/RFC7517, May 2015, 999 . 1001 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1002 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1003 May 2017, . 1005 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1006 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1007 DOI 10.17487/RFC3971, March 2005, 1008 . 1010 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1011 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1012 2016, . 1014 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1015 Signature Algorithm (EdDSA)", RFC 8032, 1016 DOI 10.17487/RFC8032, January 2017, 1017 . 1019 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 1020 Perkins, "Registration Extensions for IPv6 over Low-Power 1021 Wireless Personal Area Network (6LoWPAN) Neighbor 1022 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 1023 . 1025 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1026 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1027 DOI 10.17487/RFC6234, May 2011, 1028 . 1030 [FIPS186-4] 1031 FIPS 186-4, "Digital Signature Standard (DSS), Federal 1032 Information Processing Standards Publication 186-4", US 1033 Department of Commerce/National Institute of Standards and 1034 Technology , July 2013. 1036 [SEC1] SEC1, "SEC 1: Elliptic Curve Cryptography, Version 2.0", 1037 Standards for Efficient Cryptography , June 2009. 1039 11. Informative references 1041 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1042 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1043 . 1045 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1046 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1047 DOI 10.17487/RFC4861, September 2007, 1048 . 1050 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1051 Address Autoconfiguration", RFC 4862, 1052 DOI 10.17487/RFC4862, September 2007, 1053 . 1055 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1056 "Transmission of IPv6 Packets over IEEE 802.15.4 1057 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1058 . 1060 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1061 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1062 DOI 10.17487/RFC6282, September 2011, 1063 . 1065 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1066 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1067 Overview, Assumptions, Problem Statement, and Goals", 1068 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1069 . 1071 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1072 "Randomness Requirements for Security", BCP 106, RFC 4086, 1073 DOI 10.17487/RFC4086, June 2005, 1074 . 1076 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1077 Writing an IANA Considerations Section in RFCs", BCP 26, 1078 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1079 . 1081 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 1082 "Source Address Validation Improvement (SAVI) Framework", 1083 RFC 7039, DOI 10.17487/RFC7039, October 2013, 1084 . 1086 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1087 Interface Identifiers with IPv6 Stateless Address 1088 Autoconfiguration (SLAAC)", RFC 7217, 1089 DOI 10.17487/RFC7217, April 2014, 1090 . 1092 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 1093 Agility and Selecting Mandatory-to-Implement Algorithms", 1094 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1095 . 1097 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 1098 "Recommendation on Stable IPv6 Interface Identifiers", 1099 RFC 8064, DOI 10.17487/RFC8064, February 2017, 1100 . 1102 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 1103 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 1104 February 2017, . 1106 [BACKBONE-ROUTER] 1107 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 1108 Backbone Router", Work in Progress, Internet-Draft, draft- 1109 ietf-6lo-backbone-router-13, 26 September 2019, 1110 . 1113 [CURVE-REPRESENTATIONS] 1114 Struik, R., "Alternative Elliptic Curve Representations", 1115 Work in Progress, Internet-Draft, draft-ietf-lwig-curve- 1116 representations-08, 24 July 2019, 1117 . 1120 [breaking-ed25519] 1121 Samwel, N., Batina, L., Bertoni, G., Daemen, J., and R. 1122 Susella, "Breaking Ed25519 in WolfSSL", Cryptographers' 1123 Track at the RSA Conference , 2018, 1124 . 1127 Appendix A. Requirements Addressed in this Document 1129 In this section we state requirements of a secure neighbor discovery 1130 protocol for low-power and lossy networks. 1132 * The protocol MUST be based on the Neighbor Discovery Optimization 1133 for Low-power and Lossy Networks protocol defined in [RFC6775]. 1135 RFC6775 utilizes optimizations such as host-initiated interactions 1136 for sleeping resource-constrained hosts and elimination of 1137 multicast address resolution. 1138 * New options to be added to Neighbor Solicitation messages MUST 1139 lead to small packet sizes, especially compared with existing 1140 protocols such as SEcure Neighbor Discovery (SEND). Smaller 1141 packet sizes facilitate low-power transmission by resource- 1142 constrained nodes on lossy links. 1143 * The support for this registration mechanism SHOULD be extensible 1144 to more LLN links than IEEE 802.15.4 only. Support for at least 1145 the LLN links for which a 6lo "IPv6 over foo" specification 1146 exists, as well as Low-Power Wi-Fi SHOULD be possible. 1147 * As part of this extension, a mechanism to compute a unique 1148 Identifier should be provided with the capability to form a Link 1149 Local Address that SHOULD be unique at least within the LLN 1150 connected to a 6LBR. 1151 * The Address Registration Option used in the ND registration SHOULD 1152 be extended to carry the relevant forms of Unique Interface 1153 Identifier. 1154 * The Neighbor Discovery should specify the formation of a site- 1155 local address that follows the security recommendations from 1156 [RFC7217]. 1158 Appendix B. Representation Conventions 1160 B.1. Signature Schemes 1162 The signature scheme ECDSA256 corresponding to Crypto-Type 0 is 1163 ECDSA, as specified in [FIPS186-4], instantiated with the NIST prime 1164 curve P-256, as specified in Appendix B of [FIPS186-4], and the hash 1165 function SHA-256, as specified in [RFC6234], where points of this 1166 NIST curve are represented as points of a short-Weierstrass curve 1167 (see [FIPS186-4]) and are encoded as octet strings in most- 1168 significant-bit first (msb) and most-significant-byte first (MSB) 1169 order. The signature itself consists of two integers (r and s), 1170 which are each encoded as fixed-size octet strings in most- 1171 significant-bit first and most-significant-byte first order. For 1172 details on ECDSA, see [FIPS186-4]; for details on the integer 1173 encoding, see Appendix B.2. 1175 The signature scheme Ed25519 corresponding to Crypto-Type 1 is EdDSA, 1176 as specified in [RFC8032], instantiated with the Montgomery curve 1177 Curve25519, as specified in [RFC7748], and the hash function SHA-512, 1178 as specified in [RFC6234], where points of this Montgomery curve are 1179 represented as points of the corresponding twisted Edwards curve (see 1180 Appendix B.3) and are encoded as octet strings in least-significant- 1181 bit first (lsb) and least-significant-byte first (LSB) order. The 1182 signature itself consists of a bit string that encodes a point of 1183 this twisted Edwards curve, in compressed format, and an integer 1184 encoded in least-significant-bit first and least-significant-byte 1185 first order. For details on EdDSA and on the encoding conversions, 1186 see the specification of pure Ed25519 in . [RFC8032] 1188 The signature scheme ECDSA25519 corresponding to Crypto-Type 2 is 1189 ECDSA, as specified in [FIPS186-4], instantiated with the Montgomery 1190 curve Curve25519, as specified in [RFC7748], and the hash function 1191 SHA-256, as specified in [RFC6234], where points of this Montgomery 1192 curve are represented as points of a corresponding curve in short- 1193 Weierstrass form (see Appendix B.3) and are encoded as octet strings 1194 in most-significant-bit first and most-significant-byte first order. 1195 The signature itself consists of a bit string that encodes two 1196 integers, each encoded as fixed-size octet strings in most- 1197 significant-bit first and most-significant-byte first order. For 1198 details on ECDSA, see [FIPS186-4]; for details on the integer 1199 encoding, see Appendix B.2 1201 B.2. Integer Representation for ECDSA signatures 1203 With ECDSA, each signature is a pair (r, s) of integers [FIPS186-4]. 1204 Each integer is encoded as a fixed-size 256-bit bit string, where 1205 each integer is represented according to the Field Element to Octet 1206 String and Octet String to Bit String conversion rules in [SEC1] and 1207 where the ordered pair of integers is represented as the 1208 rightconcatenation of the resulting representation values. The 1209 inverse operation follows the corresponding Bit String to Octet 1210 String and Octet String to Field Element conversion rules of [SEC1]. 1212 B.3. Alternative Representations of Curve25519 1214 The elliptic curve Curve25519, as specified in [RFC7748], is a so- 1215 called Montgomery curve. Each point of this curve can also be 1216 represented as a point of a twisted Edwards curve or as a point of an 1217 elliptic curve in short-Weierstrass form, via a coordinate 1218 transformation (a so-called isomorphic mapping). The parameters of 1219 the Montgomery curve and the corresponding isomorphic curves in 1220 twisted Edwards curve and short-Weierstrass form are as indicated 1221 below. Here, the domain parameters of the Montgomery curve 1222 Curve25519 and of the twisted Edwards curve Edwards25519 are as 1223 specified in [RFC7748]; the domain parameters of the elliptic curve 1224 Wei25519 in short-Weierstrass curve comply with Section 6.1.1 of 1225 [FIPS186-4]. For details of the coordinate transformation referenced 1226 above, see [RFC7748] and [CURVE-REPRESENTATIONS]. 1228 General parameters (for all curve models): 1230 p 2^{255}-19 1231 (=0x7fffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 1232 ffffffed) 1233 h 8 1234 n 1235 723700557733226221397318656304299424085711635937990760600195093828 1236 5454250989 1237 (=2^{252} + 0x14def9de a2f79cd6 5812631a 5cf5d3ed) 1239 Montgomery curve-specific parameters (for Curve25519): 1241 A 486662 1242 B 1 1243 Gu 9 (=0x9) 1244 Gv 1245 147816194475895447910205935684099868872646061346164752889648818377 1246 55586237401 1247 (=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2 1248 7eced3d9) 1250 Twisted Edwards curve-specific parameters (for Edwards25519): 1252 a -1 (-0x01) 1253 d -121665/121666 1254 (=3709570593466943934313808350875456518954211387984321901638878553 1255 3085940283555) 1256 (=0x52036cee 2b6ffe73 8cc74079 7779e898 00700a4d 4141d8ab 75eb4dca 1257 135978a3) 1258 Gx 1259 151122213495354007725011514095885315114540126930418572060461132839 1260 49847762202 1261 (=0x216936d3 cd6e53fe c0a4e231 fdd6dc5c 692cc760 9525a7b2 c9562d60 1262 8f25d51a) 1263 Gy 4/5 1264 (=4631683569492647816942839400347516314130799386625622561578303360 1265 3165251855960) 1266 (=0x66666666 66666666 66666666 66666666 66666666 66666666 66666666 1267 66666658) 1269 Weierstrass curve-specific parameters (for Wei25519): 1271 a 1272 192986815395526992372618308347813179755449974442734273399095973345 1273 73241639236 1274 (=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaa98 1275 4914a144) 1276 b 1277 557517466698189089076452890782571408182411037279010123152944008379 1278 56729358436 1279 (=0x7b425ed0 97b425ed 097b425e d097b425 ed097b42 5ed097b4 260b5e9c 1280 7710c864) 1281 GX 1282 192986815395526992372618308347813179755449974442734273399095973346 1283 52188435546 1284 (=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa 1285 aaad245a) 1286 GY 1287 147816194475895447910205935684099868872646061346164752889648818377 1288 55586237401 1289 (=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2 1290 7eced3d9) 1292 Authors' Addresses 1294 Pascal Thubert (editor) 1295 Cisco Systems, Inc 1296 Building D 1297 45 Allee des Ormes - BP1200 1298 06254 MOUGINS - Sophia Antipolis 1299 France 1301 Phone: +33 497 23 26 34 1302 Email: pthubert@cisco.com 1304 Behcet Sarikaya 1306 Email: sarikaya@ieee.org 1308 Mohit Sethi 1309 Ericsson 1310 FI-02420 Jorvas 1311 Finland 1313 Email: mohit@piuha.net 1315 Rene Struik 1316 Struik Security Consultancy 1317 Email: rstruik.ext@gmail.com