On 2018-03-22 01:52, Peter Stuge wrote: > Hector Martin 'marcan' wrote: >>> Since forwarding ssh processes just forward agent socket bytes >>> without tracking the protocol state in that stream adding a packet >>> isn't trivial. >> >> It's reasonably trivial if the definition is that the forwarded-for >> extension chain happens once when agent connections are opened. Then the >> ssh process just needs to send the extension, wait for the reply >> (whether positive or not-supported), eat it, and move on with forwarding >> the remaining bytestream. > > I wouldn't like to introduce a hard requirement for agent socket > connections to only perform private key operations for a single nexthop. > > The OpenSSH ssh client is but one agent socket consumer... As far as I know, every downstream agent connection results in a new upstream agent connection (agent connections are not muxed together into one, but rather are independently forwarded). Therefore we can always uniquely tag a given agent connection with the sequence of hops it passed through at the start. I think this would add no extra latency if implemented properly. This would by necessity all be optional anyway (since older clients won't do it). However, the final returned path should be secure in the sense that a trusted node with a client that supports this will always prepend the identity of the nexthop, so an "untrusted"/unexpected hop will always be tagged by its parent, regardless or what it itself chooses to do. I.e. a complete sequence of trusted (and known implementing) hops guarantees that the request didn't inadvertently traverse an untrusted/unexpected hop. The absence of forwarded-for extensions means the consumer is on the local machine (e.g. a plain ssh client without forwarding, or anything else). It could be argued that a different forwarding client/design might want to reuse agent connections across different paths... but that opens up a bit of a can of worms regarding the protocol. At that point forwarders would need to be able to parse everything, and I could see a lot of interesting gotchas if a given forwarding client's understanding of the protocol and the agent's differs, in the presence of a malicious target. There's value in the clean break of using a new connection for each forwarding path. This is different from the remote-id (case 1). It's entirely reasonable to want to be able to change that binding during a single session, e.g. a single client authenticating to different targets reusing a single agent connection. > But I'm all for the idea for case 1. FWIW I'm not too particular about this case, my main usecase is case 1. I just think it would be neat to be able to display/log some metadata on what the forwarding path is for any given operation too. This helps secure against attacks when multiple forwardings are in use at once, by making it explicit who is making the request. -- Hector Martin "marcan" (marcan@xxxxxxxxx) Public Key: https://mrcn.st/pub _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
