idnits 2.17.1 draft-ietf-curdle-ssh-curves-05.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 (May 10, 2017) is 2514 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) -- Looks like a reference, but probably isn't: '0' on line 153 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: Standards Track S. Josefsson 5 Expires: November 11, 2017 SJD AB 6 M. Baushke 7 Juniper Networks, Inc. 8 May 10, 2017 10 Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448 11 draft-ietf-curdle-ssh-curves-05 13 Abstract 15 This document describes the conventions for using Curve25519 and 16 Curve448 key exchange methods in the Secure Shell (SSH) protocol. 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 November 11, 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 . . . . . . . . . . . . . . . . . . . . 2 54 2.1. Shared Secret Encoding . . . . . . . . . . . . . . . . . 3 55 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 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 Secure Shell (SSH) [RFC4251] is a secure remote login protocol. The 67 key exchange protocol described in [RFC4253] supports an extensible 68 set of methods. [RFC5656] describes how elliptic curves are 69 integrated in SSH, and this document reuses those protocol messages. 71 This document describes how to implement key exchange based on 72 Curve25519 and Ed448-Goldilocks [RFC7748] in SSH. For Curve25519 73 with SHA-256 [RFC6234], the algorithm we describe is equivalent to 74 the privately defined algorithm "curve25519-sha256@libssh.org", which 75 is currently implemented and widely deployed in libssh and OpenSSH. 76 The Curve448 key exchange method is novel but similar in spirit, and 77 we chose to couple it with SHA-512 [RFC6234] to further separate it 78 from the Curve25519 alternative. 80 This document provide Curve25519 as the prefered choice, but suggests 81 that the fall back option Curve448 is implemented to provide an hedge 82 against unforseen analytical advances against Curve25519 and SHA-256. 83 Due to different implementation status of these two curves (high- 84 quality free implementations of Curve25519 has been in deployed use 85 for several years, while Curve448 implementations are slowly 86 appearing), it is accepted that adoption of Curve448 will be slower. 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 2. Key Exchange Methods 94 The key exchange procedure is similar to the ECDH method described in 95 chapter 4 of [RFC5656], though with a different wire encoding used 96 for public values and the final shared secret. Public ephemeral keys 97 are encoded for transmission as standard SSH strings. 99 The protocol flow, the SSH_MSG_KEX_ECDH_INIT and 100 SSH_MSG_KEX_ECDH_REPLY messages, and the structure of the exchange 101 hash are identical to chapter 4 of [RFC5656]. 103 The method names registered by this document are "curve25519-sha256" 104 and "curve448-sha512". 106 The methods are based on Curve25519 and Curve448 scalar 107 multiplication, as described in [RFC7748]. Private and public keys 108 are generated as described therein. Public keys are defined as 109 strings of 32 bytes for Curve25519 and 56 bytes for Curve448. 110 Clients and servers MUST fail the key exchange if the length of the 111 received public keys are not the expected lengths, or if the derived 112 shared secret only consists of zero bits. No further validation is 113 required beyond what is discussed in [RFC7748]. The derived shared 114 secret is 32 bytes when Curve25519 is used and 56 bytes when Curve448 115 is used. The encodings of all values are defined in [RFC7748]. The 116 hash used is SHA-256 for Curve25519 and SHA-512 for Curve448. 118 2.1. Shared Secret Encoding 120 The following step differs from [RFC5656], which uses a different 121 conversion. This is not intended to modify that text generally, but 122 only to be applicable to the scope of the mechanism described in this 123 document. 125 The shared secret, K, is defined in [RFC4253] as a multiple precision 126 integer (mpint). Curve25519/448 outputs a binary string X, which is 127 the 32 or 56 byte point obtained by scalar multiplication of the 128 other side's public key and the local private key scalar. The 32 or 129 56 bytes of X are converted into K by interpreting the bytes as an 130 unsigned fixed-length integer encoded in network byte order. This 131 conversion follows the normal "mpint" process as described in section 132 5 of [RFC4251]. 134 To clarify a corner-case in this conversion, when X is encoded as an 135 mpint K, in order to calculate the exchange hash, it may vary as 136 follows: 138 o Trim all leading zero-bytes of X. If X is all zero-bytes, then 139 the key exchange MUST fail. 141 o If the high bit of X is set, the mpint format requires a zero byte 142 to be prepended. 144 o The length of the encoded K may not be the same as the original 145 length of X due to trimming or prepending zero-bytes as needed for 146 "mpint" format. 148 Or, as pseudo code: 150 k := x; 151 while (k.length() > 0 && k[0] == 0) k = k[1:]; 152 assert(k.length() > 0); 153 if 0 != (k[0] & 0x80) k = '\0' .. k; 155 Figure 1 157 When performing the X25519 or X448 operations, the integer values 158 there will be encoded into byte strings by doing a fix-length 159 unsigned litle-endian conversion, per [RFC7748]. It is only later 160 when these byte strings are then passed to the ECDH code in SSH that 161 the bytes are re-interpreted as a fixed-length unsigned big-endian 162 integer value K, and then later that K value is encoded as a 163 variable-length signed "mpint" before being fed to the hash algorithm 164 used for key generation. 166 3. Acknowledgements 168 The "curve25519-sha256" key exchange method is identical to the 169 "curve25519-sha256@libssh.org" key exchange method created by Aris 170 Adamantiadis and implemented in libssh and OpenSSH. 172 Thanks to the following people for review and comments: Denis Bider, 173 Damien Miller, Niels Moeller, Matt Johnston, Eric Rescorla, Ron 174 Frederick, Stefan Buehler. 176 4. Security Considerations 178 The security considerations of [RFC4251], [RFC5656], and [RFC7748] 179 are inherited. 181 Curve25519 provide strong security and is efficient on a wide range 182 of architectures, and has properties that allows better 183 implementation properties compared to traditional elliptic curves. 184 Curve448 with SHA-512 is similar, but has not received the same 185 cryptographic review as Curve25519, and is slower, but it is provided 186 as an hedge to combat unforseen analytical advances against 187 Curve25519 and SHA-256. 189 The way the derived binary secret string is encoded into a mpint 190 before it is hashed (i.e., adding or removing zero-bytes for 191 encoding) raises the potential for a side-channel attack which could 192 determine the length of what is hashed. This would leak the most 193 significant bit of the derived secret, and/or allow detection of when 194 the most significant bytes are zero. For backwards compatibility 195 reasons it was decided not to adress this potential problem. 197 5. IANA Considerations 199 IANA is requested to add "curve25519-sha256" and "curve448-sha512" to 200 the "Key Exchange Method Names" registry for SSH [IANA-KEX] that was 201 created in RFC 4250 section 4.10 [RFC4250]. 203 6. References 205 6.1. Normative References 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, 209 DOI 10.17487/RFC2119, March 1997, 210 . 212 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 213 Protocol Assigned Numbers", RFC 4250, 214 DOI 10.17487/RFC4250, January 2006, 215 . 217 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 218 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 219 January 2006, . 221 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 222 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 223 January 2006, . 225 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 226 Integration in the Secure Shell Transport Layer", 227 RFC 5656, DOI 10.17487/RFC5656, December 2009, 228 . 230 6.2. Informative References 232 [IANA-KEX] 233 Internet Assigned Numbers Authority (IANA), "Secure Shell 234 (SSH) Protocol Parameters: Key Exchange Method Names", 235 March 2017, . 238 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 239 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 240 DOI 10.17487/RFC6234, May 2011, 241 . 243 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 244 for Security", RFC 7748, DOI 10.17487/RFC7748, January 245 2016, . 247 Appendix A. Copying conditions 249 Regarding this entire document or any portion of it, the authors make 250 no guarantees and are not responsible for any damage resulting from 251 its use. The authors grant irrevocable permission to anyone to use, 252 modify, and distribute it in any way that does not diminish the 253 rights of anyone else to use, modify, and distribute it, provided 254 that redistributed derivative works do not contain misleading author 255 or version information. Derivative works need not be licensed under 256 similar terms. 258 Authors' Addresses 260 Aris Adamantiadis 261 libssh 263 Email: aris@badcode.be 265 Simon Josefsson 266 SJD AB 268 Email: simon@josefsson.org 270 Mark D. Baushke 271 Juniper Networks, Inc. 273 Email: mdb@juniper.net