< draft-ietf-6lo-ap-nd-20.txt | draft-ietf-6lo-ap-nd.txt > | |||
---|---|---|---|---|
6lo P. Thubert, Ed. | 6lo P. Thubert, Ed. | |||
Internet-Draft Cisco | Internet-Draft Cisco | |||
Updates: 8505 (if approved) B. Sarikaya | Updates: 8505 (if approved) B. Sarikaya | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: 10 September 2020 M. Sethi | Expires: 26 October 2020 M. Sethi | |||
Ericsson | Ericsson | |||
R. Struik | R. Struik | |||
Struik Security Consultancy | Struik Security Consultancy | |||
9 March 2020 | 24 April 2020 | |||
Address Protected Neighbor Discovery for Low-power and Lossy Networks | Address Protected Neighbor Discovery for Low-power and Lossy Networks | |||
draft-ietf-6lo-ap-nd-20 | draft-ietf-6lo-ap-nd-22 | |||
Abstract | Abstract | |||
This document updates the 6LoWPAN Neighbor Discovery (ND) protocol | This document updates the 6LoWPAN Neighbor Discovery (ND) protocol | |||
defined in RFC 6775 and RFC 8505. The new extension is called | defined in RFC 6775 and RFC 8505. The new extension is called | |||
Address Protected Neighbor Discovery (AP-ND) and it protects the | Address Protected Neighbor Discovery (AP-ND) and it protects the | |||
owner of an address against address theft and impersonation attacks | owner of an address against address theft and impersonation attacks | |||
in a low-power and lossy network (LLN). Nodes supporting this | in a low-power and lossy network (LLN). Nodes supporting this | |||
extension compute a cryptographic identifier (Crypto-ID) and use it | extension compute a cryptographic identifier (Crypto-ID) and use it | |||
with one or more of their Registered Addresses. The Crypto-ID | with one or more of their Registered Addresses. The Crypto-ID | |||
skipping to change at page 1, line 46 ¶ | skipping to change at page 1, line 46 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 10 September 2020. | This Internet-Draft will expire on 26 October 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2020 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
extracted from this document must include Simplified BSD License text | extracted from this document must include Simplified BSD License text | |||
as described in Section 4.e of the Trust Legal Provisions and are | as described in Section 4.e of the Trust Legal Provisions and are | |||
provided without warranty as described in the Simplified BSD License. | provided without warranty as described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 | 2.2. Additional References . . . . . . . . . . . . . . . . . . 4 | |||
2.3. Additional References . . . . . . . . . . . . . . . . . . 5 | 2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4. New Fields and Options . . . . . . . . . . . . . . . . . . . 6 | 4. New Fields and Options . . . . . . . . . . . . . . . . . . . 6 | |||
4.1. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 6 | 4.1. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 6 | |||
4.2. Updated EARO . . . . . . . . . . . . . . . . . . . . . . 6 | 4.2. Updated EARO . . . . . . . . . . . . . . . . . . . . . . 7 | |||
4.3. Crypto-ID Parameters Option . . . . . . . . . . . . . . . 7 | 4.3. Crypto-ID Parameters Option . . . . . . . . . . . . . . . 8 | |||
4.4. NDP Signature Option . . . . . . . . . . . . . . . . . . 9 | 4.4. NDP Signature Option . . . . . . . . . . . . . . . . . . 10 | |||
5. Protocol Scope . . . . . . . . . . . . . . . . . . . . . . . 11 | 4.5. Extensions to the Capability Indication Option . . . . . 11 | |||
6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 12 | 5. Protocol Scope . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 13 | 6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
6.2. NDPSO generation and verification . . . . . . . . . . . . 15 | 6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 14 | |||
6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 16 | 6.2. NDPSO generation and verification . . . . . . . . . . . . 16 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | 6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 17 | |||
7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 17 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 | |||
7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 18 | 7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 18 | |||
7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 19 | 7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 19 | |||
7.4. Implementation Attacks . . . . . . . . . . . . . . . . . 19 | 7.3. Brown Field . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
7.5. Cross-Algorithm and Cross-Protocol Attacks . . . . . . . 20 | 7.4. Compromised 6LR . . . . . . . . . . . . . . . . . . . . . 20 | |||
7.6. Compromised 6LR . . . . . . . . . . . . . . . . . . . . . 20 | 7.5. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 20 | |||
7.7. Correlating Registrations . . . . . . . . . . . . . . . . 21 | 7.6. Implementation Attacks . . . . . . . . . . . . . . . . . 21 | |||
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21 | 7.7. Cross-Algorithm and Cross-Protocol Attacks . . . . . . . 21 | |||
8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 21 | 7.8. Public Key Validation . . . . . . . . . . . . . . . . . . 21 | |||
8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 21 | 7.9. Correlating Registrations . . . . . . . . . . . . . . . . 22 | |||
8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 22 | 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 | |||
8.4. New Codepoints Associated to JWK Encoding . . . . . . . . 22 | 8.1. IPv6 ND option types . . . . . . . . . . . . . . . . . . 22 | |||
8.4.1. COSE Elliptic Curves Registration . . . . . . . . . . 23 | 8.2. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 23 | |||
8.4.2. COSE Algorithms Registration . . . . . . . . . . . . 23 | 8.3. CGA Message Type . . . . . . . . . . . . . . . . . . . . 24 | |||
8.4.3. JOSE Elliptic Curves Registration . . . . . . . . . . 23 | ||||
8.4.4. JOSE Algorithms Registration . . . . . . . . . . . . 24 | ||||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
10. Normative References . . . . . . . . . . . . . . . . . . . . 24 | 10. Normative References . . . . . . . . . . . . . . . . . . . . 24 | |||
11. Informative references . . . . . . . . . . . . . . . . . . . 25 | 11. Informative references . . . . . . . . . . . . . . . . . . . 25 | |||
Appendix A. Requirements Addressed in this Document . . . . . . 28 | Appendix A. Requirements Addressed in this Document . . . . . . 27 | |||
Appendix B. Representation Conventions . . . . . . . . . . . . . 28 | Appendix B. Representation Conventions . . . . . . . . . . . . . 28 | |||
B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 28 | B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 28 | |||
B.2. Integer Representation for ECDSA signatures . . . . . . . 29 | B.2. Representation of ECDSA Signatures . . . . . . . . . . . 29 | |||
B.3. Alternative Representations of Curve25519 . . . . . . . . 30 | B.3. Representation of Public Keys Used with ECDSA . . . . . . 29 | |||
B.4. Alternative Representations of Curve25519 . . . . . . . . 29 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
1. Introduction | 1. Introduction | |||
Neighbor Discovery Optimizations for 6LoWPAN networks [RFC6775] | Neighbor Discovery Optimizations for 6LoWPAN networks [RFC6775] | |||
(6LoWPAN ND) adapts the original IPv6 Neighbor Discovery (IPv6 ND) | (6LoWPAN ND) adapts the original IPv6 Neighbor Discovery (IPv6 ND) | |||
protocols defined in [RFC4861] and [RFC4862] for constrained low- | protocols defined in [RFC4861] and [RFC4862] for constrained low- | |||
power and lossy network (LLN). In particular, 6LoWPAN ND introduces | power and lossy network (LLN). In particular, 6LoWPAN ND introduces | |||
a unicast host Address Registration mechanism that reduces the use of | a unicast host Address Registration mechanism that reduces the use of | |||
multicast compared to the Duplicate Address Detection (DAD) mechanism | multicast compared to the Duplicate Address Detection (DAD) mechanism | |||
skipping to change at page 3, line 44 ¶ | skipping to change at page 3, line 43 ¶ | |||
use of an address if that address is already registered in the subnet | use of an address if that address is already registered in the subnet | |||
(first come first serve). In order to validate address ownership, | (first come first serve). In order to validate address ownership, | |||
the registration mechanism enables the 6LR and 6LBR to validate the | the registration mechanism enables the 6LR and 6LBR to validate the | |||
association between the registered address of a node, and its | association between the registered address of a node, and its | |||
Registration Ownership Verifier (ROVR). The ROVR is defined in | Registration Ownership Verifier (ROVR). The ROVR is defined in | |||
"Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] | "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] | |||
and it can be derived from the MAC address of the device (using the | and it can be derived from the MAC address of the device (using the | |||
64-bit Extended Unique Identifier EUI-64 address format specified by | 64-bit Extended Unique Identifier EUI-64 address format specified by | |||
IEEE). However, the EUI-64 can be spoofed, and therefore, any node | IEEE). However, the EUI-64 can be spoofed, and therefore, any node | |||
connected to the subnet and aware of a registered-address-to-ROVR | connected to the subnet and aware of a registered-address-to-ROVR | |||
mapping could effectively fake the ROVR. This would allow the an | mapping could effectively fake the ROVR. This would allow an | |||
attacker to steal the address and redirect traffic for that address. | attacker to steal the address and redirect traffic for that address. | |||
[RFC8505] defines an Extended Address Registration Option (EARO) | [RFC8505] defines an Extended Address Registration Option (EARO) | |||
option that allows to transport alternate forms of ROVRs, and is a | option that transports alternate forms of ROVRs, and is a pre- | |||
pre-requisite for this specification. | requisite for this specification. | |||
In this specification, a 6LN generates a cryptographic ID (Crypto-ID) | In this specification, a 6LN generates a cryptographic ID (Crypto-ID) | |||
and places it in the ROVR field during the registration of one (or | and places it in the ROVR field during the registration of one (or | |||
more) of its addresses with the 6LR(s). Proof of ownership of the | more) of its addresses with the 6LR(s). Proof of ownership of the | |||
Crypto-ID is passed with the first registration exchange to a new | Crypto-ID is passed with the first registration exchange to a new | |||
6LR, and enforced at the 6LR. The 6LR validates ownership of the | 6LR, and enforced at the 6LR. The 6LR validates ownership of the | |||
cryptographic ID before it creates any new registration state, or | cryptographic ID before it creates any new registration state, or | |||
changes existing information. | changes existing information. | |||
The protected address registration protocol proposed in this document | The protected address registration protocol proposed in this document | |||
skipping to change at page 4, line 38 ¶ | skipping to change at page 4, line 37 ¶ | |||
2. Terminology | 2. Terminology | |||
2.1. BCP 14 | 2.1. BCP 14 | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
2.2. Abbreviations | 2.2. Additional References | |||
The reader may get additional context for this specification from the | ||||
following references: | ||||
* "SEcure Neighbor Discovery (SEND)" [RFC3971], | ||||
* "Cryptographically Generated Addresses (CGA)" [RFC3972], | ||||
* "Neighbor Discovery for IP version 6" [RFC4861] , | ||||
* "IPv6 Stateless Address Autoconfiguration" [RFC4862], and | ||||
* "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): | ||||
Overview, Assumptions, Problem Statement, and Goals " [RFC4919]. | ||||
2.3. Abbreviations | ||||
This document uses the following abbreviations: | This document uses the following abbreviations: | |||
6BBR: 6LoWPAN Backbone Router | 6BBR: 6LoWPAN Backbone Router | |||
6LBR: 6LoWPAN Border Router | 6LBR: 6LoWPAN Border Router | |||
6LN: 6LoWPAN Node | 6LN: 6LoWPAN Node | |||
6LR: 6LoWPAN Router | 6LR: 6LoWPAN Router | |||
CGA: Cryptographically Generated Address | ||||
EARO: Extended Address Registration Option | EARO: Extended Address Registration Option | |||
ECDH: Elliptic curve Diffie-Hellman | ||||
ECDSA: Elliptic Curve Digital Signature Algorithm | ||||
CIPO: Crypto-ID Parameters Option | CIPO: Crypto-ID Parameters Option | |||
LLN: Low-Power and Lossy Network | LLN: Low-Power and Lossy Network | |||
JSON: JavaScript Object Notation | ||||
JOSE: JavaScript Object Signing and Encryption | ||||
JWK: JSON Web Key | ||||
JWS: JSON Web Signature | ||||
NA: Neighbor Advertisement | NA: Neighbor Advertisement | |||
ND: Neighbor Discovery | ND: Neighbor Discovery | |||
NDP: Neighbor Discovery Protocol | ||||
NDPSO: Neighbor Discovery Protocol Signature Option | NDPSO: Neighbor Discovery Protocol Signature Option | |||
NS: Neighbor Solicitation | NS: Neighbor Solicitation | |||
ROVR: Registration Ownership Verifier | ROVR: Registration Ownership Verifier | |||
RA: Router Advertisement | RA: Router Advertisement | |||
RS: Router Solicitation | RS: Router Solicitation | |||
RSAO: RSA Signature Option | RSAO: RSA Signature Option | |||
SHA: Secure Hash Algorithm | ||||
SLAAC: Stateless Address Autoconfiguration | ||||
TID: Transaction ID | TID: Transaction ID | |||
2.3. Additional References | ||||
The reader may get additional context for this specification from the | ||||
following references: | ||||
* "SEcure Neighbor Discovery (SEND)" [RFC3971], | ||||
* "Cryptographically Generated Addresses (CGA)" [RFC3972], | ||||
* "Neighbor Discovery for IP version 6" [RFC4861] , | ||||
* "IPv6 Stateless Address Autoconfiguration" [RFC4862], and | ||||
* "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): | ||||
Overview, Assumptions, Problem Statement, and Goals " [RFC4919]. | ||||
3. Updating RFC 8505 | 3. Updating RFC 8505 | |||
Section 5.3 of [RFC8505] introduces the ROVR that is used to detect | Section 5.3 of [RFC8505] introduces the ROVR that is used to detect | |||
and reject duplicate registrations in the DAD process. The ROVR is a | and reject duplicate registrations in the DAD process. The ROVR is a | |||
generic object that is designed for both backward compatibility and | generic object that is designed for both backward compatibility and | |||
the capability to introduce new computation methods in the future. | the capability to introduce new computation methods in the future. | |||
Using a Crypto-ID per this specification is the RECOMMENDED method. | Using a Crypto-ID per this specification is the RECOMMENDED method. | |||
Section 7.3 discusses collisions when heterogeneous methods to | Section 7.5 discusses collisions when heterogeneous methods to | |||
compute the ROVR field coexist inside a same network. | compute the ROVR field coexist inside a same network. | |||
This specification introduces a new token called a cryptographic | This specification introduces a new token called a cryptographic | |||
identifier (Crypto-ID) that is transported in the ROVR field and used | identifier (Crypto-ID) that is transported in the ROVR field and used | |||
to prove indirectly the ownership of an address that is being | to prove indirectly the ownership of an address that is being | |||
registered by means of [RFC8505]. The Crypto-ID is derived from a | registered by means of [RFC8505]. The Crypto-ID is derived from a | |||
cryptographic public key and additional parameters. | cryptographic public key and additional parameters. | |||
The overall mechanism requires the support of Elliptic Curve | The overall mechanism requires the support of Elliptic Curve | |||
Cryptography (ECC) and of a hash function as detailed in Section 6.2. | Cryptography (ECC) and of a hash function as detailed in Section 6.2. | |||
To enable the verification of the proof, the registering node needs | To enable the verification of the proof, the registering node needs | |||
to supply certain parameters including a nonce and a signature that | to supply certain parameters including a nonce and a signature that | |||
will demonstrate that the node possesses the private-key | will demonstrate that the node possesses the private-key | |||
corresponding to the public-key used to build the Crypto-ID. | corresponding to the public-key used to build the Crypto-ID. | |||
The elliptic curves and the hash functions listed in Table 2 in | The elliptic curves and the hash functions listed in Table 2 in | |||
Section 8.3 can be used with this specification; more may be added in | Section 8.2 can be used with this specification; more may be added in | |||
the future to the IANA registry. The signature scheme that specifies | the future to the IANA registry. The signature scheme that specifies | |||
which combination is used (including the curve and the representation | which combination is used (including the curve and the representation | |||
conventions) is signaled by a Crypto-Type in a new IPv6 ND Crypto-ID | conventions) is signaled by a Crypto-Type in a new IPv6 ND Crypto-ID | |||
Parameters Option (CIPO, see Section 4.3) that contains the | Parameters Option (CIPO, see Section 4.3) that contains the | |||
parameters that are necessary for the proof, a Nonce option | parameters that are necessary for the proof, a Nonce option | |||
([RFC3971]) and a NDP Signature option (Section 4.4). The NA(EARO) | ([RFC3971]) and a NDP Signature option (Section 4.4). The NA(EARO) | |||
is modified to enable a challenge and transport a Nonce option. | is modified to enable a challenge and transport a Nonce option. | |||
4. New Fields and Options | 4. New Fields and Options | |||
skipping to change at page 6, line 33 ¶ | skipping to change at page 6, line 40 ¶ | |||
ownership of the Registered Address can be ascertained. | ownership of the Registered Address can be ascertained. | |||
A node in possession of the necessary cryptographic primitives SHOULD | A node in possession of the necessary cryptographic primitives SHOULD | |||
use Crypto-ID by default as ROVR in its registrations. Whether a | use Crypto-ID by default as ROVR in its registrations. Whether a | |||
ROVR is a Crypto-ID is indicated by a new "C" flag in the NS(EARO) | ROVR is a Crypto-ID is indicated by a new "C" flag in the NS(EARO) | |||
message. | message. | |||
The Crypto-ID is derived from the public key and a modifier as | The Crypto-ID is derived from the public key and a modifier as | |||
follows: | follows: | |||
1. The hash function indicated by the Crypto-Type is applied to the | 1. The hash function used by the signature scheme indicated by the | |||
CIPO. Note that all the reserved and padding bits MUST be set to | Crypto-Type is applied to the CIPO. Note that all the reserved | |||
zero. | and padding bits MUST be set to zero. | |||
2. The leftmost bits of the resulting hash, up to the desired size, | 2. The leftmost bits of the resulting hash, up to the desired size, | |||
are used as the Crypto-ID. | are used as the Crypto-ID. | |||
At the time of this writing, a minimal size for the Crypto-ID of 128 | At the time of this writing, a minimal size for the Crypto-ID of 128 | |||
bits is RECOMMENDED unless backward compatibility is needed | bits is RECOMMENDED unless backward compatibility is needed | |||
[RFC8505]. This value is bound to augment in the future. | [RFC8505]. This value is bound to augment in the future. | |||
4.2. Updated EARO | 4.2. Updated EARO | |||
This specification updates the EARO option to enable the use of the | This specification updates the EARO option to enable the use of the | |||
skipping to change at page 8, line 6 ¶ | skipping to change at page 8, line 11 ¶ | |||
"Validation Failed", which are defined in [RFC8505]. | "Validation Failed", which are defined in [RFC8505]. | |||
this specification does not define any new Status value. | this specification does not define any new Status value. | |||
4.3. Crypto-ID Parameters Option | 4.3. Crypto-ID Parameters Option | |||
This specification defines the Crypto-ID Parameters Option (CIPO). | This specification defines the Crypto-ID Parameters Option (CIPO). | |||
The CIPO carries the parameters used to form a Crypto-ID. | The CIPO carries the parameters used to form a Crypto-ID. | |||
In order to provide cryptographic agility [BCP 201], this | In order to provide cryptographic agility [BCP 201], this | |||
specification supports different elliptic curves, indicated by a | specification supports different elliptic-curve based signature | |||
Crypto-Type field: | schemes, indicated by a Crypto-Type field: | |||
* NIST P-256 [FIPS186-4] MUST be supported by all implementations. | * The ECDSA256 signature scheme, which uses ECDSA with the NIST | |||
P-256 curve [FIPS186-4] and the hash function SHA-256 [RFC6234], | ||||
MUST be supported by all implementations. | ||||
* The Edwards-Curve Digital Signature Algorithm (EdDSA) curve | * The Ed25519 signature scheme, which uses the Pure Edwards-Curve | |||
Ed25519 (PureEdDSA) [RFC8032] MAY be supported as an alternative. | Digital Signature Algorithm (PureEdDSA) [RFC8032] with the twisted | |||
Edwards curve Edwards25519 [RFC7748] and the hash function SHA-512 | ||||
[RFC6234], MAY be supported as an alternative. | ||||
* This specification uses signature schemes that target similar | * The ECDSA25519 signature scheme, which uses ECDSA [FIPS186-4] with | |||
cryptographic strength but rely on different curves, hash | the Weierstrass curve Wei25519 (see Appendix B.4) and the hash | |||
functions, signature algorithms, and/or representation | function SHA-256 [RFC6234], MAY be supported as an alternative. | |||
conventions. Future specification may extend this to different | ||||
cryptographic algorithms and key sizes, e.g., to provide better | This specification uses signature schemes that target similar | |||
security properties or a simpler implementation. | cryptographic strength but rely on different curves, hash functions, | |||
signature algorithms, and/or representation conventions. Future | ||||
specification may extend this to different cryptographic algorithms | ||||
and key sizes, e.g., to provide better security properties or a | ||||
simpler implementation. | ||||
0 1 2 3 | 0 1 2 3 | |||
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 | 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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type | Length |Reserved1| Public Key Length | | | Type | Length |Reserved1| Public Key Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Crypto-Type | Modifier | EARO Length | Reserved2 | | | Crypto-Type | Modifier | EARO Length | Reserved2 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
. . | . . | |||
skipping to change at page 8, line 50 ¶ | skipping to change at page 9, line 14 ¶ | |||
Type: 8-bit unsigned integer. to be assigned by IANA, see Table 1. | Type: 8-bit unsigned integer. to be assigned by IANA, see Table 1. | |||
Length: 8-bit unsigned integer. The length of the option in units | Length: 8-bit unsigned integer. The length of the option in units | |||
of 8 octets. | of 8 octets. | |||
Reserved1: 5-bit unsigned integer. It MUST be set to zero by the | Reserved1: 5-bit unsigned integer. It MUST be set to zero by the | |||
sender and MUST be ignored by the receiver. | sender and MUST be ignored by the receiver. | |||
Public Key Length: 11-bit unsigned integer. The length of the | Public Key Length: 11-bit unsigned integer. The length of the | |||
Public Key field in bytes. | Public Key field in bytes (where actual length depends on Crypto | |||
Type details). | ||||
Crypto-Type: 8-bit unsigned integer. The type of cryptographic | Crypto-Type: 8-bit unsigned integer. The type of cryptographic | |||
algorithm used in calculation Crypto-ID indexed by IANA in the | algorithm used in calculation Crypto-ID indexed by IANA in the | |||
"Crypto-Type Subregistry" in the "Internet Control Message | "Crypto-Type Subregistry" in the "Internet Control Message | |||
Protocol version 6 (ICMPv6) Parameters" (see Section 8.3). | Protocol version 6 (ICMPv6) Parameters" (see Section 8.2). | |||
Modifier: 8-bit unsigned integer. Set to an arbitrary value by the | Modifier: 8-bit unsigned integer. Set to an arbitrary value by the | |||
creator of the Crypto-ID. The role of the modifier is to enable | creator of the Crypto-ID. The role of the modifier is to enable | |||
the formation of multiple Crypto-IDs from a same key pair, which | the formation of multiple Crypto-IDs from a same key pair, which | |||
reduces the traceability and thus improves the privacy of a | reduces the traceability and thus improves the privacy of a | |||
constrained node that could not maintain many key-pairs. | constrained node that could not maintain many key-pairs. | |||
EARO Length: 8-bit unsigned integer. The option length of the EARO | EARO Length: 8-bit unsigned integer. The option length of the EARO | |||
that contains the Crypto-ID associated with the CIPO. | that contains the Crypto-ID associated with the CIPO. | |||
Reserved2: 16-bit unsigned integer. It MUST be set to zero by the | Reserved2: 8-bit unsigned integer. It MUST be set to zero by the | |||
sender and MUST be ignored by the receiver. | sender and MUST be ignored by the receiver. | |||
Public Key: A variable-length field, size indicated in the Public | Public Key: A variable-length field, size indicated in the Public | |||
Key Length field. JWK-Encoded Public Key [RFC7517]. | Key Length field. | |||
Padding: A variable-length field completing the Public Key field to | Padding: A variable-length field completing the Public Key field to | |||
align to the next 8-bytes boundary. It MUST be set to zero by the | align to the next 8-bytes boundary. It MUST be set to zero by the | |||
sender and MUST be ignored by the receiver. | sender and MUST be ignored by the receiver. | |||
The implementation of multiple hash functions in a constrained | The implementation of multiple hash functions in a constrained device | |||
devices may consume excessive amounts of program memory. This | may consume excessive amounts of program memory. This specification | |||
specification enables the use of SHA-256 [RFC6234] for all the | enables the use of the same hash function SHA-256 [RFC6234] for two | |||
supported ECC curves. | of the three supported ECC-based signature schemes. Some code | |||
factorization is also possible for the ECC computation itself. | ||||
Some code factorization is also possible for the ECC computation | [CURVE-REPR] provides information on how to represent Montgomery | |||
itself. [CURVE-REPRESENTATIONS] provides information on how to | curves and (twisted) Edwards curves as curves in short-Weierstrass | |||
represent Montgomery curves and (twisted) Edwards curves as curves in | form and illustrates how this can be used to implement elliptic curve | |||
short-Weierstrass form and illustrates how this can be used to | computations using existing implementations that already provide, | |||
implement elliptic curve computations using existing implementations | e.g., ECDSA and ECDH using NIST [FIPS186-4] prime curves. For more | |||
that already provide, e.g., ECDSA and ECDH using NIST [FIPS186-4] | details on representation conventions, we refer to Appendix B. | |||
prime curves. For more details on representation conventions, we | ||||
refer to Appendix B. | ||||
4.4. NDP Signature Option | 4.4. NDP Signature Option | |||
This specification defines the NDP Signature Option (NDPSO). The | This specification defines the NDP Signature Option (NDPSO). The | |||
NDPSO carries the signature that proves the ownership of the Crypto- | NDPSO carries the signature that proves the ownership of the Crypto- | |||
ID. The format of the NDPSO is illustrated in Figure 3. | ID. The format of the NDPSO is illustrated in Figure 3. | |||
As opposed to the RSA Signature Option (RSAO) defined in section 5.2. | As opposed to the RSA Signature Option (RSAO) defined in section 5.2. | |||
of SEND [RFC3971], the NDPSO does not have a key hash field. | of SEND [RFC3971], the NDPSO does not have a key hash field. | |||
Instead, the leftmost 128 bits of the ROVR field in the EARO are used | Instead, the leftmost 128 bits of the ROVR field in the EARO are used | |||
skipping to change at page 11, line 11 ¶ | skipping to change at page 11, line 19 ¶ | |||
Reserved1: 5-bit unsigned integer. It MUST be set to zero by the | Reserved1: 5-bit unsigned integer. It MUST be set to zero by the | |||
sender and MUST be ignored by the receiver. | sender and MUST be ignored by the receiver. | |||
Digital Signature Length: 11-bit unsigned integer. The length of | Digital Signature Length: 11-bit unsigned integer. The length of | |||
the Digital Signature field in bytes. | the Digital Signature field in bytes. | |||
Reserved2: 32-bit unsigned integer. It MUST be set to zero by the | Reserved2: 32-bit unsigned integer. It MUST be set to zero by the | |||
sender and MUST be ignored by the receiver. | sender and MUST be ignored by the receiver. | |||
Digital Signature: A variable-length field containing a digital | Digital Signature: A variable-length field containing the digital | |||
signature. The length and computation of the digital signature | signature. The length and computation of the digital signature | |||
both depend on the Crypto-Type which is found in the associated | both depend on the Crypto-Type which is found in the associated | |||
CIPO. For the values of the Crypto-Type that are defined in this | CIPO, see Appendix B. For the values of the Crypto-Type defined | |||
specification, and unless specified otherwise for a future value | in this specification, and for future values of the Crypto-Type | |||
of the Crypto-Type, the signature is computed as detailed in | unless specified otherwise, the signature is computed as detailed | |||
Section 6.2. | in Section 6.2. | |||
Padding: A variable-length field completing the Digital Signature | Padding: A variable-length field completing the Digital Signature | |||
field to align to the next 8-bytes boundary. It MUST be set to | field to align to the next 8-bytes boundary. It MUST be set to | |||
zero by the sender and MUST be ignored by the receiver. | zero by the sender and MUST be ignored by the receiver. | |||
4.5. Extensions to the Capability Indication Option | ||||
This specification defines two new capability bits in the 6CIO, | ||||
defined by [RFC7400] for use by the 6LR and 6LBR in IPv6 ND RA | ||||
messages. The "A" flag is set to indicate that AP-ND is globally | ||||
activated in the network. It is set by the 6LBR that serves the | ||||
network and propagated by the 6LRs. It is typically turned on when | ||||
all 6LRs are migrated to this specification. | ||||
0 1 2 3 | ||||
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 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Type | Length = 1 | Reserved |S|A|D|L|B|P|E|G| | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Reserved | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
Figure 4: New Capability Bit in the 6CIO | ||||
New Option Field: | ||||
A: 1-bit flag. Signals that AP-ND is activated. | ||||
5. Protocol Scope | 5. Protocol Scope | |||
The scope of the protocol specified here is a 6LoWPAN LLN, typically | The scope of the protocol specified here is a 6LoWPAN LLN, typically | |||
a stub network connected to a larger IP network via a Border Router | a stub network connected to a larger IP network via a Border Router | |||
called a 6LBR per [RFC6775]. A 6LBR has sufficient capability to | called a 6LBR per [RFC6775]. A 6LBR has sufficient capability to | |||
satisfy the needs of duplicate address detection. | satisfy the needs of duplicate address detection. | |||
The 6LBR maintains registration state for all devices in its attached | The 6LBR maintains registration state for all devices in its attached | |||
LLN. Together with the first-hop router (the 6LR), the 6LBR assures | LLN. Together with the first-hop router (the 6LR), the 6LBR assures | |||
uniqueness and grants ownership of an IPv6 address before it can be | uniqueness and grants ownership of an IPv6 address before it can be | |||
skipping to change at page 11, line 50 ¶ | skipping to change at page 12, line 34 ¶ | |||
| | | | |||
+-----+ | +-----+ | |||
| | 6LBR | | | 6LBR | |||
+-----+ | +-----+ | |||
o o o | o o o | |||
o o o o | o o o o | |||
o o LLN o o o | o o LLN o o o | |||
o o o (6LR) | o o o (6LR) | |||
o (6LN) | o (6LN) | |||
Figure 4: Basic Configuration | Figure 5: Basic Configuration | |||
In a mesh network, the 6LR is directly connected to the host device. | In a mesh network, the 6LR is directly connected to the host device. | |||
This specification mandates that the peer-wise layer-2 security is | This specification mandates that the peer-wise layer-2 security is | |||
deployed so that all the packets from a particular host are securely | deployed so that all the packets from a particular host are securely | |||
identifiable by the 6LR. The 6LR may be multiple hops away from the | identifiable by the 6LR. The 6LR may be multiple hops away from the | |||
6LBR. Packets are routed between the 6LR and the 6LBR via other | 6LBR. Packets are routed between the 6LR and the 6LBR via other | |||
6LRs. This specification mandates that a chain of trust is | 6LRs. | |||
established so that a packet that was validated by the first 6LR can | ||||
be safely routed by other on-path 6LRs to the 6LBR. | This specification mandates that all the LLN links between the 6LR | |||
and the 6LBR are protected so that a packet that was validated by the | ||||
first 6LR can be safely routed by other on-path 6LRs to the 6LBR. | ||||
6. Protocol Flows | 6. Protocol Flows | |||
The 6LR/6LBR ensures first-come/first-serve by storing the ROVR | The 6LR/6LBR ensures first-come/first-serve by storing the ROVR | |||
associated to the address being registered upon the first | associated to the address being registered upon the first | |||
registration and rejecting a registration with a different ROVR | registration and rejecting a registration with a different ROVR | |||
value. A 6LN can claim any address as long as it is the first to | value. A 6LN can claim any address as long as it is the first to | |||
make that claim. After a successful registration, the 6LN becomes | make that claim. After a successful registration, the 6LN becomes | |||
the owner of the registered address and the address is bound to the | the owner of the registered address and the address is bound to the | |||
ROVR value in the 6LR/6LBR registry. | ROVR value in the 6LR/6LBR registry. | |||
This specification enables the 6LR to challenge the 6LN to verify its | This specification protects the ownership of the address at the first | |||
ownership of the binding by placing a Crypto-ID in the ROVR. The | hop (the edge). Its use in a network is signaled by the "A" flag in | |||
challenge can happen at any time at the discretion of the 6LR. The | the 6CIO. The flag is set by the 6LBR and propagated unchanged by | |||
6LR MUST challenge the 6LN when it creates a binding and when a new | the 6LRs. The "A" flag enables to migrate a network with the | |||
registration attempts to change a parameter of the binding that | protection off and then turn it on globally. | |||
The 6LN places a cryptographic token, the Crypto-ID, in the ROVR that | ||||
is associated with the address at the first registration, enabling | ||||
the 6LR to later challenge it to verify that it is the original | ||||
Registering Node. The challenge may happen at any time at the | ||||
discretion of the 6LR and the 6LBR. A valid registration in the 6LR | ||||
or the 6LBR MUST NOT be altered until the challenge is complete. | ||||
When the "A" flag is on, the 6LR MUST challenge the 6LN when it | ||||
creates a binding with the "C" flag set in the ROVR and when a new | ||||
registration attempts to change a parameter of that binding that | ||||
identifies the 6LN, for instance its Source Link-Layer Address. The | identifies the 6LN, for instance its Source Link-Layer Address. The | |||
verification protects against a rogue that would steal an address and | verification protects against a rogue that would steal an address and | |||
attract its traffic, or use it as source address. | attract its traffic, or use it as source address. | |||
The challenge can also triggered by the 6LBR, e.g., to enforce a | The 6LR MUST also challenge the 6LN if the 6LBR directly signals to | |||
global policy. In that case, the 6LBR returns a status of | do so, using an EDAC Message with a "Validation Requested" status. | |||
"Validation Requested" in the DAR/DAC exchange, which is echoed by | The EDAR is echoed by the 6LR in the NA (EARO) back to the | |||
the 6LR in the NA (EARO) back to the registering node. A valid | registering node. The 6LR SHOULD also challenge all its attached | |||
registration in the 6LR or the 6LBR MUST NOT be altered until the | 6LNs at the time the 6LBR turns the "A" flag on in the 6CIO, to | |||
challenge is complete. | detect an issue immediately. | |||
If the 6LR does not support the Crypto-Type, it MUST reply with an | ||||
EARO Status 10 "Validation Failed" without a challenge. In that | ||||
case, the 6LN may try another Crypto-Type until it falls back to | ||||
Crypto-Type 0 that MUST be supported by all 6LRs. | ||||
A node may use more than one IPv6 address at the same time. The | A node may use more than one IPv6 address at the same time. The | |||
separation of the address and the cryptographic material avoids the | separation of the address and the cryptographic material avoids the | |||
need for the constrained device to compute multiple keys for multiple | need for the constrained device to compute multiple keys for multiple | |||
addresses. The 6LN MAY use the same Crypto-ID to prove the ownership | addresses. The 6LN MAY use the same Crypto-ID to prove the ownership | |||
of multiple IPv6 addresses. The 6LN MAY also derive multiple Crypto- | of multiple IPv6 addresses. The 6LN MAY also derive multiple Crypto- | |||
IDs from a same key. | IDs from a same key. | |||
6.1. First Exchange with a 6LR | 6.1. First Exchange with a 6LR | |||
A 6LN registers to a 6LR that is one hop away from it with the "C" | A 6LN registers to a 6LR that is one hop away from it with the "C" | |||
flag set in the EARO, indicating that the ROVR field contains a | flag set in the EARO, indicating that the ROVR field contains a | |||
Crypto-ID. The Target Address in the NS message indicates the IPv6 | Crypto-ID. The Target Address in the NS message indicates the IPv6 | |||
address that the 6LN is trying to register [RFC8505]. The on-link | address that the 6LN is trying to register [RFC8505]. The on-link | |||
(local) protocol interactions are shown in Figure 5. If the 6LR does | (local) protocol interactions are shown in Figure 6. If the 6LR does | |||
not have a state with the 6LN that is consistent with the NS(EARO), | not have a state with the 6LN that is consistent with the NS(EARO), | |||
then it replies with a challenge NA (EARO, status=Validation | then it replies with a challenge NA (EARO, status=Validation | |||
Requested) that contains a Nonce Option (shown as NonceLR in | Requested) that contains a Nonce Option (shown as NonceLR in | |||
Figure 5). | Figure 6). | |||
The Nonce option contains a nonce value that, to the extent possible | ||||
for the implementation, was never employed in association with the | ||||
key pair used to generate the Crypto-ID. This specification inherits | ||||
from [RFC3971] that simply indicates that the nonce is a random | ||||
value. Ideally, an implementation uses an unpredictable | ||||
cryptographically random value [BCP 106]. But that may be | ||||
impractical in some LLN scenarios where the devices do not have a | ||||
guaranteed sense of time and for which computing complex hashes is | ||||
detrimental to the battery lifetime. Alternatively, the device may | ||||
use an always-incrementing value saved in the same stable storage as | ||||
the key, so they are lost together, and starting at a best effort | ||||
random value, either as the nonce value or as a component to its | ||||
computation. | ||||
The 6LN replies to the challenge with an NS(EARO) that includes a new | ||||
Nonce option (shown as NonceLN in Figure 5), the CIPO (Section 4.3), | ||||
and the NDPSO containing the signature. Both Nonces are included in | ||||
the signed material. This provides a "contributory behavior", so | ||||
that either party that knows it generates a good quality nonce knows | ||||
that the protocol will be secure. | ||||
The 6LR MUST store the information associated to a Crypto-ID on the | ||||
first NS exchange where it appears in a fashion that the CIPO | ||||
parameters can be retrieved from the Crypto-ID alone. | ||||
6LN 6LR | 6LN 6LR | |||
| | | | | | |||
|<------------------------- RA -------------------------| | |<------------------------- RA -------------------------| | |||
| | ^ | | | ^ | |||
|---------------- NS with EARO (Crypto-ID) ------------>| | | |---------------- NS with EARO (Crypto-ID) ------------>| | | |||
| | option | | | option | |||
|<- NA with EARO (status=Validation Requested), NonceLR-| | | |<- NA with EARO (status=Validation Requested), NonceLR-| | | |||
| | v | | | v | |||
|------- NS with EARO, CIPO, NonceLN and NDPSO -------->| | |------- NS with EARO, CIPO, NonceLN and NDPSO -------->| | |||
skipping to change at page 14, line 30 ¶ | skipping to change at page 14, line 42 ¶ | |||
| | | | | | |||
|<------------------- NA with EARO ---------------------| | |<------------------- NA with EARO ---------------------| | |||
| | | | | | |||
... | ... | |||
| | | | | | |||
|--------------- NS with EARO (Crypto-ID) ------------->| | |--------------- NS with EARO (Crypto-ID) ------------->| | |||
| | | | | | |||
|<------------------- NA with EARO ---------------------| | |<------------------- NA with EARO ---------------------| | |||
| | | | | | |||
Figure 5: On-link Protocol Operation | Figure 6: On-link Protocol Operation | |||
The Nonce option contains a nonce value that, to the extent possible | ||||
for the implementation, was never employed in association with the | ||||
key pair used to generate the Crypto-ID. This specification inherits | ||||
from [RFC3971] that simply indicates that the nonce is a random | ||||
value. Ideally, an implementation uses an unpredictable | ||||
cryptographically random value [BCP 106]. But that may be | ||||
impractical in some LLN scenarios where the devices do not have a | ||||
guaranteed sense of time and for which computing complex hashes is | ||||
detrimental to the battery lifetime. | ||||
Alternatively, the device may use an always-incrementing value saved | ||||
in the same stable storage as the key, so they are lost together, and | ||||
starting at a best effort random value, either as the nonce value or | ||||
as a component to its computation. | ||||
The 6LN replies to the challenge with an NS(EARO) that includes a new | ||||
Nonce option (shown as NonceLN in Figure 6), the CIPO (Section 4.3), | ||||
and the NDPSO containing the signature. Both Nonces are included in | ||||
the signed material. This provides a "contributory behavior", so | ||||
that either party that knows it generates a good quality nonce knows | ||||
that the protocol will be secure. | ||||
The 6LR MUST store the information associated to a Crypto-ID on the | ||||
first NS exchange where it appears in a fashion that the CIPO | ||||
parameters can be retrieved from the Crypto-ID alone. | ||||
The steps for the registration to the 6LR are as follows: | The steps for the registration to the 6LR are as follows: | |||
* Upon the first exchange with a 6LR, a 6LN will be challenged to | Upon the first exchange with a 6LR, a 6LN will be challenged to prove | |||
prove ownership of the Crypto-ID and the Target Address being | ownership of the Crypto-ID and the Target Address being registered in | |||
registered in the Neighbor Solicitation message. When a 6LR | the Neighbor Solicitation message. When a 6LR receives a NS(EARO) | |||
receives a NS(EARO) registration with a new Crypto-ID as a ROVR, | registration with a new Crypto-ID as a ROVR, and unless the | |||
and unless the registration is rejected for another reason, it | registration is rejected for another reason, it MUST challenge by | |||
MUST challenge by responding with a NA(EARO) with a status of | responding with a NA(EARO) with a status of "Validation Requested". | |||
"Validation Requested". | ||||
* Upon receiving a first NA(EARO) with a status of "Validation | Upon receiving a first NA(EARO) with a status of "Validation | |||
Requested" from a 6LR, the registering node SHOULD retry its | Requested" from a 6LR, the registering node SHOULD retry its | |||
registration with a Crypto-ID Parameters Option (CIPO) | registration with a Crypto-ID Parameters Option (CIPO) (Section 4.3) | |||
(Section 4.3) that contains all the necessary material for | that contains all the necessary material for building the Crypto-ID, | |||
building the Crypto-ID, the NonceLN that it generated, and the NDP | the NonceLN that it generated, and the NDP signature (Section 4.4) | |||
signature (Section 4.4) option that proves its ownership of the | option that proves its ownership of the Crypto-ID and intent of | |||
Crypto-ID and intent of registering the Target Address. In | registering the Target Address. In subsequent revalidation with the | |||
subsequent revalidation with the same 6LR, the 6LN MAY try to omit | same 6LR, the 6LN MAY try to omit the CIPO to save bandwidth, with | |||
the CIPO to save bandwidth, with the expectation that the 6LR | the expectation that the 6LR saved it. If the validation fails and | |||
saved it. If the validation fails and it gets challenged again, | it gets challenged again, then it SHOULD add the CIPO again. | |||
then it SHOULD add the CIPO again. | ||||
* In order to validate the ownership, the 6LR performs the same | In order to validate the ownership, the 6LR performs the same steps | |||
steps as the 6LN and rebuilds the Crypto-ID based on the | as the 6LN and rebuilds the Crypto-ID based on the parameters in the | |||
parameters in the CIPO. If the rebuilt Crypto-ID matches the | CIPO. If the rebuilt Crypto-ID matches the ROVR, the 6LN also | |||
ROVR, the 6LN also verifies the signature contained in the NDPSO | verifies the signature contained in the NDPSO option. If at that | |||
option. If at that point the signature in the NDPSO option can be | point the signature in the NDPSO option can be verified, then the | |||
verified, then the validation succeeds. Otherwise the validation | validation succeeds. Otherwise the validation fails. | |||
fails. | ||||
* If the 6LR fails to validate the signed NS(EARO), it responds with | If the 6LR fails to validate the signed NS(EARO), it responds with a | |||
a status of "Validation Failed". After receiving a NA(EARO) with | status of "Validation Failed". After receiving a NA(EARO) with a | |||
a status of "Validation Failed", the registering node SHOULD try | status of "Validation Failed", the registering node SHOULD try and | |||
to register an alternate target address in the NS message. | alternate Crypto-Type and if even Crypto-Type 0 fails, it may try to | |||
register a different address in the NS message. | ||||
6.2. NDPSO generation and verification | 6.2. NDPSO generation and verification | |||
The signature generated by the 6LN to provide proof-of-ownership of | The signature generated by the 6LN to provide proof-of-ownership of | |||
the private-key is carried in the NDP Signature Option (NDPSO). It | the private-key is carried in the NDP Signature Option (NDPSO). It | |||
is generated by the 6LN in a fashion that depends on the Crypto-Type | is generated by the 6LN in a fashion that depends on the Crypto-Type | |||
(see Table 2 in Section 8.3) chosen by the 6LN as follows: | (see Table 2 in Section 8.2) chosen by the 6LN as follows: | |||
* Concatenate the following in the order listed: | * Form the message to be signed, by concatenating the following | |||
byte-strings in the order listed: | ||||
1. The 128-bit Message Type tag [RFC3972] (in network byte | 1. The 128-bit Message Type tag [RFC3972] (in network byte | |||
order). For this specification the tag is 0x8701 55c8 0cca | order). For this specification the tag is 0x8701 55c8 0cca | |||
dd32 6ab7 e415 f148 84d0. (The tag value has been generated | dd32 6ab7 e415 f148 84d0. (The tag value has been generated | |||
by the editor of this specification on random.org). | by the editor of this specification on random.org). | |||
2. JWK-encoded public key | 2. the CIPO | |||
3. the 16-byte Target Address (in network byte order) sent in the | 3. the 16-byte Target Address (in network byte order) sent in the | |||
Neighbor Solicitation (NS) message. It is the address which | Neighbor Solicitation (NS) message. It is the address which | |||
the 6LN is registering with the 6LR and 6LBR. | the 6LN is registering with the 6LR and 6LBR. | |||
4. NonceLR received from the 6LR (in network byte order) in the | 4. NonceLR received from the 6LR (in network byte order) in the | |||
Neighbor Advertisement (NA) message. The nonce is at least 6 | Neighbor Advertisement (NA) message. The nonce is at least 6 | |||
bytes long as defined in [RFC3971]. | bytes long as defined in [RFC3971]. | |||
5. NonceLN sent from the 6LN (in network byte order). The nonce | 5. NonceLN sent from the 6LN (in network byte order). The nonce | |||
is at least 6 bytes long as defined in [RFC3971]. | is at least 6 bytes long as defined in [RFC3971]. | |||
6. 1-byte Option Length of the EARO containing the Crypto-ID. | 6. 1-byte Option Length of the EARO containing the Crypto-ID. | |||
7. 1-byte Crypto-Type value sent in the CIPO. | ||||
* Apply the hash function (if any) specified by the Crypto-Type to | * Apply the signature algorithm specified by the Crypto-Type using | |||
the concatenated data, e.g., hash the resulting data using SHA- | the private key. | |||
256. | ||||
* Apply the signature algorithm specified by the Crypto-Type, e.g., | ||||
sign the hash output with ECDSA (if curve P-256 is used) or sign | ||||
the hash with EdDSA (if curve Ed25519 (PureEdDSA)). | ||||
The 6LR on receiving the NDPSO and CIPO options first checks that the | The 6LR on receiving the NDPSO and CIPO options first checks that the | |||
EARO Length in the CIPO matches the length of the EARO. If so it | EARO Length in the CIPO matches the length of the EARO. If so it | |||
regenerates the Crypto-ID based on the CIPO to make sure that the | regenerates the Crypto-ID based on the CIPO to make sure that the | |||
leftmost bits up to the size of the ROVR match. | leftmost bits up to the size of the ROVR match. | |||
If and only if the check is successful, it tries to verify the | If and only if the check is successful, it tries to verify the | |||
signature in the NDPSO option using the following: | signature in the NDPSO option using the following: | |||
* Concatenate the following in the order listed: | * Form the message to be verified, by concatenating the following | |||
byte-strings in the order listed: | ||||
1. 128-bit type tag (in network byte order) | 1. The 128-bit Message Type tag specified above (in network byte | |||
2. JWK-encoded public key received in the CIPO | order) | |||
2. the CIPO | ||||
3. the 16-byte Target Address (in network byte order) received in | 3. the 16-byte Target Address (in network byte order) received in | |||
the Neighbor Solicitation (NS) message. It is the address | the Neighbor Solicitation (NS) message. It is the address | |||
which the 6LN is registering with the 6LR and 6LBR. | which the 6LN is registering with the 6LR and 6LBR. | |||
4. NonceLR sent in the Neighbor Advertisement (NA) message. The | 4. NonceLR sent in the Neighbor Advertisement (NA) message. The | |||
nonce is at least 6 bytes long as defined in [RFC3971]. | nonce is at least 6 bytes long as defined in [RFC3971]. | |||
5. NonceLN received from the 6LN (in network byte order) in the | 5. NonceLN received from the 6LN (in network byte order) in the | |||
NS message. The nonce is at least 6 bytes long as defined in | NS message. The nonce is at least 6 bytes long as defined in | |||
[RFC3971]. | [RFC3971]. | |||
6. 1-byte EARO Length received in the CIPO. | 6. 1-byte EARO Length received in the CIPO. | |||
7. 1-byte Crypto-Type value received in the CIPO. | ||||
* Apply the hash function (if any) specified by the Crypto-Type | ||||
indicated by the 6LN in the CIPO to the concatenated data. | ||||
* Verify the signature with the public-key in the CIPO and the | * Verify the signature on this message with the public-key in the | |||
locally computed values using the signature algorithm specified by | CIPO and the locally computed values using the signature algorithm | |||
the Crypto-Type. If the verification succeeds, the 6LR propagates | specified by the Crypto-Type. If the verification succeeds, the | |||
the information to the 6LBR using a EDAR/EDAC flow. | 6LR propagates the information to the 6LBR using a EDAR/EDAC flow. | |||
* Due to the first-come/first-serve nature of the registration, if | * Due to the first-come/first-serve nature of the registration, if | |||
the address is not registered to the 6LBR, then flow succeeds and | the address is not registered to the 6LBR, then flow succeeds and | |||
both the 6LR and 6LBR add the state information about the Crypto- | both the 6LR and 6LBR add the state information about the Crypto- | |||
ID and Target Address being registered to their respective | ID and Target Address being registered to their respective | |||
abstract database. | abstract database. | |||
6.3. Multihop Operation | 6.3. Multihop Operation | |||
A new 6LN that joins the network auto-configures an address and | A new 6LN that joins the network auto-configures an address and | |||
performs an initial registration to a neighboring 6LR with an NS | performs an initial registration to a neighboring 6LR with an NS | |||
message that carries an Address Registration Option (EARO) [RFC8505]. | message that carries an Address Registration Option (EARO) [RFC8505]. | |||
In a multihop 6LoWPAN, the registration with Crypto-ID is propagated | In a multihop 6LoWPAN, the registration with Crypto-ID is propagated | |||
to 6LBR as shown in Figure 6, which illustrates the registration flow | to 6LBR as shown in Figure 7, which illustrates the registration flow | |||
all the way to a 6LowPAN Backbone Router (6BBR) [BACKBONE-ROUTER]. | all the way to a 6LowPAN Backbone Router (6BBR) [BACKBONE-ROUTER]. | |||
The 6LR and the 6LBR communicate using ICMPv6 Extended Duplicate | ||||
Address Request (EDAR) and Extended Duplicate Address Confirmation | ||||
(EDAC) messages [RFC8505] as shown in Figure 6. This specification | ||||
extends EDAR/EDAC messages to carry cryptographically generated ROVR. | ||||
The assumption is that the 6LR and the 6LBR maintain a security | ||||
association to authenticate and protect the integrity of the EDAR and | ||||
EDAC messages, so there is no need to propagate the proof of | ||||
ownership to the 6LBR. The 6LBR implicitly trusts that the 6LR | ||||
performs the verification when the 6LBR requires it, and if there is | ||||
no further exchange from the 6LR to remove the state, that the | ||||
verification succeeded. | ||||
6LN 6LR 6LBR 6BBR | 6LN 6LR 6LBR 6BBR | |||
| | | | | | | | | | |||
| NS(EARO) | | | | | NS(EARO) | | | | |||
|--------------->| | | | |--------------->| | | | |||
| | Extended DAR | | | | | Extended DAR | | | |||
| |-------------->| | | | |-------------->| | | |||
| | | | | | | | | | |||
| | | proxy NS(EARO) | | | | | proxy NS(EARO) | | |||
| | |--------------->| | | | |--------------->| | |||
| | | | NS(DAD) | | | | | NS(DAD) | |||
skipping to change at page 17, line 39 ¶ | skipping to change at page 18, line 4 ¶ | |||
| | | | | | | | | | |||
| | | | <wait> | | | | | <wait> | |||
| | | | | | | | | | |||
| | | proxy NA(EARO) | | | | | proxy NA(EARO) | | |||
| | |<---------------| | | | |<---------------| | |||
| | Extended DAC | | | | | Extended DAC | | | |||
| |<--------------| | | | |<--------------| | | |||
| NA(EARO) | | | | | NA(EARO) | | | | |||
|<---------------| | | | |<---------------| | | | |||
| | | | | | | | | | |||
Figure 7: (Re-)Registration Flow | ||||
Figure 6: (Re-)Registration Flow | The 6LR and the 6LBR communicate using ICMPv6 Extended Duplicate | |||
Address Request (EDAR) and Extended Duplicate Address Confirmation | ||||
(EDAC) messages [RFC8505] as shown in Figure 7. This specification | ||||
extends EDAR/EDAC messages to carry cryptographically generated ROVR. | ||||
The assumption is that the 6LR and the 6LBR maintain a security | ||||
association to authenticate and protect the integrity of the EDAR and | ||||
EDAC messages, so there is no need to propagate the proof of | ||||
ownership to the 6LBR. The 6LBR implicitly trusts that the 6LR | ||||
performs the verification when the 6LBR requires it, and if there is | ||||
no further exchange from the 6LR to remove the state, that the | ||||
verification succeeded. | ||||
7. Security Considerations | 7. Security Considerations | |||
7.1. Inheriting from RFC 3971 | 7.1. Inheriting from RFC 3971 | |||
Observations regarding the following threats to the local network in | Observations regarding the following threats to the local network in | |||
[RFC3971] also apply to this specification. | [RFC3971] also apply to this specification. | |||
Neighbor Solicitation/Advertisement Spoofing: Threats in section | Neighbor Solicitation/Advertisement Spoofing: Threats in section | |||
9.2.1 of RFC3971 apply. AP-ND counters the threats on NS(EARO) | 9.2.1 of RFC3971 apply. AP-ND counters the threats on NS(EARO) | |||
skipping to change at page 19, line 19 ¶ | skipping to change at page 20, line 5 ¶ | |||
short cycles for privacy reasons [RFC8064][RFC8065], that cannot be | short cycles for privacy reasons [RFC8064][RFC8065], that cannot be | |||
compressed. | compressed. | |||
This specification provides added protection for addresses that are | This specification provides added protection for addresses that are | |||
obtained following due procedure [RFC8505] but does not constrain the | obtained following due procedure [RFC8505] but does not constrain the | |||
way the addresses are formed or the number of addresses that are used | way the addresses are formed or the number of addresses that are used | |||
in parallel by a same entity. A rogue may still perform denial-of- | in parallel by a same entity. A rogue may still perform denial-of- | |||
service attack against the registry at the 6LR or 6LBR, or attempt to | service attack against the registry at the 6LR or 6LBR, or attempt to | |||
deplete the pool of available addresses at Layer-2 or Layer-3. | deplete the pool of available addresses at Layer-2 or Layer-3. | |||
7.3. ROVR Collisions | 7.3. Brown Field | |||
Only 6LRs that are upgraded to this specification are capable to | ||||
challenge a registration and repel an attack. In a brown (mixed) | ||||
network, an attacker may attach to a legacy 6LR and fool the 6LBR. | ||||
So even if the "A" flag could be set at any time to test the protocol | ||||
operation, the security will only be effective when the all the 6LRs | ||||
are upgraded. | ||||
7.4. Compromised 6LR | ||||
This specification distributes the challenge and its validation at | ||||
the edge of the network, between the 6LN and its 6LR. This protects | ||||
against DOS attacks targeted at that central 6LBR. This also saves | ||||
back and forth exchanges across a potentially large and constrained | ||||
network. The downside is that the 6LBR needs to trust the 6LR for | ||||
performing the checking adequately, and the communication between the | ||||
6LR and the 6LBR must be protected to avoid tempering with the result | ||||
of the test. If a 6LR is compromised, and provided that it knows the | ||||
ROVR field used by the real owner of the address, the 6LR may pretend | ||||
that the owner has moved, is now attached to it and has successfully | ||||
passed the Crpto-ID validation. The 6LR may then attract and inject | ||||
traffic at will on behalf of that address or let a rogue take | ||||
ownership of the address. | ||||
7.5. ROVR Collisions | ||||
A collision of Registration Ownership Verifiers (ROVR) (i.e., the | A collision of Registration Ownership Verifiers (ROVR) (i.e., the | |||
Crypto-ID in this specification) is possible, but it is a rare event. | Crypto-ID in this specification) is possible, but it is a rare event. | |||
Assuming in the calculations/discussion below that the hash used for | Assuming in the calculations/discussion below that the hash used for | |||
calculating the Crypto-ID is a well-behaved cryptographic hash and | calculating the Crypto-ID is a well-behaved cryptographic hash and | |||
thus that random collisions are the only ones possible, the formula | thus that random collisions are the only ones possible, the formula | |||
(birthday paradox) for calculating the probability of a collision is | (birthday paradox) for calculating the probability of a collision is | |||
1 - e^{-k^2/(2n)} where n is the maximum population size (2^64 here, | 1 - e^{-k^2/(2n)} where n is the maximum population size (2^64 here, | |||
1.84E19) and k is the actual population (number of nodes, assuming | 1.84E19) and k is the actual population (number of nodes, assuming | |||
one Crypto-ID per node). | one Crypto-ID per node). | |||
skipping to change at page 19, line 41 ¶ | skipping to change at page 21, line 5 ¶ | |||
If the Crypto-ID is 64-bits (the least possible size allowed), the | If the Crypto-ID is 64-bits (the least possible size allowed), the | |||
chance of a collision is 0.01% for network of 66 million nodes. | chance of a collision is 0.01% for network of 66 million nodes. | |||
Moreover, the collision is only relevant when this happens within one | Moreover, the collision is only relevant when this happens within one | |||
stub network (6LBR). In the case of such a collision, a third party | stub network (6LBR). In the case of such a collision, a third party | |||
node would be able to claim the registered address of an another | node would be able to claim the registered address of an another | |||
legitimate node, provided that it wishes to use the same address. To | legitimate node, provided that it wishes to use the same address. To | |||
prevent address disclosure and avoid the chances of collision on both | prevent address disclosure and avoid the chances of collision on both | |||
the ROVR and the address, it is RECOMMENDED that nodes do not derive | the ROVR and the address, it is RECOMMENDED that nodes do not derive | |||
the address being registered from the ROVR. | the address being registered from the ROVR. | |||
7.4. Implementation Attacks | 7.6. Implementation Attacks | |||
The signature schemes referenced in this specification comply with | The signature schemes referenced in this specification comply with | |||
NIST [FIPS186-4] or Crypto Forum Research Group (CFRG) standards | NIST [FIPS186-4] or Crypto Forum Research Group (CFRG) standards | |||
[RFC8032] and offer strong algorithmic security at roughly 128-bit | [RFC8032] and offer strong algorithmic security at roughly 128-bit | |||
security level. These signature schemes use elliptic curves that | security level. These signature schemes use elliptic curves that | |||
were either specifically designed with exception-free and constant- | were either specifically designed with exception-free and constant- | |||
time arithmetic in mind [RFC7748] or where one has extensive | time arithmetic in mind [RFC7748] or where one has extensive | |||
implementation experience of resistance to timing attacks | implementation experience of resistance to timing attacks | |||
[FIPS186-4]. However, careless implementations of the signing | [FIPS186-4]. However, careless implementations of the signing | |||
operations could nevertheless leak information on private keys. For | operations could nevertheless leak information on private keys. For | |||
example, there are micro-architectural side channel attacks that | example, there are micro-architectural side channel attacks that | |||
implementors should be aware of [breaking-ed25519]. Implementors | implementors should be aware of [breaking-ed25519]. Implementors | |||
should be particularly aware that a secure implementation of Ed25519 | should be particularly aware that a secure implementation of Ed25519 | |||
requires a protected implementation of the hash function SHA-512, | requires a protected implementation of the hash function SHA-512, | |||
whereas this is not required with implementations of SHA-256 used | whereas this is not required with implementations of the hash | |||
with ECDSA. | function SHA-256 used with ECDSA256 and ECDSA25519. | |||
7.5. Cross-Algorithm and Cross-Protocol Attacks | 7.7. Cross-Algorithm and Cross-Protocol Attacks | |||
The keypair used in this specification can be self-generated and the | The keypair used in this specification can be self-generated and the | |||
public key does not need to be exchanged, e.g., through certificates, | public key does not need to be exchanged, e.g., through certificates, | |||
with a third party before it is used. New keypairs can be formed for | with a third party before it is used. New keypairs can be formed for | |||
new registration as the node desires. On the other hand, it is safer | new registration as the node desires. On the other hand, it is safer | |||
to allocate a keypair that is used only for the address protection | to allocate a keypair that is used only for the address protection | |||
and only for one instantiation of the signature scheme (which | and only for one instantiation of the signature scheme (which | |||
includes choice of elliptic curve domain parameters, used hash | includes choice of elliptic curve domain parameters, used hash | |||
function, and applicable representation conventions). The same | function, and applicable representation conventions). The same | |||
private key MUST NOT be reused with more than one instantiation of | private key MUST NOT be reused with more than one instantiation of | |||
the signature scheme in this specification. The same private key | the signature scheme in this specification. The same private key | |||
MUST NOT be used for anything other than computing NDPSO signatures | MUST NOT be used for anything other than computing NDPSO signatures | |||
per this specification. | per this specification. | |||
7.6. Compromised 6LR | ECDSA shall be used strictly as specified in [FIPS186-4]. In | |||
particular, each signing operation of ECDSA MUST use randomly | ||||
generated ephemeral private keys and MUST NOT reuse these ephemeral | ||||
private keys accross signing operations. (This precludes the use of | ||||
deterministic ECDSA, which is deemed dangerous for the intended | ||||
applications this document aims to serve.) | ||||
This specification distributes the challenge and its validation at | 7.8. Public Key Validation | |||
the edge of the network, between the 6LN and its 6LR. This protects | ||||
against DOS attacks targeted at that central 6LBR. This also saves | ||||
back and forth exchanges across a potentially large and constrained | ||||
network. The downside is that the 6LBR needs to trust the 6LR for | ||||
performing the checking adequately, and the communication between the | ||||
6LR and the 6LBR must be protected to avoid tempering with the result | ||||
of the test. If a 6LR is compromised, and provided that it knows the | ||||
ROVR field used by the real owner of the address, the 6LR may pretend | ||||
that the owner has moved, is now attached to it and has successfully | ||||
passed the Crpto-ID validation. The 6LR may then attract and inject | ||||
traffic at will on behalf of that address or let a rogue take | ||||
ownership of the address. | ||||
7.7. Correlating Registrations | Public keys contained in the CIPO field (which are used for signature | |||
verification) shall be verified to be correctly formed, by checking | ||||
that this public key is indeed a point of the elliptic curve | ||||
indicated by the Crypto-Type and that this point does have the proper | ||||
order. For points used with the signature scheme Ed25519, one MUST | ||||
check that this point is not a point in the small subgroup (see | ||||
Appendix B.1 of [CURVE-REPR]); for points used with the signature | ||||
scheme ECDSA (i.e., both ECDSA256 and ECDSA25519), one MUST check | ||||
that the point has the same order as the base point of the curve in | ||||
question. This is commonly called full public key validation (again, | ||||
see Appendix B.1 of [CURVE-REPR]). | ||||
7.9. Correlating Registrations | ||||
The ROVR field in the EARO introduced in [RFC8505] extends the EUI-64 | The ROVR field in the EARO introduced in [RFC8505] extends the EUI-64 | |||
field of the ARO defined in [RFC6775]. One of the drawbacks of using | field of the ARO defined in [RFC6775]. One of the drawbacks of using | |||
an EUI-64 as ROVR is that an attacker that is aware of the | an EUI-64 as ROVR is that an attacker that is aware of the | |||
registrations can correlate traffic for a same 6LN across multiple | registrations can correlate traffic for a same 6LN across multiple | |||
addresses. Section 3 of [RFC8505] indicates that the ROVR and the | addresses. Section 3 of [RFC8505] indicates that the ROVR and the | |||
address being registered are decoupled. A 6LN may use a same ROVR | address being registered are decoupled. A 6LN may use a same ROVR | |||
for multiple registrations or a different ROVR per registration, and | for multiple registrations or a different ROVR per registration, and | |||
the IID must not derive from the ROVR. In theory different 6LNs | the IID must not derive from the ROVR. In theory different 6LNs | |||
could use a same ROVR as long as they do not attempt to register the | could use a same ROVR as long as they do not attempt to register the | |||
skipping to change at page 21, line 29 ¶ | skipping to change at page 22, line 34 ¶ | |||
to build different Crypto-IDs for different addresses with a same | to build different Crypto-IDs for different addresses with a same | |||
keypair. Using that facility improves the privacy of the 6LN as the | keypair. Using that facility improves the privacy of the 6LN as the | |||
expense of storage in the 6LR, which will need to store multiple | expense of storage in the 6LR, which will need to store multiple | |||
CIPOs that contain the same public key. Note that if the attacker is | CIPOs that contain the same public key. Note that if the attacker is | |||
the 6LR, then the Modifier alone does not provide a protection, and | the 6LR, then the Modifier alone does not provide a protection, and | |||
the 6LN would need to use different keys and MAC addresses in an | the 6LN would need to use different keys and MAC addresses in an | |||
attempt to obfuscate its multiple ownership. | attempt to obfuscate its multiple ownership. | |||
8. IANA considerations | 8. IANA considerations | |||
8.1. CGA Message Type | 8.1. IPv6 ND option types | |||
This document defines a new 128-bit value under the CGA Message Type | ||||
[RFC3972] name space: 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0. | ||||
8.2. IPv6 ND option types | ||||
This document registers two new ND option types under the subregistry | This document registers two new ND option types under the subregistry | |||
"IPv6 Neighbor Discovery Option Formats": | "IPv6 Neighbor Discovery Option Formats": | |||
+------------------------------+-----------------+---------------+ | +------------------------------+-----------------+---------------+ | |||
| Option Name | Suggested Value | Reference | | | Option Name | Suggested Value | Reference | | |||
+==============================+=================+===============+ | +==============================+=================+===============+ | |||
| NDP Signature Option (NDPSO) | 38 | This document | | | NDP Signature Option (NDPSO) | 38 | This document | | |||
+------------------------------+-----------------+---------------+ | +------------------------------+-----------------+---------------+ | |||
| Crypto-ID Parameters Option | 39 | This document | | | Crypto-ID Parameters Option | 39 | This document | | |||
| (CIPO) | | | | | (CIPO) | | | | |||
+------------------------------+-----------------+---------------+ | +------------------------------+-----------------+---------------+ | |||
Table 1: New ND options | Table 1: New ND options | |||
8.3. Crypto-Type Subregistry | 8.2. Crypto-Type Subregistry | |||
IANA is requested to create a new subregistry "Crypto-Type | IANA is requested to create a new subregistry "Crypto-Type | |||
Subregistry" in the "Internet Control Message Protocol version 6 | Subregistry" in the "Internet Control Message Protocol version 6 | |||
(ICMPv6) Parameters". The registry is indexed by an integer in the | (ICMPv6) Parameters". The registry is indexed by an integer in the | |||
interval 0..255 and contains an Elliptic Curve, a Hash Function, a | interval 0..255 and contains an Elliptic Curve, a Hash Function, a | |||
Signature Algorithm, and Representation Conventions, as shown in | Signature Algorithm, Representation Conventions, Public key size, and | |||
Table 2, which together specify a signature scheme. The following | Signature size, as shown in Table 2, which together specify a | |||
Crypto-Type values are defined in this document: | signature scheme (and which are fully specified in Appendix B). | |||
+----------------+---------------+---------------+---------------+ | The following Crypto-Type values are defined in this document: | |||
| Crypto-Type | 0 (ECDSA256) | 1 (Ed25519) | 2 | | ||||
| value | | | (ECDSA25519) | | ||||
+================+===============+===============+===============+ | ||||
| Elliptic curve | NIST P-256 | Curve25519 | Curve25519 | | ||||
| | [FIPS186-4] | [RFC7748] | [RFC7748] | | ||||
+----------------+---------------+---------------+---------------+ | ||||
| Hash function | SHA-256 | SHA-512 | SHA-256 | | ||||
| | [RFC6234] | [RFC6234] | [RFC6234] | | ||||
+----------------+---------------+---------------+---------------+ | ||||
| Signature | ECDSA | Ed25519 | ECDSA | | ||||
| algorithm | [FIPS186-4] | [RFC8032] | [FIPS186-4] | | ||||
+----------------+---------------+---------------+---------------+ | ||||
| Representation | Weierstrass, | Edwards, | Weierstrass, | | ||||
| conventions | uncompressed, | compressed, | compressed, | | ||||
| | MSB/msb first | LSB/lsb first | MSB/msb first | | ||||
+----------------+---------------+---------------+---------------+ | ||||
| Defining | This document | This document | This document | | ||||
| specification | | | | | ||||
+----------------+---------------+---------------+---------------+ | ||||
Table 2: Crypto-Types | +----------------+-----------------+--------------+-----------------+ | |||
| Crypto-Type | 0 (ECDSA256) | 1 (Ed25519) | 2 (ECDSA25519) | | ||||
| value | | | | | ||||
+================+=================+==============+=================+ | ||||
| Elliptic curve | NIST P-256 | Curve25519 | Curve25519 | | ||||
| | [FIPS186-4] | [RFC7748] | [RFC7748] | | ||||
+----------------+-----------------+--------------+-----------------+ | ||||
| Hash function |SHA-256 [RFC6234]| SHA-512 |SHA-256 [RFC6234]| | ||||
| | | [RFC6234] | | | ||||
+----------------+-----------------+--------------+-----------------+ | ||||
| Signature |ECDSA [FIPS186-4]| Ed25519 |ECDSA [FIPS186-4]| | ||||
| algorithm | | [RFC8032] | | | ||||
+----------------+-----------------+--------------+-----------------+ | ||||
| Representation | Weierstrass, | Edwards, | Weierstrass, | | ||||
| conventions | (un)compressed, | compressed, | (un)compressed, | | ||||
| | MSB/msb first, |LSB/lsb first,| MSB/msb first, | | ||||
| | [RFC7518] | [RFC8037] | [CURVE-REPR] | | ||||
+----------------+-----------------+--------------+-----------------+ | ||||
|Public key size | 33/65 bytes | 32 bytes | 33/65 bytes | | ||||
| | (compressed/ | (compressed) | (compressed/ | | ||||
| | uncompressed) | | uncompressed) | | ||||
+----------------+-----------------+--------------+-----------------+ | ||||
| Signature size | 64 bytes | 64 bytes | 64 bytes | | ||||
+----------------+-----------------+--------------+-----------------+ | ||||
| Defining | This document |This document | This document | | ||||
| specification | | | | | ||||
+----------------+-----------------+--------------+-----------------+ | ||||
Table 2: Crypto-Types | ||||
New Crypto-Type values providing similar or better security may be | New Crypto-Type values providing similar or better security may be | |||
defined in the future. | defined in the future. | |||
Assignment of new values for new Crypto-Type MUST be done through | Assignment of new values for new Crypto-Type MUST be done through | |||
IANA with either "Specification Required" or "IESG Approval" as | IANA with either "Specification Required" or "IESG Approval" as | |||
defined in BCP 26 [RFC8126]. | defined in BCP 26 [RFC8126]. | |||
The "Defining specification" column indicates the document that | 8.3. CGA Message Type | |||
defines the length and computation of the digital signature, which | ||||
could be this for values defined through "IESG Approval". | ||||
8.4. New Codepoints Associated to JWK Encoding | ||||
Code points are requested for curve Wei25519 and its use with ECDSA, | ||||
using the representation conventions of this document. | ||||
8.4.1. COSE Elliptic Curves Registration | ||||
This section registers the following value in the IANA "COSE Elliptic | ||||
Curves" registry [IANA.COSE.Curves]. | ||||
Name: Wei25519 | ||||
Value: TBD (Requested value: -1) | ||||
Key Type: EC2 or OKP (where OKP uses the MSB/msb representation of | ||||
this specification) | ||||
Description: short-Weierstrass curve Wei25519 | ||||
Change Controller: IESG | ||||
Reference: Appendix E.3 of [CURVE-REPRESENTATIONS] | ||||
Recommended: Yes. | ||||
(Note that The "kty" value for Wei25519 may be "OKP" or "EC2".) | ||||
8.4.2. COSE Algorithms Registration | ||||
This section registers the following value in the IANA "COSE | ||||
Algorithms" registry [IANA.COSE.Algorithms]. | ||||
Name: ECDSA25519 | ||||
Value: TBD (Requested value: -1) | ||||
Description: ECDSA using SHA-256 and curve Wei25519 | ||||
Change Controller: IESG | ||||
Reference: Section 4.3 of [CURVE-REPRESENTATIONS] | ||||
Recommended: Yes. | ||||
8.4.3. JOSE Elliptic Curves Registration | ||||
This section registers the following value in the IANA "JSON Web Key | ||||
Elliptic Curve" registry [IANA.JOSE.Curves]. | ||||
Curve Name: Wei25519 | ||||
Curve Description: short-Weierstrass curve Wei25519 | ||||
JOSE Implementation Requirements: Optional | ||||
Change Controller: IESG | ||||
Reference: Appendix E.3 of [CURVE-REPRESENTATIONS] | ||||
8.4.4. JOSE Algorithms Registration | ||||
This section registers the following value in the IANA "JSON Web | ||||
Signature and Encryption Algorithms" registry [IANA.JOSE.Algorithms]. | ||||
Algorithm Name: ECDSA25519 | ||||
Algorithm Description: ECDSA using SHA-256 and curve Wei25519 | ||||
Algorithm Usage Locations: alg | ||||
JOSE Implementation Requirements: Optional | ||||
Change Controller: IESG | ||||
Reference: Section 4.3 of [CURVE-REPRESENTATIONS] | ||||
Algorithm Analysis Document(s): Section 4.3 of | This document defines a new 128-bit value under the CGA Message Type | |||
[CURVE-REPRESENTATIONS] | [RFC3972] name space: 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0. | |||
9. Acknowledgments | 9. Acknowledgments | |||
Many thanks to Charlie Perkins for his in-depth review and | Many thanks to Charlie Perkins for his in-depth review and | |||
constructive suggestions. The authors are also especially grateful | constructive suggestions. The authors are also especially grateful | |||
to Robert Moskowitz and Benjamin Kaduk for their comments and | to Robert Moskowitz and Benjamin Kaduk for their comments and | |||
discussions that led to many improvements. The authors wish to also | discussions that led to many improvements. The authors wish to also | |||
thank Roman Danyliw, Alissa Cooper, Mirja Kuhlewind, Eric Vyncke, | thank Roman Danyliw, Alissa Cooper, Mirja Kuhlewind, Eric Vyncke, | |||
Vijay Gurbani, Al Morton and Adam Montville for their constructive | Vijay Gurbani, Al Morton and Adam Montville for their constructive | |||
reviews during the IESG process. | reviews during the IESG process. | |||
10. Normative References | 10. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, | ||||
"SEcure Neighbor Discovery (SEND)", RFC 3971, | ||||
DOI 10.17487/RFC3971, March 2005, | ||||
<https://www.rfc-editor.org/info/rfc3971>. | ||||
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms | ||||
(SHA and SHA-based HMAC and HKDF)", RFC 6234, | ||||
DOI 10.17487/RFC6234, May 2011, | ||||
<https://www.rfc-editor.org/info/rfc6234>. | ||||
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. | [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. | |||
Bormann, "Neighbor Discovery Optimization for IPv6 over | Bormann, "Neighbor Discovery Optimization for IPv6 over | |||
Low-Power Wireless Personal Area Networks (6LoWPANs)", | Low-Power Wireless Personal Area Networks (6LoWPANs)", | |||
RFC 6775, DOI 10.17487/RFC6775, November 2012, | RFC 6775, DOI 10.17487/RFC6775, November 2012, | |||
<https://www.rfc-editor.org/info/rfc6775>. | <https://www.rfc-editor.org/info/rfc6775>. | |||
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, | [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for | |||
DOI 10.17487/RFC7517, May 2015, | IPv6 over Low-Power Wireless Personal Area Networks | |||
<https://www.rfc-editor.org/info/rfc7517>. | (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November | |||
2014, <https://www.rfc-editor.org/info/rfc7400>. | ||||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, | ||||
"SEcure Neighbor Discovery (SEND)", RFC 3971, | ||||
DOI 10.17487/RFC3971, March 2005, | ||||
<https://www.rfc-editor.org/info/rfc3971>. | ||||
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves | [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves | |||
for Security", RFC 7748, DOI 10.17487/RFC7748, January | for Security", RFC 7748, DOI 10.17487/RFC7748, January | |||
2016, <https://www.rfc-editor.org/info/rfc7748>. | 2016, <https://www.rfc-editor.org/info/rfc7748>. | |||
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital | [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital | |||
Signature Algorithm (EdDSA)", RFC 8032, | Signature Algorithm (EdDSA)", RFC 8032, | |||
DOI 10.17487/RFC8032, January 2017, | DOI 10.17487/RFC8032, January 2017, | |||
<https://www.rfc-editor.org/info/rfc8032>. | <https://www.rfc-editor.org/info/rfc8032>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. | [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. | |||
Perkins, "Registration Extensions for IPv6 over Low-Power | Perkins, "Registration Extensions for IPv6 over Low-Power | |||
Wireless Personal Area Network (6LoWPAN) Neighbor | Wireless Personal Area Network (6LoWPAN) Neighbor | |||
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, | Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, | |||
<https://www.rfc-editor.org/info/rfc8505>. | <https://www.rfc-editor.org/info/rfc8505>. | |||
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms | ||||
(SHA and SHA-based HMAC and HKDF)", RFC 6234, | ||||
DOI 10.17487/RFC6234, May 2011, | ||||
<https://www.rfc-editor.org/info/rfc6234>. | ||||
[FIPS186-4] | [FIPS186-4] | |||
FIPS 186-4, "Digital Signature Standard (DSS), Federal | FIPS 186-4, "Digital Signature Standard (DSS), Federal | |||
Information Processing Standards Publication 186-4", US | Information Processing Standards Publication 186-4", US | |||
Department of Commerce/National Institute of Standards and | Department of Commerce/National Institute of Standards and | |||
Technology , July 2013. | Technology , July 2013. | |||
[SEC1] SEC1, "SEC 1: Elliptic Curve Cryptography, Version 2.0", | [SEC1] SEC1, "SEC 1: Elliptic Curve Cryptography, Version 2.0", | |||
Standards for Efficient Cryptography , June 2009. | Standards for Efficient Cryptography , June 2009. | |||
11. Informative references | 11. Informative references | |||
[IANA.COSE.Algorithms] | ||||
IANA, "COSE Algorithms", IANA, | ||||
https://www.iana.org/assignments/cose/ | ||||
cose.xhtml#algorithms. | ||||
[IANA.COSE.Curves] | ||||
IANA, "COSE Elliptic Curves", IANA, | ||||
https://www.iana.org/assignments/cose/cose.xhtml#elliptic- | ||||
curves. | ||||
[IANA.JOSE.Algorithms] | ||||
IANA, "JSON Web Signature and Encryption Algorithms", | ||||
IANA, | ||||
https://www.iana.org/assignments/jose/jose.xhtml#web- | ||||
signature-encryption-algorithms. | ||||
[IANA.JOSE.Curves] | ||||
IANA, "JSON Web Key Elliptic Curve", IANA, | ||||
https://www.iana.org/assignments/jose/jose.xhtml#web-key- | ||||
elliptic-curve. | ||||
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", | [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", | |||
RFC 3972, DOI 10.17487/RFC3972, March 2005, | RFC 3972, DOI 10.17487/RFC3972, March 2005, | |||
<https://www.rfc-editor.org/info/rfc3972>. | <https://www.rfc-editor.org/info/rfc3972>. | |||
[BCP 106] Eastlake 3rd, D., Schiller, J., and S. Crocker, | ||||
"Randomness Requirements for Security", BCP 106, RFC 4086, | ||||
DOI 10.17487/RFC4086, June 2005, | ||||
<https://www.rfc-editor.org/info/rfc4086>. | ||||
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, | [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, | |||
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | |||
DOI 10.17487/RFC4861, September 2007, | DOI 10.17487/RFC4861, September 2007, | |||
<https://www.rfc-editor.org/info/rfc4861>. | <https://www.rfc-editor.org/info/rfc4861>. | |||
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless | [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless | |||
Address Autoconfiguration", RFC 4862, | Address Autoconfiguration", RFC 4862, | |||
DOI 10.17487/RFC4862, September 2007, | DOI 10.17487/RFC4862, September 2007, | |||
<https://www.rfc-editor.org/info/rfc4862>. | <https://www.rfc-editor.org/info/rfc4862>. | |||
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 | ||||
over Low-Power Wireless Personal Area Networks (6LoWPANs): | ||||
Overview, Assumptions, Problem Statement, and Goals", | ||||
RFC 4919, DOI 10.17487/RFC4919, August 2007, | ||||
<https://www.rfc-editor.org/info/rfc4919>. | ||||
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, | [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, | |||
"Transmission of IPv6 Packets over IEEE 802.15.4 | "Transmission of IPv6 Packets over IEEE 802.15.4 | |||
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, | Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, | |||
<https://www.rfc-editor.org/info/rfc4944>. | <https://www.rfc-editor.org/info/rfc4944>. | |||
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 | [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 | |||
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, | Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, | |||
DOI 10.17487/RFC6282, September 2011, | DOI 10.17487/RFC6282, September 2011, | |||
<https://www.rfc-editor.org/info/rfc6282>. | <https://www.rfc-editor.org/info/rfc6282>. | |||
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 | ||||
over Low-Power Wireless Personal Area Networks (6LoWPANs): | ||||
Overview, Assumptions, Problem Statement, and Goals", | ||||
RFC 4919, DOI 10.17487/RFC4919, August 2007, | ||||
<https://www.rfc-editor.org/info/rfc4919>. | ||||
[BCP 106] Eastlake 3rd, D., Schiller, J., and S. Crocker, | ||||
"Randomness Requirements for Security", BCP 106, RFC 4086, | ||||
DOI 10.17487/RFC4086, June 2005, | ||||
<https://www.rfc-editor.org/info/rfc4086>. | ||||
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | ||||
Writing an IANA Considerations Section in RFCs", BCP 26, | ||||
RFC 8126, DOI 10.17487/RFC8126, June 2017, | ||||
<https://www.rfc-editor.org/info/rfc8126>. | ||||
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., | [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., | |||
"Source Address Validation Improvement (SAVI) Framework", | "Source Address Validation Improvement (SAVI) Framework", | |||
RFC 7039, DOI 10.17487/RFC7039, October 2013, | RFC 7039, DOI 10.17487/RFC7039, October 2013, | |||
<https://www.rfc-editor.org/info/rfc7039>. | <https://www.rfc-editor.org/info/rfc7039>. | |||
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque | [RFC7217] Gont, F., "A Method for Generating Semantically Opaque | |||
Interface Identifiers with IPv6 Stateless Address | Interface Identifiers with IPv6 Stateless Address | |||
Autoconfiguration (SLAAC)", RFC 7217, | Autoconfiguration (SLAAC)", RFC 7217, | |||
DOI 10.17487/RFC7217, April 2014, | DOI 10.17487/RFC7217, April 2014, | |||
<https://www.rfc-editor.org/info/rfc7217>. | <https://www.rfc-editor.org/info/rfc7217>. | |||
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, | ||||
DOI 10.17487/RFC7518, May 2015, | ||||
<https://www.rfc-editor.org/info/rfc7518>. | ||||
[BCP 201] Housley, R., "Guidelines for Cryptographic Algorithm | [BCP 201] Housley, R., "Guidelines for Cryptographic Algorithm | |||
Agility and Selecting Mandatory-to-Implement Algorithms", | Agility and Selecting Mandatory-to-Implement Algorithms", | |||
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, | BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, | |||
<https://www.rfc-editor.org/info/rfc7696>. | <https://www.rfc-editor.org/info/rfc7696>. | |||
[RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) | ||||
and Signatures in JSON Object Signing and Encryption | ||||
(JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, | ||||
<https://www.rfc-editor.org/info/rfc8037>. | ||||
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, | [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, | |||
"Recommendation on Stable IPv6 Interface Identifiers", | "Recommendation on Stable IPv6 Interface Identifiers", | |||
RFC 8064, DOI 10.17487/RFC8064, February 2017, | RFC 8064, DOI 10.17487/RFC8064, February 2017, | |||
<https://www.rfc-editor.org/info/rfc8064>. | <https://www.rfc-editor.org/info/rfc8064>. | |||
[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- | [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- | |||
Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, | Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, | |||
February 2017, <https://www.rfc-editor.org/info/rfc8065>. | February 2017, <https://www.rfc-editor.org/info/rfc8065>. | |||
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | ||||
Writing an IANA Considerations Section in RFCs", BCP 26, | ||||
RFC 8126, DOI 10.17487/RFC8126, June 2017, | ||||
<https://www.rfc-editor.org/info/rfc8126>. | ||||
[BACKBONE-ROUTER] | [BACKBONE-ROUTER] | |||
Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 | Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 | |||
Backbone Router", Work in Progress, Internet-Draft, draft- | Backbone Router", Work in Progress, Internet-Draft, draft- | |||
ietf-6lo-backbone-router-19, 3 March 2020, | ietf-6lo-backbone-router-20, 23 March 2020, | |||
<https://tools.ietf.org/html/draft-ietf-6lo-backbone- | <https://tools.ietf.org/html/draft-ietf-6lo-backbone- | |||
router-19>. | router-20>. | |||
[CURVE-REPRESENTATIONS] | [CURVE-REPR] | |||
Struik, R., "Alternative Elliptic Curve Representations", | Struik, R., "Alternative Elliptic Curve Representations", | |||
Work in Progress, Internet-Draft, draft-ietf-lwig-curve- | Work in Progress, Internet-Draft, draft-ietf-lwig-curve- | |||
representations-08, 24 July 2019, | representations-10, 23 April 2020, | |||
<https://tools.ietf.org/html/draft-ietf-lwig-curve- | <https://tools.ietf.org/html/draft-ietf-lwig-curve- | |||
representations-08>. | representations-10>. | |||
[breaking-ed25519] | [breaking-ed25519] | |||
Samwel, N., Batina, L., Bertoni, G., Daemen, J., and R. | Samwel, N., Batina, L., Bertoni, G., Daemen, J., and R. | |||
Susella, "Breaking Ed25519 in WolfSSL", Cryptographers' | Susella, "Breaking Ed25519 in WolfSSL", Cryptographers' | |||
Track at the RSA Conference , 2018, | Track at the RSA Conference , 2018, | |||
<https://link.springer.com/ | <https://link.springer.com/ | |||
chapter/10.1007/978-3-319-76953-0_1>. | chapter/10.1007/978-3-319-76953-0_1>. | |||
Appendix A. Requirements Addressed in this Document | Appendix A. Requirements Addressed in this Document | |||
skipping to change at page 29, line 8 ¶ | skipping to change at page 28, line 34 ¶ | |||
The signature scheme ECDSA256 corresponding to Crypto-Type 0 is | The signature scheme ECDSA256 corresponding to Crypto-Type 0 is | |||
ECDSA, as specified in [FIPS186-4], instantiated with the NIST prime | ECDSA, as specified in [FIPS186-4], instantiated with the NIST prime | |||
curve P-256, as specified in Appendix B of [FIPS186-4], and the hash | curve P-256, as specified in Appendix B of [FIPS186-4], and the hash | |||
function SHA-256, as specified in [RFC6234], where points of this | function SHA-256, as specified in [RFC6234], where points of this | |||
NIST curve are represented as points of a short-Weierstrass curve | NIST curve are represented as points of a short-Weierstrass curve | |||
(see [FIPS186-4]) and are encoded as octet strings in most- | (see [FIPS186-4]) and are encoded as octet strings in most- | |||
significant-bit first (msb) and most-significant-byte first (MSB) | significant-bit first (msb) and most-significant-byte first (MSB) | |||
order. The signature itself consists of two integers (r and s), | order. The signature itself consists of two integers (r and s), | |||
which are each encoded as fixed-size octet strings in most- | which are each encoded as fixed-size octet strings in most- | |||
significant-bit first and most-significant-byte first order. For | significant-bit first and most-significant-byte first order. For | |||
details on ECDSA, see [FIPS186-4]; for details on the integer | details on ECDSA, see [FIPS186-4]; for details on the encoding of | |||
encoding, see Appendix B.2. | public keys, see Appendix B.3; for details on the signature encoding, | |||
see Appendix B.2. | ||||
The signature scheme Ed25519 corresponding to Crypto-Type 1 is EdDSA, | The signature scheme Ed25519 corresponding to Crypto-Type 1 is EdDSA, | |||
as specified in [RFC8032], instantiated with the Montgomery curve | as specified in [RFC8032], instantiated with the Montgomery curve | |||
Curve25519, as specified in [RFC7748], and the hash function SHA-512, | Curve25519, as specified in [RFC7748], and the hash function SHA-512, | |||
as specified in [RFC6234], where points of this Montgomery curve are | as specified in [RFC6234], where points of this Montgomery curve are | |||
represented as points of the corresponding twisted Edwards curve (see | represented as points of the corresponding twisted Edwards curve | |||
Appendix B.3) and are encoded as octet strings in least-significant- | Edwards25519 (see Appendix B.4) and are encoded as octet strings in | |||
bit first (lsb) and least-significant-byte first (LSB) order. The | least-significant-bit first (lsb) and least-significant-byte first | |||
signature itself consists of a bit string that encodes a point of | (LSB) order. The signature itself consists of a bit string that | |||
this twisted Edwards curve, in compressed format, and an integer | encodes a point of this twisted Edwards curve, in compressed format, | |||
encoded in least-significant-bit first and least-significant-byte | and an integer encoded in least-significant-bit first and least- | |||
first order. For details on EdDSA and on the encoding conversions, | significant-byte first order. For details on EdDSA, the encoding of | |||
see the specification of pure Ed25519 in [RFC8032]. | public keys and that of signatures, see the specification of pure | |||
Ed25519 in [RFC8032]. | ||||
The signature scheme ECDSA25519 corresponding to Crypto-Type 2 is | The signature scheme ECDSA25519 corresponding to Crypto-Type 2 is | |||
ECDSA, as specified in [FIPS186-4], instantiated with the Montgomery | ECDSA, as specified in [FIPS186-4], instantiated with the Montgomery | |||
curve Curve25519, as specified in [RFC7748], and the hash function | curve Curve25519, as specified in [RFC7748], and the hash function | |||
SHA-256, as specified in [RFC6234], where points of this Montgomery | SHA-256, as specified in [RFC6234], where points of this Montgomery | |||
curve are represented as points of a corresponding curve in short- | curve are represented as points of the corresponding short- | |||
Weierstrass form (see Appendix B.3) and are encoded as octet strings | Weierstrass curve Wei25519 (see Appendix B.4) and are encoded as | |||
in most-significant-bit first and most-significant-byte first order. | octet strings in most-significant-bit first and most-significant-byte | |||
The signature itself consists of a bit string that encodes two | first order. The signature itself consists of a bit string that | |||
integers, each encoded as fixed-size octet strings in most- | encodes two integers, each encoded as fixed-size octet strings in | |||
significant-bit first and most-significant-byte first order. For | most-significant-bit first and most-significant-byte first order. | |||
details on ECDSA, see [FIPS186-4]; for details on the integer | For details on ECDSA, see [FIPS186-4]; for details on the encoding of | |||
encoding, see Appendix B.2 | public keys, see Appendix B.3; for details on the signature encoding, | |||
see Appendix B.2 | ||||
B.2. Integer Representation for ECDSA signatures | B.2. Representation of ECDSA Signatures | |||
With ECDSA, each signature is an ordered pair (r, s) of integers | With ECDSA, each signature is an ordered pair (r, s) of integers | |||
[FIPS186-4]. Each integer is encoded as a fixed-size 256-bit bit | [FIPS186-4], where each integer is represented as a 32-octet string | |||
string, where each integer is represented according to the Field | according to the Field Element to Octet String conversion rules in | |||
Element to Octet String and Octet String to Bit String conversion | [SEC1] and where the ordered pair of integers is represented as the | |||
rules in [SEC1] and where the ordered pair of integers is represented | rightconcatenation of these representation values (thereby resulting | |||
as the rightconcatenation of the resulting representation values. | in a 64-octet string). The inverse operation checks that the | |||
The inverse operation follows the corresponding Bit String to Octet | signature is a 64-octet string and represents the left-side and | |||
String and Octet String to Field Element conversion rules of [SEC1]. | right-side halves of this string (each a 32-octet string) as the | |||
integers r and s, respectively, using the Octet String to Field | ||||
Element conversion rules in [SEC1]. | ||||
B.3. Alternative Representations of Curve25519 | B.3. Representation of Public Keys Used with ECDSA | |||
ECDSA is specified to be used with elliptic curves in short- | ||||
Weierstrass form. Each point of such a curve is represented as an | ||||
octet string using the Elliptic Curve Point to Octet String | ||||
conversion rules in [SEC1], where point compression may be enabled | ||||
(which is indicated by the leftmost octet of this representation). | ||||
The inverse operation converts an octet string to a point of this | ||||
curve using the Octet String to Elliptic Curve Point conversion rules | ||||
in [SEC1], whereby the point is rejected if this is the so-called | ||||
point at infinity. (This is the case if the input to this inverse | ||||
operation is an octet string of length 1.) | ||||
B.4. Alternative Representations of Curve25519 | ||||
The elliptic curve Curve25519, as specified in [RFC7748], is a so- | The elliptic curve Curve25519, as specified in [RFC7748], is a so- | |||
called Montgomery curve. Each point of this curve can also be | called Montgomery curve. Each point of this curve can also be | |||
represented as a point of a twisted Edwards curve or as a point of an | represented as a point of a twisted Edwards curve or as a point of an | |||
elliptic curve in short-Weierstrass form, via a coordinate | elliptic curve in short-Weierstrass form, via a coordinate | |||
transformation (a so-called isomorphic mapping). The parameters of | transformation (a so-called isomorphic mapping). The parameters of | |||
the Montgomery curve and the corresponding isomorphic curves in | the Montgomery curve and the corresponding isomorphic curves in | |||
twisted Edwards curve and short-Weierstrass form are as indicated | twisted Edwards curve and short-Weierstrass form are as indicated | |||
below. Here, the domain parameters of the Montgomery curve | below. Here, the domain parameters of the Montgomery curve | |||
Curve25519 and of the twisted Edwards curve Edwards25519 are as | Curve25519 and of the twisted Edwards curve Edwards25519 are as | |||
specified in [RFC7748]; the domain parameters of the elliptic curve | specified in [RFC7748]; the domain parameters of the elliptic curve | |||
Wei25519 in short-Weierstrass curve comply with Section 6.1.1 of | Wei25519 in short-Weierstrass curve comply with Section 6.1.1 of | |||
[FIPS186-4]. For details of the coordinate transformations | [FIPS186-4]. For further details on these curves and on the | |||
referenced above, see [RFC7748] and [CURVE-REPRESENTATIONS]. | coordinate transformations referenced above, see [CURVE-REPR]. | |||
General parameters (for all curve models): | General parameters (for all curve models): | |||
p 2^{255}-19 | p 2^{255}-19 | |||
(=0x7fffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff | (=0x7fffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff | |||
ffffffed) | ffffffed) | |||
h 8 | h 8 | |||
n | n | |||
723700557733226221397318656304299424085711635937990760600195093828 | 723700557733226221397318656304299424085711635937990760600195093828 | |||
5454250989 | 5454250989 | |||
End of changes. 94 change blocks. | ||||
420 lines changed or deleted | 433 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |