Can anyone relate war stories, gotchas and victories re: Cross Realm
Kerberos or DCE across firewalls and to another Kerberized realm?
I want to make sure my understanding of Kerberos traffic isn't twisted.
Please make corrections if I'm missing things.
We need to talk to a different organization running Kerberos (actually some
are DCE - I already heard Kerberos and DCE are not 100% compatible but we
all agree to support the lowest common denominator.) so we need to do cross
realm authentication, ticket granting and encryption all working across a
firewall.
We have a client that would like to run cross realm Kerberos across the
Firewall for process to process communication (no live user).
Why firewall if we use Kerberos?
- some nodes on the inside might not be able to run Kerberos.
- we don't want to do encryption on all the traffic.
- we will have some internal X-traffic. (idle curiosity - kerberized
X-terminals anyone?)
In addition, we like to follow Internet standards and Best Practices so
Network Address Translation (RFC 1918, 1597) is a desired architectural
feature. (We could drop it if it's totally incompatible with kerberos so I
don't call it a requirement but it's like birthday cake without decorations.)
The NAT could be a real problem. Kerberos apparently packs the nodes
network address as part of the authentication packet so if your IP address
is hidden by the firewall I expect the authentication at the client/server
to fail when source and encrypted address are compared. (are they?).
The kerberos protocol uses UDP for the initial ticket request and delivery.
Simply communicating with a single outside client registered with our TGS
should not be a problem - all UDP traffic with Kerberos port numbers simply
gets routed to the appropriate TGS/authenticator.
What I'm having a hard time with is the Kerberos V5 Cross Realm. In that
scenario the internal client must get ticket from the internal TGS (I) which
lets him talk to the inter-realm TGS (1) which lets him talk to the remote
realm TGS (R) to get a ticket for the final destination service (D). The
result is UDP packets to and from all internal clients that want to talk to
the other realms.
X
Dest(D) TGS(R) TGS(1) X TGS(I) Client
| | | X | |
| | | X |---1---|
| | |-------2----------|
| |----------------3-------------|
|--------------------4------------------|
1, 2 and 3 are UDP. Only 4 is a TCP connection
XXXX=firewall
All UDP packets have a "well known" Kerberos port number but that still
leaves a lot of UDP flying around. The firewall can have filter rules to
restrict the Kerberos UDP packets to Kerberized nodes but that only works on
a small internal net. What do people do with large mixed nets?
(Luckily I'm dealing with a small net so we can have the filter rules for
individual clients but since I'm learning I would like to understand the
other options.)
True, the Kerberos ports are well known and the non-kerberized clients
should not be listening on them so attacks on those ports should not work.
But how many applications might there be that simply listen on incorrect
ports? (I don't know. If everyone was carefull and followed standards I
would feel secure, but I've hacked code in a hurry (vs. leasurly programming
in a "development enviornment") so I recognize the temptations during a
rushed job...;)
I guess I'll be joining the Kerberos mailing list or newsgroup, but I
thought this might be an appropriate discussion for Firewalls as well.
By the way, while some gurus are anouncing the death of RPC due to security
holes and better CORBA tools I am under the distinct impression that DCE
(which is RPC based) is growing rapidly, at least from my myopic view of
some government entities and a growing list of vendors.
Sorry for the length of the above - I can't believe I wrote all that!
Adam Safier
CSC-SED-Infosec
asafier @
csc .
com
- It's scary when people call me an "expert" in a subject just as I start to
realize how little I know and how much I still need to learn.
Expressed opinions are my own and might not be shared by my employer or
anyone else.
Follow-Ups:
|
|
