idnits 2.17.1 draft-ietf-curdle-ssh-curves-07.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 (January 1, 2018) is 2307 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 (~~), 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: Standards Track S. Josefsson 5 Expires: July 5, 2018 SJD AB 6 M. Baushke 7 Juniper Networks, Inc. 8 January 1, 2018 10 Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448 11 draft-ietf-curdle-ssh-curves-07 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 https://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 July 5, 2018. 35 Copyright Notice 37 Copyright (c) 2018 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 (https://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. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 54 3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Shared Secret Encoding . . . . . . . . . . . . . . . . . 3 56 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 61 7.2. Informative References . . . . . . . . . . . . . . . . . 5 62 Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 Secure Shell (SSH) [RFC4251] is a secure remote login protocol. The 68 key exchange protocol described in [RFC4253] supports an extensible 69 set of methods. [RFC5656] describes how elliptic curves are 70 integrated in SSH, and this document reuses those protocol messages. 72 This document describes how to implement key exchange based on 73 Curve25519 and Ed448-Goldilocks [RFC7748] in SSH. For Curve25519 74 with SHA-256 [RFC6234], the algorithm we describe is equivalent to 75 the privately defined algorithm "curve25519-sha256@libssh.org", which 76 is currently implemented and widely deployed in libssh and OpenSSH. 77 The Curve448 key exchange method is novel but similar in spirit, and 78 we chose to couple it with SHA-512 [RFC6234] to further separate it 79 from the Curve25519 alternative. 81 This document provide Curve25519 as the preferred choice, but 82 suggests that the fall back option Curve448 is implemented to provide 83 an hedge against unforeseen analytical advances against Curve25519 84 and SHA-256. Due to different implementation status of these two 85 curves (high-quality free implementations of Curve25519 has been in 86 deployed use for several years, while Curve448 implementations are 87 slowly appearing), it is accepted that adoption of Curve448 will be 88 slower. 90 2. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in 95 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 96 capitals, as shown here. 98 3. 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 3.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] and [RFC5656] as an 132 integer encoded as a multiple precision integer (mpint). 133 Curve25519/448 outputs a binary string X, which is the 32 or 56 byte 134 point obtained by scalar multiplication of the other side's public 135 key and the local private key scalar. The 32 or 56 bytes of X are 136 converted into K by interpreting the octets as an unsigned fixed- 137 length integer encoded in network byte order. 139 The integer K is then encoded as an mpint using the process described 140 in section 5 of [RFC4251] and the resulting bytes are fed as 141 described in [RFC4253] to the key exchange method's hash function to 142 generate encryption keys. 144 When performing the X25519 or X448 operations, the integer values 145 there will be encoded into byte strings by doing a fixed-length 146 unsigned little-endian conversion, per [RFC7748]. It is only later 147 when these byte strings are then passed to the ECDH code in SSH that 148 the bytes are re-interpreted as a fixed-length unsigned big-endian 149 integer value K, and then later that K value is encoded as a 150 variable-length signed "mpint" before being fed to the hash algorithm 151 used for key generation. The mpint K is then fed along with other 152 data to the key exchange method's hash function to generate 153 encryption keys. 155 4. Acknowledgements 157 The "curve25519-sha256" key exchange method is identical to the 158 "curve25519-sha256@libssh.org" key exchange method created by Aris 159 Adamantiadis and implemented in libssh and OpenSSH. 161 Thanks to the following people for review and comments: Denis Bider, 162 Damien Miller, Niels Moeller, Matt Johnston, Eric Rescorla, Ron 163 Frederick, Stefan Buehler. 165 5. Security Considerations 167 The security considerations of [RFC4251], [RFC5656], and [RFC7748] 168 are inherited. 170 Curve25519 provide strong security and is efficient on a wide range 171 of architectures, and has properties that allows better 172 implementation properties compared to traditional elliptic curves. 173 Curve448 with SHA-512 is similar, but has not received the same 174 cryptographic review as Curve25519, and is slower, but it is provided 175 as an hedge to combat unforeseen analytical advances against 176 Curve25519 and SHA-256. 178 The way the derived binary secret string is encoded into a mpint 179 before it is hashed (i.e., adding or removing zero-bytes for 180 encoding) raises the potential for a side-channel attack which could 181 determine the length of what is hashed. This would leak the most 182 significant bit of the derived secret, and/or allow detection of when 183 the most significant bytes are zero. For backwards compatibility 184 reasons it was decided not to address this potential problem. 186 6. IANA Considerations 188 IANA is requested to add "curve25519-sha256" and "curve448-sha512" to 189 the "Key Exchange Method Names" registry for SSH [IANA-KEX] that was 190 created in RFC 4250 section 4.10 [RFC4250]. 192 7. References 194 7.1. Normative References 196 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 197 Requirement Levels", BCP 14, RFC 2119, 198 DOI 10.17487/RFC2119, March 1997, 199 . 201 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 202 Protocol Assigned Numbers", RFC 4250, 203 DOI 10.17487/RFC4250, January 2006, 204 . 206 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 207 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 208 January 2006, . 210 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 211 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 212 January 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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 220 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 221 May 2017, . 223 7.2. Informative References 225 [IANA-KEX] 226 Internet Assigned Numbers Authority (IANA), "Secure Shell 227 (SSH) Protocol Parameters: Key Exchange Method Names", 228 January 2018, . 231 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 232 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 233 DOI 10.17487/RFC6234, May 2011, 234 . 236 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 237 for Security", RFC 7748, DOI 10.17487/RFC7748, January 238 2016, . 240 Appendix A. Copying conditions 242 Regarding this entire document or any portion of it, the authors make 243 no guarantees and are not responsible for any damage resulting from 244 its use. The authors grant irrevocable permission to anyone to use, 245 modify, and distribute it in any way that does not diminish the 246 rights of anyone else to use, modify, and distribute it, provided 247 that redistributed derivative works do not contain misleading author 248 or version information. Derivative works need not be licensed under 249 similar terms. 251 Authors' Addresses 253 Aris Adamantiadis 254 libssh 256 Email: aris@badcode.be 258 Simon Josefsson 259 SJD AB 261 Email: simon@josefsson.org 263 Mark D. Baushke 264 Juniper Networks, Inc. 266 Email: mdb@juniper.net