idnits 2.17.1 draft-ietf-curdle-rsa-sha2-03.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 is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. -- 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 109 has weird spacing: '... string rsa...' == Line 142 has weird spacing: '... string use...' == Line 143 has weird spacing: '... string ser...' == Line 147 has weird spacing: '... string pub...' == Line 151 has weird spacing: '... string sig...' == (1 more instance...) (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 (February 27, 2017) is 2614 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) == Unused Reference: 'RFC4250' is defined on line 244, 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-02 Summary: 2 errors (**), 0 flaws (~~), 9 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 February 27, 2017 5 Expires: August 27, 2017 7 Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) 8 draft-ietf-curdle-rsa-sha2-03.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 512 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 defines a new algorithm name allowing for interoperable use 63 of RSA keys with SHA-2 256 and SHA-2 512, and a mechanism for servers 64 to inform SSH clients of signature algorithms they support and accept. 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 2. Public Key Algorithms 74 This memo adopts the style and conventions of [RFC4253] in specifying 75 how use of a signature algorithm is indicated in SSH. 77 The following new signature algorithms are defined: 79 rsa-sha2-256 RECOMMENDED sign Raw RSA key 80 rsa-sha2-512 OPTIONAL sign Raw RSA key 82 These signature algorithms are suitable for use both in the SSH transport 83 layer [RFC4253] for server authentication, and in the authentication 84 layer [RFC4252] for client authentication. 86 Since RSA keys are not dependent on the choice of hash function, both 87 new algorithms reuse the public key format of the existing "ssh-rsa" 88 algorithm as defined in [RFC4253]: 90 string "ssh-rsa" 91 mpint e 92 mpint n 94 All aspects of the "ssh-rsa" format are kept, including the encoded 95 string "ssh-rsa", in order to allow users' existing RSA keys to be 96 used with the new signature formats, without requiring re-encoding, 97 or affecting already trusted key fingerprints. 99 Signing and verifying using these algorithms is performed according to 100 the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using SHA-2 [FIPS-180-4] as 101 hash; MGF1 as mask function; and salt length equal to hash size. 103 For the algorithm "rsa-sha2-256", the hash used is SHA-2 256. 104 For the algorithm "rsa-sha2-512", the hash used is SHA-2 512. 106 The resulting signature is encoded as follows: 108 string "rsa-sha2-256" / "rsa-sha2-512" 109 string rsa_signature_blob 111 The value for 'rsa_signature_blob' is encoded as a string containing 112 S - an octet string which is the output of RSASSA-PKCS1-v1_5, of 113 length equal to the length in octets of the RSA modulus. 115 2.1. Use for server authentication 117 To express support and preference for one or both of these algorithms 118 for server authentication, the SSH client or server includes one or 119 both algorithm names, "rsa-sha2-256" and/or "rsa-sha2-512", in the 120 name-list field "server_host_key_algorithms" in the SSH_MSG_KEXINIT 121 packet [RFC4253]. If one of the two host key algorithms is negotiated, 122 the server sends an "ssh-rsa" public key as part of the negotiated key 123 exchange method (e.g. in SSH_MSG_KEXDH_REPLY), and encodes a signature 124 with the appropriate signature algorithm name - either "rsa-sha2-256", 125 or "rsa-sha2-512". 127 2.2. Use for client authentication 129 To use this algorithm for client authentication, the SSH client sends 130 an SSH_MSG_USERAUTH_REQUEST message [RFC4252] encoding the "publickey" 131 method, and encoding the string field "public key algorithm name" with 132 the value "rsa-sha2-256" or "rsa-sha2-512". The "public key blob" 133 field encodes the RSA public key using the "ssh-rsa" algorithm name. 134 The signature field, if present, encodes a signature using an 135 algorithm name that MUST match the SSH authentication request - either 136 "rsa-sha2-256", or "rsa-sha2-512". 138 For example, an SSH "publickey" authentication request using an 139 "rsa-sha2-512" signature would be properly encoded as follows: 141 byte SSH_MSG_USERAUTH_REQUEST 142 string user name 143 string service name 144 string "publickey" 145 boolean TRUE 146 string "rsa-sha2-512" 147 string public key blob: 148 string "ssh-rsa" 149 mpint e 150 mpint n 151 string signature: 152 string "rsa-sha2-512" 153 string rsa_signature_blob 155 3. Discovery of signature algorithms supported by servers 157 Implementation experience has shown that there are servers which apply 158 authentication penalties to clients attempting signature algorithms 159 which the SSH server does not support. 161 Servers that accept rsa-sha2-* signatures for client authentication 162 SHOULD implement the extension negotiation mechanism defined in 163 [SSH-EXT-INFO], including especially the "server-sig-algs" extension. 165 When authenticating with an RSA key against a server that does not 166 implement the "server-sig-algs" extension, clients MAY default to an 167 ssh-rsa signature to avoid authentication penalties. 169 4. IANA Considerations 171 IANA is requested to update the "Secure Shell (SSH) Protocol 172 Parameters" registry, to extend the table Public Key Algorithm Names: 174 - To the immediate right of the column Public Key Algorithm Name, 175 a new column is to be added, titled Signature Algorithm Name. For 176 existing entries, the column Signature Algorithm Name should be 177 assigned the same value found under Public Key Algorithm Name. 179 - Immediately following the existing entry for "ssh-rsa", two sibling 180 entries are to be added: 182 P. K. Alg. Name Sig. Alg. Name Reference Note 183 ssh-rsa rsa-sha2-256 [this document] Section 2 184 ssh-rsa rsa-sha2-512 [this document] Section 2 186 5. Security Considerations 188 The security considerations of [RFC4253] apply to this document. 190 The National Institute of Standards and Technology (NIST) Special 191 Publication 800-131A [800-131A] disallows the use of RSA and DSA keys 192 shorter than 2048 bits for US government use after 2013. Keys of 2048 193 bits or larger are considered acceptable. 195 The same document disallows the SHA-1 hash function, as used in the 196 "ssh-rsa" and "ssh-dss" algorithms, for digital signature generation 197 after 2013. The SHA-2 family of hash functions is seen as acceptable. 199 6. Why no DSA? 201 A draft version of this memo also defined an algorithm name for use of 202 2048-bit and 3072-bit DSA keys with a 256-bit subgroup and SHA-2 256 203 hashing. It is possible to implement DSA securely by generating "k" 204 deterministically as per [RFC6979]. However, a plurality of reviewers 205 were concerned that implementers would continue to use libraries that 206 generate "k" randomly. This is vulnerable to biased "k" generation, 207 and extremely vulnerable to "k" reuse. 209 This document therefore abstains from defining new algorithm names 210 for DSA, and recommends RSA where this is preferred over elliptic 211 curve cryptography. 213 7. References 215 7.1. Normative References 217 [FIPS-180-4] 218 National Institute of Standards and Technology (NIST), 219 United States of America, "Secure Hash Standard (SHS)", 220 FIPS Publication 180-4, August 2015, 221 . 223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 224 Requirement Levels", BCP 14, RFC 2119, March 1997. 226 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 227 Standards (PKCS) #1: RSA Cryptography Specifications 228 Version 2.1", RFC 3447, February 2003. 230 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 231 Authentication Protocol", RFC 4252, January 2006. 233 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 234 Transport Layer Protocol", RFC 4253, January 2006. 236 7.2. Informative References 238 [800-131A] National Institute of Standards and Technology (NIST), 239 "Transitions: Recommendation for Transitioning the Use of 240 Cryptographic Algorithms and Key Lengths", NIST Special 241 Publication 800-131A, January 2011, . 244 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 245 Protocol Assigned Numbers", RFC 4250, January 2006. 247 [RFC6979] Pornin, T., "Deterministic Usage of the Digital 248 Signature Algorithm (DSA) and Elliptic Curve Digital 249 Signature Algorithm (ECDSA)", RFC 6979, August 2013. 251 [SSH-EXT-INFO] 252 Bider, D., "Extension Negotiation in Secure Shell (SSH)", 253 draft-ietf-curdle-ssh-ext-info-02.txt, February 2017, 254 . 257 Author's Address 259 Denis Bider 260 Bitvise Limited 261 Suites 41/42, Victoria House 262 26 Main Street 263 GI 265 Phone: +506 8315 6519 266 EMail: ietf-ssh3@denisbider.com 267 URI: https://www.bitvise.com/ 269 Acknowledgments 271 Thanks to Jon Bright, Niels Moeller, Stephen Farrell, Mark D. Baushke, 272 Jeffrey Hutzelman, Hanno Boeck, Peter Gutmann, Damien Miller, and Mat 273 Berchtold for comments and suggestions.