idnits 2.17.1 draft-ietf-curdle-rsa-sha2-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 5) being 67 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4252, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4253, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 100 has weird spacing: '... string use...' == Line 101 has weird spacing: '... string ser...' == Line 104 has weird spacing: '... string sig...' == Line 105 has weird spacing: '... string pub...' == Line 156 has weird spacing: '... string rsa...' == (5 more instances...) (Using the creation date from RFC4252, updated by this document, for RFC5378 checks: 1997-03-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 29, 2017) is 2585 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) == Missing Reference: 'RFC3629' is mentioned on line 100, but not defined == Unused Reference: 'RFC4250' is defined on line 298, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-4' ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) == Outdated reference: A later version (-15) exists of draft-ietf-curdle-ssh-ext-info-03 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft D. Bider 3 Updates: 4252, 4253 (if approved) Bitvise Limited 4 Intended status: Standards Track March 29, 2017 5 Expires: September 29, 2017 7 Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) 8 draft-ietf-curdle-rsa-sha2-04.txt 10 Abstract 12 This memo defines an algorithm name, public key format, and signature 13 format for use of RSA keys with SHA-2 hashing for server and client 14 authentication in SSH connections. 16 Status 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 Task 22 Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference material 28 or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Overview and Rationale 53 Secure Shell (SSH) is a common protocol for secure communication on 54 the Internet. In [RFC4253], SSH originally defined the signature 55 methods "ssh-rsa" for server and client authentication using RSA with 56 SHA-1, and "ssh-dss" using 1024-bit DSA and SHA-1. 58 A decade later, these signature methods are considered deficient. 59 For US government use, NIST has disallowed 1024-bit RSA and DSA, and 60 use of SHA-1 for signing [800-131A]. 62 This memo introduces a distinction between public key and signature 63 algorithms in SSH, and defines new signature algorithm names allowing 64 for interoperable use of existing and new RSA keys with SHA-2 hashing. 66 1.1. Requirements Terminology 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [RFC2119]. 72 1.2. Wire Encoding Terminology 74 The wire encoding types in this document - "boolean", "byte", 75 "string", "mpint" - have meanings as described in [RFC4251]. 77 2. Signature Algorithm as Distinct Aspect of Public Key Algorithm 79 In [RFC4252], the concept "public key algorithm" is used to establish 80 a relationship between one algorithm name, and: 82 A. Procedures used to generate and validate a private/public keypair. 83 B. A format used to encode a public key. 84 C. Procedures used to calculate, encode, and verify a signature. 86 This document narrows the term "public key algorithm" to mean A and B, 87 though it can still potentially imply C when a public key algorithm is 88 associated with only one signature algorithm. A new term, "signature 89 algorithm", is introduced to refer specifically to C. 91 This affects the meaning of the field "server_host_key_algorithms" in 92 the message SSH_MSG_KEXINIT ([RFC4253]). With this document, this 93 field now refers specifically to signature, not public key algorithms. 95 This also affects the message SSH_MSG_USERAUTH_REQUEST when used with 96 the "publickey" authentication method as defined in [RFC4252]. With 97 this document, the definition of this message is updated as follows: 99 byte SSH_MSG_USERAUTH_REQUEST 100 string user name in ISO-10646 UTF-8 encoding [RFC3629] 101 string service name in US-ASCII 102 string "publickey" 103 boolean FALSE 104 string signature algorithm name 105 string public key blob 107 The format of the message remains unchanged. The change is in the line 108 which now reads "signature algorithm name". This used to read "public 109 key algorithm name". 111 These changes do not affect key types other than RSA. Other public key 112 algorithms continue to use one signature algorithm of the same name. 114 There is no impact on existing implementations that support RSA keys 115 only as "ssh-rsa". Such implementations continue to use the public key 116 algorithm "ssh-rsa", and the signature algorithm of the same name. 118 3. New RSA Signature Algorithms 120 This memo adopts the style and conventions of [RFC4253] in specifying 121 how use of a signature algorithm is indicated in SSH. 123 The following new signature algorithms are defined: 125 rsa-sha2-256 RECOMMENDED sign Raw RSA key 126 rsa-sha2-512 OPTIONAL sign Raw RSA key 128 These algorithms are suitable for use both in the SSH transport layer 129 [RFC4253] for server authentication, and in the authentication layer 130 [RFC4252] for client authentication. 132 Since RSA keys are not dependent on the choice of hash function, the 133 new signature algorithms are defined as aspects of the existing 134 "ssh-rsa" public key algorithm. This means the new algorithms reuse 135 the "ssh-rsa" public key format as defined in [RFC4253]: 137 string "ssh-rsa" 138 mpint e 139 mpint n 141 All aspects of the "ssh-rsa" format are kept, including the encoded 142 string "ssh-rsa". This allows existing RSA keys to be used with the 143 new signature formats, without requiring re-encoding, or affecting 144 already trusted key fingerprints. 146 Signing and verifying using these algorithms is performed according to 147 the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using SHA-2 [FIPS-180-4] as 148 hash; MGF1 as mask function; and salt length equal to hash size. 150 For the algorithm "rsa-sha2-256", the hash used is SHA-2 256. 151 For the algorithm "rsa-sha2-512", the hash used is SHA-2 512. 153 The resulting signature is encoded as follows: 155 string "rsa-sha2-256" / "rsa-sha2-512" 156 string rsa_signature_blob 158 The value for 'rsa_signature_blob' is encoded as a string containing 159 S - an octet string which is the output of RSASSA-PKCS1-v1_5, of 160 length equal to the length in octets of the RSA modulus. 162 3.1. Use for server authentication 164 To express support and preference for one or both of these algorithms 165 for server authentication, the SSH client or server includes one or 166 both algorithm names, "rsa-sha2-256" and/or "rsa-sha2-512", in the 167 name-list field "server_host_key_algorithms" in the SSH_MSG_KEXINIT 168 packet [RFC4253]. If one of the two host key algorithms is negotiated, 169 the server sends an "ssh-rsa" public key as part of the negotiated key 170 exchange method (e.g. in SSH_MSG_KEXDH_REPLY), and encodes a signature 171 with the appropriate signature algorithm name - either "rsa-sha2-256", 172 or "rsa-sha2-512". 174 3.2. Use for client authentication 176 To use this algorithm for client authentication, the SSH client sends 177 an SSH_MSG_USERAUTH_REQUEST message [RFC4252] encoding the "publickey" 178 method, and encoding the string field "public key algorithm name" with 179 the value "rsa-sha2-256" or "rsa-sha2-512". The "public key blob" 180 field encodes the RSA public key using the "ssh-rsa" algorithm name. 181 The signature field, if present, encodes a signature using an 182 algorithm name that MUST match the SSH authentication request - either 183 "rsa-sha2-256", or "rsa-sha2-512". 185 For example, an SSH "publickey" authentication request using an 186 "rsa-sha2-512" signature would be properly encoded as follows: 188 byte SSH_MSG_USERAUTH_REQUEST 189 string user name 190 string service name 191 string "publickey" 192 boolean TRUE 193 string "rsa-sha2-512" 194 string public key blob: 195 string "ssh-rsa" 196 mpint e 197 mpint n 198 string signature: 199 string "rsa-sha2-512" 200 string rsa_signature_blob 202 3.3. Discovery of signature algorithms supported by servers 204 Implementation experience has shown that there are servers which apply 205 authentication penalties to clients attempting signature algorithms 206 which the SSH server does not support. 208 Servers that accept rsa-sha2-* signatures for client authentication 209 SHOULD implement the extension negotiation mechanism defined in 210 [SSH-EXT-INFO], including especially the "server-sig-algs" extension. 212 When authenticating with an RSA key against a server that does not 213 implement the "server-sig-algs" extension, clients MAY default to an 214 ssh-rsa signature to avoid authentication penalties. 216 4. IANA Considerations 218 IANA is requested to update the "Secure Shell (SSH) Protocol 219 Parameters" registry, to extend the table Public Key Algorithm Names: 221 - To the immediate right of the column Public Key Algorithm Name, 222 a new column is to be added, titled Signature Algorithm Name. For 223 existing entries, the column Signature Algorithm Name should be 224 assigned the same value found under Public Key Algorithm Name. 226 - Immediately following the existing entry for "ssh-rsa", two sibling 227 entries are to be added: 229 P. K. Alg. Name Sig. Alg. Name Reference Note 230 ssh-rsa rsa-sha2-256 [this document] Section 3 231 ssh-rsa rsa-sha2-512 [this document] Section 3 233 5. Security Considerations 235 The security considerations of [RFC4251] apply to this document. 237 The National Institute of Standards and Technology (NIST) Special 238 Publication 800-131A [800-131A] disallows the use of RSA and DSA keys 239 shorter than 2048 bits for US government use after 2013. The same 240 document disallows the SHA-1 hash function, as used in the "ssh-rsa" 241 and "ssh-dss" algorithms, for digital signature generation after 2013. 243 This document is based on the premise that RSA is used in environments 244 where a gradual, compatible transition to improved algorithms will be 245 better received than one that is abrupt and incompatible. It advises 246 that SSH implementations add support for new RSA signature algorithms 247 along with SSH_MSG_EXT_INFO and the "server-sig-algs" extension to 248 allow coexistence of new deployments with older versions that support 249 only "ssh-rsa". Nevertheless, implementations SHOULD start to disable 250 "ssh-rsa" in their default configurations as soon as they have reason 251 to believe that new RSA signature algorithms have been widely adopted. 253 6. Why no DSA? 255 A draft version of this memo also defined an algorithm name for use of 256 2048-bit and 3072-bit DSA keys with a 256-bit subgroup and SHA-2 256 257 hashing. It is possible to implement DSA securely by generating "k" 258 deterministically as per [RFC6979]. However, a plurality of reviewers 259 were concerned that implementers would continue to use libraries that 260 generate "k" randomly. This is vulnerable to biased "k" generation, 261 and extremely vulnerable to "k" reuse. This document therefore 262 disrecommends DSA, in favor of RSA and elliptic curve cryptography. 264 7. References 266 7.1. Normative References 268 [FIPS-180-4] 269 National Institute of Standards and Technology (NIST), 270 United States of America, "Secure Hash Standard (SHS)", 271 FIPS Publication 180-4, August 2015, 272 . 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, March 1997. 277 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 278 Standards (PKCS) #1: RSA Cryptography Specifications 279 Version 2.1", RFC 3447, February 2003. 281 [RFC4251] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 282 Protocol Architecture", RFC 4251, January 2006. 284 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 285 Authentication Protocol", RFC 4252, January 2006. 287 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 288 Transport Layer Protocol", RFC 4253, January 2006. 290 7.2. Informative References 292 [800-131A] National Institute of Standards and Technology (NIST), 293 "Transitions: Recommendation for Transitioning the Use of 294 Cryptographic Algorithms and Key Lengths", NIST Special 295 Publication 800-131A, January 2011, . 298 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 299 Protocol Assigned Numbers", RFC 4250, January 2006. 301 [RFC6979] Pornin, T., "Deterministic Usage of the Digital 302 Signature Algorithm (DSA) and Elliptic Curve Digital 303 Signature Algorithm (ECDSA)", RFC 6979, August 2013. 305 [SSH-EXT-INFO] 306 Bider, D., "Extension Negotiation in Secure Shell (SSH)", 307 draft-ietf-curdle-ssh-ext-info-03.txt, March 2017, 308 . 311 Author's Address 313 Denis Bider 314 Bitvise Limited 315 Suites 41/42, Victoria House 316 26 Main Street 317 GI 319 Phone: +506 8315 6519 320 EMail: ietf-ssh3@denisbider.com 321 URI: https://www.bitvise.com/ 323 Acknowledgments 325 Thanks to Jon Bright, Niels Moeller, Stephen Farrell, Mark D. Baushke, 326 Jeffrey Hutzelman, Hanno Boeck, Peter Gutmann, Damien Miller, Mat 327 Berchtold, and Roumen Petrov for reviews, comments, and suggestions.