> On Jul 1, 2020, at 8:24 AM, Nikos Mavrogiannopoulos <n...@redhat.com> wrote: > > On Tue, Jun 30, 2020 at 8:09 PM Aris Adamantiadis <a...@badcode.be> wrote: >> >> Hi Felipe, >> >> In SSH, all authentication schemes are signature-based. Specifically >> user authentication is based on signing the master hash that's derived >> from key exchange (i.e. everything that was shared by peers + shared >> secret). SSH ensures that the authentication is safe because it's >> impossible for either party to replay or precompute that hash. I don't >> think TLS would let you extract or derive secrets based on the session's >> secret. > > I'm not sure how you intend to use them, but to enable your reasoning, > you can derive secrets based on the session keys using the rfc5705 > exporters. I believe the exporters are supported by most > implementations.
I’ve done some research on this. As long as the RFC 5705 key material exports can fulfill the same security profile as the SSH session identifier, it seems like it would be legit to do something like: 1) Grab TLS’s key export. 2) Sign those bytes using the private key. 3) Send the signature and the key in, say, an HTTP handshake. 4) Server can verify the signature & authorization. This more or less seems to line up with what Aris proposed back on the 30th but is a bit more “NIH”. This feels like it could be broadly useful, as it would facilitate things like SSH key authentication in web browsers. Browsers could potentially expose some sort of JavaScript API for creating/saving a private key then exposing that key’s public part to the JS application. Thus, no more passwords entered, and none saved on the user’s computer either. I hope this thread hasn’t gotten over-long for being not strictly related to libssh, but … for those interested … thoughts? -FG
