idnits 2.17.1 draft-ietf-ipsecme-eddsa-00.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 28, 2016) is 2736 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) No issues found here. Summary: 0 errors (**), 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 October 28, 2016 5 Expires: May 1, 2017 7 Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet 8 Key Exchange (IKEv2) 9 draft-ietf-ipsecme-eddsa-00 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 May 1, 2017. 33 Copyright Notice 35 Copyright (c) 2016 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 . . . . . . . . . . . . 2 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 ([I.D-eddsa]) defines signature methods that do not require 73 pre-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. 81 EdDSA defines the binary format of the signatures that should be used 82 in the "Signature Value" field of the Authentication Data Format in 83 section 3. The CURDLE PKIX document ([I.D-curdle-pkix]) defines the 84 object identifiers (OIDs) for these signature methods. For 85 convenience, these OIDs are repeated in Appendix A. 87 In order to signal within IKE that no hashing needs to be done, we 88 define a new value has in the SIGNATURE_HASH_ALGORITHMS notification, 89 one that indicates that no hashing is performed. 91 1.1. Conventions Used in This Document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. The "Identity" Hash Identifier 99 This document defines a new value called "Identity" (value TBA by 100 IANA) in the hash algorithm registry for use in the 101 SIGNATURE_HASH_ALGORITHMS notification. Inserting this new value 102 into the notification indicates that the receiver supports at least 103 one signature algorithm that accepts arbitrary-sized messages such as 104 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) SHOULD 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 algorithms has this property. On the other hand there is 118 no good reason to pre-hash the inputs where the signature algorithm 119 either does not require it or performs a hash internally. For this 120 reason implementations SHOULD have the "Identity" value in the 121 SIGNATURE_HASH_ALGORITHMS notification when they support EdDSA. 122 Implementations SHOULD NOT have other hash algorithms in the 123 notification if all signature algorithms have this property. 125 4. IANA Considerations 127 IANA is requested to assign a new value from the "IKEv2 Hash 128 Algorithms" registry with name "Identity" and this document as 129 reference. Since the value zero was reserved by RFC 7427 and this 130 "Identity" hash is no hash at all, assigning the value zero to 131 Identity seems appropriate. 133 5. Normative References 135 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 136 Requirement Levels", BCP 14, RFC 2119, 137 DOI 10.17487/RFC2119, March 1997, 138 . 140 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 141 Kivinen, "Internet Key Exchange Protocol Version 2 142 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 143 2014, . 145 [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in 146 the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, 147 DOI 10.17487/RFC7427, January 2015, 148 . 150 [I.D-eddsa] 151 Josefsson, S. and I. Liusvaara, "Edwards-curve Digital 152 Signature Algorithm (EdDSA)", August 2016, 153 . 156 [I.D-curdle-pkix] 157 Josefsson, S. and J. Schaad, "Algorithm Identifiers for 158 Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for 159 use in the Internet X.509 Public Key Infrastructure", 160 August 2016, . 163 Appendix A. ASN.1 Objects 165 The normative reference for the ASN.1 objects for Ed25519 and Ed448 166 is in [I.D-curdle-pkix]. They are repeated below for convenience. 168 A.1. ASN.1 Object for Ed25519 170 id-Ed25519 OBJECT IDENTIFIER ::= { 1.3.101.112 } 172 Parameters are absent. Length is 7 bytes. 174 Binary encoding: 3005 0603 2B65 70 176 A.2. ASN.1 Object for Ed448 178 id-Ed448 OBJECT IDENTIFIER ::= { 1.3.101.113 } 180 Parameters are absent. Length is 7 bytes. 182 Binary encoding: 3005 0603 2B65 71 184 Author's Address 186 Yoav Nir 187 Check Point Software Technologies Ltd. 188 5 Hasolelim st. 189 Tel Aviv 6789735 190 Israel 192 EMail: ynir.ietf@gmail.com