idnits 2.17.00 (12 Aug 2021) /tmp/idnits51827/draft-ietf-ipsecme-eddsa-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2017) is 1896 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 8032 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSecME Working Group Y. Nir 3 Internet-Draft Check Point 4 Intended status: Standards Track March 12, 2017 5 Expires: September 13, 2017 7 Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet 8 Key Exchange (IKEv2) 9 draft-ietf-ipsecme-eddsa-01 11 Abstract 13 This document describes the use of the Edwards-curve digital 14 signature algorithm in the IKEv2 protocol. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 13, 2017. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 52 2. The "Identity" Hash Identifier . . . . . . . . . . . . . . . 3 53 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 55 5. Normative References . . . . . . . . . . . . . . . . . . . . 3 56 Appendix A. ASN.1 Objects . . . . . . . . . . . . . . . . . . . 5 57 A.1. ASN.1 Object for Ed25519 . . . . . . . . . . . . . . . . 5 58 A.2. ASN.1 Object for Ed448 . . . . . . . . . . . . . . . . . 5 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 61 1. Introduction 63 The Internet Key Exchange protocol [RFC7296] can use arbitrary 64 signature algorithms as described in [RFC7427]. The latter RFC 65 defines the SIGNATURE_HASH_ALGORITHMS notification where each side of 66 the IKE negotiation lists its supported hash algorithms. This 67 assumes that all signature schemes involve a hashing phase followed 68 by a signature phase. This made sense because most signature 69 algorithms either cannot sign messages bigger than their key or 70 truncate messages bigger than their key. 72 EdDSA ([RFC8032]) defines signature methods that do not require pre- 73 hashing of the message. Unlike other methods, these accept 74 arbitrary-sized messages, so no pre-hashing is required. These 75 methods are called Ed25519 and Ed448, which respectively use the 76 Edwards 25519 and the Edwards 448 ("Goldilocks") curves. Although 77 that document also defines pre-hashed versions of these algorithm, 78 those versions are not recommended for protocols where the entire to- 79 be-signed message is available at once. See section 8.5 or RFC 8032 80 for that recommendation. 82 EdDSA defines the binary format of the signatures that should be used 83 in the "Signature Value" field of the Authentication Data Format in 84 section 3. The CURDLE PKIX document ([I.D-curdle-pkix]) defines the 85 object identifiers (OIDs) for these signature methods. For 86 convenience, these OIDs are repeated in Appendix A. 88 In order to signal within IKE that no hashing needs to be done, we 89 define a new value has in the SIGNATURE_HASH_ALGORITHMS notification, 90 one that indicates that no hashing is performed. 92 1.1. Conventions Used in This Document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2. The "Identity" Hash Identifier 100 This document defines a new value called "Identity" (value TBA by 101 IANA) in the hash algorithm registry for use in the 102 SIGNATURE_HASH_ALGORITHMS notification. Inserting this new value 103 into the notification indicates that the receiver supports at least 104 one signature algorithm that accepts arbitrary-sized messages such as 105 Ed25519 and Ed448. 107 Ed25519 and Ed448 are only defined with the Identity hash, and MUST 108 NOT be sent to a receiver that has not indicated support for the 109 "Identity" hash. 111 The pre-hashed versions of Ed25519 and Ed448 (Ed25519ph and Ed448ph 112 respectively) SHOULD NOT be used in IKE. 114 3. Security Considerations 116 The new "Identity" value is needed only for signature algorithms that 117 accept an arbitrary-sized input. It MUST NOT be used if none of the 118 supported algorithms has this property. On the other hand there is 119 no good reason to pre-hash the inputs where the signature algorithm 120 either does not require it or performs a hash internally. For this 121 reason implementations SHOULD have the "Identity" value in the 122 SIGNATURE_HASH_ALGORITHMS notification when they support EdDSA. 123 Implementations SHOULD NOT have other hash algorithms in the 124 notification if all signature algorithms have this property. 126 4. IANA Considerations 128 IANA is requested to assign a new value from the "IKEv2 Hash 129 Algorithms" registry with name "Identity" and this document as 130 reference. 132 5. Normative References 134 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 135 Requirement Levels", BCP 14, RFC 2119, 136 DOI 10.17487/RFC2119, March 1997, 137 . 139 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 140 Kivinen, "Internet Key Exchange Protocol Version 2 141 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 142 2014, . 144 [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in 145 the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, 146 DOI 10.17487/RFC7427, January 2015, 147 . 149 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 150 Signature Algorithm (EdDSA)", RFC 8032, 151 DOI 10.17487/RFC8032, January 2017, 152 . 154 [I.D-curdle-pkix] 155 Josefsson, S. and J. Schaad, "Algorithm Identifiers for 156 Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for 157 use in the Internet X.509 Public Key Infrastructure", 158 November 2016, . 161 Appendix A. ASN.1 Objects 163 The normative reference for the ASN.1 objects for Ed25519 and Ed448 164 is in [I.D-curdle-pkix]. They are repeated below for convenience. 166 A.1. ASN.1 Object for Ed25519 168 id-Ed25519 OBJECT IDENTIFIER ::= { 1.3.101.112 } 170 Parameters are absent. Length is 7 bytes. 172 Binary encoding: 3005 0603 2B65 70 174 A.2. ASN.1 Object for Ed448 176 id-Ed448 OBJECT IDENTIFIER ::= { 1.3.101.113 } 178 Parameters are absent. Length is 7 bytes. 180 Binary encoding: 3005 0603 2B65 71 182 Author's Address 184 Yoav Nir 185 Check Point Software Technologies Ltd. 186 5 Hasolelim st. 187 Tel Aviv 6789735 188 Israel 190 EMail: ynir.ietf@gmail.com