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
eg
C: EHLO stuff
S: AUTH LOGIN PLAIN CALLBACK
C: AUTH CALLBACK <myname> <mypassword>
then S does finds an appropriate authentication server based on 'myname'
(which would be something like 'yahoo.com') (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: OK
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)