< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/