<div dir="ltr">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 used: Noise_Xfallback(e, s, rs): -> e <- s ... -> 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 continuing it. 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): -> e <- s ... -> 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 ephemeral: Noise_Xnoephem(s, rs): <- s ... -> s, ss For authentication with Ed25519 signatures, we could extend as follows: Noise_Xnoephem+sig(s, rs): <- s ... -> 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: Noise_NXsig(rs): -> e <- 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. Cheers, Rhys. </div>