[Top] [All Lists]

Re: SMTP Kerberos Considerations

2011-11-03 08:06:35

On 03/11/2011 00:12, Russ Allbery wrote:
Hector Santos<hsantos(_at_)santronics(_dot_)com>  writes:
I'm with Hector a bit on this.

2) There is a licensing issue, and unless it is already licensed by the
OS and offered as an API entry point, adding this to your software is a
costly endeavor.  Again see #1
There is no licensing requirement for Kerberos.  There are multiple
interoperating free software (not even GPL'd) implementations and the
protocol is an IETF standard.
While that's true. It doesn't help THAT much. Many MTAs are run by small businesses, with limited technical know-how. Asking them to install and manage an open-source Kerberos server is doomed to dramatic failure.

Mail server software vendors selling to small businesses could include an open-source Kerberos server with their software and try to handle it themselves, but then they are opening themselves up to all sorts of grief - eg bugs in critical software written by a third party which they will be expected to resolve.

If one wanted to put together a more comprehensive framework, there may need to be a new standard governing what specific principal names should be used by SMTP services and how to handle the (very serious) cross-realm trust issues, but that's another matter entirely and doesn't require any changes to the SMTP protocol.
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.

Unless I'm missing something.

Douglas's mantra of 'Kerberos and SMTP is the solution to our problems' doesn't seem to explain how it would work at all.

#1) Kerberos is deemed much stronger largely due to its client/server
time synchronization dependency.
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.

If all we're talking about is senderMTA-to-receiverMTA authentication (without authorisation), then I can imagine lots of ways of doing it without the complexity of Kerberos. Unless you have millions of MTA admins sending login details to millions of other MTA admins, then you have to actually authenticate the sender with the sender itself. SPF does this by using DNS entries from the sender as authentication. If SPF is inefficient (because of lots of DNS queries), then using a simple 'callback' to a server at the sender's domain (possibly just using 2 UDP packets) would work

C: EHLO stuff
C: AUTH CALLBACK <myname> <mypassword>

then S does finds an appropriate authentication server based on 'myname' (which would be something like '') (eg using SRV DNS lookup), sends a UDP packet containing
<myname> <mypassword> <IP address of C> <secret code>
the 'myname' auth server sends back a UDP packet containing '<OK/not OK> <secret code> <max time to remember result>'


S can now cache that that IP address is OK or not so it doesn't need to do the UDP exchange in the future for a while (up to the maximum cache time specified by the auth server)

<mypassword> can be an OTP or password calculated based on time (the exchange between the client sending the password and the server verifying it would be less than a couple of minutes), so don't need to worry too much about replay attacks The auth server could even just base the authentication result on the IP address of the sender - eg Yahoo could ignore the password, and just authenticate the IP address of any of their outward servers.

<secret code> is just to stop address spoofing when using UDP

If this passes, then we know the sender is who it says it is. Authorisation could be based on the 'myname' part of the authentication.

We have four extra UDP packets (2 to get the SRV record, 2 for the authentication itself) for authentication per session (SPF needs a minimum of two (for the TXT record) per message and usually many more). If the IP address has been authenticated before, even this isn't needed.

We do need an extra authentication server, but that would be trivial in many cases (just compare the IP address against a list of valid IP addresses, or against a hash of a secret+time for the last few minutes). The authentication server here would be much simpler than a Kerberos server, and you wouldn't need to exchange authentication details. There are no timing constraints (other than a requirement that the receiving SMTP server does the authentication process within, say, 5 minutes of receiving the AUTH CALLBACK command)