A Modest Authentication Proposal ((was Re: a header authentication scheme

On Wed, 20 Oct 2004 20:05:47 +1000, Laird Breyer <[email protected]> wrote:

> For example, if the topmost Received: line (at M3) is
> 
>    Received: from 185129182.virtua.com.br (185129182.virtua.com.br
>        [200.185.129.182]) by smtpin-3211.bay.webtv.net (WebTV_Postfix+sws)
>        with SMTP id 7280B11DCC; Fri,  5 Mar 2004 19:00:48 -0800 (PST)
> 
> then a Processed: header of the form
> 
>    Processed: name="SpamAssassin"; location-ip="1.2.3.4";
>        version="2.63"; function="spamcheck";
>        auth-received="7280B11DCC"; result-tag="spam";
> 
> is guaranteed to have been added *after* the Received: line was inserted
> in the message, ie at or after M3. Such a Processed: line is unforgeable,
> unless the auth-received value can somehow be predicted with high probability.

or unless the man in the middle who is forging headers is also
ignoring the dictum
that Received: headers MUST remain unchanged. Authentication systems require
a second channel for authoritative authentication validation
information, if that channel
is key servers or ticket registries or a 'did you send this?' extension to SMTP.

"Did you send this?" could be easily enough provided by a checksum
ESMTP extension.
A server would be responsible for maintaining its own secret checksum algorithm,
a standard way of including the checksums in the headers would be defined, for
instance WRT Laird's spamcheck line the checksum line (separate, to avoid
issues of having to reformat for auth purposes) might be

    Checksum: 7280B11DCC:3Z5G01H2NP

to declare that the header tagged with the unique header ID 7280B11DCC will
have a checksum of 3Z5G01H2NP when presented to the checksum server
responsible for generating the header. Possibly immediately after the DATA phase
of the ESMTP transaction.  Adoption would require widespread modification of
MTA software to be tightly integrated with header generation software, and the
e-mail transmission protocol would become even chattier.

There's no escaping the necessity of trusting trusted peers at some level.


thanks for listening




-- 
David L Nicol
transportation infrastructure technology contracting since 2002