Pinning KDC IP addresses.

[g.w@hurderos.org]

On Feb 15,  5:27am, jaltman at secure-endpoints.com wrote:
} Subject: Re: Pinning KDC IP addresses.

Hi Jeff, thanks for the comments, hope your evening is going well.

>>g.w at hurderos.org wrote:
>> One of the issues which is a bit problematic in working against the
>> MIT sources is the issue of pinning AS_REQ's to a particular IP
>> address.  This strategy appears to be attractive in developing a
>> robust replay avoidance mechanism not only for OTI but other hardware
>> pre-authentication mechanisms as well.

> While adding the IP address of the KDC to the AS_REQ seems like a
> reasonable thing to do, I also believe it has the potential to cause
> significant operational hardship.  You are going to be requiring the
> KDC to be aware of any and all IP addresses that clients may be able
> to contact the server by.  This can be a serious problem for NAT'd
> environments or any KDC proxy or tunneling services that someone
> might decide to deploy.

Certainly a very valid concern.  I find it an interesting observation
in the context of previous conversations on this list.

I remember about two months ago a user showing up and asking questions
about how to setup KDC's behind a load balancer.  Exactly the type of
environment which fits your description of being problematic.

The user was pretty soundly browbeaten about how foolish and
malfeasant his strategy was.  The recommendations were pretty firm and
not very subtle that he should simply go off and deploy 'naked' KDC's.

I take the wisdom on this list pretty seriously.  Based on that
exchange and others which have gone by the standard of 'best practice'
appears to be to not NAT, proxy, tunnel, shroud or otherwise obscure
your KDC's.

The address pinning strategy in OTI is an attempt to leverage that
standard of best practice.

> Many large organizations that I know of are attempting to get the
> remaining IP address checking removed from the code base.  Adding
> addition IP address based checks would not be seen as a benefit to
> them.

I'm certain large organizations will be extremely persistent about
violating best practices in deploying security architectures.  There
seems to be ample historical precedent for that.

If they follow that path it seems doubtful they would waste time
deploying a security enhancing technology like OTI.  It they would
choose to do so I would assume they would simply set the variable in
the configuration file which informs the KDC to not attempt
verification of the target intentions of the client.  Hopefully they
understand the security implications of running slaves in a token
based environment.

All of these issues aside I find the underlying premise of this
somewhat troubling from a philosophical perspective.  This line of
reasoning would seem to suggest that engineering decisions of an
important security application should be subordinated to the wishes of
large organizations who don't want to be inconvenienced by proper
security practices.

It seems this should be about choice.  Implement poorly or wisely
depending on your needs but don't inflict your choice on others.  Its
probably the reason configuration files were invented.

Best wishes for a productive end of the week.

}-- End of excerpt from jaltman at secure-endpoints.com

As always,
Greg Wettstein

------------------------------------------------------------------------------
			 The Hurderos Project
         Open Identity, Service and Authorization Management
                       http://www.hurderos.org

"It would appear that we have reached the limits of what it is
 possible to achieve with computer technology, although one should be
 careful with such statements, as they tend to sound pretty silly in 5
 years."
                                -- John Von Neumann (ca. 1949)