[453] in Kerberos_V5_Development
food for thought re: hierarchical realms
jtkohl@ATHENA.MIT.EDU (jtkohl@ATHENA.MIT.EDU)
Mon Nov 19 14:31:15 1990
Date: Mon, 19 Nov 90 11:21:43 PST
From: "Morrie Gasser, LTN1-1/D07, DTN 226-6180 19-Nov-1990 1423" <gasser@ultra.enet.dec.com>
To: jtkohl@ATHENA.MIT.EDU
Subject: RE: Trust path in Kerberos V5
John,
Well, here are some thoughts:
Since V5 has the concept of hierarchical realms, it would seem reasonable that
the correct trust path from a client to a server would follow a defined
hierarchy. For example, assume the hierarchy of realms:
A
/ | \
/ | \
B F C
| | |
| | |
D c' E
| |
c s
If a server s in realm E (s@E) wants to authenticate the client identified in
the ticket as c@D, s wants to be sure that the ticket was obtained by
traversing exactly the path D->B->A->C->E. Any other path, and any other
order, would be "wrong". For example, realm F should not be not authorized to
authenticate users in realm D--all of F's users should be identified as
"some-user@F", not "some-user@D". If the AS in realm F were allowed to make up
a bogus ticket for one of its own users c', naming him as c@D, then c' in an
untrustworthy realm has masqueraded as c.
It isn't sufficient for s just to keep an unordered list of realms it trusts.
In an environment of mutual suspicion, each realm should be suspected of
attempting to compromise users in other realms, and therefore each realm should
only trust other realms for specific authentications. Therefore I'm
suggesting that each realm only be allowed to authenticate users with the name
corresponding to the realm name (a reasonable policy for Kerberos V4). It's
the server's job to decide whether that authentication is valid. Just because
the authentication of c passed through "trusted" realms, the authentication is
invalid because it doesn't pass through the right realms.
What I said so far doesn't require the server to know about a specific
hierarchy--the server just needs to check the realm name of the user with the
realm name of the first KDC that the user contacted. (Is there a way to tell
in V5? I'm not sure I see how.) However this same masquerading threat can be
carried out by realms authenticating other realms in the hierarchy. For
example, in my figure, B can claim to authenticate F when it should be A's job.
To enforce this policy the server has to keep track of the entire hierarchy.
Furthermore, the server also has to be told the order in which the realms were
transited. This is something that the V5 draft explicitly says you can't
determine.
To handle the case of non-hierarchical associations, where D and E have
established mutual trust and can authenticate each other without going through
higher authorities, the servers in those two realms need to know about that
relationship explicitly. With such an agreement in place it is in fact
improper for the realms transited to be other than D and E--the server should
reject a ticket from c@D if the transited realms include any but D and E.
Keeping track of all these relationships is more complicated than simply
storing the hierarchy (which is complicated enough), but I don't see a good way
around it.
Have you guys done any thinking along any of these lines? I realize these
concerns are sort of far out considering the real live uses of Kerberos in
systems today, but if we can ever envision more widespread use of Kerberos
across large networks spanning large numbers of realms then these concerns
about realms being malicious may be more legitimate. The example we always use
to characterize this threat is where you want to authenticate a user in the
Choas Computer Club for access to some very limited function (he's only listed
on the ACL of your bowling scores, for example), so you have to include CCC's
authentication server in your list of authorized realms, but you don't want to
authorize the CCC's realm to authenticate another realm or anyone in another
realm. It should be possible to accomplish this securely.
If I may try to rephrase your original response to my question, are you saying
that in today's implementations a server is willing to accept any arbitrary
sequence of transited realms and doesn't even check a list? Would my CCC
example then cause a problem?
Morrie
