|
> I would change the rsa-sha2 draft to say
> that the same ID string should be used
> throughout, i.e. "ssh-rsa" for RSA sigs and keys.
This is actually exactly contrary to what the current draft says, and what
it has said for 9 months in its latest version.
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.
My strong preference would have been for implementations - especially the
early implementations - to verify this strictly, and to not accept signatures
that depart from this spec. Once a deployed based of strict and correct
implementations is in place, it would have been difficult for later
implementations to do anything incorrectly.
Unfortunately, we now appear to be in a situation where not only one, but
potentially two implementations depart from the above spec. Therefore, it
definitely seems to me that we need a section about this in the draft, and
current and future implementations might need to err on the side of being
permissive. :( :-/
----- Original Message -----
From: Peter Gutmann
Sent: Monday, August 1, 2016 06:30
To: denis bider (Bitvise) ; ietf-ssh%netbsd.org@localhost
Subject: RE: rsa-sha2-256/512: handling of incorrect signature
encoding
denis bider (Bitvise) <ietf-ssh3%denisbider.com@localhost> writes:
>The invariants our implementation currently expects are:
>- name 1, in the USERAUTH request, can be any of the RSA signature
algorithm names
>- name 2, in the public key blob, must be "ssh-rsa"
>- name 3, in the signature blob, must match name 1
My code writes "ssh-rsa" for all three, and accepts whatever it finds
(along
with a sarcastic comment about why you need to specify the same thing
three
times in a row in case the server has gone deaf or something :-). For
the
first one:
/* Skip the first of the three copies of the algorithm name (see the
comment
in ssh2_cli.c for more on this). We don't do anything
with it because
we're about to get two more copies of the same thing, and the
key and
signature information take precedence over anything that we
find here */
Then for the second one it looks for ssh-rsa (or ssh-dss, or whatever,
since
it's needed to decode the key), and finally it again ignores the last
one
because it already knows what it should be.
Why is there a need for "rsa-sha2-256" and other complications when
"ssh-rsa"
is perfectly OK for everything else?
>My questions are:
>[...]
I would use (C) ignore everything except the key blob name. This
situation is
confusing enough that you're going to get implementations screwing things
up
in all sorts of ways, meaning you'll find who knows what in those ID
strings.
Apart from having to know what format the key is in the rest is
irrelevant,
you know the key is RSA, you've been hashing with SHA-1 or SHA-256 or
whatever, it doesn't matter what the ID strings say.
>Regardless of what we think is best - should we put a paragraph about
this in
>the rsa-sha2 draft?
I would change the rsa-sha2 draft to say that the same ID string should
be
used throughout, i.e. "ssh-rsa" for RSA sigs and keys.
Peter. |