draft-ietf-curdle-rsa-sha2-12.txt   rfc8332.txt 
Internet-Draft D. Bider Internet Engineering Task Force (IETF) D. Bider
Updates: 4252, 4253 (if approved) Bitvise Limited Request for Comments: 8332 Bitvise Limited
Intended status: Standards Track October 12, 2017 Updates: 4252, 4253 March 2018
Expires: April 12, 2018 Category: Standards Track
ISSN: 2070-1721
Use of RSA Keys with SHA-256 and SHA-512 in Secure Shell (SSH) Use of RSA Keys with SHA-256 and SHA-512
draft-ietf-curdle-rsa-sha2-12.txt in the Secure Shell (SSH) Protocol
Abstract Abstract
This memo updates RFC 4252 and RFC 4253 to define new public key 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 algorithms for use of RSA keys with SHA-256 and SHA-512 for server
client authentication in SSH connections. and client authentication in SSH connections.
Status Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task This document is a product of the Internet Engineering Task Force
Force (IETF), its areas, and its working groups. Note that other (IETF). It represents the consensus of the IETF community. It has
groups may also distribute working documents as Internet-Drafts. received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference material https://www.rfc-editor.org/info/rfc8332.
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at Copyright (c) 2018 IETF Trust and the persons identified as the
http://www.ietf.org/shadow.html document authors. All rights reserved.
Copyright This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) 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.
Copyright (c) 2017 IETF Trust and the persons identified as the This document may contain material from IETF Documents or IETF
document authors. All rights reserved. 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.
This document is subject to BCP 78 and the IETF Trust's Legal Table of Contents
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) 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 1. Overview and Rationale . . . . . . . . . . . . . . . . . . . 3
Contributions published or made publicly available before November 10, 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3
2008. The person(s) controlling the copyright in some of this material 1.2. Wire Encoding Terminology . . . . . . . . . . . . . . . . 3
may not have granted the IETF Trust the right to allow modifications 2. Public Key Format vs. Public Key Algorithm . . . . . . . . . 3
of such material outside the IETF Standards Process. Without obtaining 3. New RSA Public Key Algorithms . . . . . . . . . . . . . . . . 4
an adequate license from the person(s) controlling the copyright in 3.1. Use for Server Authentication . . . . . . . . . . . . . . 5
such materials, this document may not be modified outside the IETF 3.2. Use for Client Authentication . . . . . . . . . . . . . . 5
Standards Process, and derivative works of it may not be created 3.3. Discovery of Public Key Algorithms Supported by Servers . 6
outside the IETF Standards Process, except to format it for 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
publication as an RFC or to translate it into languages other than 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
English. 5.1. Key Size and Signature Hash . . . . . . . . . . . . . . . 7
5.2. Transition . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. PKCS #1 v1.5 Padding and Signature Verification . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
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 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]. [NIST.800-131A].
This memo updates RFC 4252 and RFC 4253 to define new public key This memo updates RFCs 4252 and 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
with SHA-256 and SHA-512. keys 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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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. Public Key Format vs. 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
B. A format used to encode a public key. keypair;
C. Procedures used to calculate, encode, and verify a signature. 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 This document uses the term "public key format" to identify only A
B in isolation. The term "public key algorithm" continues to identify and B in isolation. The term "public key algorithm" continues to
all three aspects A, B, and C. identify all three aspects -- A, B, and C.
3. New RSA Public Key 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 public key algorithm is indicated in SSH. how use of a public key algorithm is indicated in SSH.
The following new public key 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 public key algorithms reuse the "ssh-rsa" public key format as new public key algorithms reuse the "ssh-rsa" public key format as
defined in [RFC4253]: 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 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
the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as hash. to 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-256. For the algorithm "rsa-sha2-256", the hash used is SHA-256.
For the algorithm "rsa-sha2-512", the hash used is SHA-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 that
S - an octet string which is the output of RSASSA-PKCS1-v1_5, of contains an octet string S (which is the output of RSASSA-PKCS1-v1_5)
length equal to the length in octets of the RSA modulus. 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.
3.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
the server sends an "ssh-rsa" public key as part of the negotiated key negotiated, the server sends an "ssh-rsa" public key as part of the
exchange method (e.g. in SSH_MSG_KEXDH_REPLY), and encodes a signature negotiated key exchange method (e.g., in SSH_MSG_KEXDH_REPLY) and
with the appropriate signature algorithm name - either "rsa-sha2-256", encodes a signature with the appropriate signature algorithm name --
or "rsa-sha2-512". either "rsa-sha2-256" 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
method, and encoding the string field "public key algorithm name" with "publickey" method and encoding the string field "public key
the value "rsa-sha2-256" or "rsa-sha2-512". The "public key blob" algorithm name" with the value "rsa-sha2-256" or "rsa-sha2-512". The
field encodes the RSA public key using the "ssh-rsa" public key "public key blob" field encodes the RSA public key using the
format. "ssh-rsa" public key format.
For example, as defined in [RFC4252] and [RFC4253], an SSH "publickey" For example, as defined in [RFC4252] and [RFC4253], an SSH
authentication request using an "rsa-sha2-512" signature would be "publickey" authentication request using an "rsa-sha2-512" signature
properly encoded as follows: 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
If the client includes the signature field, the client MUST encode the If the client includes the signature field, the client MUST encode
same algorithm name in the signature as in SSH_MSG_USERAUTH_REQUEST - the same algorithm name in the signature as in
either "rsa-sha2-256", or "rsa-sha2-512". If a server receives a SSH_MSG_USERAUTH_REQUEST -- either "rsa-sha2-256" or "rsa-sha2-512".
mismatching request, it MAY apply arbitrary authentication penalties, If a server receives a mismatching request, it MAY apply arbitrary
including but not limited to authentication failure or disconnect. authentication penalties, including but not limited to authentication
failure or disconnect.
OpenSSH 7.2 (but not 7.2p2) incorrectly encodes the algorithm in the 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 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 is "rsa-sha2-256" or "rsa-sha2-512". In this case, the signature
actually use either SHA-256 or SHA-512. A server MAY, but is not does actually use either SHA-256 or SHA-512. A server MAY, but is
required to, accept this variant, or another variant that corresponds not required to, accept this variant or another variant that
to a good-faith implementation, and is decided to be safe to accept. corresponds to a good-faith implementation and is considered 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 that apply
authentication penalties to clients attempting public key algorithms authentication penalties to clients attempting public key algorithms
which the SSH server does not support. that 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. [RFC8308], 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
disabling "ssh-rsa", clients MAY default to one of the new algorithms. warrant 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 has updated the "Secure Shell (SSH) Protocol Parameters"
Parameters" registry established with [RFC4250], to extend the table registry, established with [RFC4250], to extend the table "Public Key
Public Key Algorithm Names [IANA-PKA]: Algorithm Names" [IANA-PKA] as follows.
- 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 Public Key Format. For existing a new column has been added, titled "Public Key Format". For
entries, the column Public Key Format should be assigned the same existing entries, the column "Public Key Format" has been assigned
value found under Public Key Algorithm Name. the same value as under "Public Key Algorithm Name".
- Immediately following the existing entry for "ssh-rsa", two sibling - Immediately following the existing entry for "ssh-rsa", two
entries are to be added: sibling entries have been added:
P. K. Alg. Name P. K. Format Reference Note P. K. Alg. Name P. K. Format Reference Note
rsa-sha2-256 ssh-rsa [this document] Section 3 rsa-sha2-256 ssh-rsa RFC 8332 Section 3
rsa-sha2-512 ssh-rsa [this document] Section 3 rsa-sha2-512 ssh-rsa RFC 8332 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, Revision 1 [800-131A], disallows the use of RSA Publication 800-131A, Revision 1 [NIST.800-131A] disallows RSA and
and DSA keys shorter than 2048 bits for US government use. The same 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. 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
where a gradual, compatible transition to improved algorithms will be environments where a gradual, compatible transition to improved
better received than one that is abrupt and incompatible. It advises algorithms will be better received than one that is abrupt and
that SSH implementations add support for new RSA public key algorithms incompatible. It advises that SSH implementations add support for
along with SSH_MSG_EXT_INFO and the "server-sig-algs" extension to new RSA public key algorithms along with SSH_MSG_EXT_INFO and the
allow coexistence of new deployments with older versions that support "server-sig-algs" extension to allow coexistence of new deployments
only "ssh-rsa". Nevertheless, implementations SHOULD start to disable with older versions that support only "ssh-rsa". Nevertheless,
"ssh-rsa" in their default configurations as soon as they have reason implementations SHOULD start to disable "ssh-rsa" in their default
to believe that new RSA signature algorithms have been widely adopted. configurations as soon as the implementers 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:
(1) RSASSA-PSS is not universally available to all implementations; (1) RSASSA-PSS is not universally available to all implementations;
(2) PKCS#1 v1.5 is widely supported in existing SSH implementations; (2) PKCS #1 v1.5 is widely supported in existing SSH
(3) PKCS#1 v1.5 is not known to be insecure for use in this scheme. implementations;
(3) PKCS #1 v1.5 is not known to be insecure for use in this scheme.
Implementers are advised that a signature with PKCS#1 v1.5 padding Implementers are advised that a signature with RSASSA-PKCS1-v1_5
MUST NOT be verified by applying the RSA key to the signature, and padding MUST NOT be verified by applying the RSA key to the
then parsing the output to extract the hash. This may give an attacker signature, and then parsing the output to extract the hash. This may
opportunities to exploit flaws in the parsing and vary the encoding. give an attacker opportunities to exploit flaws in the parsing and
Verifiers MUST instead apply PKCS#1 v1.5 padding to the expected hash, vary the encoding. Verifiers MUST instead apply RSASSA-PKCS1-v1_5
then compare the encoded bytes with the output of the RSA operation. padding to the expected hash, then compare the encoded bytes with the
output of the RSA operation.
6. References 6. References
6.1. Normative References 6.1. Normative References
[SHS] National Institute of Standards and Technology (NIST), [SHS] NIST, "Secure Hash Standard (SHS)", FIPS Publication
United States of America, "Secure Hash Standard (SHS)", 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,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4251] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006. Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <https://www.rfc-editor.org/info/rfc4251>.
[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, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[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, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[EXT-INFO] Bider, D., "Extension Negotiation in Secure Shell (SSH)", [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
draft-ietf-curdle-ssh-ext-info-15.txt, September 2017, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
<https://tools.ietf.org/html/ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
draft-ietf-curdle-ssh-ext-info-15>.
[RFC8308] Bider, D., "Extension Negotiation in the Secure Shell
(SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March
2018, <https://www.rfc-editor.org/info/rfc8308>.
6.2. Informative References 6.2. Informative References
[800-131A] National Institute of Standards and Technology (NIST), [NIST.800-131A]
"Transitions: Recommendation for Transitioning the Use of NIST, "Transitions: Recommendation for Transitioning the
Cryptographic Algorithms and Key Lengths", NIST Special Use of Cryptographic Algorithms and Key Lengths", NIST
Publication 800-131A, Revision 1, November 2015, Special Publication 800-131A, Revision 1,
DOI 10.6028/NIST.SP.800-131Ar1, 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,
DOI 10.17487/RFC4250, January 2006,
<https://www.rfc-editor.org/info/rfc4250>.
[RFC8017] Moriarty, K., Kaliski, B., Jonsson, J. and Rusch, A., [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2", "PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, November 2016. RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>.
[IANA-PKA] "Secure Shell (SSH) Protocol Parameters", [IANA-PKA]
<https://www.iana.org/assignments/ssh-parameters/ IANA, "Secure Shell (SSH) Protocol Parameters",
ssh-parameters.xhtml#ssh-parameters-19>. <https://www.iana.org/assignments/ssh-parameters/>.
Author's Address Acknowledgments
Denis Bider Thanks to Jon Bright, Niels Moeller, Stephen Farrell, Mark D.
Bitvise Limited Baushke, Jeffrey Hutzelman, Hanno Boeck, Peter Gutmann, Damien
4105 Lombardy Court Miller, Mat Berchtold, Roumen Petrov, Daniel Migault, Eric Rescorla,
Colleyville, Texas 76034 Russ Housley, Alissa Cooper, Adam Roach, and Ben Campbell for
United States of America reviews, comments, and suggestions.
Email: ietf-ssh3@denisbider.com Author's Address
URI: https://www.bitvise.com/
Acknowledgments Denis Bider
Bitvise Limited
4105 Lombardy Court
Colleyville, Texas 76034
United States of America
Thanks to Jon Bright, Niels Moeller, Stephen Farrell, Mark D. Baushke, Email: ietf-ssh3@denisbider.com
Jeffrey Hutzelman, Hanno Boeck, Peter Gutmann, Damien Miller, Mat URI: https://www.bitvise.com/
Berchtold, Roumen Petrov, Daniel Migault, Eric Rescorla, Russ Housley,
Alissa Cooper, Adam Roach, and Ben Campbell for reviews, comments, and
suggestions.
 End of changes. 72 change blocks. 
227 lines changed or deleted 271 lines changed or added

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