SMTP Kerberos Considerations

Douglas Otis wrote:

> John,
>
> 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.
--
Sincerely

Hector Santos
http://www.santronics.com
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net