[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (Client side) RSA signatures with SHA2 (RFC 8332 and RFC 8308)


On Wednesday, 27 June 2018 15:23:08 CEST Jakub Jelen wrote:
> Hello,

Hi Jakub,

> The attached are patches to implement extension negotiation for SSH
> (RFC 8308) and a new RSA signatures with SHA2 (RFC 8332), which are
> negotiated using this mechanism and already used for few years in
> OpenSSH.

thank you very much for your contribution. Could you please rebase them on 
current master and resend the patchset?

> While debugging the initial implementation, I noticed failures in
> torture_connect_double test, which showed up the disconnect was not
> properly resetting all the session structures and values to be ready
> for the new connection. This worked before, because just the connect
> did not use the negotiated crypto before [first patch].

Nice catch. Someone complained about that in the IRC channel already.

> Then there are few more minor issues that I hit during the work
> throughout the code.
> 
> From the RFC 8332 (SHA2 extension), Section 2 [1], it is not completely
> clear whether the the new algorithms are supposed to reference only the
> signatures in the code, or they can reference also the public/private
> keys themselves. The distinction is somehow fuzzy also in the OpenSSH
> code if I remember well, so this is one thing to consideration.
> 
> Another thing to consider is possibility to configure/enable/disable
> these algorithms if needed. This is done in OpenSSH with
> PubkeyAcceptedKeyTypes option, which is not implemented in libssh at
> this moment, but should not be too hard to handle (I can do that, if
> you would consider it make sense).

I think it would make sense to support that.
 
> The host keys are tested in a new test torture_hostkey, which tries all
> the supported mechanisms and verifies the server key signature is
> properly validated.
> 
> The second part is about using this extension for public key
> authentication, which adds the signature counterparts for the verify
> added in the previous part. This requires addition to the PKI api to
> specify the algorithm to use in addition to the key itself. The
> attached patch provides the verification that signatures provided by
> this interface are verifiable.

Does this touch public API? I haven't looked into them yet.

> The last part is about ability to request the same signatures from
> compatible ssh-agent using the flags described in the ssh-agent
> protocol.
> 
> What is missing is a server side implementation: The server recognizing
> the extension, sending its supported algorithms, sending the host keys
> signatures using the new algorithms and verifying the new signatures
> during authentication (should work, but needs to be verified). I did
> not go into that, because of the lack of the test suite for the server.
> Are there any plans for introducing tests for server?

This has been added now, see tests/pkd

configure with: -DWITH_SERVER=ON -DSERVER_TESTING=ON

> 
> I tested against current OpenSSH 7.7p1 in Fedora and with all of the
> openssl, libgcrypt and mbedtls and all the tests are passing.
> 
> [1] https://tools.ietf.org/html/rfc8332#section-2


Great work so far!


Thanks.


-- 
Andreas Schneider                 asn@xxxxxxxxxxxxxx
GPG-ID:     8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D



Follow-Ups:
Re: (Client side) RSA signatures with SHA2 (RFC 8332 and RFC 8308)Jakub Jelen <jjelen@xxxxxxxxxx>
References:
(Client side) RSA signatures with SHA2 (RFC 8332 and RFC 8308)Jakub Jelen <jjelen@xxxxxxxxxx>
Archive administrator: postmaster@lists.cynapses.org