idnits 2.17.00 (12 Aug 2021) /tmp/idnits44120/draft-rsa-dsa-sha2-256-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 'Intended status' indicated for this document; assuming Proposed Standard 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 108 has weird spacing: '... string rsa...' -- The document date (November 12, 2015) is 2381 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-4' ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) == Outdated reference: A later version (-05) exists of draft-ssh-ext-info-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft D. Bider 3 Expires: May 12, 2016 Bitvise Limited 4 November 12, 2015 6 Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) 7 draft-rsa-dsa-sha2-256-03.txt 9 Abstract 11 This memo defines an algorithm name, public key format, and signature 12 format for use of RSA keys with SHA-2 512 for server and client 13 authentication in SSH connections. 15 Status 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering Task 21 Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference material 27 or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Copyright 37 Copyright (c) 2015 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 1. Overview and Rationale 52 Secure Shell (SSH) is a common protocol for secure communication on 53 the Internet. In [RFC4253], SSH originally defined the signature 54 methods "ssh-rsa" for server and client authentication using RSA with 55 SHA-1, and "ssh-dss" using 1024-bit DSA and SHA-1. 57 A decade later, these signature methods are considered deficient. 58 For US government use, NIST has disallowed 1024-bit RSA and DSA, and 59 use of SHA-1 for signing [800-131A]. 61 This memo defines a new algorithm name allowing for interoperable use 62 of RSA keys with SHA-2 256 and SHA-2 512, and a mechanism for servers 63 to inform SSH clients of signature algorithms they support and accept. 65 1.1. Requirements Terminology 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in [RFC2119]. 71 2. Public Key Algorithms 73 This memo adopts the style and conventions of [RFC4253] in specifying 74 how the use of a signature algorithm is indicated in SSH. 76 The following new signature algorithms are defined: 78 rsa-sha2-256 RECOMMENDED sign Raw RSA key 79 rsa-sha2-512 OPTIONAL sign Raw RSA key 81 These signature algorithms are suitable for use both in the SSH transport 82 layer [RFC4253] for server authentication, and in the authentication 83 layer [RFC4252] for client authentication. 85 Since RSA keys are not dependent on the choice of hash function, both 86 new algorithms reuse the public key format of the existing "ssh-rsa" 87 algorithm as defined in [RFC4253]: 89 string "ssh-rsa" 90 mpint e 91 mpint n 93 All aspects of the "ssh-rsa" format are kept, including the encoded 94 string "ssh-rsa", in order to allow users' existing RSA keys to be 95 used with the new signature formats, without requiring re-encoding, 96 or affecting already trusted key fingerprints. 98 Signing and verifying using these algorithms is performed according to 99 the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using SHA-2 [FIPS-180-4] as 100 hash; MGF1 as mask function; and salt length equal to hash size. 102 For the algorithm "rsa-sha2-256", the hash used is SHA-2 256. 103 For the algorithm "rsa-sha2-512", the hash used is SHA-2 512. 105 The resulting signature is encoded as follows: 107 string "rsa-sha2-256" / "rsa-sha2-512" 108 string rsa_signature_blob 110 The value for 'rsa_signature_blob' is encoded as a string containing 111 S - an octet string which is the output of RSASSA-PKCS1-v1_5, of 112 length equal to the length in octets of the RSA modulus. 114 2.1. Use for server authentication 116 To express support and preference for one or both of these algorithms 117 for server authentication, the SSH client or server includes one or 118 both algorithm names, "rsa-sha2-256" and/or "rsa-sha2-512", in the 119 name-list field "server_host_key_algorithms" in the SSH_MSG_KEXINIT 120 packet [RFC4253]. If one of the two host key algorithms is negotiated, 121 the server sends an "ssh-rsa" public key as part of the negotiated key 122 exchange method (e.g. in SSH_MSG_KEXDH_REPLY), and encodes a signature 123 with the appropriate signature algorithm name - either "rsa-sha2-256", 124 or "rsa-sha2-512". 126 2.2. Use for client authentication 128 To use this algorithm for client authentication, the SSH client sends 129 an SSH_MSG_USERAUTH_REQUEST message [RFC4252] encoding the "publickey" 130 method, and encoding the string field "public key algorithm name" with 131 the value "rsa-sha2-256" or "rsa-sha2-512". The "public key blob" 132 field encodes the RSA public key using the "ssh-rsa" algorithm name. 133 The signature field, if present, encodes a signature using an 134 algorithm name that matches the SSH authentication request - either 135 "rsa-sha2-256", or "rsa-sha2-512". 137 3. Discovery of signature algorithms supported by servers 139 When a public key format can use multiple signature algorithms, it can 140 be useful for a mechanism to exist which a client can use to discover 141 signature algorithms accepted by a server for user authentication 142 without resorting to trial and error in authentication requests. 144 Such a mechanism is defined in [SSH-EXT-INFO], which describes general 145 purpose extension negotiation for SSH, and specifies discovery of 146 signature algorithms as a usage case. 148 4. IANA Considerations 150 This document augments the Public Key Algorithm Names in [RFC4253] 151 and [RFC4250]. 153 IANA is requested to update the "Secure Shell (SSH) Protocol 154 Parameters" registry with the following entry: 156 Public Key Algorithm Name Reference Note 157 rsa-sha2-256 [this document] Section 2 158 rsa-sha2-512 [this document] Section 2 160 5. Security Considerations 162 The security considerations of [RFC4253] apply to this document. 164 The National Institute of Standards and Technology (NIST) Special 165 Publication 800-131A [800-131A] disallows the use of RSA and DSA keys 166 shorter than 2048 bits for US government use after 2013. Keys of 2048 167 bits or larger are considered acceptable. 169 The same document disallows the SHA-1 hash function, as used in the 170 "ssh-rsa" and "ssh-dss" algorithms, for digital signature generation 171 after 2013. The SHA-2 family of hash functions is seen as acceptable. 173 6. Why no DSA? 175 A draft version of this memo also defined an algorithm name for use of 176 2048-bit and 3072-bit DSA keys with a 256-bit subgroup and SHA-2 256 177 hashing. It is possible to implement DSA securely by generating "k" 178 deterministically as per [RFC6979]. However, a plurality of reviewers 179 were concerned that implementers would not pay heed, and would use 180 cryptographic libraries that continue to generate "k" randomly. This 181 is vulnerable to biased "k" generation, and extremely vulnerable to 182 "k" reuse. The relative speed advantage of DSA signing compared to RSA 183 signing was not perceived to outweigh this shortcoming, especially 184 since algorithms based on elliptic curves are faster yet. 186 Due to these disrecommendations, this document abstains from defining 187 an algorithm name for large DSA keys, and recommends RSA instead. 189 7. References 191 7.1. Normative References 193 [FIPS-180-4] 194 National Institute of Standards and Technology (NIST), 195 United States of America, "Secure Hash Standard (SHS)", 196 FIPS Publication 180-4, August 2015, 197 . 199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 200 Requirement Levels", BCP 14, RFC 2119, March 1997. 202 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 203 Standards (PKCS) #1: RSA Cryptography Specifications 204 Version 2.1", RFC 3447, February 2003. 206 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 207 Authentication Protocol", RFC 4252, January 2006. 209 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 210 Transport Layer Protocol", RFC 4253, January 2006. 212 6.2. Informative References 214 [800-131A] National Institute of Standards and Technology (NIST), 215 "Transitions: Recommendation for Transitioning the Use of 216 Cryptographic Algorithms and Key Lengths", NIST Special 217 Publication 800-131A, January 2011, . 220 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 221 Protocol Assigned Numbers", RFC 4250, January 2006. 223 [RFC6979] Pornin, T., "Deterministic Usage of the Digital 224 Signature Algorithm (DSA) and Elliptic Curve Digital 225 Signature Algorithm (ECDSA)", RFC 6979, August 2013. 227 [SSH-EXT-INFO] 228 Bider, D., "Extension Negotiation in Secure Shell (SSH)", 229 draft-ssh-ext-info-00, November 2015, 230 . 232 Author's Address 234 Denis Bider 235 Bitvise Limited 236 Suites 41/42, Victoria House 237 26 Main Street 238 GI 240 Phone: +506 8315 6519 241 EMail: ietf-ssh3@denisbider.com 242 URI: https://www.bitvise.com/ 244 Acknowledgments 246 Thanks to Jon Bright, Niels Moeller, Stephen Farrell, Mark D. Baushke, 247 Jeffrey Hutzelman, Hanno Boeck, Peter Gutmann, and Damien Miller for 248 comments and suggestions.