idnits 2.17.1 draft-ietf-ipsecme-eddsa-04.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 (October 26, 2017) is 2373 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 Dell EMC 4 Intended status: Standards Track October 26, 2017 5 Expires: April 29, 2018 7 Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet 8 Key Exchange (IKEv2) 9 draft-ietf-ipsecme-eddsa-04 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 https://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 April 29, 2018. 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 (https://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 in the SIGNATURE_HASH_ALGORITHMS notification, one 90 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 is 5) in 101 the hash algorithm registry for use in the SIGNATURE_HASH_ALGORITHMS 102 notification. Inserting this new value into the notification 103 indicates that the receiver supports at least one signature algorithm 104 that accepts arbitrary-sized messages such as Ed25519 and Ed448. 106 Ed25519 and Ed448 are only defined with the Identity hash, and MUST 107 NOT be sent to a receiver that has not indicated support for the 108 "Identity" hash. 110 The pre-hashed versions of Ed25519 and Ed448 (Ed25519ph and Ed448ph 111 respectively) MUST NOT be used in IKE. 113 3. Security Considerations 115 The new "Identity" value is needed only for signature algorithms that 116 accept an arbitrary-sized input. It MUST NOT be used if none of the 117 supported and configured algorithms have this property. On the other 118 hand there is no good reason to pre-hash the inputs where the 119 signature algorithm has that property. For this reason 120 implementations MUST have the "Identity" value in the 121 SIGNATURE_HASH_ALGORITHMS notification when EdDSA is supported and 122 configured. Implementations SHOULD NOT have other hash algorithms in 123 the notification if all supported and configured signature algorithms 124 have this property. 126 4. IANA Considerations 128 IANA has assigned the value 5 for the algorithm with the name 129 "Identity" in the "IKEv2 Hash Algorithms" registry with this draft as 130 reference. 132 Upon publication of this document IANA is requested to update the 133 entry with this document as reference. 135 5. Normative References 137 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 138 Requirement Levels", BCP 14, RFC 2119, 139 DOI 10.17487/RFC2119, March 1997, 140 . 142 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 143 Kivinen, "Internet Key Exchange Protocol Version 2 144 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 145 2014, . 147 [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in 148 the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, 149 DOI 10.17487/RFC7427, January 2015, 150 . 152 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 153 Signature Algorithm (EdDSA)", RFC 8032, 154 DOI 10.17487/RFC8032, January 2017, 155 . 157 [I.D-curdle-pkix] 158 Josefsson, S. and J. Schaad, "Algorithm Identifiers for 159 Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for 160 use in the Internet X.509 Public Key Infrastructure", 161 September 2017, 162 . 164 Appendix A. ASN.1 Objects 166 The normative reference for the ASN.1 objects for Ed25519 and Ed448 167 is in [I.D-curdle-pkix]. They are repeated below for convenience. 169 A.1. ASN.1 Object for Ed25519 171 id-Ed25519 OBJECT IDENTIFIER ::= { 1.3.101.112 } 173 Parameters are absent. Length is 7 bytes. 175 Binary encoding: 3005 0603 2B65 70 177 A.2. ASN.1 Object for Ed448 179 id-Ed448 OBJECT IDENTIFIER ::= { 1.3.101.113 } 181 Parameters are absent. Length is 7 bytes. 183 Binary encoding: 3005 0603 2B65 71 185 Author's Address 187 Yoav Nir 188 Dell EMC 189 9 Andrei Sakharov St 190 Haifa 3190500 191 Israel 193 EMail: ynir.ietf@gmail.com