< draft-ietf-6lo-ap-nd-15.txt   draft-ietf-6lo-ap-nd-16.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: 3 August 2020 M.S. Sethi Expires: 6 August 2020 M.S. Sethi
Ericsson Ericsson
R.S. Struik R.S. Struik
Struik Security Consultancy Struik Security Consultancy
31 January 2020 3 February 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-15 draft-ietf-6lo-ap-nd-16
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 3 August 2020. This Internet-Draft will expire on 6 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 36 skipping to change at page 2, line 36
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 . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Crypto-ID Parameters Option . . . . . . . . . . . . . . . 7 4.3. Crypto-ID Parameters Option . . . . . . . . . . . . . . . 7
4.4. NDP Signature Option . . . . . . . . . . . . . . . . . . 9 4.4. NDP Signature Option . . . . . . . . . . . . . . . . . . 9
5. Protocol Scope . . . . . . . . . . . . . . . . . . . . . . . 11 5. Protocol Scope . . . . . . . . . . . . . . . . . . . . . . . 11
6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 11 6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 12 6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 12
6.2. NDPSO generation and verification . . . . . . . . . . . . 14 6.2. NDPSO generation and verification . . . . . . . . . . . . 14
6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 15 6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 17 7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 17
7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 18 7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 18
7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 18 7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 18
7.4. Implementation Attacks . . . . . . . . . . . . . . . . . 18 7.4. Implementation Attacks . . . . . . . . . . . . . . . . . 19
7.5. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 19 7.5. Cross-Algorithm and Cross-Protocol Attacks . . . . . . . 19
7.6. Compromised 6LR . . . . . . . . . . . . . . . . . . . . . 19 7.6. Compromised 6LR . . . . . . . . . . . . . . . . . . . . . 19
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20
8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 19 8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 20
8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 19 8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 20
8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 20 8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. Normative References . . . . . . . . . . . . . . . . . . . . 21 10. Normative References . . . . . . . . . . . . . . . . . . . . 21
11. Informative references . . . . . . . . . . . . . . . . . . . 22 11. Informative references . . . . . . . . . . . . . . . . . . . 23
Appendix A. Requirements Addressed in this Document . . . . . . 24 Appendix A. Requirements Addressed in this Document . . . . . . 24
Appendix B. Representation Conventions . . . . . . . . . . . . . 24 Appendix B. Representation Conventions . . . . . . . . . . . . . 25
B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 24 B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 25
B.2. Integer Representation for ECDSA signatures . . . . . . . 25 B.2. Integer Representation for ECDSA signatures . . . . . . . 26
B.3. Alternative Representations of Curve25519 . . . . . . . . 25 B.3. Alternative Representations of Curve25519 . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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
defined in IPv6 ND. 6LoWPAN ND defines a new Address Registration defined in IPv6 ND. 6LoWPAN ND defines a new Address Registration
skipping to change at page 4, line 6 skipping to change at page 4, line 6
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
enables Source Address Validation (SAVI) [RFC7039]. This ensures provides the same conceptual benefit as Source Address Validation
that only the actual owner uses a registered address in the IPv6 (SAVI) [RFC7039] that only the owner of an IPv6 address may source
source address field. A 6LN can only use a 6LR for forwarding packets with that address. As opposed to [RFC7039], which relies on
packets only if it has previously registered the address used in the snooping protocols, the protection is based on a state that is
source field of the IPv6 packet. installed and maintained in the network by the owner of the address.
With this specification, a 6LN may use a 6LR for forwarding an IPv6
packets if and only if it has registered the address used as source
of the packet with that 6LR.
The 6lo adaptation layer in [RFC4944] and [RFC6282] requires a device The 6lo adaptation layer in [RFC4944] and [RFC6282] requires a device
to form its IPv6 addresses based on its Layer-2 address to enable a to form its IPv6 addresses based on its Layer-2 address to enable a
better compression. This is incompatible with Secure Neighbor better compression. As a side note, this is incompatible with Secure
Discovery (SeND) [RFC3971] and Cryptographically Generated Addresses Neighbor Discovery (SeND) [RFC3971] and Cryptographically Generated
(CGAs) [RFC3972], since they derive the Interface ID (IID) in IPv6 Addresses (CGAs) [RFC3972], since they derive the Interface ID (IID)
addresses with cryptographic keys. in IPv6 addresses from cryptographic keys.
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. 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
ARO: Address Registration Option
EARO: Extended 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
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
RA: Router Advertisement RA: Router Advertisement
skipping to change at page 5, line 38 skipping to change at page 5, line 38
[RFC8505] was designed in preparation for this specification, which [RFC8505] was designed in preparation for this specification, which
is the RECOMMENDED method for building a ROVR field. is the RECOMMENDED method for building a ROVR field.
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 proof requires the support of Elliptic Curve Cryptography (ECC) The overall mechanism requires the support of Elliptic Curve
and that of a hash function as detailed in Section 6.2. To enable Cryptography (ECC) and of a hash function as detailed in Section 6.2.
the verification of the proof, the registering node needs to supply To enable the verification of the proof, the registering node needs
certain parameters including a Nonce and a signature that will to supply certain parameters including a Nonce and a signature that
demonstrate that the node has the private-key corresponding to the will demonstrate that the node possesses the private-key
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 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 a new IPv6 ND Crypto-ID Parameters Option (CIPO, see Crypto-Type (values to be confirmed by IANA) in a new IPv6 ND Crypto-
Section 4.3) that contains the parameters that are necessary for the ID Parameters Option (CIPO, see Section 4.3) that contains the
proof, a Nonce option ([RFC3971]) and a NDP Signature option parameters that are necessary for the proof, a Nonce option
(Section 4.4). The NA(EARO) is modified to enable a challenge and ([RFC3971]) and a NDP Signature option (Section 4.4). The NA(EARO)
transport a Nonce option as well. is modified to enable a challenge and transport a Nonce option.
4. New Fields and Options 4. New Fields and Options
4.1. New Crypto-ID 4.1. New Crypto-ID
The Crypto-ID is transported in the ROVR field of the EARO option and The Crypto-ID is transported in the ROVR field of the EARO option and
the EDAR message, and is associated with the Registered Address at the EDAR message, and is associated with the Registered Address at
the 6LR and the 6LBR. The ownership of a Crypto-ID can be the 6LR and the 6LBR. The ownership of a Crypto-ID can be
demonstrated by cryptographic mechanisms, and by association, the demonstrated by cryptographic mechanisms, and by association, the
ownership of the Registered Address can be acertained. ownership of the Registered Address can be acertained.
skipping to change at page 6, line 26 skipping to change at page 6, line 26
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 indicated by the Crypto-Type is applied to the
CIPO. Note that all the reserved and padding bits MUST be set to CIPO. Note that all the reserved and padding bits MUST be set to
zero. zero.
2. The leftmost bits of the resulting hash, up to the size of the 2. The leftmost bits of the resulting hash, up to the desired size,
ROVR field, 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
bits is RECOMMENDED. 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
ROVR field to transport the Crypto-ID. ROVR field to transport the Crypto-ID.
The resulting format is as follows: The resulting format is as follows:
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
skipping to change at page 7, line 7 skipping to change at page 7, line 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... 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: Defined in [RFC8505].
the type and length fields) in units of 8 bytes.
Status: 8-bit unsigned integer. Indicates the status of a Status: Defined in [RFC8505].
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): 3-bit unsigned integer. It MUST be set to zero by Rsvd (Reserved): 3-bit unsigned integer. It MUST be set to 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: Defined in [RFC8505].
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].
Status values are defined.
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 [RFC7696], this In order to provide cryptographic agility [RFC7696], this
specification supports different elliptic curves, indicated by a specification supports different elliptic curves, indicated by a
Crypto-Type field: Crypto-Type field:
* NIST P-256 [FIPS186-4] MUST be supported by all implementations. * NIST P-256 [FIPS186-4] MUST be supported by all implementations.
* The Edwards-Curve Digital Signature Algorithm (EdDSA) curve * The Edwards-Curve Digital Signature Algorithm (EdDSA) curve
Ed25519 (PureEdDSA) [RFC8032] MAY be supported as an alternate. Ed25519 (PureEdDSA) [RFC8032] MAY be supported as an alternate.
* the specification is open to future extensions for different * This specification uses signature schemes which target similar
cryptographic algorithms and longer keys. cryptographic strength but rely on different curves, hash
functions, signature algorithms, and/or representation
conventions. Future specification may extend this for different
cryptographic algorithms and longer keys, e.g., to provide a
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 | Reserved2 | | Crypto-Type | Modifier | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
skipping to change at page 8, line 37 skipping to change at page 8, line 37
Figure 2: Crypto-ID Parameters Option Figure 2: Crypto-ID Parameters Option
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: 13-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.
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 (see Table 2 in algorithm used in calculation Crypto-ID (see Table 2 in
Section 8.3). Although the different signature schemes target Section 8.3).
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.
Reserved2: 16-bit unsigned integer. It MUST be set to zero by the Reserved2: 16-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. JWK-Encoded Public Key [RFC7517].
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. align to the next 8-bytes boundary. It MUST be set to zero by the
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
devices may consume excessive amounts of program memory. devices may consume excessive amounts of program memory. This
specification enables the use of SHA-256 [RFC6234] for all the
supported ECC curves.
[CURVE-REPRESENTATIONS] provides information on how to represent Some code factorization is also possible for the ECC computation
Montgomery curves and (twisted) Edwards curves as curves in short- itself. [CURVE-REPRESENTATIONS] provides information on how to
Weierstrass form and illustrates how this can be used to implement represent Montgomery curves and (twisted) Edwards curves as curves in
elliptic curve computations using existing implementations that short-Weierstrass form and illustrates how this can be used to
already provide, e.g., ECDSA and ECDH using NIST [FIPS186-4] prime implement elliptic curve computations using existing implementations
curves. that already provide, e.g., ECDSA and ECDH using NIST [FIPS186-4]
prime 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
This specification defines the NDP Signature Option (NDPSO). The
NDPSO carries the signature that proves the ownership of the Crypto-
ID.
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.
hash that can be used as index is the 128 leftmost bits of the ROVR Instead, the leftmost 128 bits of the ROVR field in the EARO are used
field in the EARO. to retrieve the CIPO that contains the key material used for
signature verification, left-padded if needed.
Another difference is that the NDPSO signs a fixed set of fields as
opposed to all options that appear prior to it in the that bears the
signature. This allows to elide a CIPO that the 6LR already
received, at the expense of the capability to add arbitrary options
that would signed with a RSAO.
The CIPO may be present in the same message as the NDPSO. If not, it The CIPO may be present in the same message as the NDPSO. If not, it
can be found in an abstract table that was created by a previous can be found in an abstract table that was created by a previous
message and indexed by the hash. 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 | | | Type | Length |Reserved1| Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
. . . .
. Digital Signature . . Digital Signature .
. . . .
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 10, line 34 skipping to change at page 10, line 34
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Reserved1: 5-bit unsigned integer. It MUST be set to zero by the
field. sender and MUST be ignored by the receiver.
Reserved: 40-bit unsigned integer. It MUST be set to zero by the Digital Signature Length: 11-bit unsigned integer. The length of
the Digital Signature field in bytes.
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 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 this 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 completing the Digital Signature
of 8, containing as many octets as specified in the Pad Length field to align to the next 8-bytes boundary. It MUST be set to
field. Typically there is no need of a padding and the field is zero by the sender and MUST be ignored by the receiver.
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
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
skipping to change at page 11, line 45 skipping to change at page 11, line 45
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. This specification mandates that a chain of trust is
established so that a packet that was validated by the first 6LR can established so that a packet that was validated by the first 6LR can
be safely routed by other on-path 6LRs to the 6LBR. 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 EARO The 6LR/6LBR ensures first-come/first-serve by storing the ROVR
information including the Crypto-ID associated to the node being associated to the address being registered upon the first
registered. The node can claim any address as long as it is the registration and rejecting a registration with a different ROVR
first to make such a claim. After a successful registration, the value. A 6LN can claim any address as long as it is the first to
node becomes the owner of the registered address and the address is make that claim. After a successful registration, the 6LN becomes
bound to the Crypto-ID in the 6LR/6LBR registry. the owner of the registered address and the address is bound to the
ROVR value in the 6LR/6LBR registry.
This specification enables the 6LR to verify the ownership of the This specification enables the 6LR to challenge the 6LN to verify its
binding at any time assuming that the "C" flag is set. The ownership of the binding by placing a Crypto-ID in the ROVR. The
verification prevents other nodes from stealing the address and challenge can happen at any time at the discretion of the 6LR. The
trying to attract traffic for that address or use it as their source 6LR MUST challenge the 6LN when it creates a binding and when a new
address. registration attempts to change a parameter of the binding that
identifies the 6LN, for instance its Source Link-Layer Address. The
verification protects against a rogue that would steal an address and
attract its traffic, or use it as source address.
A node may use multiple IPv6 addresses at the same time. The node The challenge can also triggered by the 6LBR, e.g., to enforce a
MAY use the same Crypto-ID, to prove the ownership of multiple IPv6 global policy. In that case, the 6LBR returns a status of
addresses. The separation of the address and the cryptographic "Validation Requested" in the DAR/DAC exchange, which is echoed by
material avoids the constrained device to compute multiple keys for the 6LR in the NA (EARO) back to the registering node. A valid
multiple addresses. The registration process allows the node to use registration in the 6LR or the 6LBR MUST NOT be altered until the
the same Crypto-ID for all of its addresses. challenge is complete.
A node may use more than one IPv6 address at the same time. The
separation of the address and the cryptographic material avoids
avoids the need for the constrained device to compute multiple keys
for multiple addresses. The 6LN MAY use the same Crypto-ID to prove
the ownership of multiple IPv6 addresses. The 6LN MAY also derive
multiple Crypto-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. The on-link (local) address that the 6LN is trying to register [RFC8505]. The on-link
protocol interactions are shown in Figure 5. If the 6LR does not (local) protocol interactions are shown in Figure 5. If the 6LR does
have a state with the 6LN that is consistent with the NS(EARO), then not have a state with the 6LN that is consistent with the NS(EARO),
it replies with a challenge NA (EARO, status=Validation Requested) then it replies with a challenge NA (EARO, status=Validation
that contains a Nonce Option (shown as NonceLR in Figure 5). The Requested) that contains a Nonce Option (shown as NonceLR in
Nonce option contains a Nonce value that, to the extent possible for Figure 5).
the implementation, was never employed in association with the key
pair used to generate the ROVR. This specification inherits from The Nonce option contains a Nonce value that, to the extent possible
[RFC3971] that simply indicates that the nonce is a random value. for the implementation, was never employed in association with the
Ideally, an implementation would use an unpredictable 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 [RFC4086]. But that may be cryptographically random value [RFC4086]. But that may be
impractical in some LLN scenarios where the devices do not have a impractical in some LLN scenarios where the devices do not have a
guaranteed sense of time and for which computing complex hashes is guaranteed sense of time and for which computing complex hashes is
detrimental to the battery lifetime. Alternatively, the device may detrimental to the battery lifetime. Alternatively, the device may
use an always-incrementing value saved in the same stable storage as 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 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 random value, either as the Nonce value or as a component to its
computation. 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. Both Nonces are included in
to a Crypto-ID stored by the 6LR on the first NS exchange where it the signed material. This provides a "contributory behavior", so
appears. The 6LR MUST store the CIPO parameters associated with the that either party that knows it generates a good quality Nonce knows
Crypto-ID so it can be used for more than one address. 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 13, line 42 skipping to change at page 14, line 5
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 ownership of the Crypto-ID and the Target Address being prove ownership of the Crypto-ID and the Target Address being
registered in the Neighbor Solicitation message. When a 6LR registered in the Neighbor Solicitation message. When a 6LR
receives a NS(EARO) registration with a new Crypto-ID as a ROVR, receives a NS(EARO) registration with a new Crypto-ID as a ROVR,
and unless the registration is rejected for another reason, it and unless the registration is rejected for another reason, it
MUST challenge by responding with a NA(EARO) with a status of MUST challenge by responding with a NA(EARO) with a status of
"Validation Requested". "Validation Requested".
* The challenge is triggered when the registration for a Source
Link-Layer Address is not verifiable either at the 6LR or the
6LBR. In the latter case, the 6LBR returns a status of
"Validation Requested" in the DAR/DAC exchange, which is echoed by
the 6LR in the NA (EARO) back to the registering node. The
challenge MUST NOT alter a valid registration in the 6LR or the
6LBR.
* 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) 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,
skipping to change at page 14, line 48 skipping to change at page 15, line 4
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 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 is 5. NonceLN sent from the 6LN (in network byte order). The 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
Crypto-ID that was sent.
7. 1-byte (in network byte order) Crypto-Type value sent in the CIPO 6. The length of the ROVR field containing the Crypto-ID.
option. 7. 1-byte Crypto-Type value sent in the CIPO option.
* Depending on the Crypto-Type, apply the hash function on this * Apply the hash function (if any) specified by the Crypto-Type to
concatenation. the concatenated data, e.g., hash the resulting data using SHA-
256.
* Depending on the Crypto-Type, sign the hash output with ECDSA (if * Apply the signature algorithm specified by the Crypto-Type, e.g.,
curve P-256 is used) or sign the hash with EdDSA (if curve Ed25519 sign the hash output with ECDSA (if curve P-256 is used) or sign
(PureEdDSA)). the hash with EdDSA (if curve Ed25519 (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)
skipping to change at page 15, line 35 skipping to change at page 15, line 36
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
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 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 Crypto-Type value received in the CIPO option.
CIPO option.
* Depending on the Crypto-Type indicated by the (6LN) in the CIPO, * Apply the hash function (if any) specified by the Crypto-Type
apply the hash function on this concatenation. indicated by the 6LN in the CIPO to the concatenated data.
* Verify the signature with the public-key received and the locally * Verify the signature with the public-key in the CIPO and the
computed values. If the verification succeeds, the 6LR and 6LBR locally computed values using the signature algorithm specified by
add the state information about the Crypto-ID, public-key and the Crypto-Type. If the verification succeeds, the 6LR propagates
Target Address being registered to their database. the information to the 6LBR using a EDAR/EDAC flow. Due to the
first-come/first-serve nature of the registration, if the address
is not registered to the 6LBR, then flow succeeds and both the 6LR
and 6LBR add the state information about the Crypto-ID and Target
Address being registered to their respective abstract database.
6.3. Multihop Operation 6.3. Multihop Operation
In a multihop 6LoWPAN, the registration with Crypto-ID is propagated A new 6LN that joins the network auto-configures an address and
to 6LBR as described in this section. If the 6LR and the 6LBR
maintain a security association, then there is no need to propagate
the proof of ownership to the 6LBR.
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,
and the 6LR confirms (or denies) the address ownership with an NA
message that also carries an Address Registration Option.
Figure 6 illustrates a registration flow all the way to a 6LowPAN In a multihop 6LoWPAN, the registration with Crypto-ID is propagated
Backbone Router (6BBR) [BACKBONE-ROUTER]. to 6LBR as shown in Figure 6, which illustrates the registration flow
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, 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) |
| | |--------------->| | | |--------------->|
skipping to change at page 16, line 39 skipping to change at page 17, line 5
| | | proxy NA(EARO) | | | | proxy NA(EARO) |
| | |<---------------| | | |<---------------|
| | Extended DAC | | | | Extended DAC | |
| |<--------------| | | |<--------------| |
| NA(EARO) | | | | NA(EARO) | | |
|<---------------| | | |<---------------| | |
| | | | | | | |
Figure 6: (Re-)Registration Flow Figure 6: (Re-)Registration Flow
In a multihop 6LoWPAN, a 6LBR sends RAs with prefixes downstream and
the 6LR receives and relays them to the nodes. 6LR and 6LBR
communicate using ICMPv6 Duplicate Address Request (DAR) and
Duplicate Address Confirmation (DAC) messages. The DAR and DAC use
the same message format as NS and NA, but have different ICMPv6 type
values.
In AP-ND we extend DAR/DAC messages to carry cryptographically
generated ROVR. In a multihop 6LoWPAN, the node exchanges the
messages shown in Figure 6. The 6LBR must identify who owns an
address (EUI-64) to defend it, if there is an attacker on another
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. A different ROVR for the same Registered address
over the LLN, which provides some protection against DoS attacks entails a rejection of the second registration [RFC8505]. DAD
inside the resource-constrained part of the network. Over the coming from the backbone are not forwarded over the LLN, which
backbone, the EARO option is present in NS/NA messages. This provides some protection against DoS attacks inside the resource-
protects against misinterpreting a movement for a duplication, and constrained part of the network. Over the backbone, the EARO
enables the backbone routers to determine which one has the option is present in NS/NA messages. This protects against
freshest registration and is thus the best candidate to validate misinterpreting a movement for a duplication, and enables the
the registration for the device attached to it. But this backbone routers to determine which one has the freshest
specification does not guarantee that the backbone router claiming registration [RFC8505] and is thus the best candidate to validate
an address over the backbone is not an attacker. the registration for the device attached to it [BACKBONE-ROUTER].
But this specification does not guarantee that the backbone router
claiming 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 Using Nonces (NonceLR and NonceLN) generated by both Replay Attacks Using Nonces (NonceLR and NonceLN) generated by both
the 6LR and 6LN provides an efficient protection against replay the 6LR and 6LN ensure a contributory behavior that provides an
attacks of challenge response flow. The quality of the protection efficient protection against replay attacks of the challenge/
still depends on the quality of the Nonce, in particular of a response flow. A nonce should never repeat for a same key. The
random generator if they are computed that way. protection depends on the quality of the Nonce computation, e.g.,
of a random number generator when used to compute the Nonce.
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
The threats discussed in 6LoWPAN ND [RFC6775][RFC8505] also apply The threats and mediations discussed in 6LoWPAN ND [RFC6775][RFC8505]
here. Compared with SeND, this specification saves about 1Kbyte in also apply here, in particular denial-of-service attacks against the
every NS/NA message. Also, this specification separates the registry at the 6LR or 6LBR.
cryptographic identifier from the registered IPv6 address so that a
node can have more than one IPv6 address protected by the same Secure ND [RFC3971] forces the IPv6 address to be cryptographic since
cryptographic identifier. SeND forces the IPv6 address to be it integrates the CGA as the IID in the IPv6 address. In contrast,
cryptographic since it integrates the CGA as the IID in the IPv6 this specification saves about 1Kbyte in every NS/NA message. Also,
address. This specification frees the device to form its addresses this specification separates the cryptographic identifier from the
in any fashion, thereby enabling not only 6LoWPAN compression which registered IPv6 address so that a node can have more than one IPv6
derives IPv6 addresses from Layer-2 addresses but also privacy address protected by the same cryptographic identifier.
addresses.
With this specification the 6LN can freely form its IPv6 address(es)
in any fashion, thereby enabling either 6LoWPAN compression for IPv6
addresses that are derived from Layer-2 addresses, or temporary
addresses, e.g., formed pseudo-randomly and released in relatively
short cycles for privacy reasons [RFC8064][RFC8065], that cannot be
compressed.
This specification provides added protection for addresses that are
obtained following due procedure [RFC8505] but does not constrain the
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-
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.
7.3. ROVR Collisions 7.3. 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.
The formula for calculating the probability of a collision is 1 - Assuming in the calculations/discussion below that the hash used for
e^{-k^2/(2n)} where n is the maximum population size (2^64 here, calculating the Crypto-ID is a well-behaved cryptographic hash and
1.84E19) and K is the actual population (number of nodes). If the thus that random collisions are the only ones possible, the formula
Crypto-ID is 64-bits (the least possible size allowed), the chance of (birthday paradox) for calculating the probability of a collision is
a collision is 0.01% when the network contains 66 million nodes. 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
one Crypto-ID per node).
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.
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, an attacker stub network (6LBR). In the case of such a collision, a third party
may be able to claim the registered address of an another legitimate node would be able to claim the registered address of an another
node. However for this to happen, the attacker would also need to legitimate node, provided that it wishes to use the same address. To
know the address which was registered by the legitimate node. This prevent address disclosure and avoid the chances of collision on both
registered address is never broadcasted on the network and therefore the RIVR and the address, it is RECOMMENDED that nodes do not derive
providing an additional 64-bits that an attacker must correctly the address being registered from the ROVR.
guess. To prevent address disclosure, it is RECOMMENDED that nodes
derive the address being registered independently of the ROVR.
7.4. Implementation Attacks 7.4. 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 [BCP 201] 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 SHA-256 used
with ECDSA. with ECDSA.
7.5. Cross-Protocol Attacks 7.5. Cross-Algorithm and Cross-Protocol Attacks
The same private key MUST NOT be reused with more than one signature The keypair used in this specification can be self-generated and the
scheme in this specification. 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
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
and only for one signature scheme. The same private key MUST NOT be
reused with more than one signature scheme in this specification.
The same private key MUST NOT be used for anything other than
computing NDPSO signatures per this specification.
7.6. Compromised 6LR 7.6. Compromised 6LR
This specification distributes the challenge and its validation at This specification distributes the challenge and its validation at
the edge of the network, between the 6LN and its 6LR. The central the edge of the network, between the 6LN and its 6LR. This protects
6LBR is offloaded, which avoids DOS attacks targeted at that central against DOS attacks targeted at that central 6LBR. This also saves
entity. This also saves back and forth exchanges across a back and forth exchanges across a potentially large and constrained
potentially large and constrained network. network. The downside is that the 6LBR needs to trust the 6LR for
performing the checking adequately, and the communication between the
The downside is that the 6LBR needs to trust the 6LR for performing 6LR and the 6LBR must be protected to avoid tempering with the result
the checking adequately, and the communication between the 6LR and of the test.
the 6LBR must be protected to avoid tempering with the result of the
test.
If a 6LR is compromised, it may pretend that it owns any address and If a 6LR is compromised, and provided that it knows the ROVR field
defeat the protection. It may also admit any rogue and let it take used by the real owner of the address, the 6LR may pretend that the
ownership of any address in the network, provided that the 6LR knows owner has moved, is now attached to it and has successfully passed
the ROVR field used by the real owner of the address. the Crpto-ID validation. The 6LR may then attract and inject traffic
at will on behalf of that address. Similarly, the 6LR may admit any
rogue and let it take ownership of any address in the network for
which it knows the value of ROVR.
8. IANA considerations 8. IANA considerations
8.1. CGA Message Type 8.1. CGA Message Type
This document defines a new 128-bit value under the CGA Message Type This document defines a new 128-bit value under the CGA Message Type
[RFC3972] name space: 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0. [RFC3972] name space: 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0.
8.2. IPv6 ND option types 8.2. IPv6 ND option types
skipping to change at page 20, line 19 skipping to change at page 21, line 9
(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, and Representation Conventions, as shown in
Table 2, which together specify a signature scheme. The following Table 2, which together specify a signature scheme. The following
Crypto-Type values are defined in this document: Crypto-Type values are defined in this document:
+----------------+-----------------+-------------+-----------------+ +----------------+-----------------+-------------+-----------------+
| Crypto-Type | 0 (ECDSA256) | 1 (Ed25519) | 2 (ECDSA25519) | | Crypto-Type | 0 (ECDSA256) | 1 (Ed25519) | 2 (ECDSA25519) |
| value | | | | | value | | | |
+================+=================+=============+=================+ +================+=================+=============+=================+
| Elliptic curve | NIST P-256 | Curve25519 | Curve25519 | | Elliptic curve | NIST P-256 | Curve25519 | Curve25519 [BCP |
| | [FIPS186-4] | [RFC7748] | [RFC7748] | | | [FIPS186-4] | [BCP 201] | 201] |
+----------------+-----------------+-------------+-----------------+ +----------------+-----------------+-------------+-----------------+
| Hash function | SHA-256 | SHA-512 | SHA-256 | | Hash function | SHA-256 | SHA-512 | SHA-256 |
| | [RFC6234] | [RFC6234] | [RFC6234] | | | [RFC6234] | [RFC6234] | [RFC6234] |
+----------------+-----------------+-------------+-----------------+ +----------------+-----------------+-------------+-----------------+
| Signature | ECDSA | Ed25519 | ECDSA | | Signature | ECDSA | Ed25519 | ECDSA |
| algorithm | [FIPS186-4] | [RFC8032] | [FIPS186-4] | | algorithm | [FIPS186-4] | [RFC8032] | [FIPS186-4] |
+----------------+-----------------+-------------+-----------------+ +----------------+-----------------+-------------+-----------------+
| Representation | Weierstrass, | Edwards, | Weierstrass, | | Representation | Weierstrass, | Edwards, | Weierstrass, |
| conventions | (un)compressed, | compressed, | (un)compressed, | | conventions | (un)compressed, | compressed, | (un)compressed, |
| | MSB/msb first | LSB/lsb | MSB/msb first | | | MSB/msb first | LSB/lsb | MSB/msb first |
| | | first | | | | | first | |
+----------------+-----------------+-------------+-----------------+ +----------------+-----------------+-------------+-----------------+
| 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 may be
less code) 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 [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 Mirja Kuhlewind, Eric Vyncke, Vijay The authors wish to thank Benjamin Kaduk, Mirja Kuhlewind, Eric
Gurbani, Al Morton and Adam Montville for their constructive reviews Vyncke, Vijay Gurbani, Al Morton and Adam Montville for their
during the IESG process. 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>.
[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
skipping to change at page 21, line 40 skipping to change at page 22, line 24
[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, [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, "SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005, DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>. <https://www.rfc-editor.org/info/rfc3971>.
[BCP 201] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[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
skipping to change at page 22, line 24 skipping to change at page 23, line 21
[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>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<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,
"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>.
skipping to change at page 23, line 10 skipping to change at page 23, line 47
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <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
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[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>.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017,
<https://www.rfc-editor.org/info/rfc8064>.
[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-
Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
February 2017, <https://www.rfc-editor.org/info/rfc8065>.
[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-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>.
[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-
skipping to change at page 25, line 7 skipping to change at page 25, line 47
(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 integer
encoding, see Appendix B.2. 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 [BCP 201], 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 (see
Appendix B.3) and are encoded as octet strings in least-significant- Appendix B.3) and are encoded as octet strings in least-significant-
bit first (lsb) and least-significant-byte first (LSB) order. The bit first (lsb) and least-significant-byte first (LSB) order. The
signature itself consists of a bit string that encodes a point of signature itself consists of a bit string that encodes a point of
this twisted Edwards curve, in compressed format, and an integer this twisted Edwards curve, in compressed format, and an integer
encoded in least-significant-bit first and least-significant-byte encoded in least-significant-bit first and least-significant-byte
first order. For details on EdDSA and on the encoding conversions, first order. For details on EdDSA and on the encoding conversions,
see the specification of pure Ed25519 in . [RFC8032] 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 [BCP 201], 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 a corresponding curve in short-
Weierstrass form (see Appendix B.3) and are encoded as octet strings Weierstrass form (see Appendix B.3) and are encoded as octet strings
in most-significant-bit first and most-significant-byte first order. in most-significant-bit first and most-significant-byte first order.
The signature itself consists of a bit string that encodes two The signature itself consists of a bit string that encodes two
integers, each encoded as fixed-size octet strings in most- integers, 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 integer
encoding, see Appendix B.2 encoding, see Appendix B.2
skipping to change at page 25, line 44 skipping to change at page 26, line 36
Each integer is encoded as a fixed-size 256-bit bit string, where Each integer is encoded as a fixed-size 256-bit bit string, where
each integer is represented according to the Field Element to Octet each integer is represented according to the Field Element to Octet
String and Octet String to Bit String conversion rules in [SEC1] and String and Octet String to Bit String conversion rules in [SEC1] and
where the ordered pair of integers is represented as the where the ordered pair of integers is represented as the
rightconcatenation of the resulting representation values. The rightconcatenation of the resulting representation values. The
inverse operation follows the corresponding Bit String to Octet inverse operation follows the corresponding Bit String to Octet
String and Octet String to Field Element conversion rules of [SEC1]. String and Octet String to Field Element conversion rules of [SEC1].
B.3. Alternative Representations of Curve25519 B.3. Alternative Representations of Curve25519
The elliptic curve Curve25519, as specified in [RFC7748], is a so- The elliptic curve Curve25519, as specified in [BCP 201], 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 [BCP 201]; 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 [CURVE-REPRESENTATIONS]. above, see [BCP 201] 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. 73 change blocks. 
238 lines changed or deleted 300 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/