[Top] [All Lists]

SMTP and Kerberos (was: Re: smtp-traffic-control)

2011-11-02 23:15:52

--On Wednesday, November 02, 2011 12:45 -0700 Douglas Otis
<dotis(_at_)mail-abuse(_dot_)org> wrote:

On 11/2/11 10:21 AM, John C Klensin wrote:
In the context of the present discussion, I haven't noticed
anyone suggesting linking traffic control options and
responses to authentication, so I don't really understand
where that part of your comment is relevant.   If you are


To clarify, as IPv6 becomes more pervasive, the need for
Kerberos services will become more apparent.  IMHO, likely to
the point of become a common ISP or OS vender offering.

For email to remain practical, a better solution at
controlling use of resources is needed.  There are several
advocating creation of reputation systems that don't
authenticate acting domains involved in sending email.  Only
those domains considered "too big to block" are likely able to
survive the many exploits such a strategy would permit.

I can put together an I-D describing the Kerberos ticket
extension if you think this would be a logical next step.
Its use would supplant RBL like reputation services and
gray-listing normally cached by IP address applied at every
SMTP exchange.

Aha.  Now that I know what you are talking about...

First, consider Keith's and Hector's comments in the broadest
sense (free of Kerberos specifics which, as Russ essentially
points out, may not have been completely understood for this
context): establishing global trust structures is really hard
and most of the problems are policy, not technical.  That is
true whether the mechanisms are based on shared secrets,
Kerberos (in a cross-realm environment?), some kind of PKI,
PGP-like webs of trust, or something else.  This is the problem
that DNS-based techniques, like DKIM, were intended to solve.
The good news about the DNS-based approaches is that, if one can
use them and they work, techniques based on domain names don't
get worse with IPv6 or anything else that causes explosive
growth of the address space.  The bad news, almost independent
of any of the subtle technical issues that you and others have
raised is that trust models based on the DNS are very fragile if
someone has a serious incentive to attack them -- not because of
issues with DNSSEC or its applicability, but because there is no
general requirement for a verified identity for the registrant,
much less a verified identity as a good entity, in order to
obtain such a name.

But, as far as I know, the thing that all of those methods have
in common is a model in which the recipient system decides that,
if a message comes it, either it is associated with some sort of
credential that the would-be recipient finds acceptable or it
gets rejected or treated it with more suspicion than a message
that is associated with such a credential.  Whether that
credential is bound to the sending system, the previous-hop
server, the message originator, or the sender really are small
details by comparison, as is just what the credentials are.

I understand that these problems clear up if sprinkled with
adequate quantities of pixie dust, but I'm not aware of a
sufficient, readily-available, supply.

That isn't exactly a new model.  I, and I assume many others,
have had mailboxes around on and off since the early 70s for
which the receiving mail server looks for a particular
credential and rejects or discards the message if it isn't
there.  That credential started out as the presence of a magic
cookie in the subject line or message body (really a shared
not-very-secret) and evolved into the presence of signatures
based on shared secrets, PGP, or S/MIME; SMTP AUTH with various
flavors and trust agreements; and SPF, Sender-ID, DKIM, and
friends.   The cookie plan tests something the sender knows, the
signatures provide authentication of the sender and the message,
SMTP AUTH authenticates the last-hop server, and so on -- all
effective if that is what is wanted and one trusts the trust
system.   In a different thread, we had the notion that one
could send mail across administrative domains only via
authorization from a (probably government-certified) ADMD and
then bilateral arrangements among ADMDs -- I note that the
amount of spam sent and delivered via X.400 mail systems with
Distinguished Names based in the ITU arc in the last few years
has been rather small.

I don't see how use of Kerberos would change that basic picture.
In the final analysis, one either needs to require that anyone
who is going to send you mail make prior arrangements out of
band, centralize the trust system, depend on indirect trust
arrangements (e.g., reputation systems or address blacklists),
or centralize the mail system itself, possibly via bilateral
arrangements among mutually-trusting relaying parties.

Russ and I have assumed that your intended use of Kerberos was
hop-by-hop client-server, the sort of thing that could be done
by attaching some conventions to SMTP AUTH.   I can imagine
using it end to end, with the message originator obtaining a
ticket, including that ticket with the message, and then having
the delivery server validate the ticket.  That does eliminate
the issues of relays and hop-by-hop arrangements, but the result
is the same problem in a slightly different guise:  the
assumption that the recipient will be able to access appropriate
mechanisms to validate the ticket may not hold up in a relay
environment, especially if the relays cross realms, just may not
be true... and we are back to how one establishes a global trust
model and makes it work.


<Prev in Thread] Current Thread [Next in Thread>