< draft-ietf-6lo-ap-nd-13.txt   draft-ietf-6lo-ap-nd-14.txt >
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Updates: 8505 (if approved) B.S. Sarikaya Updates: 8505 (if approved) B.S. Sarikaya
Intended status: Standards Track Intended status: Standards Track
Expires: 9 July 2020 M.S. Sethi Expires: 3 August 2020 M.S. Sethi
Ericsson Ericsson
R.S. Struik R.S. Struik
Struik Security Consultancy Struik Security Consultancy
6 January 2020 31 January 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-13 draft-ietf-6lo-ap-nd-14
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 9 July 2020. This Internet-Draft will expire on 3 August 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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. References . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
3. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 5 3. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 5
4. New Fields and Options . . . . . . . . . . . . . . . . . . . 5 4. New Fields and Options . . . . . . . . . . . . . . . . . . . 5
4.1. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 6 4.1. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Updated EARO . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Updated EARO . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Crypto-ID Parameters Option . . . . . . . . . . . . . . . 7 4.3. Crypto-ID Parameters Option . . . . . . . . . . . . . . . 7
4.4. NDP Signature Option . . . . . . . . . . . . . . . . . . 8 4.4. NDP Signature Option . . . . . . . . . . . . . . . . . . 9
5. Protocol Scope . . . . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Scope . . . . . . . . . . . . . . . . . . . . . . . 10
6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 10 6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 11 6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 11
6.2. NDPSO generation and verification . . . . . . . . . . . . 13 6.2. NDPSO generation and verification . . . . . . . . . . . . 13
6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 14 6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 15 7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 16
7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 16 7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 17
7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 17 7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 17
7.4. Implementation Attacks . . . . . . . . . . . . . . . . . 17 7.4. Implementation Attacks . . . . . . . . . . . . . . . . . 17
7.5. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 17 7.5. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 18
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18
8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 17 8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 18
8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 18 8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 18
8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 18 8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. Normative References . . . . . . . . . . . . . . . . . . . . 19 10. Normative References . . . . . . . . . . . . . . . . . . . . 19
11. Informative references . . . . . . . . . . . . . . . . . . . 20 11. Informative references . . . . . . . . . . . . . . . . . . . 20
Appendix A. Requirements Addressed in this Document . . . . . . 22 Appendix A. Requirements Addressed in this Document . . . . . . 22
Appendix B. Representation Conventions . . . . . . . . . . . . . 23 Appendix B. Representation Conventions . . . . . . . . . . . . . 23
B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 23 B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 23
B.2. Integer Representation for ECDSA signatures . . . . . . . 24 B.2. Integer Representation for ECDSA signatures . . . . . . . 24
B.3. Alternative Representations of Curve25519 . . . . . . . . 24 B.3. Alternative Representations of Curve25519 . . . . . . . . 24
skipping to change at page 3, line 25 skipping to change at page 3, line 25
multicast compared to the Duplicate Address Detection (DAD) mechanism multicast compared to the Duplicate Address Detection (DAD) mechanism
defined in IPv6 ND. 6LoWPAN ND defines a new Address Registration defined in IPv6 ND. 6LoWPAN ND defines a new Address Registration
Option (ARO) that is carried in the unicast Neighbor Solicitation Option (ARO) that is carried in the unicast Neighbor Solicitation
(NS) and Neighbor Advertisement (NA) messages exchanged between a (NS) and Neighbor Advertisement (NA) messages exchanged between a
6LoWPAN Node (6LN) and a 6LoWPAN Router (6LR). It also defines the 6LoWPAN Node (6LN) and a 6LoWPAN Router (6LR). It also defines the
Duplicate Address Request (DAR) and Duplicate Address Confirmation Duplicate Address Request (DAR) and Duplicate Address Confirmation
(DAC) messages between the 6LR and the 6LoWPAN Border Router (6LBR). (DAC) messages between the 6LR and the 6LoWPAN Border Router (6LBR).
In LLN networks, the 6LBR is the central repository of all the In LLN networks, the 6LBR is the central repository of all the
registered addresses in its domain. registered addresses in its domain.
The registration mechanism in 6LoWPAN ND [RFC6775] prevents the use The registration mechanism in "Neighbor Discovery Optimization for
of an address if that address is already registered in the subnet Low-power and Lossy Networks" [RFC6775] (aka 6LoWPAN ND) prevents the
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). ROVR is defined in [RFC8505] Registration Ownership Verifier (ROVR). The ROVR is defined in
"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 the 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 allows to transport alternate forms of ROVRs, and is a
pre-requisite for this specification. pre-requisite for this specification.
skipping to change at page 4, line 27 skipping to change at page 4, line 31
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. References 2.2. References
Terms and concepts from the following documents are used in this The reader may get additional context for this specification from the
specification: following references:
* "Terms Used in Routing for Low-Power and Lossy Networks (LLNs)"
[RFC7102],
* "SEcure Neighbor Discovery (SEND)" [RFC3971], * "SEcure Neighbor Discovery (SEND)" [RFC3971],
* "Cryptographically Generated Addresses (CGA)" [RFC3972], * "Cryptographically Generated Addresses (CGA)" [RFC3972],
* "Neighbor Discovery for IP version 6" [RFC4861] , * "Neighbor Discovery for IP version 6" [RFC4861] ,
* "IPv6 Stateless Address Autoconfiguration" [RFC4862], * "IPv6 Stateless Address Autoconfiguration" [RFC4862], and
* "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): * "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals " [RFC4919], Overview, Assumptions, Problem Statement, and Goals " [RFC4919].
* "Neighbor Discovery Optimization for Low-power and Lossy Networks"
[RFC6775], and
* "Registration Extensions for 6LoWPAN Neighbor Discovery"
[RFC8505].
2.3. Abbreviations 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
6CIO: Capability Indication Option
ARO: Address Registration Option ARO: Address Registration Option
EARO: Extended Address Registration Option
CIPO: Crypto-ID Parameters Option CIPO: Crypto-ID Parameters Option
LLN: Low-Power and Lossy Network LLN: Low-Power and Lossy Network
NA: Neighbor Advertisement NA: Neighbor Advertisement
NCE: Neighbor Cache Entry NCE: Neighbor Cache Entry
ND: Neighbor Discovery ND: Neighbor Discovery
NDP: Neighbor Discovery Protocol NDP: Neighbor Discovery Protocol
NDPSO: NDP Signature Option NDPSO: NDP Signature Option
NS: Neighbor Solicitation NS: Neighbor Solicitation
ROVR: Registration Ownership Verifier ROVR: Registration Ownership Verifier
RPL: IPv6 Routing Protocol for LLNs RPL: Routing Protocol for LLNs
RA: Router Advertisement RA: Router Advertisement
RS: Router Solicitation RS: Router Solicitation
RSAO: RSA Signature Option RSAO: RSA Signature Option
TID: Transaction ID TID: Transaction ID
3. Updating RFC 8505 3. Updating RFC 8505
This specification introduces a new token called a cryptographic This specification introduces a new token called a cryptographic
identifier (Crypto-ID) that is used to prove indirectly the ownership identifier (Crypto-ID) that is used to prove indirectly the ownership
of an address that is being registered by means of [RFC8505]. The of an address that is being registered by means of [RFC8505]. The
Crypto-ID is derived from a cryptographic public key and additional Crypto-ID is derived from a cryptographic public key and additional
parameters. The proof requires the support of Elliptic Curve parameters. The proof requires the support of Elliptic Curve
Cryptography (ECC) and that of a hash function as detailed in Cryptography (ECC) and that of a hash function as detailed in
Section 6.2. To enable the verification of the proof, the Section 6.2. To enable the verification of the proof, the
registering node needs to supply certain parameters including a nonce registering node needs to supply certain parameters including a Nonce
and a signature that will demonstrate that the node has the private- and a signature that will demonstrate that the node has the private-
key corresponding to the public-key used to build the Crypto-ID. key corresponding to the public-key used to build the Crypto-ID.
The elliptic curves and the hash functions that can be used with this The elliptic curves and the hash functions that can be used with this
specification are listed in Table 2 in Section 8.3. The signature specification are listed in Table 2 in Section 8.3. The signature
scheme that specifies which combination is used is signaled by a scheme that specifies which combination is used is signaled by a
Crypto-Type in the CIPO (see Section 4.3). Crypto-Type in the CIPO (see Section 4.3).
The NS(EARO) is extended to transport a new Crypto-ID Parameters The NS(EARO) is extended to transport a new Crypto-ID Parameters
Option (CIPO, see Section 4.3) that contains the parameters that are Option (CIPO, see Section 4.3) that contains the parameters that are
skipping to change at page 6, line 45 skipping to change at page 6, line 38
|Rsvd |C| I |R|T| TID | Registration Lifetime | |Rsvd |C| I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... Registration Ownership Verifier (ROVR) ... ... Registration Ownership Verifier (ROVR) ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Enhanced Address Registration Option Figure 1: Enhanced Address Registration Option
Type: 33 Type: 33
Length: 8-bit unsigned integer. The length of the option (including Length: 8-bit unsigned integer. The length of the option (including
the type and length fields) in units of 8 bytes. the type and length fields) in units of 8 bytes.
Status: 8-bit unsigned integer. Indicates the status of a Status: 8-bit unsigned integer. Indicates the status of a
registration in the NA response. MUST be set to 0 in NS messages. registration in the NA response. In NS messages it MUST be set to
0 by the sender and ignored by the receiver.
Opaque: Defined in [RFC8505]. Opaque: Defined in [RFC8505].
Rsvd (Reserved): This field is unused. It MUST be initialized to Rsvd (Reserved): 3-bit unsigned integer. It MUST be set to zero by
zero by the sender and MUST be ignored by the receiver. the sender and MUST be ignored by the receiver.
C: This "C" flag is set to indicate that the ROVR field contains a C: This "C" flag is set to indicate that the ROVR field contains a
Crypto-ID and that the 6LN MAY be challenged for ownership as Crypto-ID and that the 6LN MAY be challenged for ownership as
specified in this document. specified in this document.
I, R, T, and TID: Defined in [RFC8505]. I, R, T, and TID: Defined in [RFC8505].
Registration Ownership Verifier (ROVR): When the "C" flag is set, Registration Ownership Verifier (ROVR): When the "C" flag is set,
this field contains a Crypto-ID. this field contains a Crypto-ID.
This specification uses Status values "Validation Requested" and This specification uses Status values "Validation Requested" and
"Validation Failed", which are defined in [RFC8505]. No other new "Validation Failed", which are defined in [RFC8505]. No other new
Status values are defined. Status values are defined.
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).
It carries the parameters used to form a Crypto-ID. In order to It carries the parameters used to form a Crypto-ID. In order to
provide cryptographic agility [RFC7696], this specification supports provide cryptographic agility [RFC7696], this specification supports
different elliptic curves, indicated by a Crypto-Type field. NIST different elliptic curves, indicated by a Crypto-Type field. NIST
P-256 [FIPS186-4] MUST be supported by all implementations. The P-256 [FIPS186-4] MUST be supported by all implementations. The
Edwards-Curve Digital Signature Algorithm (EdDSA) curve Ed25519 Edwards-Curve Digital Signature Algorithm (EdDSA) curve Ed25519
(PureEdDSA) [RFC8032] MAY be supported as an alternate. (PureEdDSA) [RFC8032] MAY be supported as an alternate.
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 | Pad Length | Reserved | | Type | Length |Reserved1| Public Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crypto-Type | Modifier | Reserved | | Crypto-Type | Modifier | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
. . . .
. Public Key (variable length) . . Public Key (variable length) .
. . . .
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Padding . . Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Crypto-ID Parameters Option Figure 2: Crypto-ID Parameters Option
Type: 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.
Pad Length: 8-bit unsigned integer. The length of the Padding
field. Reserved1: 5-bit unsigned integer. It MUST be set to zero by the
Reserved: This field is unused. It MUST be initialized to zero by sender and MUST be ignored by the receiver.
the sender and MUST be ignored by the receiver.
Crypto-Type: The type of cryptographic algorithm used in calculation Public Key Length: 13-bit unsigned integer. The length of the
Crypto-ID (see Table 2 in Section 8.3). Although the different Public Key field in bytes.
signature schemes target similar cryptographic strength, they rely
on different curves, hash functions, signature algorithms, and/or Crypto-Type: 8-bit unsigned integer. The type of cryptographic
representation conventions. algorithm used in calculation Crypto-ID (see Table 2 in
Section 8.3). Although the different signature schemes target
similar cryptographic strength, they rely on different curves,
hash functions, signature algorithms, and/or representation
conventions.
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.
Public Key: JWK-Encoded Public Key [RFC7517].
Padding: A variable-length field making the option length a multiple Reserved2: 16-bit unsigned integer. It MUST be set to zero by the
of 8, containing as many octets as specified in the Pad Length sender and MUST be ignored by the receiver.
field.
Public Key: A variable-length field, size indicated in the Public
Key Length field. JWK-Encoded Public Key [RFC7517].
Padding: A variable-length field completing the Public Key field to
align to the next 8-bytes boundary.
The implementation of multiple hash functions in a constrained The implementation of multiple hash functions in a constrained
devices may consume excessive amounts of program memory. devices may consume excessive amounts of program memory.
[I-D.ietf-lwig-curve-representations] provides information on how to [CURVE-REPRESENTATIONS] provides information on how to represent
represent Montgomery curves and (twisted) Edwards curves as curves in Montgomery curves and (twisted) Edwards curves as curves in short-
short-Weierstrass form and illustrates how this can be used to Weierstrass form and illustrates how this can be used to implement
implement elliptic curve computations using existing implementations elliptic curve computations using existing implementations that
that already provide, e.g., ECDSA and ECDH using NIST [FIPS186-4] already provide, e.g., ECDSA and ECDH using NIST [FIPS186-4] prime
prime curves. curves.
For more details on representation conventions, we refer to For more details on representation conventions, we refer to
Appendix B. Appendix B.
4.4. NDP Signature Option 4.4. NDP Signature Option
The format of the NDP Signature Option (NDPSO) is illustrated in The format of the NDP Signature Option (NDPSO) is illustrated in
Figure 3. 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. The of SEND [RFC3971], the NDPSO does not have a key hash field. The
hash that can be used as index is the 128 leftmost bits of the ROVR hash that can be used as index is the 128 leftmost bits of the ROVR
field in the EARO. The CIPO may be present in the same message as field in the EARO. The CIPO may be present in the same message as
the NDPSO. If not, it an be found in an abstract table that was the NDPSO. If not, it an be found in an abstract table that was
created by a previous message and indexed by the hash. created by a previous message and indexed by the hash.
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 | Pad Length | Reserved | | Type | Length | Pad Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
. . . .
. Digital Signature . . Digital Signature .
. . . .
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 9, line 30 skipping to change at page 9, line 42
| | | |
. . . .
. Padding . . Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NDP signature Option Figure 3: NDP signature Option
Type: to be assigned by IANA, see Table 1. Type: 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.
Pad Length: 8-bit unsigned integer. The length of the Padding Pad Length: 8-bit unsigned integer. The length of the Padding
field. field.
Reserved: 40-bit unsigned integer. It MUST be set to zero by the
sender and MUST be ignored by the receiver.
Digital Signature: A variable-length field containing a digital Digital Signature: A variable-length field containing a digital
signature. The computation of the digital signature depends on signature. The computation of the digital signature depends on
the Crypto-Type which is found in the associated CIPO. For the the Crypto-Type which is found in the associated CIPO. For the
values of the Crypto-Type that are defined in ths specification, values of the Crypto-Type that are defined in ths specification,
the signature is computed as detailed in Section 6.2. the signature is computed as detailed in Section 6.2.
Padding: A variable-length field making the option length a multiple Padding: A variable-length field making the option length a multiple
of 8, containing as many octets as specified in the Pad Length of 8, containing as many octets as specified in the Pad Length
field. Typically there is no need of a padding and the field is field. Typically there is no need of a padding and the field is
NULL. NULL.
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
skipping to change at page 11, line 6 skipping to change at page 11, line 23
node becomes the owner of the registered address and the address is node becomes the owner of the registered address and the address is
bound to the Crypto-ID in the 6LR/6LBR registry. bound to the Crypto-ID in the 6LR/6LBR registry.
This specification enables the 6LR to verify the ownership of the This specification enables the 6LR to verify the ownership of the
binding at any time assuming that the "C" flag is set. The binding at any time assuming that the "C" flag is set. The
verification prevents other nodes from stealing the address and verification prevents other nodes from stealing the address and
trying to attract traffic for that address or use it as their source trying to attract traffic for that address or use it as their source
address. address.
A node may use multiple IPv6 addresses at the same time. The node A node may use multiple IPv6 addresses at the same time. The node
may use a same Crypto-ID, to prove the ownership of multiple IPv6 may use the same Crypto-ID, to prove the ownership of multiple IPv6
addresses. The separation of the address and the cryptographic addresses. The separation of the address and the cryptographic
material avoids the constrained device to compute multiple keys for material avoids the constrained device to compute multiple keys for
multiple addresses. The registration process allows the node to use multiple addresses. The registration process allows the node to use
the same Crypto-ID for all of its addresses. the same Crypto-ID for all of its addresses.
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. The on-link (local) address that the 6LN is trying to register. The on-link (local)
protocol interactions are shown in Figure 5. If the 6LR does not protocol interactions are shown in Figure 5. If the 6LR does not
have a state with the 6LN that is consistent with the NS(EARO), then have a state with the 6LN that is consistent with the NS(EARO), then
it replies with a challenge NA (EARO, status=Validation Requested) it replies with a challenge NA (EARO, status=Validation Requested)
that contains a Nonce Option (shown as NonceLR in Figure 5). The that contains a Nonce Option (shown as NonceLR in Figure 5). The
Nonce option MUST contain a random Nonce value that was never used Nonce option contains a Nonce value that, to the extent possible for
with this device. the implementation, was never employed in association with the key
pair used to generate the ROVR. This specification inherits from
[RFC3971] that simply indicates that the nonce is a random value.
Ideally, an implementation would use an unpredictable
cryptographically random value [RFC4086]. 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 Nonce value or as a component to its
computation.
The 6LN replies to the challenge with an NS(EARO) that includes a new 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), Nonce option (shown as NonceLN in Figure 5), the CIPO (Section 4.3),
and the NDPSO containing the signature. The information associated and the NDPSO containing the signature. The information associated
to a Crypto-ID stored by the 6LR on the first NS exchange where it to a Crypto-ID stored by the 6LR on the first NS exchange where it
appears. The 6LR MUST store the CIPO parameters associated with the appears. The 6LR MUST store the CIPO parameters associated with the
Crypto-ID so it can be used for more than one address. Crypto-ID so it can be used for more than one address.
6LN 6LR 6LN 6LR
| | | |
skipping to change at page 13, line 10 skipping to change at page 13, line 19
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) that contains all the necessary material for (Section 4.3) that contains all the necessary material for
building the Crypto-ID, the NonceLN that it generated, and the NDP building the Crypto-ID, the NonceLN that it generated, and the NDP
signature (Section 4.4) option that proves its ownership of the signature (Section 4.4) option that proves its ownership of the
Crypto-ID and intent of registering the Target Address. In Crypto-ID and intent of registering the Target Address. In
subsequent revalidation with the same 6LR, the 6LN MAY try to omit subsequent revalidation with the same 6LR, the 6LN MAY try to omit
the CIPO to save bandwidth, with the expectation that the 6LR the CIPO to save bandwidth, with the expectation that the 6LR
saved it. If the validation fails and it gets challenged again, saved it. If the validation fails and 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 as the 6LN and rebuilds the Crypto-ID based on the steps as the 6LN and rebuilds the Crypto-ID based on the
parameters in the CIPO. If the rebuilt Crypto-ID matches the parameters in the CIPO. If the rebuilt Crypto-ID matches the
ROVR, the 6LN also verifies the signature contained in the NDPSO ROVR, the 6LN also verifies the signature contained in the NDPSO
option. If at that point the signature in the NDPSO option can be option. If at that point the signature in the NDPSO option can be
verified, then the validation succeeds. Otherwise the validation verified, then the 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 status of "Validation Failed". After receiving a NA(EARO) with a status of "Validation Failed". After receiving a NA(EARO) with
a status of "Validation Failed", the registering node SHOULD try a status of "Validation Failed", the registering node SHOULD try
to register an alternate target address in the NS message. to register an alternate target 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.3) chosen by the 6LN as follows:
Concatenate the following in the order listed: * Concatenate the following in the order listed:
1. The 128-bit Message Type tag [RFC3972] (in network byte order). 1. The 128-bit Message Type tag [RFC3972] (in network byte order).
For this specification the tag is 0x8701 55c8 0cca dd32 6ab7 e415 For this specification the tag is 0x8701 55c8 0cca dd32 6ab7 e415
f148 84d0. (The tag value has been generated by the editor of f148 84d0. (The tag value has been generated by the editor of
this specification on random.org). this specification on random.org).
2. JWK-encoded public key 2. JWK-encoded public key
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 the Neighbor Solicitation (NS) message. It is the address which the
6LN is registering with the 6LR and 6LBR. 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 random nonce is at Neighbor Advertisement (NA) message. The Nonce is at least 6
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 random 5. NonceLN sent from the 6LN (in network byte order). The Nonce is
nonce is at least 6 bytes long as defined in [RFC3971]. at least 6 bytes long as defined in [RFC3971].
6. The length of the ROVR field in the NS message containing the 6. The length of the ROVR field in the NS message containing the
Crypto-ID that was sent. Crypto-ID that was sent.
7. 1-byte (in network byte order) Crypto-Type value sent in the CIPO 7. 1-byte (in network byte order) Crypto-Type value sent in the CIPO
option. option.
Depending on the Crypto-Type, apply the hash function on this * Depending on the Crypto-Type, apply the hash function on this
concatenation. concatenation.
Depending on the Crypto-Type, sign the hash output with ECDSA (if * Depending on the Crypto-Type, sign the hash output with ECDSA (if
curve P-256 is used) or sign the hash with EdDSA (if curve Ed25519 curve P-256 is used) or sign the hash with EdDSA (if curve Ed25519
(PureEdDSA)). (PureEdDSA)).
The 6LR on receiving the NDPSO and CIPO options first regenerates the The 6LR on receiving the NDPSO and CIPO options first regenerates the
Crypto-ID based on the CIPO option to make sure that the leftmost Crypto-ID based on the CIPO option to make sure that the leftmost
bits up to the size of the ROVR match. If and only if the check is bits up to the size of the ROVR match. If and only if the check is
successful, it tries to verify the signature in the NDPSO option successful, it tries to verify the signature in the NDPSO option
using the following. using the following:
Concatenate the following in the order listed: * Concatenate the following in the order listed:
1. 128-bit type tag (in network byte order) 1. 128-bit type tag (in network byte order)
2. JWK-encoded public key received in the CIPO option 2. JWK-encoded public key received in the CIPO option
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 which the 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 sent in the Neighbor Advertisement (NA) message. The 4. NonceLR sent in the Neighbor Advertisement (NA) message. The
random 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 NS 5. NonceLN received from the 6LN (in network byte order) in the NS
message. The random nonce is at least 6 bytes long as defined in message. The Nonce is at least 6 bytes long as defined in
[RFC3971]. [RFC3971].
6. The length of the ROVR field in the NS message containing the 6. The length of the ROVR field in the NS message containing the
Crypto-ID that was received. Crypto-ID that was received.
7. 1-byte (in network byte order) Crypto-Type value received in the 7. 1-byte (in network byte order) Crypto-Type value received in the
CIPO option. CIPO option.
Depending on the Crypto-Type indicated by the (6LN) in the CIPO, * Depending on the Crypto-Type indicated by the (6LN) in the CIPO,
apply the hash function on this concatenation. apply the hash function on this concatenation.
Verify the signature with the public-key received and the locally * Verify the signature with the public-key received and the locally
computed values. If the verification succeeds, the 6LR and 6LBR add computed values. If the verification succeeds, the 6LR and 6LBR
the state information about the Crypto-ID, public-key and Target add the state information about the Crypto-ID, public-key and
Address being registered to their database. Target Address being registered to their database.
6.3. Multihop Operation 6.3. Multihop Operation
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 described in this section. If the 6LR and the 6LBR to 6LBR as described in this section. If the 6LR and the 6LBR
maintain a security association, then there is no need to propagate maintain a security association, then there is no need to propagate
the proof of ownership to the 6LBR. the proof of ownership to the 6LBR.
A new device that joins the network auto-configures an address and A new device 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].
The 6LR validates the address with an 6LBR using a DAR/DAC exchange, The 6LR validates the address with an 6LBR using a DAR/DAC exchange,
and the 6LR confirms (or denies) the address ownership with an NA and the 6LR confirms (or denies) the address ownership with an NA
message that also carries an Address Registration Option. message that also carries an Address Registration Option.
Figure 6 illustrates a registration flow all the way to a 6LowPAN Figure 6 illustrates a registration flow all the way to a 6LowPAN
Backbone Router (6BBR) [6BBR]. Backbone Router (6BBR) [BACKBONE-ROUTER].
6LN 6LR 6LBR 6BBR 6LN 6LR 6LBR 6BBR
| | | | | | | |
| NS(EARO) | | | | NS(EARO) | | |
|--------------->| | | |--------------->| | |
| | Extended DAR | | | | Extended DAR | |
| |-------------->| | | |-------------->| |
| | | | | | | |
| | | proxy NS(EARO) | | | | proxy NS(EARO) |
| | |--------------->| | | |--------------->|
skipping to change at page 16, line 5 skipping to change at page 16, line 18
address (EUI-64) to defend it, if there is an attacker on another address (EUI-64) to defend it, if there is an attacker on another
6LR. 6LR.
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)
messages by requiring that the NDP Signature and CIPO options be messages by requiring that the NDP Signature and CIPO options be
present in these solicitations. present in these solicitations.
Duplicate Address Detection DoS Attack Inside the LLN, Duplicate
Duplicate Address Detection DoS Attack: Inside the LLN, Duplicate
Addresses are sorted out using the ROVR, which differentiates it Addresses are sorted out using the ROVR, which differentiates it
from a movement. DAD coming from the backbone are not forwarded from a movement. DAD coming from the backbone are not forwarded
over the LLN, which provides some protection against DoS attacks over the LLN, which provides some protection against DoS attacks
inside the resource-constrained part of the network. Over the inside the resource-constrained part of the network. Over the
backbone, the EARO option is present in NS/NA messages. This backbone, the EARO option is present in NS/NA messages. This
protects against misinterpreting a movement for a duplication, and protects against misinterpreting a movement for a duplication, and
enables the backbone routers to determine which one has the enables the backbone routers to determine which one has the
freshest registration and is thus the best candidate to validate freshest registration and is thus the best candidate to validate
the registration for the device attached to it. But this the registration for the device attached to it. But this
specification does not guarantee that the backbone router claiming specification does not guarantee that the backbone router claiming
an address over the backbone is not an attacker. an address over the backbone is not an attacker.
Router Solicitation and Advertisement Attacks This specification
Router Solicitation and Advertisement Attacks: This specification
does not change the protection of RS and RA which can still be does not change the protection of RS and RA which can still be
protected by SEND. protected by SEND.
Replay Attacks Nonces (NonceLR and NonceLN) generated by the 6LR and Replay Attacks Nonces (NonceLR and NonceLN) generated by the 6LR and
6LN guarantees against replay attacks of the NS(EARO). 6LN guarantees against replay attacks of the NS(EARO).
Neighbor Discovery DoS Attack A rogue node that managed to access
Neighbor Discovery DoS Attack: A rogue node that managed to access
the L2 network may form many addresses and register them using AP- the L2 network may form many addresses and register them using AP-
ND. The perimeter of the attack is all the 6LRs in range of the ND. The perimeter of the attack is all the 6LRs in range of the
attacker. The 6LR MUST protect itself against overflows and attacker. The 6LR MUST protect itself against overflows and
reject excessive registration with a status 2 "Neighbor Cache reject excessive registration with a status 2 "Neighbor Cache
Full". This effectively blocks another (honest) 6LN from Full". This effectively blocks another (honest) 6LN from
registering to the same 6LR, but the 6LN may register to other registering to the same 6LR, but the 6LN may register to other
6LRs that are in its range but not in that of the rogue. 6LRs that are in its range but not in that of the rogue.
7.2. Related to 6LoWPAN ND 7.2. Related to 6LoWPAN ND
skipping to change at page 19, line 33 skipping to change at page 19, line 33
| Defining | This document | This | This document | | Defining | This document | This | This document |
| specification | | document | | | specification | | document | |
+----------------+-----------------+-------------+-----------------+ +----------------+-----------------+-------------+-----------------+
Table 2: Crypto-Types Table 2: Crypto-Types
New Crypto-Type values providing similar or better security (with New Crypto-Type values providing similar or better security (with
less code) may be defined in the future. less code) may be 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 "Specification Required" and "IESG Approval" as defined in IANA with either "Specification Required" or "IESG Approval" as
[RFC8126]. defined in [RFC8126].
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 for his comments that led to many improvements. to Robert Moskowitz for his comments that led to many improvements.
The authors wish to thank Vijay Gurbani, Al Morton and Adam Montville The authors wish to thank Eric Vyncke, Vijay Gurbani, Al Morton and
for their reviews during the IESG process. Adam Montville for their constructive 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>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[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, [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015, DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>. <https://www.rfc-editor.org/info/rfc7517>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/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>.
[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>.
[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
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[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>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
skipping to change at page 21, line 30 skipping to change at page 21, line 32
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 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs): over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007, RFC 4919, DOI 10.17487/RFC4919, August 2007,
<https://www.rfc-editor.org/info/rfc4919>. <https://www.rfc-editor.org/info/rfc4919>.
[RFC4086] 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 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>.
[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>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm [RFC7696] 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>.
[6BBR] Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 [BACKBONE-ROUTER]
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-13, 26 September 2019, ietf-6lo-backbone-router-13, 26 September 2019,
<https://tools.ietf.org/html/draft-ietf-6lo-backbone- <https://tools.ietf.org/html/draft-ietf-6lo-backbone-
router-13>. router-13>.
[I-D.ietf-lwig-curve-representations] [CURVE-REPRESENTATIONS]
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-08, 24 July 2019,
<https://tools.ietf.org/html/draft-ietf-lwig-curve- <https://tools.ietf.org/html/draft-ietf-lwig-curve-
representations-08>. representations-08>.
[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,
skipping to change at page 24, line 36 skipping to change at page 24, line 40
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 transformation referenced [FIPS186-4]. For details of the coordinate transformation referenced
above, see [RFC7748] and [I-D.ietf-lwig-curve-representations]. above, see [RFC7748] and [CURVE-REPRESENTATIONS].
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. 66 change blocks. 
117 lines changed or deleted 159 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/