draft-ietf-curdle-rsa-sha2-06.txt   draft-ietf-curdle-rsa-sha2-07.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 April 24, 2017 Intended status: Standards Track May 4, 2017
Expires: October 24, 2017 Expires: November 4, 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-06.txt draft-ietf-curdle-rsa-sha2-07.txt
Abstract Abstract
This memo updates RFC 4252 and RFC 4253 to define an algorithm name, This memo updates RFC 4252 and RFC 4253 to define new public key
public key format, and signature format for use of RSA keys with SHA-2 algorithms for use of RSA keys with SHA-2 hashing for server and
hashing 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 20 skipping to change at page 2, line 20
an adequate license from the person(s) controlling the copyright in an adequate license from the person(s) controlling the copyright in
such materials, this document may not be modified outside the IETF such materials, this document may not be modified outside the IETF
Standards Process, and derivative works of it may not be created Standards Process, and derivative works of it may not be created
outside the IETF Standards Process, except to format it for outside the IETF Standards Process, except to format it for
publication as an RFC or to translate it into languages other than publication as an RFC or to translate it into languages other than
English. English.
1. Overview and Rationale 1. Overview and Rationale
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 public key
methods "ssh-rsa" for server and client authentication using RSA with algorithms "ssh-rsa" for server and client authentication using RSA
SHA-1, and "ssh-dss" using 1024-bit DSA and SHA-1. with 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 algorithms are considered deficient. For US
For US government use, NIST has disallowed 1024-bit RSA and DSA, and government use, NIST has disallowed 1024-bit RSA and DSA, and use of
use of SHA-1 for signing [800-131A]. SHA-1 for signing [800-131A].
This memo introduces a distinction between public key and signature This memo defines new public key algorithms allowing for interoperable
algorithms in SSH, and defines new signature algorithm names allowing use of existing and new RSA keys with SHA-2 hashing.
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].
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",
"string", "mpint" - have meanings as described in [RFC4251]. "string", "mpint" - have meanings as described in [RFC4251].
2. Signature Algorithm as Distinct Aspect of Public Key Algorithm 2. Public Key Format vs. Public Key Algorithm
In [RFC4252], the concept "public key algorithm" is used to establish In [RFC4252], the concept "public key algorithm" is used to establish
a relationship between one algorithm name, and: a relationship between one algorithm name, and:
A. Procedures used to generate and validate a private/public keypair. A. Procedures used to generate and validate a private/public keypair.
B. A format used to encode a public key. B. A format used to encode a public key.
C. Procedures used to calculate, encode, and verify a signature. C. Procedures used to calculate, encode, and verify a signature.
This document narrows the term "public key algorithm" to mean A and B, This document uses the term "public key format" to identify only A and
though it can still potentially imply C when a public key algorithm is B in isolation. The term "public key algorithm" continues to identify
associated with only one signature algorithm. A new term, "signature all three aspects A, B, and C.
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 3. New RSA Public Key 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 public key algorithm is indicated in SSH.
The following new signature algorithms are defined: The following new public key 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 algorithms are suitable for use both in the SSH transport layer These algorithms are suitable for use both in the SSH transport layer
[RFC4253] for server authentication, and in the authentication layer [RFC4253] for server authentication, and in the authentication layer
[RFC4252] for client authentication. [RFC4252] for client authentication.
Since RSA keys are not dependent on the choice of hash function, the Since RSA keys are not dependent on the choice of hash function, the
new signature algorithms are defined as aspects of the existing new public key algorithms reuse the "ssh-rsa" public key format as
"ssh-rsa" public key algorithm. This means the new algorithms reuse defined in [RFC4253]:
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". This allows existing RSA keys to be used with the string "ssh-rsa". This allows existing RSA keys to be used with the
new signature formats, 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;
MGF1 as mask function; and salt length equal to hash size. 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:
skipping to change at page 4, line 48 skipping to change at page 4, line 23
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".
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" algorithm name. field encodes the RSA public key using the "ssh-rsa" public key
The signature field, if present, encodes a signature using an format. 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".
For example, an SSH "publickey" authentication request using an For example, an SSH "publickey" authentication request using an
"rsa-sha2-512" signature would be properly encoded as follows: "rsa-sha2-512" signature would be 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
3.3. Discovery of signature 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 signature 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.
When authenticating with an RSA key against a server that does not When authenticating with an RSA key against a server that does not
implement the "server-sig-algs" extension, clients MAY default to an implement the "server-sig-algs" extension, clients MAY default to an
"ssh-rsa" signature to avoid authentication penalties. When the new "ssh-rsa" signature to avoid authentication penalties. When the new
rsa-sha2-* algorithms have been sufficiently widely adopted to warrant rsa-sha2-* algorithms have been sufficiently widely adopted to warrant
disabling "ssh-rsa", clients MAY default to one of the new algorithms. disabling "ssh-rsa", clients MAY default to one of the new algorithms.
4. IANA Considerations 4. IANA Considerations
IANA is requested to update the "Secure Shell (SSH) Protocol IANA is requested to update the "Secure Shell (SSH) Protocol
Parameters" registry established with [RFC4250], to extend the table Parameters" registry established with [RFC4250], to extend the table
Public Key Algorithm Names [IANA-PKA]: Public Key Algorithm Names [IANA-PKA]:
- 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 Public Key Format. For existing
existing entries, the column Signature Algorithm Name should be entries, the column Public Key Format should be assigned the same
assigned the same value found under Public Key Algorithm Name. 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 P. K. Format Reference Note
ssh-rsa rsa-sha2-256 [this document] Section 3 rsa-sha2-256 ssh-rsa [this document] Section 3
ssh-rsa rsa-sha2-512 [this document] Section 3 rsa-sha2-512 ssh-rsa [this document] Section 3
5. Security Considerations 5. Security Considerations
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 [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. The same shorter than 2048 bits for US government use after 2013. The same
document disallows the SHA-1 hash function, as used in the "ssh-rsa" document disallows the SHA-1 hash function, as used in the "ssh-rsa"
and "ssh-dss" algorithms, for digital signature generation after 2013. and "ssh-dss" algorithms, for digital signature generation after 2013.
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 signature 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
to believe that new RSA signature algorithms have been widely adopted. to believe that new RSA signature algorithms have been widely adopted.
5.3. PKCS#1 v1.5 Padding and Signature Verification 5.3. PKCS#1 v1.5 Padding and Signature Verification
This document prescribes RSASSA-PKCS1-v1_5 signature padding because: This document prescribes RSASSA-PKCS1-v1_5 signature padding because:
skipping to change at page 7, line 17 skipping to change at page 7, line 17
7.1. Normative References 7.1. Normative References
[SHS] National Institute of Standards and Technology (NIST), [SHS] 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.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[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.
7.2. Informative References 7.2. Informative References
skipping to change at page 7, line 49 skipping to change at page 7, line 46
[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.
[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)", [EXT-INFO] Bider, D., "Extension Negotiation in Secure Shell (SSH)",
draft-ietf-curdle-ssh-ext-info-05.txt, April 2017, draft-ietf-curdle-ssh-ext-info-06.txt, May 2017,
<https://tools.ietf.org/html/ <https://tools.ietf.org/html/
draft-ietf-curdle-ssh-ext-info-05>. draft-ietf-curdle-ssh-ext-info-06>.
[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
Suites 41/42, Victoria House Suites 41/42, Victoria House
 End of changes. 22 change blocks. 
70 lines changed or deleted 37 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/