Re: Feedback on draft-ssh-ext-info-00

denis bider <[email protected]>
Newsgroups gmane.ietf.secsh
Message-ID <[email protected]>
My implementation agrees with Niels's analysis. Even without signature, the signature algorithm name ("rsa-sha2-256") is sent in USERAUTH_REQUEST as "public key algorithm name", followed by public key blob encoding an "ssh-rsa" public key.

No signature is needed to find out whether the server will accept "rsa-sha2-256". If you don't mind making multiple attempts - first "rsa-sha2-256", then "rsa-sha2-512", then "ssh-rsa" - then no extensions are needed to discover which signature algorithms will be accepted; and an actual signature is needed only with the one that will be accepted.

My concern with extensions is removing the trial and error, so that public key authentication with Australia doesn't take 1.5 seconds.


Niels Möller <[email protected]> , 12/3/2015 8:23 AM:
Damien Miller <[email protected]> writes: 
 
> The problem is that, for a client to test whether rsa-sha2-256 is supported, 
> it must make publickey userauth with an included signature. A 
> signature free PK_OK style request won't do since the key blob just 
> contains ssh-rsa and not the signature algorithm. 
 
Hmm. This sounds like a serious breakage, and if that's the case, we 
really ought to use a new algorithm name also in the key blob. 
 
But is it really so? Looking at RFC 5252, we have 
 
      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    public key algorithm name 
      string    public key blob 
 
and 
 
      byte      SSH_MSG_USERAUTH_PK_OK 
      string    public key algorithm name from the request 
      string    public key blob from the request 
 
I'd expect the "public key algorithm name" to be "ssh-rsa-sha2-256", and 
then it's fine if the string inside the keyblob is "ssh-rsa". There's no 
ambiguity as to what type of signature is intended. 
 
Regards, 
/Niels 
 
--  
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. 
Internet email is subject to wholesale government surveillance.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.