1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc8420.txt b/doc/rfc/rfc8420.txt
new file mode 100644
index 0000000..b11e7f8
--- /dev/null
+++ b/doc/rfc/rfc8420.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                            Y. Nir
+Request for Comments: 8420                                      Dell EMC
+Category: Standards Track                                    August 2018
+ISSN: 2070-1721
+
+
+   Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the
+            Internet Key Exchange Protocol Version 2 (IKEv2)
+
+Abstract
+
+   This document describes the use of the Edwards-curve Digital
+   Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol
+   Version 2 (IKEv2).
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for 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 this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8420.
+
+Copyright Notice
+
+   Copyright (c) 2018 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+
+
+
+
+
+
+
+Nir                          Standards Track                    [Page 1]
+
+RFC 8420                     EdDSA in IKEv2                  August 2018
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Conventions Used in This Document ..........................3
+   2. The "Identity" Hash Identifier ..................................3
+   3. Security Considerations .........................................3
+   4. IANA Considerations .............................................3
+   5. Normative References ............................................3
+   Appendix A.  ASN.1 Objects .........................................4
+     A.1.  ASN.1 Object for Ed25519 ...................................4
+     A.2.  ASN.1 Object for Ed448 .....................................4
+   Author's Address ...................................................5
+
+1.  Introduction
+
+   The Internet Key Exchange Protocol Version 2 [RFC7296] can use
+   arbitrary signature algorithms as described in [RFC7427].  [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] defines signature methods that do not require
+   prehashing of the message.  Unlike other methods, these accept
+   messages of arbitrary size, so no prehashing is required.  These
+   methods are called Ed25519 and Ed448; they use the Edwards 25519 and
+   the Edwards 448 ("Goldilocks") curves, respectively.  Although that
+   document also defines prehashed versions of these algorithms, those
+   versions are not recommended for protocols where there is minimal
+   burden in buffering the entire message so as to make it practical to
+   make two passes over the message.  This is true of IKEv2.  See
+   Section 8.5 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 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 to
+   indicate that no hashing is performed.
+
+
+
+
+
+
+
+Nir                          Standards Track                    [Page 2]
+
+RFC 8420                     EdDSA in IKEv2                  August 2018
+
+
+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
+   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" (5) in the "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 messages of arbitrary size such as Ed25519 and Ed448.
+
+   Ed25519 and Ed448 are only defined with the "Identity" hash and MUST
+   NOT be sent to a receiver that has not indicated support for the
+   "Identity" hash.
+
+   The prehashed versions of Ed25519 and Ed448 (Ed25519ph and Ed448ph,
+   respectively) MUST NOT be used in IKE.
+
+3.  Security Considerations
+
+   The new "Identity" value is needed only for signature algorithms that
+   accept an input of arbitrary size.  It MUST NOT be used if none of
+   the supported and configured algorithms have this property.  On the
+   other hand, there is no good reason to prehash the inputs where the
+   signature algorithm has that property.  For this 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 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>.
+
+
+
+Nir                          Standards Track                    [Page 3]
+
+RFC 8420                     EdDSA in IKEv2                  August 2018
+
+
+   [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>.
+
+   [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, Ed448, X25519, and X448 for Use in the Internet
+              X.509 Public Key Infrastructure", RFC 8410,
+              DOI 10.17487/RFC8410, August 2018,
+              <https://www.rfc-editor.org/info/rfc8410>.
+
+Appendix A.  ASN.1 Objects
+
+   [RFC8410] is the normative reference for the ASN.1 objects for
+   Ed25519 and 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
+
+
+
+
+
+
+Nir                          Standards Track                    [Page 4]
+
+RFC 8420                     EdDSA in IKEv2                  August 2018
+
+
+Author's Address
+
+   Yoav Nir
+   Dell EMC
+   9 Andrei Sakharov St
+   Haifa  3190500
+   Israel
+
+   Email: ynir.ietf@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir                          Standards Track                    [Page 5]
+