idnits 2.17.00 (12 Aug 2021) /tmp/idnits52879/draft-ietf-6lo-ap-nd-14.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 (31 January 2020) is 841 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-4' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' == Outdated reference: draft-ietf-6lo-backbone-router has been published as RFC 8929 == Outdated reference: A later version (-23) exists of draft-ietf-lwig-curve-representations-08 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo P. Thubert, Ed. 3 Internet-Draft Cisco 4 Updates: 8505 (if approved) B.S. Sarikaya 5 Intended status: Standards Track 6 Expires: 3 August 2020 M.S. Sethi 7 Ericsson 8 R.S. Struik 9 Struik Security Consultancy 10 31 January 2020 12 Address Protected Neighbor Discovery for Low-power and Lossy Networks 13 draft-ietf-6lo-ap-nd-14 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 3 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. References . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 5 69 4. New Fields and Options . . . . . . . . . . . . . . . . . . . 5 70 4.1. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . 10 75 6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 11 76 6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 11 77 6.2. NDPSO generation and verification . . . . . . . . . . . . 13 78 6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 15 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 16 81 7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 17 82 7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 17 83 7.4. Implementation Attacks . . . . . . . . . . . . . . . . . 17 84 7.5. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 18 85 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 86 8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 18 87 8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 18 88 8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 18 89 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 90 10. Normative References . . . . . . . . . . . . . . . . . . . . 19 91 11. Informative references . . . . . . . . . . . . . . . . . . . 20 92 Appendix A. Requirements Addressed in this Document . . . . . . 22 93 Appendix B. Representation Conventions . . . . . . . . . . . . . 23 94 B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 23 95 B.2. Integer Representation for ECDSA signatures . . . . . . . 24 96 B.3. Alternative Representations of Curve25519 . . . . . . . . 24 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 99 1. Introduction 101 Neighbor Discovery Optimizations for 6LoWPAN networks [RFC6775] 102 (6LoWPAN ND) adapts the original IPv6 Neighbor Discovery (IPv6 ND) 103 protocols defined in [RFC4861] and [RFC4862] for constrained low- 104 power and lossy network (LLN). In particular, 6LoWPAN ND introduces 105 a unicast host Address Registration mechanism that reduces the use of 106 multicast compared to the Duplicate Address Detection (DAD) mechanism 107 defined in IPv6 ND. 6LoWPAN ND defines a new Address Registration 108 Option (ARO) that is carried in the unicast Neighbor Solicitation 109 (NS) and Neighbor Advertisement (NA) messages exchanged between a 110 6LoWPAN Node (6LN) and a 6LoWPAN Router (6LR). It also defines the 111 Duplicate Address Request (DAR) and Duplicate Address Confirmation 112 (DAC) messages between the 6LR and the 6LoWPAN Border Router (6LBR). 113 In LLN networks, the 6LBR is the central repository of all the 114 registered addresses in its domain. 116 The registration mechanism in "Neighbor Discovery Optimization for 117 Low-power and Lossy Networks" [RFC6775] (aka 6LoWPAN ND) prevents the 118 use of an address if that address is already registered in the subnet 119 (first come first serve). In order to validate address ownership, 120 the registration mechanism enables the 6LR and 6LBR to validate the 121 association between the registered address of a node, and its 122 Registration Ownership Verifier (ROVR). The ROVR is defined in 123 "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] 124 and it can be derived from the MAC address of the device (using the 125 64-bit Extended Unique Identifier EUI-64 address format specified by 126 IEEE). However, the EUI-64 can be spoofed, and therefore, any node 127 connected to the subnet and aware of a registered-address-to-ROVR 128 mapping could effectively fake the ROVR. This would allow the an 129 attacker to steal the address and redirect traffic for that address. 130 [RFC8505] defines an Extended Address Registration Option (EARO) 131 option that allows to transport alternate forms of ROVRs, and is a 132 pre-requisite for this specification. 134 In this specification, a 6LN generates a cryptographic ID (Crypto-ID) 135 and places it in the ROVR field during the registration of one (or 136 more) of its addresses with the 6LR(s). Proof of ownership of the 137 Crypto-ID is passed with the first registration exchange to a new 138 6LR, and enforced at the 6LR. The 6LR validates ownership of the 139 cryptographic ID before it creates any new registration state, or 140 changes existing information. 142 The protected address registration protocol proposed in this document 143 enables Source Address Validation (SAVI) [RFC7039]. This ensures 144 that only the actual owner uses a registered address in the IPv6 145 source address field. A 6LN can only use a 6LR for forwarding 146 packets only if it has previously registered the address used in the 147 source field of the IPv6 packet. 149 The 6lo adaptation layer in [RFC4944] and [RFC6282] requires a device 150 to form its IPv6 addresses based on its Layer-2 address to enable a 151 better compression. This is incompatible with Secure Neighbor 152 Discovery (SeND) [RFC3971] and Cryptographically Generated Addresses 153 (CGAs) [RFC3972], since they derive the Interface ID (IID) in IPv6 154 addresses with cryptographic keys. 156 2. Terminology 158 2.1. BCP 14 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in BCP 163 14 [RFC2119] [RFC8174] when, and only when, they appear in all 164 capitals, as shown here. 166 2.2. References 168 The reader may get additional context for this specification from the 169 following references: 171 * "SEcure Neighbor Discovery (SEND)" [RFC3971], 172 * "Cryptographically Generated Addresses (CGA)" [RFC3972], 173 * "Neighbor Discovery for IP version 6" [RFC4861] , 174 * "IPv6 Stateless Address Autoconfiguration" [RFC4862], and 175 * "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 176 Overview, Assumptions, Problem Statement, and Goals " [RFC4919]. 178 2.3. Abbreviations 180 This document uses the following abbreviations: 182 6BBR: 6LoWPAN Backbone Router 183 6LBR: 6LoWPAN Border Router 184 6LN: 6LoWPAN Node 185 6LR: 6LoWPAN Router 186 ARO: Address Registration Option 187 EARO: Extended Address Registration Option 188 CIPO: Crypto-ID Parameters Option 189 LLN: Low-Power and Lossy Network 190 NA: Neighbor Advertisement 191 NCE: Neighbor Cache Entry 192 ND: Neighbor Discovery 193 NDP: Neighbor Discovery Protocol 194 NDPSO: NDP Signature Option 195 NS: Neighbor Solicitation 196 ROVR: Registration Ownership Verifier 197 RPL: Routing Protocol for LLNs 198 RA: Router Advertisement 199 RS: Router Solicitation 200 RSAO: RSA Signature Option 201 TID: Transaction ID 203 3. Updating RFC 8505 205 This specification introduces a new token called a cryptographic 206 identifier (Crypto-ID) that is used to prove indirectly the ownership 207 of an address that is being registered by means of [RFC8505]. The 208 Crypto-ID is derived from a cryptographic public key and additional 209 parameters. The proof requires the support of Elliptic Curve 210 Cryptography (ECC) and that of a hash function as detailed in 211 Section 6.2. To enable the verification of the proof, the 212 registering node needs to supply certain parameters including a Nonce 213 and a signature that will demonstrate that the node has the private- 214 key corresponding to the public-key used to build the Crypto-ID. 216 The elliptic curves and the hash functions that can be used with this 217 specification are listed in Table 2 in Section 8.3. The signature 218 scheme that specifies which combination is used is signaled by a 219 Crypto-Type in the CIPO (see Section 4.3). 221 The NS(EARO) is extended to transport a new Crypto-ID Parameters 222 Option (CIPO, see Section 4.3) that contains the parameters that are 223 necessary for the proof, a Nonce option ([RFC3971]) and a NDP 224 Signature option (Section 4.4). The NA(EARO) is modified to enable a 225 challenge and transport a Nonce option as well. 227 4. New Fields and Options 229 4.1. New Crypto-ID 231 The Crypto-ID is transported in the ROVR field of the EARO option and 232 the EDAR message, and is associated with the Registered Address at 233 the 6LR and the 6LBR. The ownership of a Crypto-ID can be 234 demonstrated by cryptographic mechanisms, and by association, the 235 ownership of the Registered Address can be acertained. 237 A node in possession of the necessary cryptographic primitives SHOULD 238 use Crypto-ID by default as ROVR in its registrations. Whether a 239 ROVR is a Crypto-ID is indicated by a new "C" flag in the NS(EARO) 240 message. 242 The Crypto-ID is derived from the public key and a modifier as 243 follows: 245 1. The hash function indicated by the Crypto-Type is applied to the 246 CIPO. Note that all the reserved and padding bits MUST be set to 247 zero. 248 2. The leftmost bits of the resulting hash, up to the size of the 249 ROVR field, are used as the Crypto-ID. 251 4.2. Updated EARO 253 This specification updates the EARO option as follows: 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Type | Length | Status | Opaque | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 |Rsvd |C| I |R|T| TID | Registration Lifetime | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | | 263 ... Registration Ownership Verifier (ROVR) ... 264 | | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Figure 1: Enhanced Address Registration Option 269 Type: 33 271 Length: 8-bit unsigned integer. The length of the option (including 272 the type and length fields) in units of 8 bytes. 274 Status: 8-bit unsigned integer. Indicates the status of a 275 registration in the NA response. In NS messages it MUST be set to 276 0 by the sender and ignored by the receiver. 278 Opaque: Defined in [RFC8505]. 280 Rsvd (Reserved): 3-bit unsigned integer. It MUST be set to zero by 281 the sender and MUST be ignored by the receiver. 283 C: This "C" flag is set to indicate that the ROVR field contains a 284 Crypto-ID and that the 6LN MAY be challenged for ownership as 285 specified in this document. 287 I, R, T, and TID: Defined in [RFC8505]. 289 Registration Ownership Verifier (ROVR): When the "C" flag is set, 290 this field contains a Crypto-ID. 292 This specification uses Status values "Validation Requested" and 293 "Validation Failed", which are defined in [RFC8505]. No other new 294 Status values are defined. 296 4.3. Crypto-ID Parameters Option 298 This specification defines the Crypto-ID Parameters Option (CIPO). 299 It carries the parameters used to form a Crypto-ID. In order to 300 provide cryptographic agility [RFC7696], this specification supports 301 different elliptic curves, indicated by a Crypto-Type field. NIST 302 P-256 [FIPS186-4] MUST be supported by all implementations. The 303 Edwards-Curve Digital Signature Algorithm (EdDSA) curve Ed25519 304 (PureEdDSA) [RFC8032] MAY be supported as an alternate. 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Type | Length |Reserved1| Public Key Length | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Crypto-Type | Modifier | Reserved2 | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | | 314 | | 315 . . 316 . Public Key (variable length) . 317 . . 318 | | 319 | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | | 322 . . 323 . Padding . 324 . . 325 | | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Figure 2: Crypto-ID Parameters Option 330 Type: 8-bit unsigned integer. to be assigned by IANA, see Table 1. 332 Length: 8-bit unsigned integer. The length of the option in units 333 of 8 octets. 335 Reserved1: 5-bit unsigned integer. It MUST be set to zero by the 336 sender and MUST be ignored by the receiver. 338 Public Key Length: 13-bit unsigned integer. The length of the 339 Public Key field in bytes. 341 Crypto-Type: 8-bit unsigned integer. The type of cryptographic 342 algorithm used in calculation Crypto-ID (see Table 2 in 343 Section 8.3). Although the different signature schemes target 344 similar cryptographic strength, they rely on different curves, 345 hash functions, signature algorithms, and/or representation 346 conventions. 348 Modifier: 8-bit unsigned integer. Set to an arbitrary value by the 349 creator of the Crypto-ID. The role of the modifier is to enable 350 the formation of multiple Crypto-IDs from a same key pair, which 351 reduces the traceability and thus improves the privacy of a 352 constrained node that could not maintain many key-pairs. 354 Reserved2: 16-bit unsigned integer. It MUST be set to zero by the 355 sender and MUST be ignored by the receiver. 357 Public Key: A variable-length field, size indicated in the Public 358 Key Length field. JWK-Encoded Public Key [RFC7517]. 360 Padding: A variable-length field completing the Public Key field to 361 align to the next 8-bytes boundary. 363 The implementation of multiple hash functions in a constrained 364 devices may consume excessive amounts of program memory. 366 [CURVE-REPRESENTATIONS] provides information on how to represent 367 Montgomery curves and (twisted) Edwards curves as curves in short- 368 Weierstrass form and illustrates how this can be used to implement 369 elliptic curve computations using existing implementations that 370 already provide, e.g., ECDSA and ECDH using NIST [FIPS186-4] prime 371 curves. 373 For more details on representation conventions, we refer to 374 Appendix B. 376 4.4. NDP Signature Option 378 The format of the NDP Signature Option (NDPSO) is illustrated in 379 Figure 3. 381 As opposed to the RSA Signature Option (RSAO) defined in section 5.2. 382 of SEND [RFC3971], the NDPSO does not have a key hash field. The 383 hash that can be used as index is the 128 leftmost bits of the ROVR 384 field in the EARO. The CIPO may be present in the same message as 385 the NDPSO. If not, it an be found in an abstract table that was 386 created by a previous message and indexed by the hash. 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Type | Length | Pad Length | | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 393 | Reserved | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | | 396 | | 397 . . 398 . Digital Signature . 399 . . 400 | | 401 | | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | | 404 . . 405 . Padding . 406 . . 407 | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Figure 3: NDP signature Option 412 Type: to be assigned by IANA, see Table 1. 414 Length: 8-bit unsigned integer. The length of the option in units 415 of 8 octets. 417 Pad Length: 8-bit unsigned integer. The length of the Padding 418 field. 420 Reserved: 40-bit unsigned integer. It MUST be set to zero by the 421 sender and MUST be ignored by the receiver. 423 Digital Signature: A variable-length field containing a digital 424 signature. The computation of the digital signature depends on 425 the Crypto-Type which is found in the associated CIPO. For the 426 values of the Crypto-Type that are defined in ths specification, 427 the signature is computed as detailed in Section 6.2. 429 Padding: A variable-length field making the option length a multiple 430 of 8, containing as many octets as specified in the Pad Length 431 field. Typically there is no need of a padding and the field is 432 NULL. 434 5. Protocol Scope 436 The scope of the protocol specified here is a 6LoWPAN LLN, typically 437 a stub network connected to a larger IP network via a Border Router 438 called a 6LBR per [RFC6775]. A 6LBR has sufficient capability to 439 satisfy the needs of duplicate address detection. 441 The 6LBR maintains registration state for all devices in its attached 442 LLN. Together with the first-hop router (the 6LR), the 6LBR assures 443 uniqueness and grants ownership of an IPv6 address before it can be 444 used in the LLN. This is in contrast to a traditional network that 445 relies on IPv6 address auto-configuration [RFC4862], where there is 446 no guarantee of ownership from the network, and each IPv6 Neighbor 447 Discovery packet must be individually secured [RFC3971]. 449 ---+-------- ............ 450 | External Network 451 | 452 +-----+ 453 | | 6LBR 454 +-----+ 455 o o o 456 o o o o 457 o o LLN o o o 458 o o o (6LR) 459 o (6LN) 461 Figure 4: Basic Configuration 463 In a mesh network, the 6LR is directly connected to the host device. 464 This specification mandates that the peer-wise layer-2 security is 465 deployed so that all the packets from a particular host are securely 466 identifiable by the 6LR. The 6LR may be multiple hops away from the 467 6LBR. Packets are routed between the 6LR and the 6LBR via other 468 6LRs. This specification mandates that a chain of trust is 469 established so that a packet that was validated by the first 6LR can 470 be safely routed by other on-path 6LRs to the 6LBR. 472 6. Protocol Flows 474 The 6LR/6LBR ensures first-come/first-serve by storing the EARO 475 information including the Crypto-ID associated to the node being 476 registered. The node can claim any address as long as it is the 477 first to make such a claim. After a successful registration, the 478 node becomes the owner of the registered address and the address is 479 bound to the Crypto-ID in the 6LR/6LBR registry. 481 This specification enables the 6LR to verify the ownership of the 482 binding at any time assuming that the "C" flag is set. The 483 verification prevents other nodes from stealing the address and 484 trying to attract traffic for that address or use it as their source 485 address. 487 A node may use multiple IPv6 addresses at the same time. The node 488 may use the same Crypto-ID, to prove the ownership of multiple IPv6 489 addresses. The separation of the address and the cryptographic 490 material avoids the constrained device to compute multiple keys for 491 multiple addresses. The registration process allows the node to use 492 the same Crypto-ID for all of its addresses. 494 6.1. First Exchange with a 6LR 496 A 6LN registers to a 6LR that is one hop away from it with the "C" 497 flag set in the EARO, indicating that the ROVR field contains a 498 Crypto-ID. The Target Address in the NS message indicates the IPv6 499 address that the 6LN is trying to register. The on-link (local) 500 protocol interactions are shown in Figure 5. If the 6LR does not 501 have a state with the 6LN that is consistent with the NS(EARO), then 502 it replies with a challenge NA (EARO, status=Validation Requested) 503 that contains a Nonce Option (shown as NonceLR in Figure 5). The 504 Nonce option contains a Nonce value that, to the extent possible for 505 the implementation, was never employed in association with the key 506 pair used to generate the ROVR. This specification inherits from 507 [RFC3971] that simply indicates that the nonce is a random value. 508 Ideally, an implementation would use an unpredictable 509 cryptographically random value [RFC4086]. But that may be 510 impractical in some LLN scenarios where the devices do not have a 511 guaranteed sense of time and for which computing complex hashes is 512 detrimental to the battery lifetime. Alternatively, the device may 513 use an always-incrementing value saved in the same stable storage as 514 the key, so they are lost together, and starting at a best effort 515 random value, either as Nonce value or as a component to its 516 computation. 518 The 6LN replies to the challenge with an NS(EARO) that includes a new 519 Nonce option (shown as NonceLN in Figure 5), the CIPO (Section 4.3), 520 and the NDPSO containing the signature. The information associated 521 to a Crypto-ID stored by the 6LR on the first NS exchange where it 522 appears. The 6LR MUST store the CIPO parameters associated with the 523 Crypto-ID so it can be used for more than one address. 525 6LN 6LR 526 | | 527 |<------------------------- RA -------------------------| 528 | | ^ 529 |---------------- NS with EARO (Crypto-ID) ------------>| | 530 | | option 531 |<- NA with EARO (status=Validation Requested), NonceLR-| | 532 | | v 533 |------- NS with EARO, CIPO, NonceLN and NDPSO -------->| 534 | | 535 |<------------------- NA with EARO ---------------------| 536 | | 537 ... 538 | | 539 |--------------- NS with EARO (Crypto-ID) ------------->| 540 | | 541 |<------------------- NA with EARO ---------------------| 542 | | 543 ... 544 | | 545 |--------------- NS with EARO (Crypto-ID) ------------->| 546 | | 547 |<------------------- NA with EARO ---------------------| 548 | | 550 Figure 5: On-link Protocol Operation 552 The steps for the registration to the 6LR are as follows: 554 * Upon the first exchange with a 6LR, a 6LN will be challenged to 555 prove ownership of the Crypto-ID and the Target Address being 556 registered in the Neighbor Solicitation message. When a 6LR 557 receives a NS(EARO) registration with a new Crypto-ID as a ROVR, 558 and unless the registration is rejected for another reason, it 559 MUST challenge by responding with a NA(EARO) with a status of 560 "Validation Requested". 562 * The challenge is triggered when the registration for a Source 563 Link-Layer Address is not verifiable either at the 6LR or the 564 6LBR. In the latter case, the 6LBR returns a status of 565 "Validation Requested" in the DAR/DAC exchange, which is echoed by 566 the 6LR in the NA (EARO) back to the registering node. The 567 challenge MUST NOT alter a valid registration in the 6LR or the 568 6LBR. 570 * Upon receiving a first NA(EARO) with a status of "Validation 571 Requested" from a 6LR, the registering node SHOULD retry its 572 registration with a Crypto-ID Parameters Option (CIPO) 573 (Section 4.3) that contains all the necessary material for 574 building the Crypto-ID, the NonceLN that it generated, and the NDP 575 signature (Section 4.4) option that proves its ownership of the 576 Crypto-ID and intent of registering the Target Address. In 577 subsequent revalidation with the same 6LR, the 6LN MAY try to omit 578 the CIPO to save bandwidth, with the expectation that the 6LR 579 saved it. If the validation fails and it gets challenged again, 580 then it SHOULD add the CIPO again. 582 * In order to validate the ownership, the 6LR performs the same 583 steps as the 6LN and rebuilds the Crypto-ID based on the 584 parameters in the CIPO. If the rebuilt Crypto-ID matches the 585 ROVR, the 6LN also verifies the signature contained in the NDPSO 586 option. If at that point the signature in the NDPSO option can be 587 verified, then the validation succeeds. Otherwise the validation 588 fails. 590 * If the 6LR fails to validate the signed NS(EARO), it responds with 591 a status of "Validation Failed". After receiving a NA(EARO) with 592 a status of "Validation Failed", the registering node SHOULD try 593 to register an alternate target address in the NS message. 595 6.2. NDPSO generation and verification 597 The signature generated by the 6LN to provide proof-of-ownership of 598 the private-key is carried in the NDP Signature Option (NDPSO). It 599 is generated by the 6LN in a fashion that depends on the Crypto-Type 600 (see Table 2 in Section 8.3) chosen by the 6LN as follows: 602 * Concatenate the following in the order listed: 604 1. The 128-bit Message Type tag [RFC3972] (in network byte order). 605 For this specification the tag is 0x8701 55c8 0cca dd32 6ab7 e415 606 f148 84d0. (The tag value has been generated by the editor of 607 this specification on random.org). 608 2. JWK-encoded public key 609 3. the 16-byte Target Address (in network byte order) sent in the 610 Neighbor Solicitation (NS) message. It is the address which the 611 6LN is registering with the 6LR and 6LBR. 613 4. NonceLR received from the 6LR (in network byte order) in the 614 Neighbor Advertisement (NA) message. The Nonce is at least 6 615 bytes long as defined in [RFC3971]. 616 5. NonceLN sent from the 6LN (in network byte order). The Nonce is 617 at least 6 bytes long as defined in [RFC3971]. 618 6. The length of the ROVR field in the NS message containing the 619 Crypto-ID that was sent. 620 7. 1-byte (in network byte order) Crypto-Type value sent in the CIPO 621 option. 623 * Depending on the Crypto-Type, apply the hash function on this 624 concatenation. 626 * Depending on the Crypto-Type, sign the hash output with ECDSA (if 627 curve P-256 is used) or sign the hash with EdDSA (if curve Ed25519 628 (PureEdDSA)). 630 The 6LR on receiving the NDPSO and CIPO options first regenerates the 631 Crypto-ID based on the CIPO option to make sure that the leftmost 632 bits up to the size of the ROVR match. If and only if the check is 633 successful, it tries to verify the signature in the NDPSO option 634 using the following: 636 * Concatenate the following in the order listed: 638 1. 128-bit type tag (in network byte order) 639 2. JWK-encoded public key received in the CIPO option 640 3. the 16-byte Target Address (in network byte order) received in 641 the Neighbor Solicitation (NS) message. It is the address which 642 the 6LN is registering with the 6LR and 6LBR. 643 4. NonceLR sent in the Neighbor Advertisement (NA) message. The 644 Nonce is at least 6 bytes long as defined in [RFC3971]. 645 5. NonceLN received from the 6LN (in network byte order) in the NS 646 message. The Nonce is at least 6 bytes long as defined in 647 [RFC3971]. 648 6. The length of the ROVR field in the NS message containing the 649 Crypto-ID that was received. 650 7. 1-byte (in network byte order) Crypto-Type value received in the 651 CIPO option. 653 * Depending on the Crypto-Type indicated by the (6LN) in the CIPO, 654 apply the hash function on this concatenation. 656 * Verify the signature with the public-key received and the locally 657 computed values. If the verification succeeds, the 6LR and 6LBR 658 add the state information about the Crypto-ID, public-key and 659 Target Address being registered to their database. 661 6.3. Multihop Operation 663 In a multihop 6LoWPAN, the registration with Crypto-ID is propagated 664 to 6LBR as described in this section. If the 6LR and the 6LBR 665 maintain a security association, then there is no need to propagate 666 the proof of ownership to the 6LBR. 668 A new device that joins the network auto-configures an address and 669 performs an initial registration to a neighboring 6LR with an NS 670 message that carries an Address Registration Option (EARO) [RFC8505]. 671 The 6LR validates the address with an 6LBR using a DAR/DAC exchange, 672 and the 6LR confirms (or denies) the address ownership with an NA 673 message that also carries an Address Registration Option. 675 Figure 6 illustrates a registration flow all the way to a 6LowPAN 676 Backbone Router (6BBR) [BACKBONE-ROUTER]. 678 6LN 6LR 6LBR 6BBR 679 | | | | 680 | NS(EARO) | | | 681 |--------------->| | | 682 | | Extended DAR | | 683 | |-------------->| | 684 | | | | 685 | | | proxy NS(EARO) | 686 | | |--------------->| 687 | | | | NS(DAD) 688 | | | | ------> 689 | | | | 690 | | | | 691 | | | | 692 | | | proxy NA(EARO) | 693 | | |<---------------| 694 | | Extended DAC | | 695 | |<--------------| | 696 | NA(EARO) | | | 697 |<---------------| | | 698 | | | | 700 Figure 6: (Re-)Registration Flow 702 In a multihop 6LoWPAN, a 6LBR sends RAs with prefixes downstream and 703 the 6LR receives and relays them to the nodes. 6LR and 6LBR 704 communicate using ICMPv6 Duplicate Address Request (DAR) and 705 Duplicate Address Confirmation (DAC) messages. The DAR and DAC use 706 the same message format as NS and NA, but have different ICMPv6 type 707 values. 709 In AP-ND we extend DAR/DAC messages to carry cryptographically 710 generated ROVR. In a multihop 6LoWPAN, the node exchanges the 711 messages shown in Figure 6. The 6LBR must identify who owns an 712 address (EUI-64) to defend it, if there is an attacker on another 713 6LR. 715 7. Security Considerations 717 7.1. Inheriting from RFC 3971 719 Observations regarding the following threats to the local network in 720 [RFC3971] also apply to this specification. 722 Neighbor Solicitation/Advertisement Spoofing: Threats in section 723 9.2.1 of RFC3971 apply. AP-ND counters the threats on NS(EARO) 724 messages by requiring that the NDP Signature and CIPO options be 725 present in these solicitations. 727 Duplicate Address Detection DoS Attack: Inside the LLN, Duplicate 728 Addresses are sorted out using the ROVR, which differentiates it 729 from a movement. DAD coming from the backbone are not forwarded 730 over the LLN, which provides some protection against DoS attacks 731 inside the resource-constrained part of the network. Over the 732 backbone, the EARO option is present in NS/NA messages. This 733 protects against misinterpreting a movement for a duplication, and 734 enables the backbone routers to determine which one has the 735 freshest registration and is thus the best candidate to validate 736 the registration for the device attached to it. But this 737 specification does not guarantee that the backbone router claiming 738 an address over the backbone is not an attacker. 740 Router Solicitation and Advertisement Attacks: This specification 741 does not change the protection of RS and RA which can still be 742 protected by SEND. 744 Replay Attacks Nonces (NonceLR and NonceLN) generated by the 6LR and 745 6LN guarantees against replay attacks of the NS(EARO). 747 Neighbor Discovery DoS Attack: A rogue node that managed to access 748 the L2 network may form many addresses and register them using AP- 749 ND. The perimeter of the attack is all the 6LRs in range of the 750 attacker. The 6LR MUST protect itself against overflows and 751 reject excessive registration with a status 2 "Neighbor Cache 752 Full". This effectively blocks another (honest) 6LN from 753 registering to the same 6LR, but the 6LN may register to other 754 6LRs that are in its range but not in that of the rogue. 756 7.2. Related to 6LoWPAN ND 758 The threats discussed in 6LoWPAN ND [RFC6775][RFC8505] also apply 759 here. Compared with SeND, this specification saves about 1Kbyte in 760 every NS/NA message. Also, this specification separates the 761 cryptographic identifier from the registered IPv6 address so that a 762 node can have more than one IPv6 address protected by the same 763 cryptographic identifier. SeND forces the IPv6 address to be 764 cryptographic since it integrates the CGA as the IID in the IPv6 765 address. This specification frees the device to form its addresses 766 in any fashion, thereby enabling not only 6LoWPAN compression which 767 derives IPv6 addresses from Layer-2 addresses but also privacy 768 addresses. 770 7.3. ROVR Collisions 772 A collision of Registration Ownership Verifiers (ROVR) (i.e., the 773 Crypto-ID in this specification) is possible, but it is a rare event. 774 The formula for calculating the probability of a collision is 1 - 775 e^{-k^2/(2n)} where n is the maximum population size (2^64 here, 776 1.84E19) and K is the actual population (number of nodes). If the 777 Crypto-ID is 64-bits (the least possible size allowed), the chance of 778 a collision is 0.01% when the network contains 66 million nodes. 779 Moreover, the collision is only relevant when this happens within one 780 stub network (6LBR). In the case of such a collision, an attacker 781 may be able to claim the registered address of an another legitimate 782 node. However for this to happen, the attacker would also need to 783 know the address which was registered by the legitimate node. This 784 registered address is never broadcasted on the network and therefore 785 providing an additional 64-bits that an attacker must correctly 786 guess. To prevent address disclosure, it is RECOMMENDED that nodes 787 derive the address being registered independently of the ROVR. 789 7.4. Implementation Attacks 791 The signature schemes referenced in this specification comply with 792 NIST [FIPS186-4] or Crypto Forum Research Group (CFRG) standards 793 [RFC8032] and offer strong algorithmic security at roughly 128-bit 794 security level. These signature schemes use elliptic curves that 795 were either specifically designed with exception-free and constant- 796 time arithmetic in mind [RFC7748] or where one has extensive 797 implementation experience of resistance to timing attacks 798 [FIPS186-4]. However, careless implementations of the signing 799 operations could nevertheless leak information on private keys. For 800 example, there are micro-architectural side channel attacks that 801 implementors should be aware of [breaking-ed25519]. Implementors 802 should be particularly aware that a secure implementation of Ed25519 803 requires a protected implementation of the hash function SHA-512, 804 whereas this is not required with implementations of SHA-256 used 805 with ECDSA. 807 7.5. Cross-Protocol Attacks 809 The same private key MUST NOT be reused with more than one signature 810 scheme in this specification. 812 8. IANA considerations 814 8.1. CGA Message Type 816 This document defines a new 128-bit value under the CGA Message Type 817 [RFC3972] name space: 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0. 819 8.2. IPv6 ND option types 821 This document registers two new ND option types under the subregistry 822 "IPv6 Neighbor Discovery Option Formats": 824 +------------------------------+-----------------+---------------+ 825 | Option Name | Suggested Value | Reference | 826 +==============================+=================+===============+ 827 | NDP Signature Option (NDPSO) | 38 | This document | 828 +------------------------------+-----------------+---------------+ 829 | Crypto-ID Parameters Option | 39 | This document | 830 | (CIPO) | | | 831 +------------------------------+-----------------+---------------+ 833 Table 1: New ND options 835 8.3. Crypto-Type Subregistry 837 IANA is requested to create a new subregistry "Crypto-Type 838 Subregistry" in the "Internet Control Message Protocol version 6 839 (ICMPv6) Parameters". The registry is indexed by an integer in the 840 interval 0..255 and contains an Elliptic Curve, a Hash Function, a 841 Signature Algorithm, and Representation Conventions, as shown in 842 Table 2, which together specify a signature scheme. The following 843 Crypto-Type values are defined in this document: 845 +----------------+-----------------+-------------+-----------------+ 846 | Crypto-Type | 0 (ECDSA256) | 1 (Ed25519) | 2 (ECDSA25519) | 847 | value | | | | 848 +================+=================+=============+=================+ 849 | Elliptic curve | NIST P-256 | Curve25519 | Curve25519 | 850 | | [FIPS186-4] | [RFC7748] | [RFC7748] | 851 +----------------+-----------------+-------------+-----------------+ 852 | Hash function | SHA-256 | SHA-512 | SHA-256 | 853 | | [RFC6234] | [RFC6234] | [RFC6234] | 854 +----------------+-----------------+-------------+-----------------+ 855 | Signature | ECDSA | Ed25519 | ECDSA | 856 | algorithm | [FIPS186-4] | [RFC8032] | [FIPS186-4] | 857 +----------------+-----------------+-------------+-----------------+ 858 | Representation | Weierstrass, | Edwards, | Weierstrass, | 859 | conventions | (un)compressed, | compressed, | (un)compressed, | 860 | | MSB/msb first | LSB/lsb | MSB/msb first | 861 | | | first | | 862 +----------------+-----------------+-------------+-----------------+ 863 | Defining | This document | This | This document | 864 | specification | | document | | 865 +----------------+-----------------+-------------+-----------------+ 867 Table 2: Crypto-Types 869 New Crypto-Type values providing similar or better security (with 870 less code) may be defined in the future. 872 Assignment of new values for new Crypto-Type MUST be done through 873 IANA with either "Specification Required" or "IESG Approval" as 874 defined in [RFC8126]. 876 9. Acknowledgments 878 Many thanks to Charlie Perkins for his in-depth review and 879 constructive suggestions. The authors are also especially grateful 880 to Robert Moskowitz for his comments that led to many improvements. 881 The authors wish to thank Eric Vyncke, Vijay Gurbani, Al Morton and 882 Adam Montville for their constructive reviews during the IESG 883 process. 885 10. Normative References 887 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 888 Requirement Levels", BCP 14, RFC 2119, 889 DOI 10.17487/RFC2119, March 1997, 890 . 892 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 893 Bormann, "Neighbor Discovery Optimization for IPv6 over 894 Low-Power Wireless Personal Area Networks (6LoWPANs)", 895 RFC 6775, DOI 10.17487/RFC6775, November 2012, 896 . 898 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 899 DOI 10.17487/RFC7517, May 2015, 900 . 902 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 903 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 904 May 2017, . 906 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 907 "SEcure Neighbor Discovery (SEND)", RFC 3971, 908 DOI 10.17487/RFC3971, March 2005, 909 . 911 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 912 Perkins, "Registration Extensions for IPv6 over Low-Power 913 Wireless Personal Area Network (6LoWPAN) Neighbor 914 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 915 . 917 [FIPS186-4] 918 FIPS 186-4, "Digital Signature Standard (DSS), Federal 919 Information Processing Standards Publication 186-4", US 920 Department of Commerce/National Institute of Standards and 921 Technology , July 2013. 923 [SEC1] SEC1, "SEC 1: Elliptic Curve Cryptography, Version 2.0", 924 Standards for Efficient Cryptography , June 2009. 926 11. Informative references 928 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 929 RFC 3972, DOI 10.17487/RFC3972, March 2005, 930 . 932 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 933 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 934 DOI 10.17487/RFC4861, September 2007, 935 . 937 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 938 Address Autoconfiguration", RFC 4862, 939 DOI 10.17487/RFC4862, September 2007, 940 . 942 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 943 for Security", RFC 7748, DOI 10.17487/RFC7748, January 944 2016, . 946 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 947 Signature Algorithm (EdDSA)", RFC 8032, 948 DOI 10.17487/RFC8032, January 2017, 949 . 951 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 952 "Transmission of IPv6 Packets over IEEE 802.15.4 953 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 954 . 956 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 957 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 958 DOI 10.17487/RFC6282, September 2011, 959 . 961 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 962 over Low-Power Wireless Personal Area Networks (6LoWPANs): 963 Overview, Assumptions, Problem Statement, and Goals", 964 RFC 4919, DOI 10.17487/RFC4919, August 2007, 965 . 967 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 968 "Randomness Requirements for Security", BCP 106, RFC 4086, 969 DOI 10.17487/RFC4086, June 2005, 970 . 972 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 973 Writing an IANA Considerations Section in RFCs", BCP 26, 974 RFC 8126, DOI 10.17487/RFC8126, June 2017, 975 . 977 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 978 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 979 DOI 10.17487/RFC6234, May 2011, 980 . 982 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 983 "Source Address Validation Improvement (SAVI) Framework", 984 RFC 7039, DOI 10.17487/RFC7039, October 2013, 985 . 987 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 988 Interface Identifiers with IPv6 Stateless Address 989 Autoconfiguration (SLAAC)", RFC 7217, 990 DOI 10.17487/RFC7217, April 2014, 991 . 993 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 994 Agility and Selecting Mandatory-to-Implement Algorithms", 995 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 996 . 998 [BACKBONE-ROUTER] 999 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 1000 Backbone Router", Work in Progress, Internet-Draft, draft- 1001 ietf-6lo-backbone-router-13, 26 September 2019, 1002 . 1005 [CURVE-REPRESENTATIONS] 1006 Struik, R., "Alternative Elliptic Curve Representations", 1007 Work in Progress, Internet-Draft, draft-ietf-lwig-curve- 1008 representations-08, 24 July 2019, 1009 . 1012 [breaking-ed25519] 1013 Samwel, N., Batina, L., Bertoni, G., Daemen, J., and R. 1014 Susella, "Breaking Ed25519 in WolfSSL", Cryptographers' 1015 Track at the RSA Conference , 2018, 1016 . 1019 Appendix A. Requirements Addressed in this Document 1021 In this section we state requirements of a secure neighbor discovery 1022 protocol for low-power and lossy networks. 1024 * The protocol MUST be based on the Neighbor Discovery Optimization 1025 for Low-power and Lossy Networks protocol defined in [RFC6775]. 1026 RFC6775 utilizes optimizations such as host-initiated interactions 1027 for sleeping resource-constrained hosts and elimination of 1028 multicast address resolution. 1029 * New options to be added to Neighbor Solicitation messages MUST 1030 lead to small packet sizes, especially compared with existing 1031 protocols such as SEcure Neighbor Discovery (SEND). Smaller 1032 packet sizes facilitate low-power transmission by resource- 1033 constrained nodes on lossy links. 1035 * The support for this registration mechanism SHOULD be extensible 1036 to more LLN links than IEEE 802.15.4 only. Support for at least 1037 the LLN links for which a 6lo "IPv6 over foo" specification 1038 exists, as well as Low-Power Wi-Fi SHOULD be possible. 1039 * As part of this extension, a mechanism to compute a unique 1040 Identifier should be provided with the capability to form a Link 1041 Local Address that SHOULD be unique at least within the LLN 1042 connected to a 6LBR. 1043 * The Address Registration Option used in the ND registration SHOULD 1044 be extended to carry the relevant forms of Unique Interface 1045 Identifier. 1046 * The Neighbor Discovery should specify the formation of a site- 1047 local address that follows the security recommendations from 1048 [RFC7217]. 1050 Appendix B. Representation Conventions 1052 B.1. Signature Schemes 1054 The signature scheme ECDSA256 corresponding to Crypto-Type 0 is 1055 ECDSA, as specified in [FIPS186-4], instantiated with the NIST prime 1056 curve P-256, as specified in Appendix B of [FIPS186-4], and the hash 1057 function SHA-256, as specified in [RFC6234], where points of this 1058 NIST curve are represented as points of a short-Weierstrass curve 1059 (see [FIPS186-4]) and are encoded as octet strings in most- 1060 significant-bit first (msb) and most-significant-byte first (MSB) 1061 order. The signature itself consists of two integers (r and s), 1062 which are each encoded as fixed-size octet strings in most- 1063 significant-bit first and most-significant-byte first order. For 1064 details on ECDSA, see [FIPS186-4]; for details on the integer 1065 encoding, see Appendix B.2. 1067 The signature scheme Ed25519 corresponding to Crypto-Type 1 is EdDSA, 1068 as specified in [RFC8032], instantiated with the Montgomery curve 1069 Curve25519, as specified in [RFC7748], and the hash function SHA-512, 1070 as specified in [RFC6234], where points of this Montgomery curve are 1071 represented as points of the corresponding twisted Edwards curve (see 1072 Appendix B.3) and are encoded as octet strings in least-significant- 1073 bit first (lsb) and least-significant-byte first (LSB) order. The 1074 signature itself consists of a bit string that encodes a point of 1075 this twisted Edwards curve, in compressed format, and an integer 1076 encoded in least-significant-bit first and least-significant-byte 1077 first order. For details on EdDSA and on the encoding conversions, 1078 see the specification of pure Ed25519 in . [RFC8032] 1080 The signature scheme ECDSA25519 corresponding to Crypto-Type 2 is 1081 ECDSA, as specified in [FIPS186-4], instantiated with the Montgomery 1082 curve Curve25519, as specified in [RFC7748], and the hash function 1083 SHA-256, as specified in [RFC6234], where points of this Montgomery 1084 curve are represented as points of a corresponding curve in short- 1085 Weierstrass form (see Appendix B.3) and are encoded as octet strings 1086 in most-significant-bit first and most-significant-byte first order. 1087 The signature itself consists of a bit string that encodes two 1088 integers, each encoded as fixed-size octet strings in most- 1089 significant-bit first and most-significant-byte first order. For 1090 details on ECDSA, see [FIPS186-4]; for details on the integer 1091 encoding, see Appendix B.2 1093 B.2. Integer Representation for ECDSA signatures 1095 With ECDSA, each signature is a pair (r, s) of integers [FIPS186-4]. 1096 Each integer is encoded as a fixed-size 256-bit bit string, where 1097 each integer is represented according to the Field Element to Octet 1098 String and Octet String to Bit String conversion rules in [SEC1] and 1099 where the ordered pair of integers is represented as the 1100 rightconcatenation of the resulting representation values. The 1101 inverse operation follows the corresponding Bit String to Octet 1102 String and Octet String to Field Element conversion rules of [SEC1]. 1104 B.3. Alternative Representations of Curve25519 1106 The elliptic curve Curve25519, as specified in [RFC7748], is a so- 1107 called Montgomery curve. Each point of this curve can also be 1108 represented as a point of a twisted Edwards curve or as a point of an 1109 elliptic curve in short-Weierstrass form, via a coordinate 1110 transformation (a so-called isomorphic mapping). The parameters of 1111 the Montgomery curve and the corresponding isomorphic curves in 1112 twisted Edwards curve and short-Weierstrass form are as indicated 1113 below. Here, the domain parameters of the Montgomery curve 1114 Curve25519 and of the twisted Edwards curve Edwards25519 are as 1115 specified in [RFC7748]; the domain parameters of the elliptic curve 1116 Wei25519 in short-Weierstrass curve comply with Section 6.1.1 of 1117 [FIPS186-4]. For details of the coordinate transformation referenced 1118 above, see [RFC7748] and [CURVE-REPRESENTATIONS]. 1120 General parameters (for all curve models): 1122 p 2^{255}-19 1123 (=0x7fffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 1124 ffffffed) 1125 h 8 1126 n 1127 723700557733226221397318656304299424085711635937990760600195093828 1128 5454250989 1129 (=2^{252} + 0x14def9de a2f79cd6 5812631a 5cf5d3ed) 1131 Montgomery curve-specific parameters (for Curve25519): 1133 A 486662 1134 B 1 1135 Gu 9 (=0x9) 1136 Gv 1137 147816194475895447910205935684099868872646061346164752889648818377 1138 55586237401 1139 (=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2 1140 7eced3d9) 1142 Twisted Edwards curve-specific parameters (for Edwards25519): 1144 a -1 (-0x01) 1145 d -121665/121666 1146 (=3709570593466943934313808350875456518954211387984321901638878553 1147 3085940283555) 1148 (=0x52036cee 2b6ffe73 8cc74079 7779e898 00700a4d 4141d8ab 75eb4dca 1149 135978a3) 1150 Gx 1151 151122213495354007725011514095885315114540126930418572060461132839 1152 49847762202 1153 (=0x216936d3 cd6e53fe c0a4e231 fdd6dc5c 692cc760 9525a7b2 c9562d60 1154 8f25d51a) 1155 Gy 4/5 1156 (=4631683569492647816942839400347516314130799386625622561578303360 1157 3165251855960) 1158 (=0x66666666 66666666 66666666 66666666 66666666 66666666 66666666 1159 66666658) 1161 Weierstrass curve-specific parameters (for Wei25519): 1163 a 1164 192986815395526992372618308347813179755449974442734273399095973345 1165 73241639236 1166 (=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaa98 1167 4914a144) 1168 b 1169 557517466698189089076452890782571408182411037279010123152944008379 1170 56729358436 1171 (=0x7b425ed0 97b425ed 097b425e d097b425 ed097b42 5ed097b4 260b5e9c 1172 7710c864) 1173 GX 1174 192986815395526992372618308347813179755449974442734273399095973346 1175 52188435546 1176 (=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa 1177 aaad245a) 1178 GY 1179 147816194475895447910205935684099868872646061346164752889648818377 1180 55586237401 1181 (=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2 1182 7eced3d9) 1184 Authors' Addresses 1186 Pascal Thubert (editor) 1187 Cisco Systems, Inc 1188 Building D 1189 45 Allee des Ormes - BP1200 1190 06254 MOUGINS - Sophia Antipolis 1191 France 1193 Phone: +33 497 23 26 34 1194 Email: pthubert@cisco.com 1196 Behcet Sarikaya 1198 Email: sarikaya@ieee.org 1200 Mohit Sethi 1201 Ericsson 1202 FI-02420 Jorvas 1203 Finland 1205 Email: mohit@piuha.net 1207 Rene Struik 1208 Struik Security Consultancy 1210 Email: rstruik.ext@gmail.com