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

2002-11-24 Thread Branden Robinson
On Sun, Nov 24, 2002 at 12:36:13AM +0100, Bernd Eckenfels wrote:
 On Sun, Nov 24, 2002 at 10:31:46AM +1100, Brian May wrote:
  You need to keep track (at both ends of the link) of the last
  sequence number sent.
 
 can we perhaps set up a mailinglist or discuss this on the mailinglist of
 grunt, it realy gets offtopic.

Yeah, God forbid we talk about development on debian-DEVEL, instead of
removing non-free or the cost of IDE vs. SCSI hard drives.

-- 
G. Branden Robinson| Don't use nuclear weapons to
Debian GNU/Linux   | troubleshoot faults.
[EMAIL PROTECTED] | -- US Air Force Instruction 91-111
http://people.debian.org/~branden/ |


pgpiGNyGOYR36.pgp
Description: PGP signature


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

2002-11-23 Thread Shadur t'Kharn
In other news for Sat, Nov 23, 2002 at 11:18:22AM +1100, Brian May has been 
seen typing:
 
 The could remarkably slow the process down for slow batched based
 E-Mail systems.
 
 (it would appear to be a tradeoff of functionality/efficiency vs
 security).
Isn't that a fairly accurate summary of *every* security measure?

 --
 Brian May [EMAIL PROTECTED]

--
Rens Houben / Shadur t'Kharn: Linux guru, programmer, geek, dreamer.
GPG public key: http://swordbreaker.systemec.nl/~shadur/shadur.key.asc


pgpT5uBTaxp1q.pgp
Description: PGP signature


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

2002-11-23 Thread Anthony DeRobertis
 1. notice that oops, the cd burning script will do something evil if
passed a certian type of iso.
 2. send in a fixed script
 3. run it

Have you considered adding sequencing to the protocol? That is, if each
of those mails above had a sequence number in them, the receiver would
not execute (3) until it had done (2).


signature.asc
Description: This is a digitally signed message part


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

2002-11-23 Thread Brian May
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 [EMAIL PROTECTED]




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

2002-11-23 Thread Bernd Eckenfels
On Sun, Nov 24, 2002 at 10:31:46AM +1100, Brian May wrote:
 You need to keep track (at both ends of the link) of the last
 sequence number sent.

can we perhaps set up a mailinglist or discuss this on the mailinglist of
grunt, it realy gets offtopic.

Greetings
Bernd




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

2002-11-22 Thread Manoj Srivastava
Hi,
Jason == Jason Gunthorpe [EMAIL PROTECTED] writes:

 Jason PGP signatures have a signature ID and a date that are ment to be used 
to
 Jason prevent against replay attacks. I forget the exact details but there is 
a
 Jason gpg mode that prints it out. The db.debian.org gateways all make use of
 Jason it. 

Indeed, as does the voting machinery. I was going to post
 example code here, but the example got too huge (email me if you want
 a copy).  Replay attacks can be thwarted by a simple check on the
 server. 

manoj
-- 
 Q: How many IBM CPU's does it take to execute a job? A: Four; three
 to hold it down, and one to rip its head off.
Manoj Srivastava   [EMAIL PROTECTED]  http://www.debian.org/%7Esrivasta/
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C




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

2002-11-22 Thread Josselin Mouette
Le ven 22/11/2002 à 05:41, Brian May a écrit :

  A secure way to handle this would be a challenge/response
  authentification, or a system similar to SSH's one-time passwords.
 
 No, I think it is an inherent problem with using E-Mail for such things.
 
 As long as E-Mail is used, the possibility exists that the E-Mail will
 get delayed.
 
 If the E-Mail gets delayed it is not possible to cancel it, it has
 already been sent.

That's why I suggest using either a challenge/response authentification
(if the mail is lost, you have to ask for a new challenge and the
previous mail won't be accepted if it is delayed), or one-time passwords
(every time you use a OTP, all previous passwords are revoked).

-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: PGP signature


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

2002-11-22 Thread John Goerzen
On Fri, Nov 22, 2002 at 03:35:11PM +1100, Brian May wrote:
 30 days seems like an awfully long time...
 
 I would have though rejecting any requests, say an hour old would
 be better...
 
 So, if you did issue an halt command, the worst an attacker could do
 would be to delay execution by one hour, not 30 days.

It's configurable.

An hour might be too little if, for instance, things are travelling across
UUCP that run a few times a week.

-- John




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

2002-11-22 Thread John Goerzen
On Fri, Nov 22, 2002 at 12:55:07AM +0100, Josselin Mouette wrote:
 message from being sent, and keep it for another day. Seeing your
 computer doesn't halt, you resend the message, and the attacker has 30
 days to use what he has stolen.

So you set the window to 2 days, or 15 minutes, or whatever.

But really, 'halt' is not really the kind of command this is designed to
run.  And couldn't, unless you either used sudo or did something nasty to
make it run as root.

It's more designed to do things like take this 650MB ISO and go burn it
whenever or run this batch processing command.

 A secure way to handle this would be a challenge/response
 authentification, or a system similar to SSH's one-time passwords.

How can you respond if you are communicating asynchronously?




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

2002-11-22 Thread John Goerzen
On Fri, Nov 22, 2002 at 12:43:28AM -0500, Joey Hess wrote:
 This is interesting. I've been planning to add play-by-mail support to
 my mooix moo, but have held off because I didn't want to tackle doing it
 securely. But if I can just use grunt and it turns out to be secure..
 that'd be sweet. I hope that grunt lets you just compose commands with a
 standard mailer, without having to run some command on your system to
 set up the random block John mentions. For my (very specific) purposes,
 it would be nice if it could be used without gpg, from any system that
 can send and receive mail.

GPG is integral to grunt's security, so you won't be able to run it without
GPG.

You invoke GRUNT with simple commands like:

gruntsend file.txt [EMAIL PROTECTED] destination/file.txt

or

gruntrun [EMAIL PROTECTED] 'cdrecord -v dev=1,1,0 -eject'  file.iso

or

gruntrun [EMAIL PROTECTED] somebatchjob.sh

That is, it's mostly designed for things like batch jobs -- things that
don't depend on being executed in any particular order.

When you run gruntsend or gruntrun, you'll have to enter in your GPG
passphrase to sign the message.

The receiver has the aging restrictions described before.  Though it can be
tuned -- you could set it down to 60 minutes if that's more appropriate for
your setting.  I'm also still tweaking things yet until I make the first
release -- I want to get the protocol set before that.

I am confident that Grunt is secure.  There is no way to make your system
execute commands that you did not request, nor for an attacker to use a
replay attack.  It is possible, as some have brought up, to delay a command. 
Though you can set the window in which commands are allowed, and can set it
to whatever you like.

 This could me especially amusing if the first, delayed email was:
 
   cd /tmp
 
 And the second was:
 
   rm -rf *

Grunt doesn't preserve any notion of a session (think of it sort of like
'at', maybe?)  It's more designed to be able to execute 'batch' type of
commands.  That is, here's this chunk of data, go do something intensive
with it.  It's also designed to help with people that need to use a
modified sneakernet to get data around -- ie, a slow connection one place,
fast one other place, and a laptop.

-- John




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

2002-11-22 Thread John Goerzen
On Fri, Nov 22, 2002 at 12:24:34AM -0500, Joey Hess wrote:
  After verifying the signature on the data, the receiver does some sanity
  checks.  One of the checks is doing an md5sum over the entire file
  
  (remember, this includes both the headers and the payload).  If it
  has seen the same md5sum in the last 60 days, it rejects the request.  If
  the date of the request was more than 30 days ago, it rejects the request.
 
 Hold on, if you're md5summing the headers, what is to stop an attacker
 from modifying the subject, and using an intercepted, gpg-signed body to
 repeat the command?

It's an md5sum over the entire file.  The file includes both the headers and
the body.

-- John




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

2002-11-22 Thread John Goerzen
On Thu, Nov 21, 2002 at 10:47:46PM -0700, Jason Gunthorpe wrote:
 PGP signatures have a signature ID and a date that are ment to be used to
 prevent against replay attacks. I forget the exact details but there is a
 gpg mode that prints it out. The db.debian.org gateways all make use of
 it. 

I didn't know about that.  I'll look into it.  It would make things a bit
easier, I think.  Thanks for pointing it out.

BTW for those interested, I hope to put out the first release early next
week.  I'm still ironing out a few of these details and have to write the
e-mail support and some documentation yet, but you can check it out at the
subversion repository at svn.complete.org.

-- John




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

2002-11-22 Thread Joey Hess
John Goerzen wrote:
 Grunt doesn't preserve any notion of a session

It doesn't need to: the unix filesystem already does. I said that was a
contrived example, but I'm sure you will find some real ones eventually.

Slightly less contrived:

1. notice that oops, the cd burning script will do something evil if
   passed a certian type of iso.
2. send in a fixed script
3. run it

You really don't want step 2 to be intercepted here either.

-- 
see shy jo


pgpv5hOluWMzD.pgp
Description: PGP signature


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

2002-11-22 Thread Brian May
On Fri, Nov 22, 2002 at 12:43:28AM -0500, Joey Hess wrote:
 This could me especially amusing if the first, delayed email was:
 
   cd /tmp
 
 And the second was:
 
   rm -rf *
 
 (Dumb contrived example, but you get the idea.)

I think the lesson here is that grunt is not a transparent
replacement, for say ssh, but a tool that you have to think about
using before using it.

So, you could include both commands in the one email, and it
would be OK.

Or you could include the full path in the second E-Mail, and assuming it
isn't tricked by any of these race conditions surrounding /tmp, then it
would be OK too.

Yes, it is a dumb contrived example, I don't think grunt would preserve
the current working directory...

So you might have serious problems even if the order of the messages
was correct.
--
Brian May [EMAIL PROTECTED]




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

2002-11-22 Thread Brian May
On Fri, Nov 22, 2002 at 10:32:22AM +0100, Josselin Mouette wrote:
 That's why I suggest using either a challenge/response authentification
 (if the mail is lost, you have to ask for a new challenge and the
 previous mail won't be accepted if it is delayed), or one-time passwords
 (every time you use a OTP, all previous passwords are revoked).

Presumably you would have to send 1 E-Mail (challange), wait for
the response, and then send the next E-Mail.

The could remarkably slow the process down for slow batched based
E-Mail systems.

(it would appear to be a tradeoff of functionality/efficiency vs
security).
--
Brian May [EMAIL PROTECTED]




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

2002-11-22 Thread Adam Heath
On Sat, 23 Nov 2002, Brian May wrote:

 On Fri, Nov 22, 2002 at 12:43:28AM -0500, Joey Hess wrote:
  This could me especially amusing if the first, delayed email was:
 
cd /tmp
 
  And the second was:
 
rm -rf *
 
  (Dumb contrived example, but you get the idea.)

 I think the lesson here is that grunt is not a transparent
 replacement, for say ssh, but a tool that you have to think about
 using before using it.

In case it hasn't been mentioned, one could use sequence numbers, ala tcp.




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

2002-11-22 Thread Brian May
On Fri, Nov 22, 2002 at 09:47:48AM -0600, John Goerzen wrote:
 On Fri, Nov 22, 2002 at 12:24:34AM -0500, Joey Hess wrote:
   After verifying the signature on the data, the receiver does some sanity
   checks.  One of the checks is doing an md5sum over the entire file
   
   (remember, this includes both the headers and the payload).  If it
   has seen the same md5sum in the last 60 days, it rejects the request.  If
   the date of the request was more than 30 days ago, it rejects the request.
  
  Hold on, if you're md5summing the headers, what is to stop an attacker
  from modifying the subject, and using an intercepted, gpg-signed body to
  repeat the command?
 
 It's an md5sum over the entire file.  The file includes both the headers and
 the body.

No, I think the question might be what if the MD5SUM is different but
the GPG signature is the same?

I think it depends on the method used to sign the message, some methods
sign the headers, some don't.

So if I manually sign a message, and include it in the body of this
message, it won't protect the headers in anyway.

Somebody could alter the headers, resulting in the md5sum becomming
altered, and the message won't be detected as a replay.

Also, to prevent another possible (maybe obvious) attack; make sure your
clock is set correctly (and not some time in the future) before sending
a email...
--
Brian May [EMAIL PROTECTED]




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

2002-11-21 Thread Jonathan Oxer
On Fri, 2002-11-22 at 06:36, Alexander Neumann wrote:
 John Goerzen wrote:
   GRUNT is a tool to let you execute commands remotely, offline.
   It will also let you copy files to a remote machine.
 
 How did you solve the problem of re-sending such mails? Say, Joe Evil
 Cracker is able to catch a command mail containing halt. Will he be
 able to shutdown my machine every time he want?

I can't speak for GRUNT (having no first-hand knowledge of it) but a
couple of ways to do this spring to mind.

For example, timestamp every message internally (so the timestamp is
inside the GPG payload, not just in the header) and keep a record at the
recipient end of timestamps of all executed commands. Ignore duplicates.

Alternatively a random character string could be used, but timestamps
might give other benefits (for eg, ignore messages older than 5
minutes).

Jonathan Oxer
Ph +61 3 9723 9399 / Fx +61 3 9723 4899
GPG key: http://www.ivt.com.au/gpg/jon.oxer.gpg


signature.asc
Description: This is a digitally signed message part


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

2002-11-21 Thread John Goerzen
On Thu, Nov 21, 2002 at 08:36:37PM +0100, Alexander Neumann wrote:
 John Goerzen wrote:
   GRUNT is a tool to let you execute commands remotely, offline.
   It will also let you copy files to a remote machine.
 
 How did you solve the problem of re-sending such mails? Say, Joe Evil
 Cracker is able to catch a command mail containing halt. Will he be
 able to shutdown my machine every time he want?

Each message has its payload and its header information (what command to
run, what file is being copied, etc.) GPG-signed.  (The two are combined
together to a single file, which is GPG signed as a whole.)

This header information includes, among other things:
 1. Date  time the file was prepared
 2. pid that created the file
 3. 2048 bits of random data

After verifying the signature on the data, the receiver does some sanity
checks.  One of the checks is doing an md5sum over the entire file
(remember, this includes both the headers and the payload).  If it
has seen the same md5sum in the last 60 days, it rejects the request.  If
the date of the request was more than 30 days ago, it rejects the request.

Therefore, the sender is able to reissue the halt command legitimately as
often as he/she wants, since the random bits  time will ensure different
md5sums on the recipient.  But replay attacks will be useless since the
recipient will have seen the request already, and will reject it.

-- John




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

2002-11-21 Thread Josselin Mouette
Le jeu 21/11/2002 à 23:12, John Goerzen a écrit :

 After verifying the signature on the data, the receiver does some sanity
 checks.  One of the checks is doing an md5sum over the entire file
 (remember, this includes both the headers and the payload).  If it
 has seen the same md5sum in the last 60 days, it rejects the request.  If
 the date of the request was more than 30 days ago, it rejects the request

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

2002-11-21 Thread Brian May
On Thu, Nov 21, 2002 at 04:12:42PM -0600, John Goerzen wrote:
 After verifying the signature on the data, the receiver does some sanity
 checks.  One of the checks is doing an md5sum over the entire file
 (remember, this includes both the headers and the payload).  If it
 has seen the same md5sum in the last 60 days, it rejects the request.  If
 the date of the request was more than 30 days ago, it rejects the request.

30 days seems like an awfully long time...

I would have though rejecting any requests, say an hour old would
be better...

So, if you did issue an halt command, the worst an attacker could do
would be to delay execution by one hour, not 30 days.
--
Brian May [EMAIL PROTECTED]




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

2002-11-21 Thread Brian May
On Fri, Nov 22, 2002 at 12:55:07AM +0100, Josselin Mouette wrote:
 What if the attacker can intercept the messages ? He can prevent a
 message from being sent, and keep it for another day. Seeing your
 computer doesn't halt, you resend the message, and the attacker has 30
 days to use what he has stolen.
 
 A secure way to handle this would be a challenge/response
 authentification, or a system similar to SSH's one-time passwords.

No, I think it is an inherent problem with using E-Mail for such things.

As long as E-Mail is used, the possibility exists that the E-Mail will
get delayed.

If the E-Mail gets delayed it is not possible to cancel it, it has
already been sent.

An E-Mail could go missing due to bad mail configuration, could get
delayed due to a link going down, or deliberately (for example).

When the remote hosts does receive the E-Mail, it has no way of knowing
if the submitter still wants it to be executed or not.

Maybe it might be possible to send a cancel or revoke message to the
server, but presumably if initial E-Mail got delayed, the cancel/revoke
message would be delayed too.
--
Brian May [EMAIL PROTECTED]




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

2002-11-21 Thread Joey Hess
John Goerzen wrote:
 After verifying the signature on the data, the receiver does some sanity
 checks.  One of the checks is doing an md5sum over the entire file
 (remember, this includes both the headers and the payload).  If it
 has seen the same md5sum in the last 60 days, it rejects the request.  If
 the date of the request was more than 30 days ago, it rejects the request.

Hold on, if you're md5summing the headers, what is to stop an attacker
from modifying the subject, and using an intercepted, gpg-signed body to
repeat the command?

-- 
see shy jo


pgpOU8IXaGsID.pgp
Description: PGP signature


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

2002-11-21 Thread Joey Hess
This is interesting. I've been planning to add play-by-mail support to
my mooix moo, but have held off because I didn't want to tackle doing it
securely. But if I can just use grunt and it turns out to be secure..
that'd be sweet. I hope that grunt lets you just compose commands with a
standard mailer, without having to run some command on your system to
set up the random block John mentions. For my (very specific) purposes,
it would be nice if it could be used without gpg, from any system that
can send and receive mail.

Brian May wrote:
 No, I think it is an inherent problem with using E-Mail for such things.
 
 As long as E-Mail is used, the possibility exists that the E-Mail will
 get delayed.
 
 If the E-Mail gets delayed it is not possible to cancel it, it has
 already been sent.
 
 An E-Mail could go missing due to bad mail configuration, could get
 delayed due to a link going down, or deliberately (for example).

This could me especially amusing if the first, delayed email was:

  cd /tmp

And the second was:

  rm -rf *

(Dumb contrived example, but you get the idea.)

You could possibly do stuff with seqence numbers though to prevent this.
If every command you sent was a reply to a message from the grunt
server (the response to the last command), the server could generate a
new number each time. Something like this:

  From: me
  Subject: hi, I want a grunt session


  From: grunt server
  Subject: your session started

  Be sure to reply to this message to include this data --
  Session-id: 240943
  Sequence-number: 1


  From: me
  Subject: my first command

  cd /tmp
  
   Be sure to reply to this message to include this data --
   Session-id: 240943
   Sequence-number: 1

  From: grunt server
  Subject: re: my first command

   cd /tmp
  pwd: /tmp

  Be sure to reply to this message to include this data --
  Session-id: 240943
  Sequence-number: 2
  

  From: me
  Subject: my second command

  rm -rf *
  
   Session-id: 240943
   Sequence-number: 2


If the cd command is intercepted or delayed, then I'll notice that the
server is not responding back. I could then try to resend it, superceding
my old command (which the server would discard if it got it, since its
sequence number for this session would increase). Unless I'm terminally
stupid, I cannot send the second, dependant rm command until the first
command gets run. I'd have to forge the sequence number (2). The server
could even protect from this by using randomly increasing sequence
numbers, at-la-tcp.

I could also try to cancel the whole session, with another mail. If the
mail got through, that would prevent the interceptor from feeding it to
the server at a later date. However, they could just intercept the
cancel mail too. That's about the time I think I'd reach for out of band
communication.

-- 
see shy jo


pgpX615Hu6g6v.pgp
Description: PGP signature


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

2002-11-21 Thread Jason Gunthorpe

On Fri, 22 Nov 2002, Joey Hess wrote:

  After verifying the signature on the data, the receiver does some sanity
  checks.  One of the checks is doing an md5sum over the entire file
  (remember, this includes both the headers and the payload).  If it
  has seen the same md5sum in the last 60 days, it rejects the request.  If
  the date of the request was more than 30 days ago, it rejects the request.
 
 Hold on, if you're md5summing the headers, what is to stop an attacker
 from modifying the subject, and using an intercepted, gpg-signed body to
 repeat the command?

PGP signatures have a signature ID and a date that are ment to be used to
prevent against replay attacks. I forget the exact details but there is a
gpg mode that prints it out. The db.debian.org gateways all make use of
it. 

Jason