[noise] Comparing SSH and Noise
rhys.weatherley at gmail.com
Tue Jun 27 23:44:35 PDT 2017
I've been re-reading RFC 4253, which describes the SSH transport layer
protocol (hereafter called "TLP").
The purpose of TLP is to establish an encrypted/authenticated session,
transfer the host's public key to the client, prove that that host is in
possession of the corresponding private key, and to output a hash which the
RFC calls a "session identifier".
That's it. TLP does not perform user authentication. That's done by inner
protocols using the session identifier for channel binding.
In Noise terminology, the TLP is a Noise_NX handshake with the session
identifier being the final handshake hash.
The discussion of NoiseSocket/Link/Transport until now has focused on
Noise_XX but I'm wondering whether that's the correct pattern. User
authentication is a different and difficult problem: passwords, DH
authentication, Ed25519 signatures, two factor codes sent via SMS, and on
and on. Authentication requirements are very application-centric, whereas
basic TLP can be application-agnostic.
I wonder whether we could use Noise to do something like SSH
authentication. Perform an NX handshake to secure the transport and then
authenticate with a nested Noise handshake inside the data transport phase
of the session. For DH authentication, the "Xfallback" pattern could be
Noise_Xfallback(e, s, rs):
-> es, s, ss
This reuses the ephemeral key from the outer NX handshake rather than
create a new one. The outer handshake hash is provided as the prologue to
the inner handshake to perform channel binding. This is a novel use of
"fallback" in that we are not abandoning the previous session but rather
Technically we don't need to encrypt "s" in the inner handshake because we
already have encryption from the outer handshake. We do need the MAC
though to prove the user's identity. So instead:
Noise_Xfallback+noidh(e, s, rs):
-> s, es, ss
An unrolled implementation of this pattern requires two DH operations and a
MAC computation. One of the DH computations is the same as from the "es"
token in the surrounding NX handshake, so the DH output could be reused.
Maybe the inner handshake can be shortened even further by ditching the
-> s, ss
For authentication with Ed25519 signatures, we could extend as follows:
-> s, ss, sig
I am assuming here that the client's DH key can be transposed into an
Ed25519 key for the "sig" token. For server Ed25519 signatures, the server
would use NXsig as the outer handshake instead of NX:
<- e, ee, s, es, sig
There you have it. Thoughts? I think this demonstrates that we don't have
to solve everything in the outermost link layer. We can use nested Noise
sessions for authentication and other extensions.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Noise