idnits 2.17.1 draft-ietf-curdle-ssh-curves-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2017) is 2579 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Adamantiadis 3 Internet-Draft libssh 4 Intended status: Informational S. Josefsson 5 Expires: September 28, 2017 SJD AB 6 M. Baushke 7 Juniper Networks, Inc. 8 March 27, 2017 10 Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448 11 draft-ietf-curdle-ssh-curves-01 13 Abstract 15 How to implement the Curve25519 and Curve448 key exchange methods in 16 the Secure Shell (SSH) protocol is described. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 28, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Shared Secret Encoding . . . . . . . . . . . . . . . . . 3 55 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 60 6.2. Informative References . . . . . . . . . . . . . . . . . 5 61 Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 In [Curve25519], a new elliptic curve function for use in 67 cryptographic applications was introduced. In [Ed448-Goldilocks] the 68 Ed448-Goldilocks curve (also known as Curve448) is described. In 69 [RFC7748], the Diffie-Hellman functions using Curve25519 and Curve448 70 are specified. 72 Secure Shell (SSH) [RFC4251] is a secure remote login protocol. The 73 key exchange protocol described in [RFC4253] supports an extensible 74 set of methods. [RFC5656] describes how elliptic curves are 75 integrated in SSH, and this document reuses those protocol messages. 77 This document describes how to implement key exchange based on 78 Curve25519 and Curve448 in SSH. For Curve25519 with SHA-256 79 [RFC4634], the algorithm we describe is equivalent to the privately 80 defined algorithm "curve25519-sha256@libssh.org", which is currently 81 implemented and widely deployed in libssh and OpenSSH. The Curve448 82 key exchange method is novel but similar in spirit, and we chose to 83 couple it with SHA-512 [RFC4634] to further separate it from the 84 Curve25519 alternative. 86 This document provide Curve25519 as the prefered choice, but suggests 87 that the fall back option Curve448 is implemented to provide an hedge 88 against unforseen analytical advances against Curve25519 and SHA-256. 89 Due to different implementation status of these two curves (high- 90 quality free implementations of Curve25519 has been in deployed use 91 for several years, while Curve448 implementations are slowly 92 appearing), it is accepted that adoption of Curve448 will be slower. 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 RFC 2119 [RFC2119]. 98 2. Key Exchange Methods 100 The key exchange procedure is similar to the ECDH method described in 101 chapter 4 of [RFC5656], though with a different wire encoding used 102 for public values and the final shared secret. Public ephemeral keys 103 are encoded for transmission as standard SSH strings. 105 The protocol flow, the SSH_MSG_KEX_ECDH_INIT and 106 SSH_MSG_KEX_ECDH_REPLY messages, and the structure of the exchange 107 hash are identical to chapter 4 of [RFC5656]. 109 The method names registered by this document are "curve25519-sha256" 110 and "curve448-sha512". 112 The methods are based on Curve25519 and Curve448 scalar 113 multiplication, as described in [RFC7748]. Private and public keys 114 are generated as described therein. Public keys are defined as 115 strings of 32 bytes for Curve25519 and 56 bytes for Curve448. 116 Clients and servers MUST fail the key exchange if the length of the 117 received public keys are not the expected lengths, or if the derived 118 shared secret only consists of zero bits. No further validation is 119 required beyond what is discussed in [RFC7748]. The derived shared 120 secret is 32 bytes when Curve25519 is used and 56 bytes when Curve448 121 is used. The encodings of all values are defined in [RFC7748]. The 122 hash used is SHA-256 for Curve25519 and SHA-512 for Curve448. 124 2.1. Shared Secret Encoding 126 The following step differs from [RFC5656], which uses a different 127 conversion. This is not intended to modify that text generally, but 128 only to be applicable to the scope of the mechanism described in this 129 document. 131 The shared secret, K, is defined in [RFC4253] as a multiple precision 132 integer (mpint). Curve25519/448 outputs a binary string X, which is 133 the 32 or 56 byte point obtained by scalar multiplication of the 134 other side's public key and the local private key scalar. The 32 or 135 56 bytes of X are converted into K by interpreting the bytes as an 136 unsigned fixed-length integer encoded in network byte order. This 137 conversion follows the normal "mpint" process as described in section 138 5 of [RFC4251]. 140 To clarify a corner-case in this conversion, when X is encoded as an 141 mpint K, in order to calculate the exchange hash, it may vary as 142 follows: 144 o If the high bit of X is set, the mpint format requires a zero byte 145 to be prepended. In this case, the length of the encoded K will 146 be larger. 148 o If X has leading zero bytes, the mpint format requires such bytes 149 to be skipped. In this case, the length of the encoded K will be 150 smaller. 152 3. Acknowledgements 154 The "curve25519-sha256" key exchange method is identical to the 155 "curve25519-sha256@libssh.org" key exchange method created by Aris 156 Adamantiadis and implemented in libssh and OpenSSH. 158 Thanks to the following people for review and comments: Denis Bider, 159 Damien Miller, Niels Moeller, Matt Johnston. 161 4. Security Considerations 163 The security considerations of [RFC4251], [RFC5656], and [RFC7748] 164 are inherited. 166 Curve25519 provide strong security and is efficient on a wide range 167 of architectures, and has properties that allows better 168 implementation properties compared to traditional elliptic curves. 169 Curve448 with SHA-512 is similar, but have not received the same 170 cryptographic review as Curve25519, and is slower, but it is provided 171 as an hedge to combat unforseen analytical advances against 172 Curve25519 and SHA-256. 174 The way the derived binary secret string is encoded into a mpint 175 before it is hashed (i.e., adding or removing zero-bytes for 176 encoding) raises the potential for a side-channel attack which could 177 determine the length of what is hashed. This would leak the most 178 significant bit of the derived secret, and/or allow detection of when 179 the most significant bytes are zero. For backwards compatibility 180 reasons it was decided not to adress this potential problem. 182 5. IANA Considerations 184 IANA is requested to add "curve25519-sha256" and "curve448-sha512" to 185 the "Key Exchange Method Names" registry for SSH that was created in 186 RFC 4250 section 4.10 [RFC4250]. 188 6. References 190 6.1. Normative References 192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, 194 DOI 10.17487/RFC2119, March 1997, 195 . 197 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 198 Protocol Assigned Numbers", RFC 4250, 199 DOI 10.17487/RFC4250, January 2006, 200 . 202 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 203 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 204 January 2006, . 206 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 207 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 208 January 2006, . 210 [RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 211 (SHA and HMAC-SHA)", RFC 4634, DOI 10.17487/RFC4634, July 212 2006, . 214 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 215 Integration in the Secure Shell Transport Layer", 216 RFC 5656, DOI 10.17487/RFC5656, December 2009, 217 . 219 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 220 for Security", RFC 7748, DOI 10.17487/RFC7748, January 221 2016, . 223 6.2. Informative References 225 [Curve25519] 226 Bernstein, D., "Curve25519: New Diffie-Hellman Speed 227 Records", Lecture Notes in Computer Science (LNCS) vol 228 3958, pp. 207-228, February 2006, 229 . 231 [Ed448-Goldilocks] 232 Hamburg, , "Ed448-Goldilocks, a new elliptic curve", June 233 2015, . 235 Appendix A. Copying conditions 237 Regarding this entire document or any portion of it, the authors make 238 no guarantees and are not responsible for any damage resulting from 239 its use. The authors grant irrevocable permission to anyone to use, 240 modify, and distribute it in any way that does not diminish the 241 rights of anyone else to use, modify, and distribute it, provided 242 that redistributed derivative works do not contain misleading author 243 or version information. Derivative works need not be licensed under 244 similar terms. 246 Authors' Addresses 248 Aris Adamantiadis 249 libssh 251 Email: aris@badcode.be 253 Simon Josefsson 254 SJD AB 256 Email: simon@josefsson.org 258 Mark D. Baushke 259 Juniper Networks, Inc. 261 Email: mdb@juniper.net