8332
PROPOSED STANDARD
Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol
Authors: D. Bider
Date: March 2018
Area: sec
Working Group: curdle
Stream: IETF
Updates:
RFC 4252
Abstract
This memo updates RFCs 4252 and 4253 to define new public key algorithms for use of RSA keys with SHA-256 and SHA-512 for server and client authentication in SSH connections.
RFC 8332
PROPOSED STANDARD
Internet Engineering Task Force (IETF) D. Bider
Request for Comments: 8332 Bitvise Limited
Updates: <a href="./rfc4252">4252</a>, <a href="./rfc4253">4253</a> March 2018
Category: Standards Track
ISSN: 2070-1721
<span class="h1">Use of RSA Keys with SHA-256 and SHA-512</span>
<span class="h1">in the Secure Shell (SSH) Protocol</span>
Abstract
This memo updates RFCs 4252 and 4253 to define new public key
algorithms for use of RSA keys with SHA-256 and SHA-512 for server
and client authentication in SSH connections.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8332">https://www.rfc-editor.org/info/rfc8332</a>.
<span class="grey">Bider Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc8332">RFC 8332</a> Use of RSA Keys with SHA-256 and SHA-512 March 2018</span>
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
<a href="#section-1">1</a>. Overview and Rationale . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Requirements Terminology . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Wire Encoding Terminology . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Public Key Format vs. Public Key Algorithm . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. New RSA Public Key Algorithms . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Use for Server Authentication . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. Use for Client Authentication . . . . . . . . . . . . . . <a href="#page-5">5</a>
3.3. Discovery of Public Key Algorithms Supported by Servers . 6
<a href="#section-4">4</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.1">5.1</a>. Key Size and Signature Hash . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.2">5.2</a>. Transition . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.3">5.3</a>. PKCS #1 v1.5 Padding and Signature Verification . . . . . <a href="#page-7">7</a>
<a href="#section-6">6</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6.1">6.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6.2">6.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<span class="grey">Bider Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc8332">RFC 8332</a> Use of RSA Keys with SHA-256 and SHA-512 March 2018</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Overview and Rationale</span>
Secure Shell (SSH) is a common protocol for secure communication on
the Internet. In [<a href="./rfc4253" title=""The Secure Shell (SSH) Transport Layer Protocol"">RFC4253</a>], SSH originally defined the public key
algorithms "ssh-rsa" for server and client authentication using RSA
with SHA-1, and "ssh-dss" using 1024-bit DSA and SHA-1. These
algorithms are now considered deficient. For US government use, NIST
has disallowed 1024-bit RSA and DSA, and use of SHA-1 for signing
[<a href="#ref-NIST.800-131A">NIST.800-131A</a>].
This memo updates RFCs 4252 and 4253 to define new public key
algorithms allowing for interoperable use of existing and new RSA
keys with SHA-256 and SHA-512.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Wire Encoding Terminology</span>
The wire encoding types in this document -- "boolean", "byte",
"string", "mpint" -- have meanings as described in [<a href="./rfc4251" title=""The Secure Shell (SSH) Protocol Architecture"">RFC4251</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Public Key Format vs. Public Key Algorithm</span>
In [<a href="./rfc4252" title=""The Secure Shell (SSH) Authentication Protocol"">RFC4252</a>], the concept "public key algorithm" is used to establish
a relationship between one algorithm name, and:
A. procedures used to generate and validate a private/public
keypair;
B. a format used to encode a public key; and
C. procedures used to calculate, encode, and verify a signature.
This document uses the term "public key format" to identify only A
and B in isolation. The term "public key algorithm" continues to
identify all three aspects -- A, B, and C.
<span class="grey">Bider Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc8332">RFC 8332</a> Use of RSA Keys with SHA-256 and SHA-512 March 2018</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. New RSA Public Key Algorithms</span>
This memo adopts the style and conventions of [<a href="./rfc4253" title=""The Secure Shell (SSH) Transport Layer Protocol"">RFC4253</a>] in specifying
how use of a public key algorithm is indicated in SSH.
The following new public key algorithms are defined:
rsa-sha2-256 RECOMMENDED sign Raw RSA key
rsa-sha2-512 OPTIONAL sign Raw RSA key
These algorithms are suitable for use both in the SSH transport layer
[<a href="./rfc4253" title=""The Secure Shell (SSH) Transport Layer Protocol"">RFC4253</a>] for server authentication and in the authentication layer
[<a href="./rfc4252" title=""The Secure Shell (SSH) Authentication Protocol"">RFC4252</a>] for client authentication.
Since RSA keys are not dependent on the choice of hash function, the
new public key algorithms reuse the "ssh-rsa" public key format as
defined in [<a href="./rfc4253" title=""The Secure Shell (SSH) Transport Layer Protocol"">RFC4253</a>]:
string "ssh-rsa"
mpint e
mpint n
All aspects of the "ssh-rsa" format are kept, including the encoded
string "ssh-rsa". This allows existing RSA keys to be used with the
new public key algorithms, without requiring re-encoding or affecting
already trusted key fingerprints.
Signing and verifying using these algorithms is performed according
to the RSASSA-PKCS1-v1_5 scheme in [<a href="./rfc8017" title=""PKCS #1: RSA Cryptography Specifications Version 2.2"">RFC8017</a>] using SHA-2 [<a href="#ref-SHS" title=""Secure Hash Standard (SHS)"">SHS</a>] as
hash.
For the algorithm "rsa-sha2-256", the hash used is SHA-256.
For the algorithm "rsa-sha2-512", the hash used is SHA-512.
The resulting signature is encoded as follows:
string "rsa-sha2-256" / "rsa-sha2-512"
string rsa_signature_blob
The value for 'rsa_signature_blob' is encoded as a string that
contains an octet string S (which is the output of RSASSA-PKCS1-v1_5)
and that has the same length (in octets) as the RSA modulus. When S
contains leading zeros, there exist signers that will send a shorter
encoding of S that omits them. A verifier MAY accept shorter
encodings of S with one or more leading zeros omitted.
<span class="grey">Bider Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc8332">RFC 8332</a> Use of RSA Keys with SHA-256 and SHA-512 March 2018</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Use for Server Authentication</span>
To express support and preference for one or both of these algorithms
for server authentication, the SSH client or server includes one or
both algorithm names, "rsa-sha2-256" and/or "rsa-sha2-512", in the
name-list field "server_host_key_algorithms" in the SSH_MSG_KEXINIT
packet [<a href="./rfc4253" title=""The Secure Shell (SSH) Transport Layer Protocol"">RFC4253</a>]. If one of the two host key algorithms is
negotiated, the server sends an "ssh-rsa" public key as part of the
negotiated key exchange method (e.g., in SSH_MSG_KEXDH_REPLY) and
encodes a signature with the appropriate signature algorithm name --
either "rsa-sha2-256" or "rsa-sha2-512".
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Use for Client Authentication</span>
To use this algorithm for client authentication, the SSH client sends
an SSH_MSG_USERAUTH_REQUEST message [<a href="./rfc4252" title=""The Secure Shell (SSH) Authentication Protocol"">RFC4252</a>] encoding the
"publickey" method and encoding the string field "public key
algorithm name" with the value "rsa-sha2-256" or "rsa-sha2-512". The
"public key blob" field encodes the RSA public key using the
"ssh-rsa" public key format.
For example, as defined in [<a href="./rfc4252" title=""The Secure Shell (SSH) Authentication Protocol"">RFC4252</a>] and [<a href="./rfc4253" title=""The Secure Shell (SSH) Transport Layer Protocol"">RFC4253</a>], an SSH
"publickey" authentication request using an "rsa-sha2-512" signature
would be properly encoded as follows:
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string "rsa-sha2-512"
string public key blob:
string "ssh-rsa"
mpint e
mpint n
string signature:
string "rsa-sha2-512"
string rsa_signature_blob
If the client includes the signature field, the client MUST encode
the same algorithm name in the signature as in
SSH_MSG_USERAUTH_REQUEST -- either "rsa-sha2-256" or "rsa-sha2-512".
If a server receives a mismatching request, it MAY apply arbitrary
authentication penalties, including but not limited to authentication
failure or disconnect.
<span class="grey">Bider Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc8332">RFC 8332</a> Use of RSA Keys with SHA-256 and SHA-512 March 2018</span>
OpenSSH 7.2 (but not 7.2p2) incorrectly encodes the algorithm in the
signature as "ssh-rsa" when the algorithm in SSH_MSG_USERAUTH_REQUEST
is "rsa-sha2-256" or "rsa-sha2-512". In this case, the signature
does actually use either SHA-256 or SHA-512. A server MAY, but is
not required to, accept this variant or another variant that
corresponds to a good-faith implementation and is considered safe to
accept.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Discovery of Public Key Algorithms Supported by Servers</span>
Implementation experience has shown that there are servers that apply
authentication penalties to clients attempting public key algorithms
that the SSH server does not support.
Servers that accept rsa-sha2-* signatures for client authentication
SHOULD implement the extension negotiation mechanism defined in
[<a href="./rfc8308" title=""Extension Negotiation in the Secure Shell (SSH) Protocol"">RFC8308</a>], including especially the "server-sig-algs" extension.
When authenticating with an RSA key against a server that does not
implement the "server-sig-algs" extension, clients MAY default to an
"ssh-rsa" signature to avoid authentication penalties. When the new
rsa-sha2-* algorithms have been sufficiently widely adopted to
warrant disabling "ssh-rsa", clients MAY default to one of the new
algorithms.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
IANA has updated the "Secure Shell (SSH) Protocol Parameters"
registry, established with [<a href="./rfc4250" title=""The Secure Shell (SSH) Protocol Assigned Numbers"">RFC4250</a>], to extend the table "Public Key
Algorithm Names" [<a href="#ref-IANA-PKA">IANA-PKA</a>] as follows.
- To the immediate right of the column "Public Key Algorithm Name",
a new column has been added, titled "Public Key Format". For
existing entries, the column "Public Key Format" has been assigned
the same value as under "Public Key Algorithm Name".
- Immediately following the existing entry for "ssh-rsa", two
sibling entries have been added:
P. K. Alg. Name P. K. Format Reference Note
rsa-sha2-256 ssh-rsa <a href="./rfc8332#section-3">RFC 8332 Section 3</a>
rsa-sha2-512 ssh-rsa <a href="./rfc8332#section-3">RFC 8332 Section 3</a>
<span class="grey">Bider Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc8332">RFC 8332</a> Use of RSA Keys with SHA-256 and SHA-512 March 2018</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
The security considerations of [<a href="./rfc4251" title=""The Secure Shell (SSH) Protocol Architecture"">RFC4251</a>] apply to this document.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Key Size and Signature Hash</span>
The National Institute of Standards and Technology (NIST) Special
Publication 800-131A, Revision 1 [<a href="#ref-NIST.800-131A">NIST.800-131A</a>] disallows RSA and
DSA keys shorter than 2048 bits for US government use. The same
document disallows the SHA-1 hash function for digital signature
generation, except under NIST's protocol-specific guidance.
It is prudent to follow this advice also outside of US government
use.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Transition</span>
This document is based on the premise that RSA is used in
environments where a gradual, compatible transition to improved
algorithms will be better received than one that is abrupt and
incompatible. It advises that SSH implementations add support for
new RSA public key algorithms along with SSH_MSG_EXT_INFO and the
"server-sig-algs" extension to allow coexistence of new deployments
with older versions that support only "ssh-rsa". Nevertheless,
implementations SHOULD start to disable "ssh-rsa" in their default
configurations as soon as the implementers believe that new RSA
signature algorithms have been widely adopted.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. PKCS #1 v1.5 Padding and Signature Verification</span>
This document prescribes RSASSA-PKCS1-v1_5 signature padding because:
(1) RSASSA-PSS is not universally available to all implementations;
(2) PKCS #1 v1.5 is widely supported in existing SSH
implementations;
(3) PKCS #1 v1.5 is not known to be insecure for use in this scheme.
Implementers are advised that a signature with RSASSA-PKCS1-v1_5
padding MUST NOT be verified by applying the RSA key to the
signature, and then parsing the output to extract the hash. This may
give an attacker opportunities to exploit flaws in the parsing and
vary the encoding. Verifiers MUST instead apply RSASSA-PKCS1-v1_5
padding to the expected hash, then compare the encoded bytes with the
output of the RSA operation.
<span class="grey">Bider Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc8332">RFC 8332</a> Use of RSA Keys with SHA-256 and SHA-512 March 2018</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<a id="ref-SHS">SHS</a>] NIST, "Secure Hash Standard (SHS)", FIPS Publication
180-4, August 2015,
<<a href="https://dx.doi.org/10.6028/NIST.FIPS.180-4">http://dx.doi.org/10.6028/NIST.FIPS.180-4</a>>.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC4251">RFC4251</a>] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", <a href="./rfc4251">RFC 4251</a>, DOI 10.17487/RFC4251,
January 2006, <<a href="https://www.rfc-editor.org/info/rfc4251">https://www.rfc-editor.org/info/rfc4251</a>>.
[<a id="ref-RFC4252">RFC4252</a>] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", <a href="./rfc4252">RFC 4252</a>, DOI 10.17487/RFC4252,
January 2006, <<a href="https://www.rfc-editor.org/info/rfc4252">https://www.rfc-editor.org/info/rfc4252</a>>.
[<a id="ref-RFC4253">RFC4253</a>] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", <a href="./rfc4253">RFC 4253</a>, DOI 10.17487/RFC4253,
January 2006, <<a href="https://www.rfc-editor.org/info/rfc4253">https://www.rfc-editor.org/info/rfc4253</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
[<a id="ref-RFC8308">RFC8308</a>] Bider, D., "Extension Negotiation in the Secure Shell
(SSH) Protocol", <a href="./rfc8308">RFC 8308</a>, DOI 10.17487/RFC8308, March
2018, <<a href="https://www.rfc-editor.org/info/rfc8308">https://www.rfc-editor.org/info/rfc8308</a>>.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-NIST.800-131A">NIST.800-131A</a>]
NIST, "Transitions: Recommendation for Transitioning the
Use of Cryptographic Algorithms and Key Lengths", NIST
Special Publication 800-131A, Revision 1,
DOI 10.6028/NIST.SP.800-131Ar1, November 2015,
<<a href="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf">http://nvlpubs.nist.gov/nistpubs/SpecialPublications/</a>
<a href="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf">NIST.SP.800-131Ar1.pdf</a>>.
[<a id="ref-RFC4250">RFC4250</a>] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", <a href="./rfc4250">RFC 4250</a>,
DOI 10.17487/RFC4250, January 2006,
<<a href="https://www.rfc-editor.org/info/rfc4250">https://www.rfc-editor.org/info/rfc4250</a>>.
<span class="grey">Bider Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc8332">RFC 8332</a> Use of RSA Keys with SHA-256 and SHA-512 March 2018</span>
[<a id="ref-RFC8017">RFC8017</a>] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
<a href="./rfc8017">RFC 8017</a>, DOI 10.17487/RFC8017, November 2016,
<<a href="https://www.rfc-editor.org/info/rfc8017">https://www.rfc-editor.org/info/rfc8017</a>>.
[<a id="ref-IANA-PKA">IANA-PKA</a>]
IANA, "Secure Shell (SSH) Protocol Parameters",
<<a href="https://www.iana.org/assignments/ssh-parameters/">https://www.iana.org/assignments/ssh-parameters/</a>>.
Acknowledgments
Thanks to Jon Bright, Niels Moeller, Stephen Farrell, Mark D.
Baushke, Jeffrey Hutzelman, Hanno Boeck, Peter Gutmann, Damien
Miller, Mat Berchtold, Roumen Petrov, Daniel Migault, Eric Rescorla,
Russ Housley, Alissa Cooper, Adam Roach, and Ben Campbell for
reviews, comments, and suggestions.
Author's Address
Denis Bider
Bitvise Limited
4105 Lombardy Court
Colleyville, Texas 76034
United States of America
Email: [email protected]
URI: <a href="https://www.bitvise.com/">https://www.bitvise.com/</a>
Bider Standards Track [Page 9]
Annotations
Select text to annotate