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