draft-ietf-curdle-rsa-sha2-03.txt   draft-ietf-curdle-rsa-sha2-04.txt 
Internet-Draft D. Bider Internet-Draft D. Bider
Updates: 4252, 4253 (if approved) Bitvise Limited Updates: 4252, 4253 (if approved) Bitvise Limited
Intended status: Standards Track February 27, 2017 Intended status: Standards Track March 29, 2017
Expires: August 27, 2017 Expires: September 29, 2017
Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH)
draft-ietf-curdle-rsa-sha2-03.txt draft-ietf-curdle-rsa-sha2-04.txt
Abstract Abstract
This memo defines an algorithm name, public key format, and signature This memo defines an algorithm name, public key format, and signature
format for use of RSA keys with SHA-2 512 for server and client format for use of RSA keys with SHA-2 hashing for server and client
authentication in SSH connections. authentication in SSH connections.
Status Status
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Secure Shell (SSH) is a common protocol for secure communication on Secure Shell (SSH) is a common protocol for secure communication on
the Internet. In [RFC4253], SSH originally defined the signature the Internet. In [RFC4253], SSH originally defined the signature
methods "ssh-rsa" for server and client authentication using RSA with methods "ssh-rsa" for server and client authentication using RSA with
SHA-1, and "ssh-dss" using 1024-bit DSA and SHA-1. SHA-1, and "ssh-dss" using 1024-bit DSA and SHA-1.
A decade later, these signature methods are considered deficient. A decade later, these signature methods are considered deficient.
For US government use, NIST has disallowed 1024-bit RSA and DSA, and For US government use, NIST has disallowed 1024-bit RSA and DSA, and
use of SHA-1 for signing [800-131A]. use of SHA-1 for signing [800-131A].
This memo defines a new algorithm name allowing for interoperable use This memo introduces a distinction between public key and signature
of RSA keys with SHA-2 256 and SHA-2 512, and a mechanism for servers algorithms in SSH, and defines new signature algorithm names allowing
to inform SSH clients of signature algorithms they support and accept. for interoperable use of existing and new RSA keys with SHA-2 hashing.
1.1. Requirements Terminology 1.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Public Key Algorithms 1.2. Wire Encoding Terminology
The wire encoding types in this document - "boolean", "byte",
"string", "mpint" - have meanings as described in [RFC4251].
2. Signature Algorithm as Distinct Aspect of Public Key Algorithm
In [RFC4252], 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.
C. Procedures used to calculate, encode, and verify a signature.
This document narrows the term "public key algorithm" to mean A and B,
though it can still potentially imply C when a public key algorithm is
associated with only one signature algorithm. A new term, "signature
algorithm", is introduced to refer specifically to C.
This affects the meaning of the field "server_host_key_algorithms" in
the message SSH_MSG_KEXINIT ([RFC4253]). With this document, this
field now refers specifically to signature, not public key algorithms.
This also affects the message SSH_MSG_USERAUTH_REQUEST when used with
the "publickey" authentication method as defined in [RFC4252]. With
this document, the definition of this message is updated as follows:
byte SSH_MSG_USERAUTH_REQUEST
string user name in ISO-10646 UTF-8 encoding [RFC3629]
string service name in US-ASCII
string "publickey"
boolean FALSE
string signature algorithm name
string public key blob
The format of the message remains unchanged. The change is in the line
which now reads "signature algorithm name". This used to read "public
key algorithm name".
These changes do not affect key types other than RSA. Other public key
algorithms continue to use one signature algorithm of the same name.
There is no impact on existing implementations that support RSA keys
only as "ssh-rsa". Such implementations continue to use the public key
algorithm "ssh-rsa", and the signature algorithm of the same name.
3. New RSA Signature Algorithms
This memo adopts the style and conventions of [RFC4253] in specifying This memo adopts the style and conventions of [RFC4253] in specifying
how use of a signature algorithm is indicated in SSH. how use of a signature algorithm is indicated in SSH.
The following new signature algorithms are defined: The following new signature algorithms are defined:
rsa-sha2-256 RECOMMENDED sign Raw RSA key rsa-sha2-256 RECOMMENDED sign Raw RSA key
rsa-sha2-512 OPTIONAL sign Raw RSA key rsa-sha2-512 OPTIONAL sign Raw RSA key
These signature algorithms are suitable for use both in the SSH transport These algorithms are suitable for use both in the SSH transport layer
layer [RFC4253] for server authentication, and in the authentication [RFC4253] for server authentication, and in the authentication layer
layer [RFC4252] for client authentication. [RFC4252] for client authentication.
Since RSA keys are not dependent on the choice of hash function, both Since RSA keys are not dependent on the choice of hash function, the
new algorithms reuse the public key format of the existing "ssh-rsa" new signature algorithms are defined as aspects of the existing
algorithm as defined in [RFC4253]: "ssh-rsa" public key algorithm. This means the new algorithms reuse
the "ssh-rsa" public key format as defined in [RFC4253]:
string "ssh-rsa" string "ssh-rsa"
mpint e mpint e
mpint n mpint n
All aspects of the "ssh-rsa" format are kept, including the encoded All aspects of the "ssh-rsa" format are kept, including the encoded
string "ssh-rsa", in order to allow users' existing RSA keys to be string "ssh-rsa". This allows existing RSA keys to be used with the
used with the new signature formats, without requiring re-encoding, new signature formats, without requiring re-encoding, or affecting
or affecting already trusted key fingerprints. already trusted key fingerprints.
Signing and verifying using these algorithms is performed according to Signing and verifying using these algorithms is performed according to
the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using SHA-2 [FIPS-180-4] as the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using SHA-2 [FIPS-180-4] as
hash; MGF1 as mask function; and salt length equal to hash size. hash; MGF1 as mask function; and salt length equal to hash size.
For the algorithm "rsa-sha2-256", the hash used is SHA-2 256. For the algorithm "rsa-sha2-256", the hash used is SHA-2 256.
For the algorithm "rsa-sha2-512", the hash used is SHA-2 512. For the algorithm "rsa-sha2-512", the hash used is SHA-2 512.
The resulting signature is encoded as follows: The resulting signature is encoded as follows:
string "rsa-sha2-256" / "rsa-sha2-512" string "rsa-sha2-256" / "rsa-sha2-512"
string rsa_signature_blob string rsa_signature_blob
The value for 'rsa_signature_blob' is encoded as a string containing The value for 'rsa_signature_blob' is encoded as a string containing
S - an octet string which is the output of RSASSA-PKCS1-v1_5, of S - an octet string which is the output of RSASSA-PKCS1-v1_5, of
length equal to the length in octets of the RSA modulus. length equal to the length in octets of the RSA modulus.
2.1. Use for server authentication 3.1. Use for server authentication
To express support and preference for one or both of these algorithms To express support and preference for one or both of these algorithms
for server authentication, the SSH client or server includes one or for server authentication, the SSH client or server includes one or
both algorithm names, "rsa-sha2-256" and/or "rsa-sha2-512", in the 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 name-list field "server_host_key_algorithms" in the SSH_MSG_KEXINIT
packet [RFC4253]. If one of the two host key algorithms is negotiated, packet [RFC4253]. If one of the two host key algorithms is negotiated,
the server sends an "ssh-rsa" public key as part of the negotiated key 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 exchange method (e.g. in SSH_MSG_KEXDH_REPLY), and encodes a signature
with the appropriate signature algorithm name - either "rsa-sha2-256", with the appropriate signature algorithm name - either "rsa-sha2-256",
or "rsa-sha2-512". or "rsa-sha2-512".
2.2. Use for client authentication 3.2. Use for client authentication
To use this algorithm for client authentication, the SSH client sends To use this algorithm for client authentication, the SSH client sends
an SSH_MSG_USERAUTH_REQUEST message [RFC4252] encoding the "publickey" an SSH_MSG_USERAUTH_REQUEST message [RFC4252] encoding the "publickey"
method, and encoding the string field "public key algorithm name" with method, and encoding the string field "public key algorithm name" with
the value "rsa-sha2-256" or "rsa-sha2-512". The "public key blob" the value "rsa-sha2-256" or "rsa-sha2-512". The "public key blob"
field encodes the RSA public key using the "ssh-rsa" algorithm name. field encodes the RSA public key using the "ssh-rsa" algorithm name.
The signature field, if present, encodes a signature using an The signature field, if present, encodes a signature using an
algorithm name that MUST match the SSH authentication request - either algorithm name that MUST match the SSH authentication request - either
"rsa-sha2-256", or "rsa-sha2-512". "rsa-sha2-256", or "rsa-sha2-512".
skipping to change at page 4, line 5 skipping to change at page 5, line 5
boolean TRUE boolean TRUE
string "rsa-sha2-512" string "rsa-sha2-512"
string public key blob: string public key blob:
string "ssh-rsa" string "ssh-rsa"
mpint e mpint e
mpint n mpint n
string signature: string signature:
string "rsa-sha2-512" string "rsa-sha2-512"
string rsa_signature_blob string rsa_signature_blob
3. Discovery of signature algorithms supported by servers 3.3. Discovery of signature algorithms supported by servers
Implementation experience has shown that there are servers which apply Implementation experience has shown that there are servers which apply
authentication penalties to clients attempting signature algorithms authentication penalties to clients attempting signature algorithms
which the SSH server does not support. which the SSH server does not support.
Servers that accept rsa-sha2-* signatures for client authentication Servers that accept rsa-sha2-* signatures for client authentication
SHOULD implement the extension negotiation mechanism defined in SHOULD implement the extension negotiation mechanism defined in
[SSH-EXT-INFO], including especially the "server-sig-algs" extension. [SSH-EXT-INFO], including especially the "server-sig-algs" extension.
When authenticating with an RSA key against a server that does not When authenticating with an RSA key against a server that does not
skipping to change at page 4, line 33 skipping to change at page 5, line 33
- To the immediate right of the column Public Key Algorithm Name, - To the immediate right of the column Public Key Algorithm Name,
a new column is to be added, titled Signature Algorithm Name. For a new column is to be added, titled Signature Algorithm Name. For
existing entries, the column Signature Algorithm Name should be existing entries, the column Signature Algorithm Name should be
assigned the same value found under Public Key Algorithm Name. assigned the same value found under Public Key Algorithm Name.
- Immediately following the existing entry for "ssh-rsa", two sibling - Immediately following the existing entry for "ssh-rsa", two sibling
entries are to be added: entries are to be added:
P. K. Alg. Name Sig. Alg. Name Reference Note P. K. Alg. Name Sig. Alg. Name Reference Note
ssh-rsa rsa-sha2-256 [this document] Section 2 ssh-rsa rsa-sha2-256 [this document] Section 3
ssh-rsa rsa-sha2-512 [this document] Section 2 ssh-rsa rsa-sha2-512 [this document] Section 3
5. Security Considerations 5. Security Considerations
The security considerations of [RFC4253] apply to this document. The security considerations of [RFC4251] apply to this document.
The National Institute of Standards and Technology (NIST) Special The National Institute of Standards and Technology (NIST) Special
Publication 800-131A [800-131A] disallows the use of RSA and DSA keys Publication 800-131A [800-131A] disallows the use of RSA and DSA keys
shorter than 2048 bits for US government use after 2013. Keys of 2048 shorter than 2048 bits for US government use after 2013. The same
bits or larger are considered acceptable. document disallows the SHA-1 hash function, as used in the "ssh-rsa"
and "ssh-dss" algorithms, for digital signature generation after 2013.
The same document disallows the SHA-1 hash function, as used in the This document is based on the premise that RSA is used in environments
"ssh-rsa" and "ssh-dss" algorithms, for digital signature generation where a gradual, compatible transition to improved algorithms will be
after 2013. The SHA-2 family of hash functions is seen as acceptable. better received than one that is abrupt and incompatible. It advises
that SSH implementations add support for new RSA signature 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 they have reason
to believe that new RSA signature algorithms have been widely adopted.
6. Why no DSA? 6. Why no DSA?
A draft version of this memo also defined an algorithm name for use of A draft version of this memo also defined an algorithm name for use of
2048-bit and 3072-bit DSA keys with a 256-bit subgroup and SHA-2 256 2048-bit and 3072-bit DSA keys with a 256-bit subgroup and SHA-2 256
hashing. It is possible to implement DSA securely by generating "k" hashing. It is possible to implement DSA securely by generating "k"
deterministically as per [RFC6979]. However, a plurality of reviewers deterministically as per [RFC6979]. However, a plurality of reviewers
were concerned that implementers would continue to use libraries that were concerned that implementers would continue to use libraries that
generate "k" randomly. This is vulnerable to biased "k" generation, generate "k" randomly. This is vulnerable to biased "k" generation,
and extremely vulnerable to "k" reuse. and extremely vulnerable to "k" reuse. This document therefore
disrecommends DSA, in favor of RSA and elliptic curve cryptography.
This document therefore abstains from defining new algorithm names
for DSA, and recommends RSA where this is preferred over elliptic
curve cryptography.
7. References 7. References
7.1. Normative References 7.1. Normative References
[FIPS-180-4] [FIPS-180-4]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
United States of America, "Secure Hash Standard (SHS)", United States of America, "Secure Hash Standard (SHS)",
FIPS Publication 180-4, August 2015, FIPS Publication 180-4, August 2015,
<http://dx.doi.org/10.6028/NIST.FIPS.180-4>. <http://dx.doi.org/10.6028/NIST.FIPS.180-4>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
[RFC4251] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006. Authentication Protocol", RFC 4252, January 2006.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006. Transport Layer Protocol", RFC 4253, January 2006.
7.2. Informative References 7.2. Informative References
[800-131A] National Institute of Standards and Technology (NIST), [800-131A] National Institute of Standards and Technology (NIST),
"Transitions: Recommendation for Transitioning the Use of "Transitions: Recommendation for Transitioning the Use of
skipping to change at page 5, line 51 skipping to change at page 6, line 51
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250, January 2006. Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital [RFC6979] Pornin, T., "Deterministic Usage of the Digital
Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (DSA) and Elliptic Curve Digital
Signature Algorithm (ECDSA)", RFC 6979, August 2013. Signature Algorithm (ECDSA)", RFC 6979, August 2013.
[SSH-EXT-INFO] [SSH-EXT-INFO]
Bider, D., "Extension Negotiation in Secure Shell (SSH)", Bider, D., "Extension Negotiation in Secure Shell (SSH)",
draft-ietf-curdle-ssh-ext-info-02.txt, February 2017, draft-ietf-curdle-ssh-ext-info-03.txt, March 2017,
<https://tools.ietf.org/html/ <https://tools.ietf.org/html/
draft-ietf-curdle-ssh-ext-info-02>. draft-ietf-curdle-ssh-ext-info-03>.
Author's Address Author's Address
Denis Bider Denis Bider
Bitvise Limited Bitvise Limited
Suites 41/42, Victoria House Suites 41/42, Victoria House
26 Main Street 26 Main Street
GI GI
Phone: +506 8315 6519 Phone: +506 8315 6519
EMail: ietf-ssh3@denisbider.com EMail: ietf-ssh3@denisbider.com
URI: https://www.bitvise.com/ URI: https://www.bitvise.com/
Acknowledgments Acknowledgments
Thanks to Jon Bright, Niels Moeller, Stephen Farrell, Mark D. Baushke, Thanks to Jon Bright, Niels Moeller, Stephen Farrell, Mark D. Baushke,
Jeffrey Hutzelman, Hanno Boeck, Peter Gutmann, Damien Miller, and Mat Jeffrey Hutzelman, Hanno Boeck, Peter Gutmann, Damien Miller, Mat
Berchtold for comments and suggestions. Berchtold, and Roumen Petrov for reviews, comments, and suggestions.
 End of changes. 21 change blocks. 
37 lines changed or deleted 91 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/