Pinning KDC IP addresses.

[g.w@hurderos.org]

On Feb 16,  4:55am, Jeffrey Altman wrote:
} Subject: Re: Pinning KDC IP addresses.

Hi Jeff, thanks for the note.

> g.w at hurderos.org wrote:
> > 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.

> You are mis-understanding my concern.  On my network I do not have a
> choice but to run my multiple KDCs behind a NAT because I do not
> have enough public address space.  My KDCs need to be aware of the
> internal networking infrastructure and in fact they are publicly
> available via the public NAT'd IP address assigned to them.  There
> is also the possibility of VPN'ing into the private network from
> outside which gives a third range of addresses for the VPN clients
> and the resources they are permitted access to on their VLAN.  The
> KDCs can therefore be reached via three IP addresses but they are
> only aware of one, the private network interface.
>
> My concern is, how would my KDCs be able to respond to your client
> requests that are embedding addresses that the KDCs are not aware
> of?

I would fix the problem by making the KDC's aware of the ingress
addresses which can be used to contact them.  I know that sounds a bit
trite but I believe its a matter of engineering a solution appropriate
to the situation.

Let take your example a bit further.  I'm assuming you have a many to
one mapping problem.  Based on your description each of the KDC's
would seem to have three separate IP addresses which can be used to
contact them.  One physical address, a publically accessible IP which
is port forwarded to the KDC and a VPN subnet which has an IP address
which is port forwarded onto the internal network.

I've actually got test setups not that different from the above.  I
simply pasted each KDC's two additional IP addresses into the
configuration file for the OTI plug-in.

Before the howls about 'configuration nightmare' begin reverbrating
lets put a different spin on this.  By definition the clients know how
to come up with an address list of the available KDC's.  I would
probably think of ways to make the KDC's at least as smart as the
clients.

If its an extremely static configuration the information is probably
in a text file.  We make such files available to the client it doesn't
seem like a leap in complexity to make the same text file available to
the KDC's, there are way fewer of the latter than the former.

The other obvious alternative is to have the information in the DNS.
It wouldn't take a great deal of cleverness to teach the KDC how to
interrogate the DNS to figure out how its potentially reachable.

In truth, if I were faced with doing this dynamically, the information
would be in LDAP.  I haven't run an implementation of MIT Kerberos in
three years which hasn't, as part of its plugin initialization, bolted
up a connection to an OpenLDAP server.  The KDC IP ingres addresses
would simply be managed by the central service provisioning system.

If the situation is a one to many mapping (ie. rotary load balancer)
you are simply screwed.  The client has no deterministic knowledge of
who its talking to.  Interestingly its Russian Roulette for a replay
attacker as well.

There are only two options; avoidance or detection.  In a one to many
mapping you cannot avoid and must detect so you implement a complete
cross-host replay detection matrix if you are serious about absolute
replay exclusion.

I even have a solution for that.

If I was forced to provide security guarantees in a whacked up network
segment I would run a single KDC and let OTI's on target replay
detector deal with the issue.  I routinely get 1 year 24x7 uptimes on
KDC's running Linux so I would make the architectural decision to drop
the slave(s).

Its either that or wait for one of the hundreds of Open-Source
groupies hanging around the authn/authz development arena to come
boiling out of the bullrushes with a debugged, production ready quorum
arbitrated or multi-master replay detector to bolt on the back of your
KDC's.

Given the historical precedent for that type of engineering getting
dropped on us I would recommend a good UPS and a long term battery
maintenance contract.  Based on recent experience I would also
recommend throwing a hundred gallons of #1 fuel oil in the diesel
tanks each September as well.

> In the same train of thought, how would this work with a protocol
> that was used to authenticate a mobile client as part of the
> issuance of an IP address to the client so that it may be permitted
> to access the network in the first place?

To avoid the risk of boring everyone even further I'm not going to
even start guessing the exact mechanistic details of this one.  Once
again, lets think in generalities.

I'm assuming the IP address the client gets is a default route for
everything.  Once again the client is going to know an address it
needs to contact to make a port 88 connection to.  I would architect
my authentication system to know what those addresses are.

If its some type of magical singing/dancing bridge address which port
forwards any connection somewhere else the client is going to think
the magic address is the KDC.  Once again, it shouldn't be rocket
science to engineer solutions for the KDC(s) to know that.

Anyone who thinks the future belongs to a KDC implementation which is
a self-contained static island will be working on a system whose only
relevancy is running a basement network.  Organizations don't
implement Kerberos they implement solution's which allow them to
arbitrate who is getting access to their resources and how that access
is being delivered.

> >> 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.

> IP addresses do not make secure bindings.  Removing the use of IP
> addresses is best practice.

No, there are two best practices, avoid insanity and engineer
appropriate solutions.

As an industry we have already decided how to avoid insanity in this
venue, its called IPV6.

I have a deeply respected colleague who is active in the national
networking circles.  He has forgotten more about IP networking than I
would ever hope to know.  I sit on an enterprise IPV6 migration
committee with him.

I believe these people feel they are on a divinely inspired mission to
exterminate the need for NAT and their weapon is IPV6.  Experience is
causing me to appreciate their zeal.

We can engineer solutions which allow us to take advantage of emerging
advances in technology to make our life easier or we can choose to
lock ourselves into difficult and complex implementations.  Portions
of the OTI design are predicated on the notion that we should choose
the former rather than the latter option.

IP based client intention expression is a tool, no better or worse
than any other tool.  In an authentication token environment it
provides a straight forward remedy which would otherwise require a
complex, sophisticated solution which no one has even invented yet.

Given the track record of our industry in making cranky, complex and
sophisticated solutions work properly, let alone securely, I will work
overtime to fill in the blanks to help make a simple alternative work
properly.

> Jeffrey Altman

Its all about choice Jeff, my choices may not meet your needs and vice
versa.  In a world of configuration files and LDAP directories it
doesn't seem like choice is something we need to preclude.

Have a good weekend.

}-- End of excerpt from Jeffrey Altman

As always,
Greg

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

"The best way to predict the future is to invent it."
                                -- Alan Kay