< draft-ietf-6lo-ap-nd-09.txt   draft-ietf-6lo-ap-nd-10.txt >
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Updates: 6775 (if approved) M. Sethi Updates: 8505 (if approved) M. Sethi
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: June 16, 2019 R. Struik Expires: August 29, 2019 R. Struik
Struik Security Consultancy Struik Security Consultancy
B. Sarikaya B. Sarikaya
December 13, 2018 February 25, 2019
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-09 draft-ietf-6lo-ap-nd-10
Abstract Abstract
This document specifies an extension to 6LoWPAN Neighbor Discovery This document specifies an extension to 6LoWPAN Neighbor Discovery
(ND) defined in RFC6775 and updated in [I-D.ietf-6lo-rfc6775-update]. (ND) defined in RFC6775 and updated in RFC8505. The new extension is
The new extension is called Address Protected Neighbor Discovery (AP- called Address Protected Neighbor Discovery (AP-ND) and it protects
ND) and it protects the owner of an address against address theft and the owner of an address against address theft and impersonation
impersonation attacks in a low-power and lossy network (LLN). Nodes attacks in a low-power and lossy network (LLN). Nodes supporting
supporting this extension compute a cryptographic identifier (Crypto- this extension compute a cryptographic identifier (Crypto-ID) and use
ID) and use it with one or more of their Registered Addresses. The it with one or more of their Registered Addresses. The Crypto-ID
Crypto-ID identifies the owner of the Registered Address and can be identifies the owner of the Registered Address and can be used to
used to provide proof of ownership of the Registered Addresses. Once provide proof of ownership of the Registered Addresses. Once an
an address is registered with the Crypto-ID and a proof-of-ownership address is registered with the Crypto-ID and a proof-of-ownership is
is provided, only the owner of that address can modify the provided, only the owner of that address can modify the registration
registration information, thereby enforcing Source Address information, thereby enforcing Source Address Validation.
Validation.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 16, 2019. This Internet-Draft will expire on August 29, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. References . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. 6LoWPAN sub-glossary . . . . . . . . . . . . . . . . . . 4 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4
3. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
3. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 6
4. New Fields and Options . . . . . . . . . . . . . . . . . . . 6 4. New Fields and Options . . . . . . . . . . . . . . . . . . . 6
4.1. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 6 4.1. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Updated EARO . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Updated EARO . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Crypto-ID Parameters Option . . . . . . . . . . . . . . . 8 4.3. Crypto-ID Parameters Option . . . . . . . . . . . . . . . 8
4.4. Nonce Option . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Nonce Option . . . . . . . . . . . . . . . . . . . . . . 9
4.5. NDP Signature Option . . . . . . . . . . . . . . . . . . 9 4.5. 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 verficiation . . . . . . . . . . . . 13 6.2. NDPSO generation and verification . . . . . . . . . . . . 13
6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 14 6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 16 7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 16
7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . 18
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18
8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 18 8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 18
8.2. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 18 8.2. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative references . . . . . . . . . . . . . . . . . 20 10.2. Informative references . . . . . . . . . . . . . . . . . 20
Appendix A. Requirements Addressed in this Document . . . . . . 22 Appendix A. Requirements Addressed in this Document . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix B. Representation Conventions . . . . . . . . . . . . . 22
B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 22
B.2. Integer Representation for ECDSA signatures . . . . . . . 23
B.3. Alternative Representations of Curve25519 . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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 (NDv6) (6LoWPAN ND) adapts the original IPv6 neighbor discovery (NDv6)
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. 6LoWPAN ND defines a new Address Registration Option (ARO) multicast. 6LoWPAN ND defines a new Address Registration Option (ARO)
that is carried in the unicast Neighbor Solicitation (NS) and that is carried in the unicast Neighbor Solicitation (NS) and
skipping to change at page 3, line 26 skipping to change at page 3, line 31
Address Request (DAR) and Duplicate Address Confirmation (DAC) Address Request (DAR) and Duplicate Address Confirmation (DAC)
messages between the 6LR and the 6LoWPAN Border Router (6LBR). In messages between the 6LR and the 6LoWPAN Border Router (6LBR). In
LLN networks, the 6LBR is the central repository of all the 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 6LoWPAN ND [RFC6775] prevents the use
of an address if that address is already registered in the subnet 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 Registration Ownership Verifier (ROVR). ROVR is defined in [RFC8505]
[I-D.ietf-6lo-rfc6775-update] and it can be derived from the MAC and it can be derived from the MAC address of the device (using the
address of the device (using the 64-bit Extended Unique Identifier 64-bit Extended Unique Identifier EUI-64 address format specified by
EUI-64 address format specified by IEEE). However, the EUI-64 can be IEEE). However, the EUI-64 can be spoofed, and therefore, any node
spoofed, and therefore, any node connected to the subnet and aware of connected to the subnet and aware of a registered-address-to-ROVR
a registered-address-to-ROVR mapping could effectively fake the ROVR. mapping could effectively fake the ROVR. This would allow the an
This would allow the an attacker to steal the address and redirect attacker to steal the address and redirect traffic for that address.
traffic for that address. [I-D.ietf-6lo-rfc6775-update] defines an [RFC8505] defines an Extended Address Registration Option (EARO)
Extended Address Registration Option (EARO) option that allows to option that allows to transport alternate forms of ROVRs, and is a
transport alternate forms of ROVRs, and is a pre-requisite for this pre-requisite for this specification.
specification.
In this specification, a 6LN generates a cryptographic ID (Crypto-ID) In this specification, a 6LN generates a cryptographic ID (Crypto-ID)
and places it in the ROVR field during the registration of one (or and places it in the ROVR field during the registration of one (or
more) of its addresses with the 6LR(s). Proof of ownership of the more) of its addresses with the 6LR(s). Proof of ownership of the
Crypto-ID is passed with the first registration exchange to a new Crypto-ID is passed with the first registration exchange to a new
6LR, and enforced at the 6LR. The 6LR validates ownership of the 6LR, and enforced at the 6LR. The 6LR validates ownership of the
cryptographic ID before it creates any new registration state, or cryptographic ID before it creates any new registration state, or
changes existing information. changes existing information.
The protected address registration protocol proposed in this document The protected address registration protocol proposed in this document
skipping to change at page 4, line 14 skipping to change at page 4, line 18
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. This is incompatible with Secure Neighbor
Discovery (SeND) [RFC3971] and Cryptographically Generated Addresses Discovery (SeND) [RFC3971] and Cryptographically Generated Addresses
(CGAs) [RFC3972], since they derive the Interface ID (IID) in IPv6 (CGAs) [RFC3972], since they derive the Interface ID (IID) in IPv6
addresses with cryptographic keys. addresses with cryptographic keys.
2. Terminology 2. Terminology
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.1. References 2.2. References
Terms and concepts from the following documents are used in this Terms and concepts from the following documents are used in this
specification: specification:
o SEcure Neighbor Discovery (SEND) [RFC3971] o "Terms Used in Routing for Low-Power and Lossy Networks (LLNs)"
[RFC7102],
o Cryptographically Generated Addresses (CGA) [RFC3972]
o Neighbor Discovery for IP version 6 [RFC4861]
o IPv6 Stateless Address Autoconfiguration[RFC4862], o "SEcure Neighbor Discovery (SEND)" [RFC3971],
o Problem Statement and Requirements for IPv6 over Low-Power o "Cryptographically Generated Addresses (CGA)" [RFC3972],
Wireless Personal Area Network (6LoWPAN) Routing [RFC6606]
o IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): o "Neighbor Discovery for IP version 6" [RFC4861] ,
Overview, Assumptions, Problem Statement, and Goals [RFC4919]
o Neighbor Discovery Optimization for Low-power and Lossy Networks o "IPv6 Stateless Address Autoconfiguration" [RFC4862],
[RFC6775]
o Terms Used in Routing for Low-Power and Lossy Networks (LLNs) o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
[RFC7102] Overview, Assumptions, Problem Statement, and Goals " [RFC4919],
o Terminology for Constrained-Node Networks [RFC7228] o "Neighbor Discovery Optimization for Low-power and Lossy Networks"
[RFC6775], and
o Registration Extensions for 6LoWPAN Neighbor Discovery" o "Registration Extensions for 6LoWPAN Neighbor Discovery"
[I-D.ietf-6lo-rfc6775-update] [RFC8505].
2.2. 6LoWPAN sub-glossary 2.3. Abbreviations
This document uses the following acronyms: This document uses the following abbreviations:
6BBR: 6LoWPAN Backbone Router (proxy for the 6BBR: 6LoWPAN Backbone Router
registration)[I-D.ietf-6lo-backbone-router]
6LBR: 6LoWPAN Border Router 6LBR: 6LoWPAN Border Router
6LN: 6LoWPAN Node 6LN: 6LoWPAN Node
6LR: 6LoWPAN Router (relay to the registration process) 6LR: 6LoWPAN Router
CIPO: Crypto-ID Parameters Option 6CIO: Capability Indication Option
(E)ARO: (Extended) Address Registration Option ARO: Address Registration Option
DAD: Duplicate Address Detection CIPO: Crypto-ID Parameters Option
LLN: Low-Power and Lossy Network (a typical IoT network) LLN: Low-Power and Lossy Network
NA: Neighbor Advertisement NA: Neighbor Advertisement
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 (pronounced rover) ROVR: Registration Ownership Verifier
RPL: IPv6 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 (a sequence counter in the EARO) TID: Transaction ID
3. Updating RFC 6775 3. Updating RFC 8505
This specification defines a cryptographic identifier (Crypto-ID) This specification introduces a new token called a cryptographic
that can be used as a replacement to the MAC address in the ROVR identifier (Crypto-ID) that is used to prove indirectly the ownership
field of the EARO option; the computation of the Crypto-ID is of an address that is being registered by means of [RFC8505].
detailed in Section 4.1. A node in possession of the necessary
cryptographic primitives SHOULD use Crypto-ID by default as ROVR in
its registration. Whether a ROVR is a Crypto-ID is indicated by a
new "C" flag in the NS(EARO) message.
In order to prove its ownership of a Crypto-ID, the registering node In order to prove its ownership of a Crypto-ID, the registering node
needs to supply certain parameters including a nonce and a signature needs to supply certain parameters including a nonce and a signature
that will prove that the node has the private-key corresponding to that will prove that the node has the private-key corresponding to
the public-key used to build the Crypto-ID. This specification adds the public-key used to build the Crypto-ID. This specification adds
the capability to carry new options in the NS(EARO) and the NA(EARO). the capability to carry new options in the NS(EARO) and the NA(EARO).
The NS(EARO) carries a variation of the CGA Option (Section 4.3), a The NS(EARO) carries a variation of the CGA Option (Section 4.3), a
Nonce option and a variation of the RSA Signature option Nonce option and a variation of the RSA Signature option
(Section 4.5) in the NS(EARO). The NA(EARO) carries a Nonce option. (Section 4.5) in the NS(EARO). The NA(EARO) carries a Nonce option.
4. New Fields and Options 4. New Fields and Options
In order to avoid the need for new ND option types, this In order to avoid the need for new ND option types, this
specification reuses/ extends options defined in SEND [RFC3971] and specification reuses and extends options defined in SEND [RFC3971]
6LoWPAN ND [RFC6775] [I-D.ietf-6lo-rfc6775-update]. This applies in and 6LoWPAN ND [RFC6775] [RFC8505]. This applies in particular to
particular to the CGA option and the RSA Signature Option. This the CGA option and the RSA Signature Option. This specification
specification provides aliases for the specific variations of those provides aliases for the specific variations of those options as used
options as used in this document. The presence of the EARO option in in this document. The presence of the EARO option in the NS/NA
the NS/NA messages indicates that the options are to be processed as messages indicates that the options are to be processed as specified
specified in this document, and not as defined in SEND [RFC3971]. in this document, and not as defined in SEND [RFC3971].
4.1. New Crypto-ID 4.1. New Crypto-ID
Each 6LN using this specification for address registration MUST The Crypto-ID can be used as a replacement to the MAC address in the
support Elliptic Curve Crytpograhy (ECC) and a hash function. The ROVR field of the EARO option and the EDAR message, and is associated
choice of elliptic curves and hash function currently defined in this with the Registered Address. The ownership of a Crypto-ID can be
specification are listed in Section 8.2. demonstrated by cryptographic mechanisms, and by association, the
ownership of the Registered Address can be acertained. A node in
The Crypto-ID is computed by a 6LN as follows: possession of the necessary cryptographic primitives SHOULD use
Crypto-ID by default as ROVR in its registrations. Whether a ROVR is
1. Depending on the Crypto-Type (see Section 8.2) used by the node, a Crypto-ID is indicated by a new "C" flag in the NS(EARO) message.
the hash function is applied to the JSON Web Key (JWK) [RFC7517]
encoding of the public-key of the node.
2. The leftmost bits of the resulting hash, up to the size of the The computation of the Crypto-ID requires the support of Elliptic
ROVR field, are used as the Crypto-ID. Curve Cryptography (ECC) and that of a hash function as detailed in
Section 6.2. The elliptic curves and the hash functions that can be
used with this specification are listed in Table 1 in section
Section 8.2. The signature scheme that specifies which combination
is used is signaled by a Crypto-Type in a new Crypto-ID Parameters
Option (see Section 4.3).
4.2. Updated EARO 4.2. Updated EARO
This specification updates the EARO option as follows: This specification updates the EARO option 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Status | Opaque | | Type | Length | Status | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 29 skipping to change at page 7, line 33
Type: 33 Type: 33
Length: 8-bit unsigned integer. The length of the option Length: 8-bit unsigned integer. The length of the option
(including the type and length fields) in units of 8 (including the type and length fields) in units of 8
bytes. 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 registration in the NA response. MUST be set to 0 in
NS messages. NS messages.
Opaque: Defined in [I-D.ietf-6lo-rfc6775-update]. Opaque: Defined in [RFC8505].
Rsvd (Reserved): This field is unused. It MUST be initialized to Rsvd (Reserved): This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the zero by the sender and MUST be ignored by the
receiver. receiver.
C: This "C" flag is set to indicate that the ROVR field C: This "C" flag is set to indicate that the ROVR field
contains a Crypto-ID and that the 6LN MAY be contains a Crypto-ID and that the 6LN MAY be
challenged for ownership as specified in this challenged for ownership as specified in this
document. document.
I: Defined in [I-D.ietf-6lo-rfc6775-update]. I, R, T, and TID: Defined in [RFC8505].
R: Defined in [I-D.ietf-6lo-rfc6775-update].
T and TID: Defined in [I-D.ietf-6lo-rfc6775-update].
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 6LoWPAN ND "Validation Failed", which are defined in [RFC8505]. No other new
[I-D.ietf-6lo-rfc6775-update]. No other new Status values are Status values are defined.
defined.
4.3. Crypto-ID Parameters Option 4.3. Crypto-ID Parameters Option
This specification defines the Crypto-ID Parameters Option (CIPO), as This specification defines the Crypto-ID Parameters Option (CIPO), as
a variation of the CGA Option that carries the parameters used to a variation of the CGA Option that carries the parameters used to
form a Crypto-ID. In order to provide cryptographic agility form a Crypto-ID. In order to provide cryptographic agility
[RFC7696], AP-ND supports two possible elliptic curves, indicated by [RFC7696], this specification supports different elliptic curves,
a Crypto-Type field. NIST P-256 [FIPS186-4] MUST be supported by all indicated by a Crypto-Type field. NIST P-256 [FIPS186-4] MUST be
implementations. The Edwards-Curve Digital Signature Algorithm supported by all implementations. The Edwards-Curve Digital
(EdDSA) curve Ed25519 (PureEdDSA) [RFC8032] MAY be supported as an Signature Algorithm (EdDSA) curve Ed25519 (PureEdDSA) [RFC8032] MAY
alternate. be supported as an alternate.
The type of cryptographic algorithm used in the calculation of the
Crypto-ID is signaled by the Crypto-Type field of the CIPO as
specified in Table 1 in section Section 8.2. Although the different
signature schemes target similar cryptographic strength, they rely on
different curves, hash functions, signature algorithms, and/or
representation conventions.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crypto-Type | Modifier | Reserved | | Crypto-Type | Modifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
skipping to change at page 8, line 52 skipping to change at page 9, line 11
Length: 8-bit unsigned integer. The length of the option in Length: 8-bit unsigned integer. The length of the option in
units of 8 octets. units of 8 octets.
Modifier: 8-bit unsigned integer. Modifier: 8-bit unsigned integer.
Pad Length: 8-bit unsigned integer. The length of the Padding Pad Length: 8-bit unsigned integer. The length of the Padding
field. field.
Crypto-Type: The type of cryptographic algorithm used in Crypto-Type: The type of cryptographic algorithm used in
calculation Crypto-ID. A value of 0 indicates NIST calculation Crypto-ID (see Table 1 in section
P-256, with SHA-256 as the hash algorithm. A value Section 8.2).
of 1 is assigned for Ed25519 (PureEdDSA), with
SHA-512 as the hash algorithm.
Public Key: JWK-Encoded Public Key [RFC7517]. Public Key: JWK-Encoded Public Key [RFC7517].
Padding: A variable-length field making the option length a Padding: A variable-length field making the option length a
multiple of 8, containing as many octets as specified multiple of 8, containing as many octets as specified
in the Pad Length field. in the Pad Length field.
The implementation of multiple hash functions in a constrained
devices may consume excessive amounts of program memory.
[I-D.ietf-lwig-curve-representations] provides information on how to
represent Montgomery curves and (twisted) Edwards curves as curves in
short-Weierstrass form and illustrates how this can be used to
implement elliptic curve computations using existing implementations
that already provide, e.g., ECDSA and ECDH using NIST [FIPS186-4]
prime curves.
For more details on representation conventions, we refer to
Appendix B.
4.4. Nonce Option 4.4. Nonce Option
This document reuses the Nonce Option defined in section 5.3.2. of This document reuses the Nonce Option defined in section 5.3.2. of
SEND [RFC3971] without a change. SEND [RFC3971] without a change.
4.5. NDP Signature Option 4.5. NDP Signature Option
This document reuses the RSA Signature Option (RSAO) defined in This document reuses the RSA Signature Option (RSAO) defined in
section 5.2. of SEND [RFC3971]. Admittedly, the name is ill-chosen section 5.2. of SEND [RFC3971]. Admittedly, the name is ill-chosen
since the option is extended for non-RSA Signatures and this since the option is extended for non-RSA Signatures and this
skipping to change at page 12, line 36 skipping to change at page 12, line 36
| | | |
|<------------------- NA with EARO ---------------------| |<------------------- NA with EARO ---------------------|
| | | |
Figure 4: On-link Protocol Operation Figure 4: On-link Protocol Operation
The steps for the registration to the 6LR are as follows: The steps for the registration to the 6LR are as follows:
o Upon the first exchange with a 6LR, a 6LN will be challenged to o 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. The proof is not registered in the Neighbor Solicitation message. When a 6LR
needed again in later registrations for that address. 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,
it SHOULD challenge by responding with a NA(EARO) with a status of it SHOULD challenge by responding with a NA(EARO) with a status of
"Validation Requested". "Validation Requested".
o The challenge is triggered when the registration for a Source o The challenge is triggered when the registration for a Source
Link-Layer Address is not verifiable either at the 6LR or the Link-Layer Address is not verifiable either at the 6LR or the
6LBR. In the latter case, the 6LBR returns a status of 6LBR. In the latter case, the 6LBR returns a status of
"Validation Requested" in the DAR/DAC exchange, which is echoed by "Validation Requested" in the DAR/DAC exchange, which is echoed by
the 6LR in the NA (EARO) back to the registering node. The the 6LR in the NA (EARO) back to the registering node. The
challenge MUST NOT alter a valid registration in the 6LR or the challenge MUST NOT alter a valid registration in the 6LR or the
skipping to change at page 13, line 21 skipping to change at page 13, line 20
parameters in the CIPO. It also verifies the signature contained parameters in the CIPO. It also verifies the signature contained
in the NDPSO option. If the Crypto-ID does not match with the in the NDPSO option. If the Crypto-ID does not match with the
public-key in the CIPO option, or if the signature in the NDPSO public-key in the CIPO option, or if the signature in the NDPSO
option cannot be verified, the validation fails. option cannot be verified, the validation fails.
o If the 6LR fails to validate the signed NS(EARO), it responds with o 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 verficiation 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 as follows: is generated by the 6LN in a fashion that depends on the Crypto-Type
(see Table 1 in section Section 8.2) chosen by the 6LN as follows:
o Concatenate the following in the order listed: o 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 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 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.
skipping to change at page 13, line 50 skipping to change at page 13, line 50
5. NonceLN sent from the 6LN (in network byte order). The random 5. NonceLN sent from the 6LN (in network byte order). The random
nonce is at least 6 bytes long as defined in [RFC3971]. nonce is at least 6 bytes long as defined in [RFC3971].
6. The length of the ROVR field in the NS message cotainting the 6. The length of the ROVR field in the NS message cotainting the
Crypto-ID that was sent. Crypto-ID that was sent.
7. 1-byte (in network byte order) Crypto-Type value sent in the 7. 1-byte (in network byte order) Crypto-Type value sent in the
CIPO option. CIPO option.
o Depending on the Crypto-Type (see Section 8.2) chosen by the node o Depending on the Crypto-Type, apply the hash function on this
(6LN), apply the hash function on this concatenation. concatenation.
o Depending on the Crypto-Type (see Section 8.2) chosen by the node o Depending on the Crypto-Type, sign the hash output with ECDSA (if
(6LN), sign the hash output with ECDSA (if curve P-256 is used) or curve P-256 is used) or sign the hash with EdDSA (if curve Ed25519
sign the hash with EdDSA (if curve Ed25519 (PureEdDSA)). (PureEdDSA)).
The 6LR on receiving the NDPSO and CIPO options first hashes the JWK The 6LR on receiving the NDPSO and CIPO options first hashes the JWK
encoded public-key in the CIPO option to make sure that the leftmost encoded public-key in the CIPO option to make sure that the leftmost
bits up to the size of the ROVR match. Only if the check is bits up to the size of the ROVR match. 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.
o Concatenate the following in the order listed: o 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 14, line 38 skipping to change at page 14, line 38
5. NonceLN received from the 6LN (in network byte order) in the 5. NonceLN received from the 6LN (in network byte order) in the
NS message. The random nonce is at least 6 bytes long as NS message. The random nonce is at least 6 bytes long as
defined in [RFC3971]. 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 received. Crypto-ID that was received.
7. 1-byte (in network byte order) Crypto-Type value received in 7. 1-byte (in network byte order) Crypto-Type value received in
the CIPO option. the CIPO option.
o Depending on the Crypto-Type (see Section 8.2) indicated by the o Depending on the Crypto-Type indicated by the (6LN) in the CIPO,
(6LN) in the CIPO, apply the hash function on this concatenation. apply the hash function on this concatenation.
o Verify the signature with the public-key received and the locally o Verify the signature with the public-key received and the locally
computed values. If the verification succeeds, the 6LR and 6LBR computed values. If the verification succeeds, the 6LR and 6LBR
add the state information about the Crypto-ID, public-key and add the state information about the Crypto-ID, public-key and
Target 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) [RFC6775]. 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 5 illustrates a registration flow all the way to a 6LowPAN Figure 5 illustrates a registration flow all the way to a 6LowPAN
Backbone Router (6BBR). Backbone Router (6BBR) [I-D.ietf-6lo-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 17, line 7 skipping to change at page 17, line 7
addresses and register them using AP-ND. The perimeter of the addresses and register them using AP-ND. The perimeter of the
attack is all the 6LRs in range of the attacker. The 6LR must attack is all the 6LRs in range of the attacker. The 6LR must
protect itself against overflows and reject excessive registration protect itself against overflows and reject excessive registration
with a status 2 "Neighbor Cache Full". This effectively blocks with a status 2 "Neighbor Cache Full". This effectively blocks
another (honest) 6LN from registering to the same 6LR, but the 6LN another (honest) 6LN from registering to the same 6LR, but the 6LN
may register to other 6LRs that are in its range but not in that may register to other 6LRs that are in its range but not in that
of the rogue. of the rogue.
7.2. Related to 6LoWPAN ND 7.2. Related to 6LoWPAN ND
The threats discussed in 6LoWPAN ND [RFC6775] and its update The threats discussed in 6LoWPAN ND [RFC6775][RFC8505] also apply
[I-D.ietf-6lo-rfc6775-update] also apply here. Compared with SeND, here. Compared with SeND, this specification saves about 1Kbyte in
this specification saves about 1Kbyte in every NS/NA message. Also, every NS/NA message. Also, this specification separates the
this specification separates the cryptographic identifier from the cryptographic identifier from the registered IPv6 address so that a
registered IPv6 address so that a node can have more than one IPv6 node can have more than one IPv6 address protected by the same
address protected by the same cryptographic identifier. SeND forces cryptographic identifier. SeND forces the IPv6 address to be
the IPv6 address to be cryptographic since it integrates the CGA as cryptographic since it integrates the CGA as the IID in the IPv6
the IID in the IPv6 address. This specification frees the device to address. This specification frees the device to form its addresses
form its addresses in any fashion, thereby enabling not only 6LoWPAN in any fashion, thereby enabling not only 6LoWPAN compression which
compression which derives IPv6 addresses from Layer-2 addresses but derives IPv6 addresses from Layer-2 addresses but also privacy
also privacy addresses. addresses.
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 - The formula for calculating the probability of a collision is 1 -
e^{-k^2/(2n)} where n is the maximum population size (2^64 here, 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). If the 1.84E19) and K is the actual population (number of nodes). If the
Crypto-ID is 64-bits (the least possible size allowed), the chance of Crypto-ID is 64-bits (the least possible size allowed), the chance of
a collision is 0.01% when the network contains 66 million nodes. a collision is 0.01% when the network contains 66 million nodes.
skipping to change at page 17, line 45 skipping to change at page 17, line 45
guess. To prevent address disclosure, it is RECOMMENDED that nodes guess. To prevent address disclosure, it is RECOMMENDED that nodes
derive the address being registered independently of the ROVR. 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 then we have extensive time arithmetic in mind [RFC7748] or where one has extensive
implementation experience of resistance to timing attacks implementation experience of resistance to timing attacks
[FIPS186-4]. However, careless implementations of the signing [FIPS186-4]. However, careless implementations of the signing
operations could nevertheless leak information on private keys. For operations could nevertheless leak information on private keys. For
example, there are micro-architectural side channel attacks that example, there are micro-architectural side channel attacks that
implementors should be aware of [breaking-ed25519]. Implementors implementors should be aware of [breaking-ed25519]. Implementors
should be particularly aware that a secure implementation of Ed25519 should be particularly aware that a secure implementation of Ed25519
requires a protected implementation of the hash function SHA-512, requires a protected implementation of the hash function SHA-512,
whereas this is not required with implementations of SHA-256 used whereas this is not required with implementations of SHA-256 used
with ECDSA. with ECDSA.
7.5. Cross-Protocol Attacks
The same private key MUST NOT be reused with more than one signature
scheme in this specification.
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] namespace, 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0. [RFC3972] name space: 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0.
8.2. Crypto-Type Subregistry 8.2. Crypto-Type Subregistry
IANA is requested to create a new subregistry "Crypto-Type IANA is requested to create a new subregistry "Crypto-Type
Subregistry" in the "Internet Control Message Protocol version 6 Subregistry" in the "Internet Control Message Protocol version 6
(ICMPv6) Parameters". The registry is indexed by an integer 0..255 (ICMPv6) Parameters". The registry is indexed by an integer in the
and contains a Signature Algorithm and a Hash Function as shown in interval 0..255 and contains an Elliptic Curve, a Hash Function, a
Table 1. The following Crypto-Type values are defined in this Signature Algorithm, and Representation Conventions, as shown in
document: Table 1, which together specify a signature scheme. The following
Crypto-Type values are defined in this document:
+--------------+-----------------+---------------+------------------+ +----------------+-----------------+-------------+------------------+
| Crypto-Type | Signature | Hash Function | Defining | | Crypto-Type | 0 (ECDSA256) | 1 (Ed25519) | 2 (ECDSA25519) |
| value | Algorithm | | Specification | | value | | | |
+--------------+-----------------+---------------+------------------+ +----------------+-----------------+-------------+------------------+
| 0 | NIST P-256 | SHA-256 | RFC THIS | | Elliptic curve | NIST P-256 | Curve25519 | Curve25519 |
| | [FIPS186-4] | [RFC6234] | | | | [FIPS186-4] | [RFC7748] | [RFC7748] |
| 1 | Ed25519 | SHA-512 | RFC THIS | | | | | |
| | [RFC8032] | [RFC6234] | | | Hash function | SHA-256 | SHA-512 | SHA-256 |
+--------------+-----------------+---------------+------------------+ | | [RFC6234] | [RFC6234] | [RFC6234] |
| | | | |
| Signature | ECDSA | Ed25519 | ECDSA |
| algorithm | [FIPS186-4] | [RFC8032] | [FIPS186-4] |
| | | | |
| Representation | Weierstrass, | Edwards, | Weierstrass, |
| conventions | (un)compressed, | compressed, | (un)compressed, |
| | MSB/msb first | LSB/lsb | MSB/msb first |
| | | first | |
| | | | |
| Defining | RFC THIS | RFC THIS | RFC THIS |
| specification | | | |
+----------------+-----------------+-------------+------------------+
Table 1: Crypto-Types Table 1: Crypto-Types
As is evident from the table above, although the two curves provide New Crypto-Type values providing similar or better security (with
similar security, they however rely on different hash functions. less code) may be defined in the future.
Supporting multiple hash functions on constrained devices is not
ideal. [I-D.struik-lwig-curve-representations] provides information
on how to represent Montgomery curves and (twisted) Edwards curves as
curves in short-Weierstrass form and illustrates how this can be used
to implement elliptic curve computations using existing
implementations that already implement, e.g., ECDSA and ECDH using
NIST [FIPS186-4] prime curves. New Crypto-Type values providing
similar or better security (with less code) can be defined in 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 "Specification Required" and "IESG Approval" as defined in
[RFC8126]. [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. We are also especially grateful to Robert constructive suggestions. We are also especially grateful to Robert
Moskowitz for his comments that led to many improvements. Moskowitz for his comments that led to many improvements.
skipping to change at page 19, line 21 skipping to change at page 19, line 28
10. References 10. References
10.1. Normative References 10.1. Normative References
[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.
[I-D.ietf-6lo-rfc6775-update]
Thubert, P., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for 6LoWPAN Neighbor
Discovery", draft-ietf-6lo-rfc6775-update-21 (work in
progress), June 2018.
[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, [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>.
skipping to change at page 20, line 5 skipping to change at page 20, line 5
[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>.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing",
RFC 6606, DOI 10.17487/RFC6606, May 2012,
<https://www.rfc-editor.org/info/rfc6606>.
[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>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[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
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.
[SEC1] SEC1, "SEC 1: Elliptic Curve Cryptography, Version 2.0",
Standards for Efficient Cryptography , June 2009.
10.2. Informative references 10.2. Informative references
[breaking-ed25519] [breaking-ed25519]
Samwel, N., Batina, L., Bertoni, G., Daemen, J., and R. Samwel, N., Batina, L., Bertoni, G., Daemen, J., and R.
Susella, "Breaking Ed25519 in WolfSSL", Cryptographers' Susella, "Breaking Ed25519 in WolfSSL", Cryptographers'
Track at the RSA Conference , 2018, Track at the RSA Conference , 2018,
<https://link.springer.com/ <https://link.springer.com/
chapter/10.1007/978-3-319-76953-0_1>. chapter/10.1007/978-3-319-76953-0_1>.
[I-D.ietf-6lo-backbone-router] [I-D.ietf-6lo-backbone-router]
Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
Backbone Router", draft-ietf-6lo-backbone-router-09 (work Backbone Router", draft-ietf-6lo-backbone-router-11 (work
in progress), December 2018. in progress), February 2019.
[I-D.struik-lwig-curve-representations] [I-D.ietf-lwig-curve-representations]
Struik, R., "Alternative Elliptic Curve Representations", Struik, R., "Alternative Elliptic Curve Representations",
draft-struik-lwig-curve-representations-02 (work in draft-ietf-lwig-curve-representations-01 (work in
progress), July 2018. progress), November 2018.
[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>.
[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,
skipping to change at page 22, line 40 skipping to change at page 22, line 40
connected to a 6LBR. connected to a 6LBR.
o The Address Registration Option used in the ND registration SHOULD o The Address Registration Option used in the ND registration SHOULD
be extended to carry the relevant forms of Unique Interface be extended to carry the relevant forms of Unique Interface
IDentifier. IDentifier.
o The Neighbour Discovery should specify the formation of a site- o The Neighbour Discovery should specify the formation of a site-
local address that follows the security recommendations from local address that follows the security recommendations from
[RFC7217]. [RFC7217].
Authors' Addresses Appendix B. Representation Conventions
B.1. Signature Schemes
The signature scheme ECDSA256 corresponding to Crypto-Type 0 is
ECDSA, as specified in [FIPS186-4], instantiated with the NIST prime
curve P-256, as specified in Appendix B of [FIPS186-4], and the hash
function SHA-256, as specified in [RFC6234], where points of this
NIST curve are represented as points of a short-Weierstrass curve
(see [FIPS186-4]) and are encoded as octet strings in most-
significant-bit first (msb) and most-significant-byte first (MSB)
order. The signature itself consists of two integers (r and s),
which are each encoded as fixed-size octet strings in most-
significant-bit first and most-significant-byte first order. For
details on ECDSA, see [FIPS186-4]; for details on the integer
encoding, see Appendix B.2.
The signature scheme Ed25519 corresponding to Crypto-Type 1 is EdDSA,
as specified in [RFC8032], instantiated with the Montgomery curve
Curve25519, as specified in [RFC7748], and the hash function SHA-512,
as specified in [RFC6234], where points of this Montgomery curve are
represented as points of the corresponding twisted Edwards curve (see
Appendix B.3) and are encoded as octet strings in least-significant-
bit first (lsb) and least-significant-byte first (LSB) order. The
signature itself consists of a bit string that encodes a point of
this twisted Edwards curve, in compressed format, and an integer
encoded in least-significant-bit first and least-significant-byte
first order. For details on EdDSA and on the encoding conversions,
see the specification of pure Ed25519 in . [RFC8032]
The signature scheme ECDSA25519 corresponding to Crypto-Type 2 is
ECDSA, as specified in [FIPS186-4], instantiated with the Montgomery
curve Curve25519, as specified in [RFC7748], and the hash function
SHA-256, as specified in [RFC6234], where points of this Montgomery
curve are represented as points of a corresponding curve in short-
Weierstrass form (see Appendix B.3) and are encoded as octet strings
in most-significant-bit first and most-significant-byte first order.
The signature itself consists of a bit string that encodes two
integers, each encoded as fixed-size octet strings in most-
significant-bit first and most-significant-byte first order. For
details on ECDSA, see [FIPS186-4]; for details on the integer
encoding, see Appendix B.2
B.2. Integer Representation for ECDSA signatures
With ECDSA, each signature is a pair (r, s) of integers [FIPS186-4].
Each integer is encoded as a fixed-size 256-bit bit string, where
each integer is represented according to the Field Element to Octet
String and Octet String to Bit String conversion rules in [SEC1] and
where the ordered pair of integers is represented as the
rightconcatenation of the resulting representation values. The
inverse operation follows the corresponding Bit String to Octet
String and Octet String to Field Element conversion rules of [SEC1].
B.3. Alternative Representations of Curve25519
The elliptic curve Curve25519, as specified in [RFC7748], is a so-
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
elliptic curve in short-Weierstrass form, via a coordinate
transformation (a so-called isomorphic mapping). The parameters of
the Montgomery curve and the corresponding isomorphic curves in
twisted Edwards curve and short-Weierstrass form are as indicated
below. Here, the domain parameters of the Montgomery curve
Curve25519 and of the twisted Edwards curve Edwards25519 are as
specified in [RFC7748]; the domain parameters of the elliptic curve
Wei25519 in short-Weierstrass curve comply with Section 6.1.1 of
[FIPS186-4]. For details of the coordinate transformation referenced
above, see [RFC7748] and [I-D.ietf-lwig-curve-representations].
General parameters (for all curve models):
p 2^{255}-19
(=0x7fffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff ffffffed)
h 8
n 72370055773322622139731865630429942408571163593799076060019509382
85454250989
(=2^{252} + 0x14def9de a2f79cd6 5812631a 5cf5d3ed)
Montgomery curve-specific parameters (for Curve25519):
A 486662
B 1
Gu 9 (=0x9)
Gv 14781619447589544791020593568409986887264606134616475288964881837
755586237401
(=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2
29e9c5a2 7eced3d9)
Twisted Edwards curve-specific parameters (for Edwards25519):
a -1 (-0x01)
d -121665/121666
(=370957059346694393431380835087545651895421138798432190163887855
33085940283555)
(=0x52036cee 2b6ffe73 8cc74079 7779e898 00700a4d 4141d8ab
75eb4dca 135978a3)
Gx 15112221349535400772501151409588531511454012693041857206046113283
949847762202
(=0x216936d3 cd6e53fe c0a4e231 fdd6dc5c 692cc760 9525a7b2
c9562d60 8f25d51a)
Gy 4/5
(=463168356949264781694283940034751631413079938662562256157830336
03165251855960)
(=0x66666666 66666666 66666666 66666666 66666666 66666666
66666666 66666658)
Weierstrass curve-specific parameters (for Wei25519):
a 19298681539552699237261830834781317975544997444273427339909597334
573241639236
(=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa
aaaaaa98 4914a144)
b 55751746669818908907645289078257140818241103727901012315294400837
956729358436
(=0x7b425ed0 97b425ed 097b425e d097b425 ed097b42 5ed097b4
260b5e9c 7710c864)
GX 19298681539552699237261830834781317975544997444273427339909597334
652188435546
(=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa
aaaaaaaa aaad245a)
GY 14781619447589544791020593568409986887264606134616475288964881837
755586237401
(=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2
29e9c5a2 7eced3d9)
Authors' Addresses
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D
45 Allee des Ormes - BP1200 45 Allee des Ormes - BP1200
MOUGINS - Sophia Antipolis 06254 MOUGINS - Sophia Antipolis 06254
FRANCE FRANCE
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
Mohit Sethi Mohit Sethi
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: mohit@piuha.net Email: mohit@piuha.net
Rene Struik Rene Struik
Struik Security Consultancy Struik Security Consultancy
 End of changes. 72 change blocks. 
185 lines changed or deleted 358 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/