wdiff rfc8420.original rfc8420.txt

IPSecME Working Group
Internet Engineering Task Force (IETF) Y. Nir
Internet-Draft
Request for Comments: 8420 Dell EMC
Intended status:
Category: Standards Track October 26, 2017
Expires: April 29, August 2018
ISSN: 2070-1721

Using Edwards-curve the Edwards-Curve Digital Signature Algorithm (EdDSA) in the
Internet Key Exchange Protocol Version 2 (IKEv2)
draft-ietf-ipsecme-eddsa-04

Abstract

This document describes the use of the Edwards-curve digital
signature algorithm Digital
Signature Algorithm (EdDSA) in the IKEv2 protocol. Internet Key Exchange Protocol
Version 2 (IKEv2).

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 29, 2018.
https://www.rfc-editor.org/info/rfc8420.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 ....................................................2
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 ..........................3
2. The "Identity" Hash Identifier . . . . . . . . . . . . . . . 3 ..................................3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 .........................................3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 .............................................3
5. Normative References . . . . . . . . . . . . . . . . . . . . 3 ............................................3
Appendix A. ASN.1 Objects . . . . . . . . . . . . . . . . . . . 5 .........................................4
A.1. ASN.1 Object for Ed25519 . . . . . . . . . . . . . . . . 5 ...................................4
A.2. ASN.1 Object for Ed448 . . . . . . . . . . . . . . . . . 5 .....................................4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 ...................................................5

1. Introduction

The Internet Key Exchange protocol Protocol Version 2 [RFC7296] can use
arbitrary signature algorithms as described in [RFC7427]. The latter RFC [RFC7427]
defines the SIGNATURE_HASH_ALGORITHMS notification where each side of
the IKE negotiation lists its supported hash algorithms. This
assumes that all signature schemes involve a hashing phase followed
by a signature phase. This made sense because most signature
algorithms either cannot sign messages bigger than their key or
truncate messages bigger than their key.

EdDSA ([RFC8032]) [RFC8032] defines signature methods that do not require pre-
hashing
prehashing of the message. Unlike other methods, these accept
arbitrary-sized messages,
messages of arbitrary size, so no pre-hashing prehashing is required. These
methods are called Ed25519 and Ed448, which respectively Ed448; they use the Edwards 25519 and
the Edwards 448 ("Goldilocks") curves. curves, respectively. Although that
document also defines pre-hashed prehashed versions of these algorithm, algorithms, those
versions are not recommended for protocols where there is minimal
burden in buffering the entire to-
be-signed message so as to make it practical to
make two passes over the message. This is available at once. true of IKEv2. See section
Section 8.5 or RFC 8032 of [RFC8032] for that recommendation.

EdDSA defines the binary format of the signatures that should be used
in the "Signature Value" field of the Authentication Data Format in
section 3. The CURDLE PKIX document ([I.D-curdle-pkix])
Section 3 of RFC 8032. [RFC8410] defines the object identifiers
(OIDs) for these signature methods. For convenience, these OIDs are
repeated in Appendix A.

In order to signal within IKE that no hashing needs to be done, we
define a new value in the SIGNATURE_HASH_ALGORITHMS notification, one
that indicates notification to
indicate that no hashing is performed.

1.1. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in [RFC2119].
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

2. The "Identity" Hash Identifier

This document defines a new value called "Identity" (value is 5) (5) in the hash algorithm "IKEv2
Hash Algorithms" registry for use in the SIGNATURE_HASH_ALGORITHMS
notification. Inserting this new value into the notification
indicates that the receiver supports at least one signature algorithm
that accepts arbitrary-sized messages of arbitrary size such as Ed25519 and Ed448.

Ed25519 and Ed448 are only defined with the Identity hash, "Identity" hash and MUST
NOT be sent to a receiver that has not indicated support for the
"Identity" hash.

The pre-hashed prehashed versions of Ed25519 and Ed448 (Ed25519ph and Ed448ph Ed448ph,
respectively) MUST NOT be used in IKE.

3. Security Considerations

The new "Identity" value is needed only for signature algorithms that
accept an arbitrary-sized input. input of arbitrary size. It MUST NOT be used if none of
the supported and configured algorithms have this property. On the
other
hand hand, there is no good reason to pre-hash prehash the inputs where the
signature algorithm has that property. For this reason reason,
implementations MUST have the "Identity" value in the
SIGNATURE_HASH_ALGORITHMS notification when EdDSA is supported and
configured. Implementations SHOULD NOT have other hash algorithms in
the notification if all supported and configured signature algorithms
have this property.

4. IANA Considerations

IANA has assigned the value 5 for the algorithm with the name
"Identity" in the "IKEv2 Hash Algorithms" registry with this draft as
reference.

Upon publication of this document IANA is requested to update the
entry with this document
as reference.

5. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.

[RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in
the Internet Key Exchange Version 2 (IKEv2)", RFC 7427,
DOI 10.17487/RFC7427, January 2015,
<https://www.rfc-editor.org/info/rfc7427>.

[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.

[I.D-curdle-pkix]

[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>.

[RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for
Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 X25519, and X448 for
use Use in the Internet
X.509 Public Key Infrastructure",
September 2017,
<https://tools.ietf.org/html/draft-ietf-curdle-pkix-06>. RFC 8410,
DOI 10.17487/RFC8410, August 2018,
<https://www.rfc-editor.org/info/rfc8410>.

Appendix A. ASN.1 Objects

The

[RFC8410] is the normative reference for the ASN.1 objects for
Ed25519 and Ed448
is in [I.D-curdle-pkix]. Ed448. They are repeated below for convenience.

A.1. ASN.1 Object for Ed25519

id-Ed25519 OBJECT IDENTIFIER ::= { 1.3.101.112 }

Parameters are absent. Length is 7 bytes.

Binary encoding: 3005 0603 2B65 70

A.2. ASN.1 Object for Ed448

id-Ed448 OBJECT IDENTIFIER ::= { 1.3.101.113 }

Parameters are absent. Length is 7 bytes.

Binary encoding: 3005 0603 2B65 71

Author's Address

Yoav Nir
Dell EMC
9 Andrei Sakharov St
Haifa 3190500
Israel

EMail:

Email: ynir.ietf@gmail.com