Re: rsa-sha2-256/512: handling of incorrect signature encoding

Hello Ron,

I’m not familiar with the OpenSSH certificate implementation, but there is an RFC specifying the use of X.509 certificates in SSH that defines its own key type for RSA with SHA-2 based signatures:

https://tools.ietf.org/html/rfc6187

I don’t know what your users require, but from our users we are seeing requests to implement X.509 as per this RFC, not the @openssh versions.

denis

From: Ron Frederick

Sent: Sunday, September 11, 2016 20:39

To: ietf-ssh%netbsd.org@localhost

Subject: Re: rsa-sha2-256/512: handling of incorrect signature encoding

Denis Bider (Bitvise) wrote:

If you are sending an rsa-sha2-XXX signature, you cannot set all 3 fields in the authentication request to "ssh-rsa", because then this makes for a SHA-1 signature as it was done traditionally, not a SHA-2 signature. To send a SHA-2 signature, at least one field has to contain "rsa-sha2-XXX".

The draft specifically says the signature format names are "rsa-sha2-XXX", but the public key format name stays "ssh-rsa", which it must stay in order to preserve existing RSA key fingerprints.

The signature format is defined thus:

string    "rsa-sha2-256" / "rsa-sha2-512"

string    rsa_signature_blob

These specifications seem to me very clear and unambiguous. In a user authentication request, when sending a SHA-2 signature, the only correct encoding of algorithm names is as follows:

byte      SSH_MSG_USERAUTH_REQUEST

string    user name

string    service name

string    "publickey"

boolean   TRUE

string    "rsa-sha2-256" / "rsa-sha2-512"

string    public key blob:

string    "ssh-rsa"

mpint     e

mpint     n

string    signature:

string    "rsa-sha2-256" / "rsa-sha2-512"

string    rsa_signature_blob

If your implementation does not encode the algorithm names this way, it is incorrect. The latest OpenSSH versions encode the algorithm names this way, though a previous version used "ssh-rsa" in the third field by mistake.

Bitvise SSH Client encodes the fields this way also, and the current version of Bitvise SSH Server expects the algorithm names this way, and only this way.

I did an implementation of this recently for AsyncSSH, and I have matched the above in the case where regular keys are used, with the first and third identifiers being rsa-sha2-256/rsa-sha2-512 and the second identifier remaining ssh-rsa when the new-style signatures are used. However, I also wanted to verify the correct identifiers to use in the certificate case.

Right now, I’m using ssh-rsa-cert-v01%openssh.com@localhost as both the first and second identifier in the certificate case, and only using rsa-sha2-256/rsa-sha2-512 for the third identifier associated with the signature. This seems to work when talking to an OpenSSH server, and in fact OpenSSH doesn’t seem to accept the certificate if the first identifier does not identify that a certificate is being used, even if the second identifier indicates that a certificate was provided as the public key blob.

I know that certificates are OpenSSH-specific, so my apologies in advance if this is the wrong list to ask this question on. I just happened to see this thread in the mailing list archive, and though it would be good to get confirmation from the group.

Ron Frederick

ronf%timeheart.net@localhost