Re: Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG

[Brian May <bam@debian.org>]

On Fri, Nov 22, 2002 at 06:22:53PM -0600, Adam Heath wrote:
> In case it hasn't been mentioned, one could use sequence numbers, ala tcp.

You need to keep track (at both ends of the link) of the last
sequence number sent.

Or, if you allow emails to be sent from multiple hosts, you need
to keep track of the last sequence number from each host.

This is very much similar to TCP.

However, unlike TCP, there is no concept of a "connection" or "session"
(unless you create one), so sequence numbers have to be kept
indefinitely.

hmmm... come to think of it, session tracking might be an interesting
idea. sessions could also keep track of environment variables
and/or CWD. eg (one email by line, server is S, sender is C):

C --> S: open session
S --> C: session X is open
C --> S: session X command 1 execute "cd /tmp"
S --> C: session X command 1 output was "" (OPTIONAL)
C --> S: session X command 2 execute "rm *"
S --> C: session X command 2 output was "" (OPTIONAL)
C --> S: session X command 3 close
S --> C: session X is closed, session text was "..."

OR if received in duplicates or out of order:

C --> S: open session
S --> C: session X is open
C --> S: session X command 2 execute "rm *"
S --> C: session X command 2 received out of order; delayed. (OPTIONAL)
C --> S: session X command 1 execute "cd /tmp"
S --> C: session X command 1 output was "" (OPTIONAL)
C --> S: session X command 1 execute "cd /tmp"
S --> C: session X command 1 received duplicated. (OPTIONAL)
S --> C: session X command 2 output was "" (OPTIONAL)
(after n hours)
S --> C: session X is closed, session text was "..."
C --> S: session X command 3 execute "cd /tmp"
S --> C: session X command 3 session was closed. (OPTIONAL)

Except for the optional warnings that something has gone wrong, I think
this is very similar to TCP (except only one sequence per message is all
thats really required).

You just need to make sure it is not possible to replay the open session
command; this could be done by having the session number (X) a sequence
number that is always incremented by one. So even if a session open is
replayed, the session number would be different, making it useless to
replay the commands.

I think the worst an attacker could do with this protocol would be to
delay the last commands until after the session expires. This is
effectively a Denial-Of-Service attack, which is possible even with
ssh (eg. pull the plug out of the network), and nothing you can really
do about it.

This effectively means it is a challange/response protocol like
somebody else suggested, but the challange response is only required
once per session.

Any errors are entirely my own ;-).
--
Brian May <bam@debian.org>