idnits 2.17.1 draft-ietf-6lo-ap-nd-19.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 (6 February 2020) is 1538 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: 9 August 2020 M. Sethi 7 Ericsson 8 R. Struik 9 Struik Security Consultancy 10 6 February 2020 12 Address Protected Neighbor Discovery for Low-power and Lossy Networks 13 draft-ietf-6lo-ap-nd-19 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 9 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 . . . . . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . 27 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 that is used to detect 212 and reject duplicate registrations in the DAD process. The ROVR is a 213 generic object that is designed for backward compatibility with the 214 capability to introduce new computation methods in the future. Using 215 a Crypto-ID per this specification is the RECOMMENDED method. 216 Section 7.3 discusses collisions when heterogeneous methods to 217 compute the ROVR field coexist inside a same network. 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 ascertained. 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 [BCP 201], 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 indexed by IANA in the 371 "Crypto-Type Subregistry" in the "Internet Control Message 372 Protocol version 6 (ICMPv6) Parameters" (see Section 8.3). 374 Modifier: 8-bit unsigned integer. Set to an arbitrary value by the 375 creator of the Crypto-ID. The role of the modifier is to enable 376 the formation of multiple Crypto-IDs from a same key pair, which 377 reduces the traceability and thus improves the privacy of a 378 constrained node that could not maintain many key-pairs. 380 EARO Length: 8-bit unsigned integer. The option length of the EARO 381 that contains the Crypto-ID associated with the CIPO. 383 Reserved2: 16-bit unsigned integer. It MUST be set to zero by the 384 sender and MUST be ignored by the receiver. 386 Public Key: A variable-length field, size indicated in the Public 387 Key Length field. JWK-Encoded Public Key [RFC7517]. 389 Padding: A variable-length field completing the Public Key field to 390 align to the next 8-bytes boundary. It MUST be set to zero by the 391 sender and MUST be ignored by the receiver. 393 The implementation of multiple hash functions in a constrained 394 devices may consume excessive amounts of program memory. This 395 specification enables the use of SHA-256 [RFC6234] for all the 396 supported ECC curves. 398 Some code factorization is also possible for the ECC computation 399 itself. [CURVE-REPRESENTATIONS] provides information on how to 400 represent Montgomery curves and (twisted) Edwards curves as curves in 401 short-Weierstrass form and illustrates how this can be used to 402 implement elliptic curve computations using existing implementations 403 that already provide, e.g., ECDSA and ECDH using NIST [FIPS186-4] 404 prime curves. For more details on representation conventions, we 405 refer to Appendix B. 407 4.4. NDP Signature Option 409 This specification defines the NDP Signature Option (NDPSO). The 410 NDPSO carries the signature that proves the ownership of the Crypto- 411 ID. The format of the NDPSO is illustrated in Figure 3. 413 As opposed to the RSA Signature Option (RSAO) defined in section 5.2. 414 of SEND [RFC3971], the NDPSO does not have a key hash field. 415 Instead, the leftmost 128 bits of the ROVR field in the EARO are used 416 as hash to retrieve the CIPO that contains the key material used for 417 signature verification, left-padded if needed. 419 Another difference is that the NDPSO signs a fixed set of fields as 420 opposed to all options that appear prior to it in the ND message that 421 bears the signature. This allows to elide a CIPO that the 6LR 422 already received, at the expense of the capability to add arbitrary 423 options that would signed with a RSAO. 425 An ND message that carries an NDPSO MUST have one and only one EARO. 426 The EARO MUST contain a Crypto-ID in the ROVR field, and the Crypto- 427 ID MUST be associated with the keypair used for the Digital Signature 428 in the NDPSO. 430 The CIPO may be present in the same message as the NDPSO. If it is 431 not present, it can be found in an abstract table that was created by 432 a previous message and indexed by the hash. 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Type | Length |Reserved1| Signature Length | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Reserved2 | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | | 442 . . 443 . Digital Signature (variable length) . 444 . . 445 | | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | | 448 . Padding . 449 | | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Figure 3: NDP signature Option 454 Type: to be assigned by IANA, see Table 1. 456 Length: 8-bit unsigned integer. The length of the option in units 457 of 8 octets. 459 Reserved1: 5-bit unsigned integer. It MUST be set to zero by the 460 sender and MUST be ignored by the receiver. 462 Digital Signature Length: 11-bit unsigned integer. The length of 463 the Digital Signature field in bytes. 465 Reserved2: 32-bit unsigned integer. It MUST be set to zero by the 466 sender and MUST be ignored by the receiver. 468 Digital Signature: A variable-length field containing a digital 469 signature. The length and computation of the digital signature 470 both depend on the Crypto-Type which is found in the associated 471 CIPO. For the values of the Crypto-Type that are defined in this 472 specification, and unless specified otherwise for a future value 473 of the Crypto-Type, the signature is computed as detailed in 474 Section 6.2. 476 Padding: A variable-length field completing the Digital Signature 477 field to align to the next 8-bytes boundary. It MUST be set to 478 zero by the sender and MUST be ignored by the receiver. 480 5. Protocol Scope 482 The scope of the protocol specified here is a 6LoWPAN LLN, typically 483 a stub network connected to a larger IP network via a Border Router 484 called a 6LBR per [RFC6775]. A 6LBR has sufficient capability to 485 satisfy the needs of duplicate address detection. 487 The 6LBR maintains registration state for all devices in its attached 488 LLN. Together with the first-hop router (the 6LR), the 6LBR assures 489 uniqueness and grants ownership of an IPv6 address before it can be 490 used in the LLN. This is in contrast to a traditional network that 491 relies on IPv6 address auto-configuration [RFC4862], where there is 492 no guarantee of ownership from the network, and each IPv6 Neighbor 493 Discovery packet must be individually secured [RFC3971]. 495 ---+-------- ............ 496 | External Network 497 | 498 +-----+ 499 | | 6LBR 500 +-----+ 501 o o o 502 o o o o 503 o o LLN o o o 504 o o o (6LR) 505 o (6LN) 507 Figure 4: Basic Configuration 509 In a mesh network, the 6LR is directly connected to the host device. 510 This specification mandates that the peer-wise layer-2 security is 511 deployed so that all the packets from a particular host are securely 512 identifiable by the 6LR. The 6LR may be multiple hops away from the 513 6LBR. Packets are routed between the 6LR and the 6LBR via other 514 6LRs. This specification mandates that a chain of trust is 515 established so that a packet that was validated by the first 6LR can 516 be safely routed by other on-path 6LRs to the 6LBR. 518 6. Protocol Flows 520 The 6LR/6LBR ensures first-come/first-serve by storing the ROVR 521 associated to the address being registered upon the first 522 registration and rejecting a registration with a different ROVR 523 value. A 6LN can claim any address as long as it is the first to 524 make that claim. After a successful registration, the 6LN becomes 525 the owner of the registered address and the address is bound to the 526 ROVR value in the 6LR/6LBR registry. 528 This specification enables the 6LR to challenge the 6LN to verify its 529 ownership of the binding by placing a Crypto-ID in the ROVR. The 530 challenge can happen at any time at the discretion of the 6LR. The 531 6LR MUST challenge the 6LN when it creates a binding and when a new 532 registration attempts to change a parameter of the binding that 533 identifies the 6LN, for instance its Source Link-Layer Address. The 534 verification protects against a rogue that would steal an address and 535 attract its traffic, or use it as source address. 537 The challenge can also triggered by the 6LBR, e.g., to enforce a 538 global policy. In that case, the 6LBR returns a status of 539 "Validation Requested" in the DAR/DAC exchange, which is echoed by 540 the 6LR in the NA (EARO) back to the registering node. A valid 541 registration in the 6LR or the 6LBR MUST NOT be altered until the 542 challenge is complete. 544 A node may use more than one IPv6 address at the same time. The 545 separation of the address and the cryptographic material avoids the 546 need for the constrained device to compute multiple keys for multiple 547 addresses. The 6LN MAY use the same Crypto-ID to prove the ownership 548 of multiple IPv6 addresses. The 6LN MAY also derive multiple Crypto- 549 IDs from a same key. 551 6.1. First Exchange with a 6LR 553 A 6LN registers to a 6LR that is one hop away from it with the "C" 554 flag set in the EARO, indicating that the ROVR field contains a 555 Crypto-ID. The Target Address in the NS message indicates the IPv6 556 address that the 6LN is trying to register [RFC8505]. The on-link 557 (local) protocol interactions are shown in Figure 5. If the 6LR does 558 not have a state with the 6LN that is consistent with the NS(EARO), 559 then it replies with a challenge NA (EARO, status=Validation 560 Requested) that contains a Nonce Option (shown as NonceLR in 561 Figure 5). 563 The Nonce option contains a nonce value that, to the extent possible 564 for the implementation, was never employed in association with the 565 key pair used to generate the Crypto-ID. This specification inherits 566 from [RFC3971] that simply indicates that the nonce is a random 567 value. Ideally, an implementation uses an unpredictable 568 cryptographically random value [BCP 106]. But that may be 569 impractical in some LLN scenarios where the devices do not have a 570 guaranteed sense of time and for which computing complex hashes is 571 detrimental to the battery lifetime. Alternatively, the device may 572 use an always-incrementing value saved in the same stable storage as 573 the key, so they are lost together, and starting at a best effort 574 random value, either as the nonce value or as a component to its 575 computation. 577 The 6LN replies to the challenge with an NS(EARO) that includes a new 578 Nonce option (shown as NonceLN in Figure 5), the CIPO (Section 4.3), 579 and the NDPSO containing the signature. Both Nonces are included in 580 the signed material. This provides a "contributory behavior", so 581 that either party that knows it generates a good quality nonce knows 582 that the protocol will be secure. 584 The 6LR MUST store the information associated to a Crypto-ID on the 585 first NS exchange where it appears in a fashion that the CIPO 586 parameters can be retrieved from the Crypto-ID alone. 588 6LN 6LR 589 | | 590 |<------------------------- RA -------------------------| 591 | | ^ 592 |---------------- NS with EARO (Crypto-ID) ------------>| | 593 | | option 594 |<- NA with EARO (status=Validation Requested), NonceLR-| | 595 | | v 596 |------- NS with EARO, CIPO, NonceLN and NDPSO -------->| 597 | | 598 |<------------------- NA with EARO ---------------------| 599 | | 600 ... 601 | | 602 |--------------- NS with EARO (Crypto-ID) ------------->| 603 | | 604 |<------------------- NA with EARO ---------------------| 605 | | 606 ... 607 | | 608 |--------------- NS with EARO (Crypto-ID) ------------->| 609 | | 610 |<------------------- NA with EARO ---------------------| 611 | | 613 Figure 5: On-link Protocol Operation 615 The steps for the registration to the 6LR are as follows: 617 * Upon the first exchange with a 6LR, a 6LN will be challenged to 618 prove ownership of the Crypto-ID and the Target Address being 619 registered in the Neighbor Solicitation message. When a 6LR 620 receives a NS(EARO) registration with a new Crypto-ID as a ROVR, 621 and unless the registration is rejected for another reason, it 622 MUST challenge by responding with a NA(EARO) with a status of 623 "Validation Requested". 625 * Upon receiving a first NA(EARO) with a status of "Validation 626 Requested" from a 6LR, the registering node SHOULD retry its 627 registration with a Crypto-ID Parameters Option (CIPO) 628 (Section 4.3) that contains all the necessary material for 629 building the Crypto-ID, the NonceLN that it generated, and the NDP 630 signature (Section 4.4) option that proves its ownership of the 631 Crypto-ID and intent of registering the Target Address. In 632 subsequent revalidation with the same 6LR, the 6LN MAY try to omit 633 the CIPO to save bandwidth, with the expectation that the 6LR 634 saved it. If the validation fails and it gets challenged again, 635 then it SHOULD add the CIPO again. 637 * In order to validate the ownership, the 6LR performs the same 638 steps as the 6LN and rebuilds the Crypto-ID based on the 639 parameters in the CIPO. If the rebuilt Crypto-ID matches the 640 ROVR, the 6LN also verifies the signature contained in the NDPSO 641 option. If at that point the signature in the NDPSO option can be 642 verified, then the validation succeeds. Otherwise the validation 643 fails. 645 * If the 6LR fails to validate the signed NS(EARO), it responds with 646 a status of "Validation Failed". After receiving a NA(EARO) with 647 a status of "Validation Failed", the registering node SHOULD try 648 to register an alternate target address in the NS message. 650 6.2. NDPSO generation and verification 652 The signature generated by the 6LN to provide proof-of-ownership of 653 the private-key is carried in the NDP Signature Option (NDPSO). It 654 is generated by the 6LN in a fashion that depends on the Crypto-Type 655 (see Table 2 in Section 8.3) chosen by the 6LN as follows: 657 * Concatenate the following in the order listed: 659 1. The 128-bit Message Type tag [RFC3972] (in network byte order). 660 For this specification the tag is 0x8701 55c8 0cca dd32 6ab7 e415 661 f148 84d0. (The tag value has been generated by the editor of 662 this specification on random.org). 663 2. JWK-encoded public key 664 3. the 16-byte Target Address (in network byte order) sent in the 665 Neighbor Solicitation (NS) message. It is the address which the 666 6LN is registering with the 6LR and 6LBR. 667 4. NonceLR received from the 6LR (in network byte order) in the 668 Neighbor Advertisement (NA) message. The nonce is at least 6 669 bytes long as defined in [RFC3971]. 670 5. NonceLN sent from the 6LN (in network byte order). The nonce is 671 at least 6 bytes long as defined in [RFC3971]. 673 6. 1-byte Option Length of the EARO containing the Crypto-ID. 674 7. 1-byte Crypto-Type value sent in the CIPO. 676 * Apply the hash function (if any) specified by the Crypto-Type to 677 the concatenated data, e.g., hash the resulting data using SHA- 678 256. 680 * Apply the signature algorithm specified by the Crypto-Type, e.g., 681 sign the hash output with ECDSA (if curve P-256 is used) or sign 682 the hash with EdDSA (if curve Ed25519 (PureEdDSA)). 684 The 6LR on receiving the NDPSO and CIPO options first checks that the 685 EARO Length in the CIPO matches the length of the EARO. If so it 686 regenerates the Crypto-ID based on the CIPO to make sure that the 687 leftmost bits up to the size of the ROVR match. 689 If and only if the check is successful, it tries to verify the 690 signature in the NDPSO option using the following: 692 * Concatenate the following in the order listed: 694 1. 128-bit type tag (in network byte order) 695 2. JWK-encoded public key received in the CIPO 696 3. the 16-byte Target Address (in network byte order) received in 697 the Neighbor Solicitation (NS) message. It is the address which 698 the 6LN is registering with the 6LR and 6LBR. 699 4. NonceLR sent in the Neighbor Advertisement (NA) message. The 700 nonce is at least 6 bytes long as defined in [RFC3971]. 701 5. NonceLN received from the 6LN (in network byte order) in the NS 702 message. The nonce is at least 6 bytes long as defined in 703 [RFC3971]. 704 6. 1-byte EARO Length received in the CIPO. 705 7. 1-byte Crypto-Type value received in the CIPO. 707 * Apply the hash function (if any) specified by the Crypto-Type 708 indicated by the 6LN in the CIPO to the concatenated data. 710 * Verify the signature with the public-key in the CIPO and the 711 locally computed values using the signature algorithm specified by 712 the Crypto-Type. If the verification succeeds, the 6LR propagates 713 the information to the 6LBR using a EDAR/EDAC flow. 715 * Due to the first-come/first-serve nature of the registration, if 716 the address is not registered to the 6LBR, then flow succeeds and 717 both the 6LR and 6LBR add the state information about the Crypto- 718 ID and Target Address being registered to their respective 719 abstract database. 721 6.3. Multihop Operation 723 A new 6LN that joins the network auto-configures an address and 724 performs an initial registration to a neighboring 6LR with an NS 725 message that carries an Address Registration Option (EARO) [RFC8505]. 727 In a multihop 6LoWPAN, the registration with Crypto-ID is propagated 728 to 6LBR as shown in Figure 6, which illustrates the registration flow 729 all the way to a 6LowPAN Backbone Router (6BBR) [BACKBONE-ROUTER]. 731 The 6LR and the 6LBR communicate using ICMPv6 Extended Duplicate 732 Address Request (EDAR) and Extended Duplicate Address Confirmation 733 (EDAC) messages [RFC8505] as shown in Figure 6. This specification 734 extends EDAR/EDAC messages to carry cryptographically generated ROVR. 736 The assumption is that the 6LR and the 6LBR maintain a security 737 association to authenticate and protect the integrity of the EDAR and 738 EDAC messages, so there is no need to propagate the proof of 739 ownership to the 6LBR. The 6LBR implicitly trusts that the 6LR 740 performs the verification when the 6LBR requires it, and if there is 741 no further exchange from the 6LR to remove the state, that the 742 verification succeeded. 744 6LN 6LR 6LBR 6BBR 745 | | | | 746 | NS(EARO) | | | 747 |--------------->| | | 748 | | Extended DAR | | 749 | |-------------->| | 750 | | | | 751 | | | proxy NS(EARO) | 752 | | |--------------->| 753 | | | | NS(DAD) 754 | | | | ------> 755 | | | | 756 | | | | 757 | | | | 758 | | | proxy NA(EARO) | 759 | | |<---------------| 760 | | Extended DAC | | 761 | |<--------------| | 762 | NA(EARO) | | | 763 |<---------------| | | 764 | | | | 766 Figure 6: (Re-)Registration Flow 768 7. Security Considerations 770 7.1. Inheriting from RFC 3971 772 Observations regarding the following threats to the local network in 773 [RFC3971] also apply to this specification. 775 Neighbor Solicitation/Advertisement Spoofing: Threats in section 776 9.2.1 of RFC3971 apply. AP-ND counters the threats on NS(EARO) 777 messages by requiring that the NDP Signature and CIPO options be 778 present in these solicitations. 780 Duplicate Address Detection DoS Attack: Inside the LLN, Duplicate 781 Addresses are sorted out using the ROVR, which differentiates it 782 from a movement. A different ROVR for the same Registered address 783 entails a rejection of the second registration [RFC8505]. DAD 784 coming from the backbone are not forwarded over the LLN, which 785 provides some protection against DoS attacks inside the resource- 786 constrained part of the network. Over the backbone, the EARO 787 option is present in NS/NA messages. This protects against 788 misinterpreting a movement for a duplication, and enables the 789 backbone routers to determine which one has the freshest 790 registration [RFC8505] and is thus the best candidate to validate 791 the registration for the device attached to it [BACKBONE-ROUTER]. 792 But this specification does not guarantee that the backbone router 793 claiming an address over the backbone is not an attacker. 795 Router Solicitation and Advertisement Attacks: This specification 796 does not change the protection of RS and RA which can still be 797 protected by SEND. 799 Replay Attacks A nonce should never repeat for a single key, but 800 nonces do not need to be unpredictable for secure operation. 801 Using nonces (NonceLR and NonceLN) generated by both the 6LR and 802 6LN ensure a contributory behavior that provides an efficient 803 protection against replay attacks of the challenge/response flow. 804 The quality of the protection by a random nonce depends on the 805 random number generator and its parameters (e.g., sense of time). 807 Neighbor Discovery DoS Attack: A rogue node that managed to access 808 the L2 network may form many addresses and register them using AP- 809 ND. The perimeter of the attack is all the 6LRs in range of the 810 attacker. The 6LR MUST protect itself against overflows and 811 reject excessive registration with a status 2 "Neighbor Cache 812 Full". This effectively blocks another (honest) 6LN from 813 registering to the same 6LR, but the 6LN may register to other 814 6LRs that are in its range but not in that of the rogue. 816 7.2. Related to 6LoWPAN ND 818 The threats and mediations discussed in 6LoWPAN ND [RFC6775][RFC8505] 819 also apply here, in particular denial-of-service attacks against the 820 registry at the 6LR or 6LBR. 822 Secure ND [RFC3971] forces the IPv6 address to be cryptographic since 823 it integrates the CGA as the IID in the IPv6 address. In contrast, 824 this specification saves about 1Kbyte in every NS/NA message. Also, 825 this specification separates the cryptographic identifier from the 826 registered IPv6 address so that a node can have more than one IPv6 827 address protected by the same cryptographic identifier. 829 With this specification the 6LN can freely form its IPv6 address(es) 830 in any fashion, thereby enabling either 6LoWPAN compression for IPv6 831 addresses that are derived from Layer-2 addresses, or temporary 832 addresses, e.g., formed pseudo-randomly and released in relatively 833 short cycles for privacy reasons [RFC8064][RFC8065], that cannot be 834 compressed. 836 This specification provides added protection for addresses that are 837 obtained following due procedure [RFC8505] but does not constrain the 838 way the addresses are formed or the number of addresses that are used 839 in parallel by a same entity. A rogue may still perform denial-of- 840 service attack against the registry at the 6LR or 6LBR, or attempt to 841 deplete the pool of available addresses at Layer-2 or Layer-3. 843 7.3. ROVR Collisions 845 A collision of Registration Ownership Verifiers (ROVR) (i.e., the 846 Crypto-ID in this specification) is possible, but it is a rare event. 847 Assuming in the calculations/discussion below that the hash used for 848 calculating the Crypto-ID is a well-behaved cryptographic hash and 849 thus that random collisions are the only ones possible, the formula 850 (birthday paradox) for calculating the probability of a collision is 851 1 - e^{-k^2/(2n)} where n is the maximum population size (2^64 here, 852 1.84E19) and k is the actual population (number of nodes, assuming 853 one Crypto-ID per node). 855 If the Crypto-ID is 64-bits (the least possible size allowed), the 856 chance of a collision is 0.01% for network of 66 million nodes. 857 Moreover, the collision is only relevant when this happens within one 858 stub network (6LBR). In the case of such a collision, a third party 859 node would be able to claim the registered address of an another 860 legitimate node, provided that it wishes to use the same address. To 861 prevent address disclosure and avoid the chances of collision on both 862 the ROVR and the address, it is RECOMMENDED that nodes do not derive 863 the address being registered from the ROVR. 865 7.4. Implementation Attacks 867 The signature schemes referenced in this specification comply with 868 NIST [FIPS186-4] or Crypto Forum Research Group (CFRG) standards 869 [RFC8032] and offer strong algorithmic security at roughly 128-bit 870 security level. These signature schemes use elliptic curves that 871 were either specifically designed with exception-free and constant- 872 time arithmetic in mind [RFC7748] or where one has extensive 873 implementation experience of resistance to timing attacks 874 [FIPS186-4]. However, careless implementations of the signing 875 operations could nevertheless leak information on private keys. For 876 example, there are micro-architectural side channel attacks that 877 implementors should be aware of [breaking-ed25519]. Implementors 878 should be particularly aware that a secure implementation of Ed25519 879 requires a protected implementation of the hash function SHA-512, 880 whereas this is not required with implementations of SHA-256 used 881 with ECDSA. 883 7.5. Cross-Algorithm and Cross-Protocol Attacks 885 The keypair used in this specification can be self-generated and the 886 public key does not need to be exchanged, e.g., through certificates, 887 with a third party before it is used. New keypairs can be formed for 888 new registration as the node desires. On the other hand, it is safer 889 to allocate a keypair that is used only for the address protection 890 and only for one instantiation of the signature scheme (which 891 includes choice of elliptic curve domain parameters, used hash 892 function, and applicable representation conventions). The same 893 private key MUST NOT be reused with more than one instantiation of 894 the signature scheme in this specification. The same private key 895 MUST NOT be used for anything other than computing NDPSO signatures 896 per this specification. 898 7.6. Compromised 6LR 900 This specification distributes the challenge and its validation at 901 the edge of the network, between the 6LN and its 6LR. This protects 902 against DOS attacks targeted at that central 6LBR. This also saves 903 back and forth exchanges across a potentially large and constrained 904 network. The downside is that the 6LBR needs to trust the 6LR for 905 performing the checking adequately, and the communication between the 906 6LR and the 6LBR must be protected to avoid tempering with the result 907 of the test. If a 6LR is compromised, and provided that it knows the 908 ROVR field used by the real owner of the address, the 6LR may pretend 909 that the owner has moved, is now attached to it and has successfully 910 passed the Crpto-ID validation. The 6LR may then attract and inject 911 traffic at will on behalf of that address or let a rogue take 912 ownership of the address. 914 7.7. Correlating Registrations 916 The ROVR field in the EARO introduced in [RFC8505] extends the EUI-64 917 field of the ARO defined in [RFC6775]. One of the drawbacks of using 918 an EUI-64 as ROVR is that an attacker that is aware of the 919 registrations can correlate traffic for a same 6LN across multiple 920 addresses. Section 3 of [RFC8505] indicates that the ROVR and the 921 address being registered are decoupled. A 6LN may use a same ROVR 922 for multiple registrations or a different ROVR per registration, and 923 the IID must not derive from the ROVR. In theory different 6LNs 924 could use a same ROVR as long as they do not attempt to register the 925 same address. 927 The Modifier used in the computation of the Crypto-ID enables a 6LN 928 to build different Crypto-IDs for different addresses with a same 929 keypair. Using that facility improves the privacy of the 6LN as the 930 expense of storage in the 6LR, which will need to store multiple 931 CIPOs that contain the same public key. Note that if the attacker is 932 the 6LR, then the Modifier alone does not provide a protection, and 933 the 6LN would need to use different keys and MAC addresses in an 934 attempt to obfuscate its multiple ownership. 936 8. IANA considerations 938 8.1. CGA Message Type 940 This document defines a new 128-bit value under the CGA Message Type 941 [RFC3972] name space: 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0. 943 8.2. IPv6 ND option types 945 This document registers two new ND option types under the subregistry 946 "IPv6 Neighbor Discovery Option Formats": 948 +------------------------------+-----------------+---------------+ 949 | Option Name | Suggested Value | Reference | 950 +==============================+=================+===============+ 951 | NDP Signature Option (NDPSO) | 38 | This document | 952 +------------------------------+-----------------+---------------+ 953 | Crypto-ID Parameters Option | 39 | This document | 954 | (CIPO) | | | 955 +------------------------------+-----------------+---------------+ 957 Table 1: New ND options 959 8.3. Crypto-Type Subregistry 961 IANA is requested to create a new subregistry "Crypto-Type 962 Subregistry" in the "Internet Control Message Protocol version 6 963 (ICMPv6) Parameters". The registry is indexed by an integer in the 964 interval 0..255 and contains an Elliptic Curve, a Hash Function, a 965 Signature Algorithm, and Representation Conventions, as shown in 966 Table 2, which together specify a signature scheme. The following 967 Crypto-Type values are defined in this document: 969 +----------------+---------------+---------------+---------------+ 970 | Crypto-Type | 0 (ECDSA256) | 1 (Ed25519) | 2 | 971 | value | | | (ECDSA25519) | 972 +================+===============+===============+===============+ 973 | Elliptic curve | NIST P-256 | Curve25519 | Curve25519 | 974 | | [FIPS186-4] | [RFC7748] | [RFC7748] | 975 +----------------+---------------+---------------+---------------+ 976 | Hash function | SHA-256 | SHA-512 | SHA-256 | 977 | | [RFC6234] | [RFC6234] | [RFC6234] | 978 +----------------+---------------+---------------+---------------+ 979 | Signature | ECDSA | Ed25519 | ECDSA | 980 | algorithm | [FIPS186-4] | [RFC8032] | [FIPS186-4] | 981 +----------------+---------------+---------------+---------------+ 982 | Representation | Weierstrass, | Edwards, | Weierstrass, | 983 | conventions | uncompressed, | compressed, | compressed, | 984 | | MSB/msb first | LSB/lsb first | MSB/msb first | 985 +----------------+---------------+---------------+---------------+ 986 | Defining | This document | This document | This document | 987 | specification | | | | 988 +----------------+---------------+---------------+---------------+ 990 Table 2: Crypto-Types 992 New Crypto-Type values providing similar or better security may be 993 defined in the future. 995 Assignment of new values for new Crypto-Type MUST be done through 996 IANA with either "Specification Required" or "IESG Approval" as 997 defined in BCP 26 [RFC8126]. 999 The "Defining specification" column indicates the document that 1000 defines the length and computation of the digital signature, which 1001 could be this for values defined through "IESG Approval". 1003 9. Acknowledgments 1005 Many thanks to Charlie Perkins for his in-depth review and 1006 constructive suggestions. The authors are also especially grateful 1007 to Robert Moskowitz and Benjamin Kaduk for their comments and 1008 discussions that led to many improvements. The authors wish to also 1009 thank Roman Danyliw, Alissa Cooper, Mirja Kuhlewind, Eric Vyncke, 1010 Vijay Gurbani, Al Morton and Adam Montville for their constructive 1011 reviews during the IESG process. 1013 10. Normative References 1015 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1016 Requirement Levels", BCP 14, RFC 2119, 1017 DOI 10.17487/RFC2119, March 1997, 1018 . 1020 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1021 Bormann, "Neighbor Discovery Optimization for IPv6 over 1022 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1023 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1024 . 1026 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 1027 DOI 10.17487/RFC7517, May 2015, 1028 . 1030 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1031 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1032 May 2017, . 1034 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1035 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1036 DOI 10.17487/RFC3971, March 2005, 1037 . 1039 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1040 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1041 2016, . 1043 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1044 Signature Algorithm (EdDSA)", RFC 8032, 1045 DOI 10.17487/RFC8032, January 2017, 1046 . 1048 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 1049 Perkins, "Registration Extensions for IPv6 over Low-Power 1050 Wireless Personal Area Network (6LoWPAN) Neighbor 1051 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 1052 . 1054 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1055 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1056 DOI 10.17487/RFC6234, May 2011, 1057 . 1059 [FIPS186-4] 1060 FIPS 186-4, "Digital Signature Standard (DSS), Federal 1061 Information Processing Standards Publication 186-4", US 1062 Department of Commerce/National Institute of Standards and 1063 Technology , July 2013. 1065 [SEC1] SEC1, "SEC 1: Elliptic Curve Cryptography, Version 2.0", 1066 Standards for Efficient Cryptography , June 2009. 1068 11. Informative references 1070 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1071 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1072 . 1074 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1075 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1076 DOI 10.17487/RFC4861, September 2007, 1077 . 1079 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1080 Address Autoconfiguration", RFC 4862, 1081 DOI 10.17487/RFC4862, September 2007, 1082 . 1084 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1085 "Transmission of IPv6 Packets over IEEE 802.15.4 1086 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1087 . 1089 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1090 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1091 DOI 10.17487/RFC6282, September 2011, 1092 . 1094 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1095 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1096 Overview, Assumptions, Problem Statement, and Goals", 1097 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1098 . 1100 [BCP 106] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1101 "Randomness Requirements for Security", BCP 106, RFC 4086, 1102 DOI 10.17487/RFC4086, June 2005, 1103 . 1105 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1106 Writing an IANA Considerations Section in RFCs", BCP 26, 1107 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1108 . 1110 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 1111 "Source Address Validation Improvement (SAVI) Framework", 1112 RFC 7039, DOI 10.17487/RFC7039, October 2013, 1113 . 1115 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1116 Interface Identifiers with IPv6 Stateless Address 1117 Autoconfiguration (SLAAC)", RFC 7217, 1118 DOI 10.17487/RFC7217, April 2014, 1119 . 1121 [BCP 201] Housley, R., "Guidelines for Cryptographic Algorithm 1122 Agility and Selecting Mandatory-to-Implement Algorithms", 1123 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1124 . 1126 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 1127 "Recommendation on Stable IPv6 Interface Identifiers", 1128 RFC 8064, DOI 10.17487/RFC8064, February 2017, 1129 . 1131 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 1132 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 1133 February 2017, . 1135 [BACKBONE-ROUTER] 1136 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 1137 Backbone Router", Work in Progress, Internet-Draft, draft- 1138 ietf-6lo-backbone-router-13, 26 September 2019, 1139 . 1142 [CURVE-REPRESENTATIONS] 1143 Struik, R., "Alternative Elliptic Curve Representations", 1144 Work in Progress, Internet-Draft, draft-ietf-lwig-curve- 1145 representations-08, 24 July 2019, 1146 . 1149 [breaking-ed25519] 1150 Samwel, N., Batina, L., Bertoni, G., Daemen, J., and R. 1151 Susella, "Breaking Ed25519 in WolfSSL", Cryptographers' 1152 Track at the RSA Conference , 2018, 1153 . 1156 Appendix A. Requirements Addressed in this Document 1158 In this section we state requirements of a secure neighbor discovery 1159 protocol for low-power and lossy networks. 1161 * The protocol MUST be based on the Neighbor Discovery Optimization 1162 for Low-power and Lossy Networks protocol defined in [RFC6775]. 1163 RFC6775 utilizes optimizations such as host-initiated interactions 1164 for sleeping resource-constrained hosts and elimination of 1165 multicast address resolution. 1166 * New options to be added to Neighbor Solicitation messages MUST 1167 lead to small packet sizes, especially compared with existing 1168 protocols such as SEcure Neighbor Discovery (SEND). Smaller 1169 packet sizes facilitate low-power transmission by resource- 1170 constrained nodes on lossy links. 1171 * The support for this registration mechanism SHOULD be extensible 1172 to more LLN links than IEEE 802.15.4 only. Support for at least 1173 the LLN links for which a 6lo "IPv6 over foo" specification 1174 exists, as well as Low-Power Wi-Fi SHOULD be possible. 1175 * As part of this extension, a mechanism to compute a unique 1176 Identifier should be provided with the capability to form a Link 1177 Local Address that SHOULD be unique at least within the LLN 1178 connected to a 6LBR. 1179 * The Address Registration Option used in the ND registration SHOULD 1180 be extended to carry the relevant forms of Unique Interface 1181 Identifier. 1182 * The Neighbor Discovery should specify the formation of a site- 1183 local address that follows the security recommendations from 1184 [RFC7217]. 1186 Appendix B. Representation Conventions 1188 B.1. Signature Schemes 1190 The signature scheme ECDSA256 corresponding to Crypto-Type 0 is 1191 ECDSA, as specified in [FIPS186-4], instantiated with the NIST prime 1192 curve P-256, as specified in Appendix B of [FIPS186-4], and the hash 1193 function SHA-256, as specified in [RFC6234], where points of this 1194 NIST curve are represented as points of a short-Weierstrass curve 1195 (see [FIPS186-4]) and are encoded as octet strings in most- 1196 significant-bit first (msb) and most-significant-byte first (MSB) 1197 order. The signature itself consists of two integers (r and s), 1198 which are each encoded as fixed-size octet strings in most- 1199 significant-bit first and most-significant-byte first order. For 1200 details on ECDSA, see [FIPS186-4]; for details on the integer 1201 encoding, see Appendix B.2. 1203 The signature scheme Ed25519 corresponding to Crypto-Type 1 is EdDSA, 1204 as specified in [RFC8032], instantiated with the Montgomery curve 1205 Curve25519, as specified in [RFC7748], and the hash function SHA-512, 1206 as specified in [RFC6234], where points of this Montgomery curve are 1207 represented as points of the corresponding twisted Edwards curve (see 1208 Appendix B.3) and are encoded as octet strings in least-significant- 1209 bit first (lsb) and least-significant-byte first (LSB) order. The 1210 signature itself consists of a bit string that encodes a point of 1211 this twisted Edwards curve, in compressed format, and an integer 1212 encoded in least-significant-bit first and least-significant-byte 1213 first order. For details on EdDSA and on the encoding conversions, 1214 see the specification of pure Ed25519 in [RFC8032]. 1216 The signature scheme ECDSA25519 corresponding to Crypto-Type 2 is 1217 ECDSA, as specified in [FIPS186-4], instantiated with the Montgomery 1218 curve Curve25519, as specified in [RFC7748], and the hash function 1219 SHA-256, as specified in [RFC6234], where points of this Montgomery 1220 curve are represented as points of a corresponding curve in short- 1221 Weierstrass form (see Appendix B.3) and are encoded as octet strings 1222 in most-significant-bit first and most-significant-byte first order. 1223 The signature itself consists of a bit string that encodes two 1224 integers, each encoded as fixed-size octet strings in most- 1225 significant-bit first and most-significant-byte first order. For 1226 details on ECDSA, see [FIPS186-4]; for details on the integer 1227 encoding, see Appendix B.2 1229 B.2. Integer Representation for ECDSA signatures 1231 With ECDSA, each signature is an ordered pair (r, s) of integers 1232 [FIPS186-4]. Each integer is encoded as a fixed-size 256-bit bit 1233 string, where each integer is represented according to the Field 1234 Element to Octet String and Octet String to Bit String conversion 1235 rules in [SEC1] and where the ordered pair of integers is represented 1236 as the rightconcatenation of the resulting representation values. 1237 The inverse operation follows the corresponding Bit String to Octet 1238 String and Octet String to Field Element conversion rules of [SEC1]. 1240 B.3. Alternative Representations of Curve25519 1242 The elliptic curve Curve25519, as specified in [RFC7748], is a so- 1243 called Montgomery curve. Each point of this curve can also be 1244 represented as a point of a twisted Edwards curve or as a point of an 1245 elliptic curve in short-Weierstrass form, via a coordinate 1246 transformation (a so-called isomorphic mapping). The parameters of 1247 the Montgomery curve and the corresponding isomorphic curves in 1248 twisted Edwards curve and short-Weierstrass form are as indicated 1249 below. Here, the domain parameters of the Montgomery curve 1250 Curve25519 and of the twisted Edwards curve Edwards25519 are as 1251 specified in [RFC7748]; the domain parameters of the elliptic curve 1252 Wei25519 in short-Weierstrass curve comply with Section 6.1.1 of 1253 [FIPS186-4]. For details of the coordinate transformations 1254 referenced above, see [RFC7748] and [CURVE-REPRESENTATIONS]. 1256 General parameters (for all curve models): 1258 p 2^{255}-19 1259 (=0x7fffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 1260 ffffffed) 1261 h 8 1262 n 1263 723700557733226221397318656304299424085711635937990760600195093828 1264 5454250989 1265 (=2^{252} + 0x14def9de a2f79cd6 5812631a 5cf5d3ed) 1267 Montgomery curve-specific parameters (for Curve25519): 1269 A 486662 1270 B 1 1271 Gu 9 (=0x9) 1272 Gv 1273 147816194475895447910205935684099868872646061346164752889648818377 1274 55586237401 1275 (=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2 1276 7eced3d9) 1278 Twisted Edwards curve-specific parameters (for Edwards25519): 1280 a -1 (-0x01) 1281 d -121665/121666 1282 (=3709570593466943934313808350875456518954211387984321901638878553 1283 3085940283555) 1284 (=0x52036cee 2b6ffe73 8cc74079 7779e898 00700a4d 4141d8ab 75eb4dca 1285 135978a3) 1287 Gx 1288 151122213495354007725011514095885315114540126930418572060461132839 1289 49847762202 1290 (=0x216936d3 cd6e53fe c0a4e231 fdd6dc5c 692cc760 9525a7b2 c9562d60 1291 8f25d51a) 1292 Gy 4/5 1293 (=4631683569492647816942839400347516314130799386625622561578303360 1294 3165251855960) 1295 (=0x66666666 66666666 66666666 66666666 66666666 66666666 66666666 1296 66666658) 1298 Weierstrass curve-specific parameters (for Wei25519): 1300 a 1301 192986815395526992372618308347813179755449974442734273399095973345 1302 73241639236 1303 (=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaa98 1304 4914a144) 1305 b 1306 557517466698189089076452890782571408182411037279010123152944008379 1307 56729358436 1308 (=0x7b425ed0 97b425ed 097b425e d097b425 ed097b42 5ed097b4 260b5e9c 1309 7710c864) 1310 GX 1311 192986815395526992372618308347813179755449974442734273399095973346 1312 52188435546 1313 (=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa 1314 aaad245a) 1315 GY 1316 147816194475895447910205935684099868872646061346164752889648818377 1317 55586237401 1318 (=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2 1319 7eced3d9) 1321 Authors' Addresses 1323 Pascal Thubert (editor) 1324 Cisco Systems, Inc 1325 Building D 1326 45 Allee des Ormes - BP1200 1327 06254 MOUGINS - Sophia Antipolis 1328 France 1330 Phone: +33 497 23 26 34 1331 Email: pthubert@cisco.com 1332 Behcet Sarikaya 1334 Email: sarikaya@ieee.org 1336 Mohit Sethi 1337 Ericsson 1338 FI-02420 Jorvas 1339 Finland 1341 Email: mohit@piuha.net 1343 Rene Struik 1344 Struik Security Consultancy 1346 Email: rstruik.ext@gmail.com