draft-ietf-curdle-rsa-sha2-11.txt   draft-ietf-curdle-rsa-sha2-12.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 October 6, 2017 Intended status: Standards Track October 12, 2017
Expires: April 6, 2018 Expires: April 12, 2018
Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) Use of RSA Keys with SHA-256 and SHA-512 in Secure Shell (SSH)
draft-ietf-curdle-rsa-sha2-11.txt draft-ietf-curdle-rsa-sha2-12.txt
Abstract Abstract
This memo updates RFC 4252 and RFC 4253 to define new public key This memo updates RFC 4252 and RFC 4253 to define new public key
algorithms for use of RSA keys with SHA-2 hashing for server and algorithms for use of RSA keys with SHA-256 and SHA-512 for server and
client authentication in SSH connections. client 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 29 skipping to change at page 2, line 29
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 public key the Internet. In [RFC4253], SSH originally defined the public key
algorithms "ssh-rsa" for server and client authentication using RSA algorithms "ssh-rsa" for server and client authentication using RSA
with SHA-1, and "ssh-dss" using 1024-bit DSA and SHA-1. These with SHA-1, and "ssh-dss" using 1024-bit DSA and SHA-1. These
algorithms are now considered deficient. For US government use, NIST algorithms are now considered deficient. For US government use, NIST
has disallowed 1024-bit RSA and DSA, and use of SHA-1 for signing has disallowed 1024-bit RSA and DSA, and use of SHA-1 for signing
[800-131A]. [800-131A].
This memo updates RFC 4252 and RFC 4253 to define new public key This memo updates RFC 4252 and RFC 4253 to define new public key
algorithms allowing for interoperable use of existing and new RSA keys algorithms allowing for interoperable use of existing and new RSA keys
with SHA-2 hashing. with SHA-256 and SHA-512.
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].
1.2. Wire Encoding Terminology 1.2. Wire Encoding Terminology
The wire encoding types in this document - "boolean", "byte", The wire encoding types in this document - "boolean", "byte",
skipping to change at page 3, line 35 skipping to change at page 3, line 35
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". This allows existing RSA keys to be used with the string "ssh-rsa". This allows existing RSA keys to be used with the
new public key algorithms, without requiring re-encoding, or affecting new public key algorithms, without requiring re-encoding, 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 [RFC8017] using SHA-2 [SHS] as hash. the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as hash.
For the algorithm "rsa-sha2-256", the hash used is SHA-2 256. For the algorithm "rsa-sha2-256", the hash used is SHA-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-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.
skipping to change at page 4, line 24 skipping to change at page 4, line 24
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".
3.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" public key field encodes the RSA public key using the "ssh-rsa" public key
format. The signature field, if present, encodes a signature using an format.
algorithm name that MUST match the SSH authentication request - either
"rsa-sha2-256", or "rsa-sha2-512".
For example, as defined in [RFC4252] and [RFC4253], an SSH "publickey" For example, as defined in [RFC4252] and [RFC4253], an SSH "publickey"
authentication request using an "rsa-sha2-512" signature would be authentication request using an "rsa-sha2-512" signature would be
properly encoded as follows: properly encoded as follows:
byte SSH_MSG_USERAUTH_REQUEST byte SSH_MSG_USERAUTH_REQUEST
string user name string user name
string service name string service name
string "publickey" string "publickey"
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
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.
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 decided to be safe to accept.
3.3. Discovery of public key algorithms supported by servers 3.3. Discovery of public key 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 public key algorithms authentication penalties to clients attempting public key 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
[EXT-INFO], including especially the "server-sig-algs" extension. [EXT-INFO], including especially the "server-sig-algs" extension.
skipping to change at page 5, line 41 skipping to change at page 5, line 51
The security considerations of [RFC4251] apply to this document. The security considerations of [RFC4251] apply to this document.
5.1. Key Size and Signature Hash 5.1. Key Size and Signature Hash
The National Institute of Standards and Technology (NIST) Special The National Institute of Standards and Technology (NIST) Special
Publication 800-131A, Revision 1 [800-131A], disallows the use of RSA Publication 800-131A, Revision 1 [800-131A], disallows the use of RSA
and DSA keys shorter than 2048 bits for US government use. The same and DSA keys shorter than 2048 bits for US government use. The same
document disallows the SHA-1 hash function for digital signature document disallows the SHA-1 hash function for digital signature
generation, except under NIST's protocol-specific guidance. generation, except under NIST's protocol-specific guidance.
It is prudent to follow this advice also outside of US government use.
5.2. Transition 5.2. Transition
This document is based on the premise that RSA is used in environments This document is based on the premise that RSA is used in environments
where a gradual, compatible transition to improved algorithms will be where a gradual, compatible transition to improved algorithms will be
better received than one that is abrupt and incompatible. It advises better received than one that is abrupt and incompatible. It advises
that SSH implementations add support for new RSA public key algorithms that SSH implementations add support for new RSA public key algorithms
along with SSH_MSG_EXT_INFO and the "server-sig-algs" extension to along with SSH_MSG_EXT_INFO and the "server-sig-algs" extension to
allow coexistence of new deployments with older versions that support allow coexistence of new deployments with older versions that support
only "ssh-rsa". Nevertheless, implementations SHOULD start to disable only "ssh-rsa". Nevertheless, implementations SHOULD start to disable
"ssh-rsa" in their default configurations as soon as they have reason "ssh-rsa" in their default configurations as soon as they have reason
skipping to change at page 7, line 26 skipping to change at page 7, line 26
[RFC4251] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4251] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006. 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.
[EXT-INFO] Bider, D., "Extension Negotiation in Secure Shell (SSH)",
draft-ietf-curdle-ssh-ext-info-15.txt, September 2017,
<https://tools.ietf.org/html/
draft-ietf-curdle-ssh-ext-info-15>.
6.2. Informative References 6.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
Cryptographic Algorithms and Key Lengths", NIST Special Cryptographic Algorithms and Key Lengths", NIST Special
Publication 800-131A, Revision 1, November 2015, Publication 800-131A, Revision 1, November 2015,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-131Ar1.pdf>. NIST.SP.800-131Ar1.pdf>.
[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
Signature Algorithm (DSA) and Elliptic Curve Digital
Signature Algorithm (ECDSA)", RFC 6979, August 2013.
[RFC8017] Moriarty, K., Kaliski, B., Jonsson, J. and Rusch, A., [RFC8017] Moriarty, K., Kaliski, B., Jonsson, J. and Rusch, A.,
"PKCS #1: RSA Cryptography Specifications Version 2.2", "PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, November 2016. RFC 8017, November 2016.
[EXT-INFO] Bider, D., "Extension Negotiation in Secure Shell (SSH)",
draft-ietf-curdle-ssh-ext-info-15.txt, September 2017,
<https://tools.ietf.org/html/
draft-ietf-curdle-ssh-ext-info-15>.
[IANA-PKA] "Secure Shell (SSH) Protocol Parameters", [IANA-PKA] "Secure Shell (SSH) Protocol Parameters",
<https://www.iana.org/assignments/ssh-parameters/ <https://www.iana.org/assignments/ssh-parameters/
ssh-parameters.xhtml#ssh-parameters-19>. ssh-parameters.xhtml#ssh-parameters-19>.
Author's Address Author's Address
Denis Bider Denis Bider
Bitvise Limited Bitvise Limited
4105 Lombardy Court 4105 Lombardy Court
Colleyville, Texas 76034 Colleyville, Texas 76034
United States of America United States of America
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, Mat Jeffrey Hutzelman, Hanno Boeck, Peter Gutmann, Damien Miller, Mat
Berchtold, Roumen Petrov, Daniel Migault, and Eric Rescorla for reviews, Berchtold, Roumen Petrov, Daniel Migault, Eric Rescorla, Russ Housley,
comments, and suggestions. Alissa Cooper, Adam Roach, and Ben Campbell for reviews, comments, and
suggestions.
 End of changes. 12 change blocks. 
20 lines changed or deleted 29 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/