draft-ietf-6lo-ap-nd-17.txt   draft-ietf-6lo-ap-nd-18.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. Sarikaya
Intended status: Standards Track Intended status: Standards Track
Expires: 7 August 2020 M.S. Sethi Expires: 8 August 2020 M. Sethi
Ericsson Ericsson
R.S. Struik R. Struik
Struik Security Consultancy Struik Security Consultancy
4 February 2020 5 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-17 draft-ietf-6lo-ap-nd-18
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 7 August 2020. This Internet-Draft will expire on 8 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 44 skipping to change at page 2, line 44
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 . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . 19 7.4. Implementation Attacks . . . . . . . . . . . . . . . . . 19
7.5. Cross-Algorithm and Cross-Protocol Attacks . . . . . . . 19 7.5. Cross-Algorithm and Cross-Protocol Attacks . . . . . . . 19
7.6. Compromised 6LR . . . . . . . . . . . . . . . . . . . . . 19 7.6. Compromised 6LR . . . . . . . . . . . . . . . . . . . . . 19
7.7. Correlating Registrations . . . . . . . . . . . . . . . . 20
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20
8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 20 8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 20
8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 20 8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 20
8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 20 8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 21
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. Normative References . . . . . . . . . . . . . . . . . . . . 21 10. Normative References . . . . . . . . . . . . . . . . . . . . 22
11. Informative references . . . . . . . . . . . . . . . . . . . 23 11. Informative references . . . . . . . . . . . . . . . . . . . 23
Appendix A. Requirements Addressed in this Document . . . . . . 24 Appendix A. Requirements Addressed in this Document . . . . . . 25
Appendix B. Representation Conventions . . . . . . . . . . . . . 25 Appendix B. Representation Conventions . . . . . . . . . . . . . 25
B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 25 B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 25
B.2. Integer Representation for ECDSA signatures . . . . . . . 26 B.2. Integer Representation for ECDSA signatures . . . . . . . 26
B.3. Alternative Representations of Curve25519 . . . . . . . . 26 B.3. Alternative Representations of Curve25519 . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 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)
skipping to change at page 7, line 44 skipping to change at page 7, line 44
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 alternative.
* This specification uses signature schemes which target similar * This specification uses signature schemes that target similar
cryptographic strength but rely on different curves, hash cryptographic strength but rely on different curves, hash
functions, signature algorithms, and/or representation functions, signature algorithms, and/or representation
conventions. Future specification may extend this for different conventions. Future specification may extend this to different
cryptographic algorithms and longer keys, e.g., to provide a cryptographic algorithms and key sizes, e.g., to provide better
better security properties or a simpler implementation. security properties or a simpler implementation.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Reserved1| Public Key Length | | Type | Length |Reserved1| Public Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crypto-Type | Modifier | EARO Length | Reserved2 | | Crypto-Type | Modifier | EARO Length | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
skipping to change at page 9, line 35 skipping to change at page 9, line 35
4.4. NDP Signature Option 4.4. NDP Signature Option
This specification defines the NDP Signature Option (NDPSO). The This specification defines the NDP Signature Option (NDPSO). The
NDPSO carries the signature that proves the ownership of the Crypto- NDPSO carries the signature that proves the ownership of the Crypto-
ID. The format of the NDPSO is illustrated in Figure 3. ID. The format of the NDPSO is illustrated in Figure 3.
As opposed to the RSA Signature Option (RSAO) defined in section 5.2. As opposed to the RSA Signature Option (RSAO) defined in section 5.2.
of SEND [RFC3971], the NDPSO does not have a key hash field. of SEND [RFC3971], the NDPSO does not have a key hash field.
Instead, the leftmost 128 bits of the ROVR field in the EARO are used Instead, the leftmost 128 bits of the ROVR field in the EARO are used
to retrieve the CIPO that contains the key material used for as hash to retrieve the CIPO that contains the key material used for
signature verification, left-padded if needed. signature verification, left-padded if needed.
Another difference is that the NDPSO signs a fixed set of fields as Another difference is that the NDPSO signs a fixed set of fields as
opposed to all options that appear prior to it in the ND message that opposed to all options that appear prior to it in the ND message that
bears the signature. This allows to elide a CIPO that the 6LR bears the signature. This allows to elide a CIPO that the 6LR
already received, at the expense of the capability to add arbitrary already received, at the expense of the capability to add arbitrary
options that would signed with a RSAO. options that would signed with a RSAO.
An ND message that carries an NDPSO MUST have one and only one EARO. An ND message that carries an NDPSO MUST have one and only one EARO.
The EARO MUST contain a Crypto-ID in the ROVR field, and the Crypto- The EARO MUST contain a Crypto-ID in the ROVR field, and the Crypto-
skipping to change at page 19, line 30 skipping to change at page 19, line 30
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-Algorithm and Cross-Protocol Attacks 7.5. Cross-Algorithm and Cross-Protocol Attacks
The keypair used in this specification can be self-generated and the The keypair used in this specification can be self-generated and the
public key does not need to be exchanged, e.g., through certificates, public key does not need to be exchanged, e.g., through certificates,
with a third party before it is used. New keypairs can be formed for with a third party before it is used. New keypairs can be formed for
new registration as the node desires. On the other hand, it is safer new registration as the node desires. On the other hand, it is safer
to allocate a keypair that is used only for the address protection to allocate a keypair that is used only for the address protection
and only for one signature scheme. The same private key MUST NOT be and only for one instantiation of the signature scheme (which
reused with more than one signature scheme in this specification. includes choice of elliptic curve domain parameters, used hash
The same private key MUST NOT be used for anything other than function, and applicable representation conventions). The same
computing NDPSO signatures per this specification. private key MUST NOT be reused with more than one instantiation of
the 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. This protects the edge of the network, between the 6LN and its 6LR. This protects
against DOS attacks targeted at that central 6LBR. This also saves against DOS attacks targeted at that central 6LBR. This also saves
back and forth exchanges across a potentially large and constrained back and forth exchanges across a potentially large and constrained
network. The downside is that the 6LBR needs to trust the 6LR for network. The downside is that the 6LBR needs to trust the 6LR for
performing the checking adequately, and the communication between the performing the checking adequately, and the communication between the
6LR and the 6LBR must be protected to avoid tempering with the result 6LR and the 6LBR must be protected to avoid tempering with the result
of the test. of the test. If a 6LR is compromised, and provided that it knows the
ROVR field used by the real owner of the address, the 6LR may pretend
that the owner has moved, is now attached to it and has successfully
passed the Crpto-ID validation. The 6LR may then attract and inject
traffic at will on behalf of that address or let a rogue take
ownership of the address.
If a 6LR is compromised, and provided that it knows the ROVR field 7.7. Correlating Registrations
used by the real owner of the address, the 6LR may pretend that the
owner has moved, is now attached to it and has successfully passed The ROVR field in the EARO introduced in [RFC8505] extends the EUI-64
the Crpto-ID validation. The 6LR may then attract and inject traffic field of the ARO defined in [RFC6775]. One of the drawbacks of using
at will on behalf of that address. Similarly, the 6LR may admit any an EUI-64 as ROVR is that an attacker that is aware of the
rogue and let it take ownership of any address in the network for registrations can correlate traffic for a same 6LN across multiple
which it knows the value of ROVR. addresses. Section 3 of [RFC8505] indicates that the ROVR and the
address being registered are decoupled. A 6LN may use a same ROVR
for multiple registrations or a different ROVR per registration, and
the IID must not derive from the ROVR. In theory different 6LNs
could use a same ROVR as long as they do not attempt to register the
same address.
The Modifier used in the computation of the Crypto-ID enables a 6LN
to build different Crypto-IDs for different addresses with a same
keypair. Using that facility improves the privacy of the 6LN as the
expense of storage in the 6LR, which will need to store multiple
CIPOs that contain the same private key. Note that if the attacker
is the 6LR, then the Modifier alone does not provide a protection,
and the 6LN would need to use different keys and MAC addresses in an
attempt to obfuscate its multiple ownership.
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 21, line 5 skipping to change at page 21, line 15
8.3. Crypto-Type Subregistry 8.3. Crypto-Type Subregistry
IANA is requested to create a new subregistry "Crypto-Type IANA is requested to create a new subregistry "Crypto-Type
Subregistry" in the "Internet Control Message Protocol version 6 Subregistry" in the "Internet Control Message Protocol version 6
(ICMPv6) Parameters". The registry is indexed by an integer in the (ICMPv6) Parameters". The registry is indexed by an integer in the
interval 0..255 and contains an Elliptic Curve, a Hash Function, a interval 0..255 and contains an Elliptic Curve, a Hash Function, a
Signature Algorithm, and Representation Conventions, as shown in Signature Algorithm, 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 |
| value | | | | | value | | | (ECDSA25519) |
+================+=================+=============+=================+ +================+===============+===============+===============+
| Elliptic curve | NIST P-256 | Curve25519 | Curve25519 | | Elliptic curve | NIST P-256 | Curve25519 | Curve25519 |
| | [FIPS186-4] | [RFC7748] | [RFC7748] | | | [FIPS186-4] | [RFC7748] | [RFC7748] |
+----------------+-----------------+-------------+-----------------+ +----------------+---------------+---------------+---------------+
| 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 | uncompressed, | compressed, | compressed, |
| | MSB/msb first | LSB/lsb | MSB/msb first | | | MSB/msb first | LSB/lsb first | MSB/msb first |
| | | first | | +----------------+---------------+---------------+---------------+
+----------------+-----------------+-------------+-----------------+ | Defining | This document | This document | This document |
| Defining | This document | This | This document | | specification | | | |
| specification | | document | | +----------------+---------------+---------------+---------------+
+----------------+-----------------+-------------+-----------------+
Table 2: Crypto-Types Table 2: Crypto-Types
New Crypto-Type values providing similar or better security may be New Crypto-Type values providing similar or better security may be
defined in the future. defined in the future.
Assignment of new values for new Crypto-Type MUST be done through Assignment of new values for new Crypto-Type MUST be done through
IANA with either "Specification Required" or "IESG Approval" as IANA with either "Specification Required" or "IESG Approval" as
defined in [RFC8126]. defined in [RFC8126].
skipping to change at page 26, line 8 skipping to change at page 26, line 16
as specified in [RFC8032], instantiated with the Montgomery curve as specified in [RFC8032], instantiated with the Montgomery curve
Curve25519, as specified in [RFC7748], and the hash function SHA-512, Curve25519, as specified in [RFC7748], and the hash function SHA-512,
as specified in [RFC6234], where points of this Montgomery curve are as specified in [RFC6234], where points of this Montgomery curve are
represented as points of the corresponding twisted Edwards curve (see represented as points of the corresponding twisted Edwards curve (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 [RFC7748], and the hash function
SHA-256, as specified in [RFC6234], where points of this Montgomery SHA-256, as specified in [RFC6234], where points of this Montgomery
curve are represented as points of a corresponding curve in short- curve are represented as points of 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
B.2. Integer Representation for ECDSA signatures B.2. Integer Representation for ECDSA signatures
With ECDSA, each signature is a pair (r, s) of integers [FIPS186-4]. With ECDSA, each signature is an ordered pair (r, s) of integers
Each integer is encoded as a fixed-size 256-bit bit string, where [FIPS186-4]. Each integer is encoded as a fixed-size 256-bit bit
each integer is represented according to the Field Element to Octet string, where each integer is represented according to the Field
String and Octet String to Bit String conversion rules in [SEC1] and Element to Octet String and Octet String to Bit String conversion
where the ordered pair of integers is represented as the rules in [SEC1] and where the ordered pair of integers is represented
rightconcatenation of the resulting representation values. The as the rightconcatenation of the resulting representation values.
inverse operation follows the corresponding Bit String to Octet The 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 [RFC7748], is a so-
called Montgomery curve. Each point of this curve can also be called Montgomery curve. Each point of this curve can also be
represented as a point of a twisted Edwards curve or as a point of an represented as a point of a twisted Edwards curve or as a point of an
elliptic curve in short-Weierstrass form, via a coordinate elliptic curve in short-Weierstrass form, via a coordinate
transformation (a so-called isomorphic mapping). The parameters of transformation (a so-called isomorphic mapping). The parameters of
the Montgomery curve and the corresponding isomorphic curves in the Montgomery curve and the corresponding isomorphic curves in
twisted Edwards curve and short-Weierstrass form are as indicated twisted Edwards curve and short-Weierstrass form are as indicated
below. Here, the domain parameters of the Montgomery curve below. Here, the domain parameters of the Montgomery curve
Curve25519 and of the twisted Edwards curve Edwards25519 are as Curve25519 and of the twisted Edwards curve Edwards25519 are as
specified in [RFC7748]; the domain parameters of the elliptic curve specified in [RFC7748]; the domain parameters of the elliptic curve
Wei25519 in short-Weierstrass curve comply with Section 6.1.1 of Wei25519 in short-Weierstrass curve comply with Section 6.1.1 of
[FIPS186-4]. For details of the coordinate transformation referenced [FIPS186-4]. For details of the coordinate transformations
above, see [RFC7748] and [CURVE-REPRESENTATIONS]. referenced above, see [RFC7748] and [CURVE-REPRESENTATIONS].
General parameters (for all curve models): General parameters (for all curve models):
p 2^{255}-19 p 2^{255}-19
(=0x7fffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff (=0x7fffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffed) ffffffed)
h 8 h 8
n n
723700557733226221397318656304299424085711635937990760600195093828 723700557733226221397318656304299424085711635937990760600195093828
5454250989 5454250989
 End of changes. 21 change blocks. 
58 lines changed or deleted 80 lines changed or added

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