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