[Top] [All Lists]

Re: SMTP Kerberos Considerations

2011-11-03 12:12:00

Paul Smith <paul(_at_)pscs(_dot_)co(_dot_)uk> writes:

This is where I have trouble as well. I can't see how Kerberos would
help at all, as it's essentially like any other SMTP AUTH system (which
could be used as well, AFAICS) so would involve giving everyone else
(except for spammers) in the world authentication details to our server.

This is the primary problem indeed.  Now, of course you wouldn't use your
regular authentication system for this necessarily, but you still have to
solve a significant cross-institutional authentication problem.

Federated cross-institutional authentication is a Very Hard Problem.
Those of us whose primary work is in the authentication space have been
working on it for a long time.  Huge amounts of effort have been put into
systems like SAML or OpenID, which continue to only solve small, tightly
constrained portions of the problem.  There is by no means a federated
authentication story that's strong enough to tackle email as a whole at
this time.  It just doesn't exist.

The protocol isn't the problem.  We have lots of protocols.  The
management and trust requirements are the problem.

Also, even if one wants to move forward with an SMTP solution for a
constrained case of the problem, Kerberos is an odd choice.  Kerberos is a
symmetric shared-secret authentication system based on a central authority
or network of central authorities.  In other words, except within an
institution, you couldn't find an authentication protocol more unlike the
way that SMTP networks are currently assembled.

We already have an authentication protocol that looks much more like SMTP,
given that for the normal SMTP case you want to authenticate end-to-end
rather than point-to-point, authenticate the message rather than the
transport so that you don't have lots of complexity around intermediate
hops and backup MX records, decouple the system as much as possible due to
the huge number of institutional boundaries, avoid requiring shared
secrets due to their point-to-point agreement requirements, and allow
authentication of messages after arbitrary delays.  That's a classic set
of feature requirements for public key cryptography.  And we already have
standardized authentication protocols for content using either X.509 or
PGP, and those could be fairly easily adopted to cover, say, the message
headers as well if one really wanted.

I think it's telling that, apart from some specific work for some narrow
use cases, no one has done widespread deployment of a general-purpose SMTP
system that requires public-key message authentication.  I think there are
very good reasons for that, most of which are related to the difficulty of
key management, inter-institutional trust, and getting all SMTP traffic
originators to authenticate their outgoing messages.

The time synchronization requirement for Kerberos is nowhere near as
strong as you seem to think it is.

It's 5 minutes isn't it? While that should be possible, it's a new
requirement for SMTP, so could cause problems for some people.

Five minutes is only an application-side default.  The application can use
any time skew that it wants.  The primary implications are around replay
attacks: you need to keep a replay cache for the length of your supported
time skew.  This is a minor issue; if the cross-realm trust problem could
be solved, there are various ways to deal with this.

Russ Allbery (rra(_at_)stanford(_dot_)edu)             

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