--- 1/draft-ietf-curdle-rsa-sha2-01.txt 2016-09-12 20:16:16.919391172 -0700 +++ 2/draft-ietf-curdle-rsa-sha2-02.txt 2016-09-12 20:16:16.935391578 -0700 @@ -1,18 +1,18 @@ Internet-Draft D. Bider Updates: 4252, 4253 (if approved) Bitvise Limited -Intended status: Standards Track August 1, 2016 -Expires: February 1, 2017 +Intended status: Standards Track September 12, 2016 +Expires: February 12, 2017 Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) - draft-ietf-curdle-rsa-sha2-01.txt + draft-ietf-curdle-rsa-sha2-02.txt Abstract 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 authentication in SSH connections. Status This Internet-Draft is submitted in full conformance with the @@ -65,21 +65,21 @@ 1.1. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Public Key Algorithms This memo adopts the style and conventions of [RFC4253] in specifying - how the 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: rsa-sha2-256 RECOMMENDED sign Raw RSA key rsa-sha2-512 OPTIONAL sign Raw RSA key These signature algorithms are suitable for use both in the SSH transport layer [RFC4253] for server authentication, and in the authentication layer [RFC4252] for client authentication. @@ -161,58 +161,61 @@ Servers that accept rsa-sha2-* signatures for client authentication SHOULD implement the extension negotiation mechanism defined in [SSH-EXT-INFO], 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. 4. IANA Considerations - This document augments the Public Key Algorithm Names in [RFC4253] - and [RFC4250]. - IANA is requested to update the "Secure Shell (SSH) Protocol - Parameters" registry with the following entry: + Parameters" registry, to extend the table Public Key Algorithm Names: - Public Key Algorithm Name Reference Note - rsa-sha2-256 [this document] Section 2 - rsa-sha2-512 [this document] Section 2 + - To the immediate right of the column Public Key Algorithm Name, + a new column is to be added, titled Signature Algorithm Name. For + existing entries, the column Signature Algorithm Name should be + assigned the same value found under Public Key Algorithm Name. + + - Immediately following the existing entry for "ssh-rsa", two sibling + entries are to be added: + + P. K. Alg. Name Sig. Alg. Name Reference Note + ssh-rsa rsa-sha2-256 [this document] Section 2 + ssh-rsa rsa-sha2-512 [this document] Section 2 5. Security Considerations The security considerations of [RFC4253] apply to this document. The National Institute of Standards and Technology (NIST) Special 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 bits or larger are considered acceptable. The same document disallows the SHA-1 hash function, as used in the "ssh-rsa" and "ssh-dss" algorithms, for digital signature generation after 2013. The SHA-2 family of hash functions is seen as acceptable. 6. Why no DSA? 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 hashing. It is possible to implement DSA securely by generating "k" deterministically as per [RFC6979]. However, a plurality of reviewers - were concerned that implementers would not pay heed, and would use - cryptographic libraries that continue to generate "k" randomly. This - is vulnerable to biased "k" generation, and extremely vulnerable to - "k" reuse. The relative speed advantage of DSA signing compared to RSA - signing was not perceived to outweigh this shortcoming, especially - since algorithms based on elliptic curves are faster yet. + were concerned that implementers would continue to use libraries that + generate "k" randomly. This is vulnerable to biased "k" generation, + and extremely vulnerable to "k" reuse. - Due to these disrecommendations, this document abstains from defining - an algorithm name for large DSA keys, and recommends RSA instead. + 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.1. Normative References [FIPS-180-4] National Institute of Standards and Technology (NIST), United States of America, "Secure Hash Standard (SHS)", FIPS Publication 180-4, August 2015, . @@ -240,22 +243,23 @@ [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 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. [SSH-EXT-INFO] Bider, D., "Extension Negotiation in Secure Shell (SSH)", - draft-ietf-curdle-ssh-ext-info-00, March 2016, . + draft-ietf-curdle-ssh-ext-info-01, September 2016, + . Author's Address Denis Bider Bitvise Limited Suites 41/42, Victoria House 26 Main Street GI Phone: +506 8315 6519