Subject: RE: [Asrg] Has anybody thought about using Kerberos to authentica te E-mail senders

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 8 Jan 2004 04:44:30 -0800

Operating Kerberos across trust domains is not very practical - unless you
want to create a master kerberos domain operator role.

I am sure VeriSign would be very happy running a root kerberos server for
the Internet if we could persuade people to let us...

There is a tendency for people to suggest Kerberos as an alternative for
PKI, completely ignoring the fact that the complexity of PKI is the result
of having to bridge trust domains. There is certainly no intrinsic
difficulty to managing two keys instead of one. 

Symmetric key operations do offer a performance advantage and there may well
be a role for a symmetric authentication scheme to run in parallel with a
public key based scheme - we do not require non-repudiation after all.

In practice however it appears that SSL accelerators are cheap enough to
make the processing costs of PKI acceptable in this application.

> -----Original Message-----
> From: GertJan Hagenaars [mailto:[email-masked]]
> Sent: Thursday, January 08, 2004 1:20 AM
> To: [email-masked]
> Subject: Re: [Asrg] Has anybody thought about using Kerberos to
> authenticate E-mail senders
> 
> 
> Apparently, Jeff_Silverman wrote:
> % People,
> % 
> % 	I came to this discussion late, so if this topic has 
> been brought up
> % and dismissed already, please inform me.
> % 
> % 	It occurs to me that one way to deal with the SPAM 
> issue is to force
> % senders to authenticate themselves.  The sender's MTA would have to
> % query a kerberos server and get a ticket.  The ticket has to be sent
> % with the message somehow.  The receiver's MTA then checks with the
> % kerberos server to verify the ticket.
> % 
> % 	Then, the receiver's MTA would handle the message 
> according to policy
> % set by the receiver.  There are several possibilities:
> % 
> % 1) The sender is unknown (this covers backwards 
> compatibility and also
> % failures in the authenticator)
> % 2) The sender authenticated as a known spammer
> % 3) The sender authenticated as a known trusted party
> % 4) The sender sent a fraudulent message
> % 5) The sender authenticated but is not known to be trustworthy or
> % untrustworthy.
> 
> ad 1.  Necessary, yes.
> ad 2.  I don't think you'll every authenticate a sender as a known
> spammer by themselves.
> ad 3.  The "known trusted party" sounds like the peering 
> agreement that
> Microsoft / yahoo / AOL are pursuing.
> ad 4.  Someone masquerading as someone else (or trying to get into
> systems that do not implement the scheme properly).  
> Potential spammer,
> depending on what they're trying to do.
> ad 5.  Lots and lots of smaller companies / ISPs etc.
> 
> I think the interesting question becomes: who decides if someone is a
> spammer and who decides if someone is trustworthy?  Is this different
> from community updated RBLs?
> 
> CHeers,
> GertJan.
> 
> -- 
> +++++++++++++ -------- +++++ --- ++ - +0+ + ++ +++ +++++ 
> ++++++++ +++++++++++++
> sed '/^[when][coders]/!d         G.J.W. Hagenaars -- gj at 
> hagenaars dot com
>     /^...[discover].$/d          Remembering Mike Carty 1968-1994
>    /^..[real].[code]$/!d         
> UltrixIrixAIXHPUXSunOSLinuxBSD, nothing but nix
> ' /usr/dict/words                I'm Dutch, what's _your_ excuse?
> 
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
> 

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg