[Top] [All Lists]

SMTP Kerberos Considerations

2011-11-02 17:11:11

Douglas Otis wrote:


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.

And thats a critical framework presumption - centralization requirement.

Changes required of SMTP to make use of Kerberos would be minimal. I believe it would only require an SMTP-Auth extension to exchange retained tickets for destination domains.

It will require more than that at the infrastructure level. There are many critical issues so I can only list most immediate ones

1) Not everyone uses the same software.

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

3) While it may be viewed as insignificant, it its security value is highly dependent on time synchronization of servers and clients. That means your machines MUST be properly prepared with a 3rd party 100% availability Time Server. I can tell you may not always get that to work right for whatever reasons we have given up trying to figure out. I believe it is KERBEROS related - a chicken and egg situation and off hand, as we last left it, kerberos related login failures disables some of the OS components such as the client ability to access time servers.

The resulting reduction in unwanted traffic and message overhead should produce a sizable reduction in the cost of providing email, and allow SMTP to properly function within Today's Internet.

Any client/server authentication will provide the same overhead reduction simply because the transports frictions factor are now zero.

SMTP will not function within amber.

It would seem appropriate for error codes to be defined for "invalid ticket" and a "valid ticket required". It will be years before "valid ticket required" messages could be used. Even so, this is likely the best solution to deal with LSNs, and the large IPv6 address space that will negate most anti-abuse strategies.

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.

I support a Kerberos SMTP AUTH extension proposal, if only as another AUTH alternative. However, IMO, the reasons for it would be difference than what the discussions were about.

#1) Kerberos is deemed much stronger largely due to its client/server time synchronization dependency. There are all kinds of requirements here, including making sure a common Time Server is used, making sure clock batteries are ok!! Now a machine off by just a minute is important.

#2) In centralized networks, included clouds, a single ticket can be used for many things during its life span for the entire machine/device. But with this machine wide applicability, it can also be viewed as a Threat Entry point as well.

#3) This is so server specific policy dependent, it offers no additional payoff over any other authenticated method as it relates to mail filtering needs. Since the receiver MTA behavior mode is now that of an MSA (not MDA), it will more than likely disable most of the filtering restrictions especially those related to intentional 4yz temporary rejections designed to force anonymous senders to retry after some blocked time. Will it change other user or system level 4yx reasons?

I don't see how and while I am thinking about it, I did scratched my head regarding your comment that IPv6 can not be used for reputation. I am thinking that IPv6 offers more of a theatrical static and forever assignment as oppose to IPv4 today which can not be guarantee to be static (event though ISP today don't often change on users unlike the past).

In other words, IMV, with a higher guarantee that a device, machines, even IPv6 ready SMTP clients, they will have a constant IPv6 that will never change and this can be leveraged for all kinds of things, not just the cat's meow for tracking and direct marketing Advertisers.

In fact, I believe that in the future, a person will be able to have an IPv6 address that is permanent and/or *legally* transportable, like an telephone # is today. But again, if its unlimited, than it might be argued that once a IPv6 is burned into a device (or new born baby :), its becomes its DNA and can not be duplicated (used on another device the user upgraded to). I don't know enough about how IPv6 are assigned today.


Hector Santos
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net