[Fwd: bridging of Kerberos realms]
Douglas E. Engert
deengert at anl.gov
Tue Oct 1 10:27:01 EDT 2002
Some interesting uses of Kerberos as sent to the GGF security working group.
Does anyone see any problems with this?
-------- Original Message --------
Subject: bridging of Kerberos realms
Date: Mon, 30 Sep 2002 11:41:05 -0700
From: Frank Siebenlist <franks at mcs.anl.gov>
To: security-wg at gridforum.org, ogsa-security at globus.org
In an other thread, we've been discussing issues concerning the bridging of
CA "domains", which brought us to the topic of the bridging of kerberos/DCE
realms/cells through Kerberos' cross realm authentication feature.
A few months ago, I was in a meeting where we "accidently" ended up on the
white board with an ad-hoc way to create bridges between kerberos realms
without using the cross realm authentication. (Please, Von, Karl, Steve*2
and Raj, keep me honest with the following protocol description...)
The requirement for this was similar to the CA trust issue: it may be more
difficult to establish a true cross realm trust agreement on a corporate
level than to establish it on an individual level between individuals and
the resource owners in a VO.
I would like to discuss the scheme here and solicit input from the
community on the viability and usefulness of such a feature.
---------------
* The mini, ad-hoc, bridging KDC.
The use-case scenario has two kerberos realms, X and Y, that do not have
any cross realm trust established.
We have the KDCs in both realms: Kx and Ky.
There are users, with principal names U1, U2, Ui, in realm X, that would
like to access resources, with principal names R1, R2, Ri, in realm Y.
It is assumed, that the users in X and the resource owners in Y have
established a trust agreement, and that only "technology" stands in the
way. This implies that both sides have policies in place that allows some
users access to some resources, and given the right "names" for users and
resources, this policy can be expressed and enforced.
The idea is to use a trusted third party as an authentication bridge for
the two realms.
Let "B" be this special bridge service, that has both credentials in X and
Y: Bx at X and By at Y.
The protocol will use B as some kind of mini-KDC, setting up its own ad-hoc
realm for the VO where it will hand out server tickets to the users in X
that will allow them to mutual authenticate with the resources in Y.
So, if we have a user Ui at X, it can obtain a server ticket from Kx to
communicate securely with Bx at X.
Over this connections, Ui will request a server ticket from Bx for resource
Ri at Y.
B uses its By at Y credentials to obtain a server ticket for Ri at Y from Ky.
At this moment, B will share separate secrets with both Ui at X and Ri at Y.
This allows B to issue a special server ticket to Ui for Ri, where the
secret is encrypted for Ui by the (Bx, Ui at X) session key and encrypted with
the (By, Ri at Y) session key for Ri.
B has essentially created a new ad-hoc realm, "Bxy", and can issue tickets
that will allow Ui and Ri to authenticate each other: these tickets are
authentication assertions where By at Y asserts to Ri at Y that the other party
is Ui at X, and Bx at X asserts to Ui at X that the server's principal is Ri at Y.
I don't want to bore you with asn.1 here, but I believe one can use the
exact same format for server ticket requests and tickets as for
plain-vanilla kerberos message exchanges.
The "path validation" of these tickets will be somewhat different, because
Ri at Y has to be able to recognize the presented server ticket as coming from
a trusted party By at Y, and subsequently use the session key from that
relationship to authenticate the requester as coming from a different realm X.
The users from X and resources in Y will need to define their policy rules
with these special principal names and bridge realms in mind, but this is
not very different from the names that are obtained from conventional cross
realm authentication.
* Notes.
User-to-user should work as well, with some extra round trips here and there.
The bridging service will probably reside on the resource owners side, but
that is not required.
It could even be managed by a real third party that works as a broker (but
now we're really dreaming...)
The pattern is not really kerberos specific: if we can create a trusted
third party that shares secrets with Ui and Ri, then it can introduce Ui to
Ri through a newly created secret communicated to both.
The latter observation means that we could extend to scenarios where one
party would not be part of a kerberos domain, but is for example part of a
PKI with x.509 credentials:
If Ui and B have both x.509 credentials with CA "K", then Ui could be
identified by Ui#K, and the bridging service by Bk#K.
If the Ui and B also have kerberos-enabled runtimes, and the resources Ri
and B are part of kerberos realm Y, then B can again issue a special
kerberos server ticket to Ui, where the session key (Ui, Ri) is encrypted
by the SSL connection between Ui#K and B#K.
This scenario would address a situation where the users are both PKI and
kerberos enabled, but only have x.509 credentials, while the resources are
only kerberos enabled and only have kerberos creds.
If Ui and Bx are part of kerberos realm X, and B and Ri have x.509
credentials, and all have kerberos enabled runtimes, then B can issue a
similar service ticket to Ui that will be encrypted by the SSL session
between B and Ri.
This scenario would address a situation where the users Ui are not
PKI-enabled, but the resources are both PKI and kerberos enabled but have
only X.509 creds.
---------------
Again, would it make sense to work towards a next generation toolkit that
would enable runtimes to work with different authentication protocols, like
kerberos and x.509, and let the policy decide how to bridge incompatible
domains/realms?
Enjoy, Frank.
PS. I've cross posted to both the ogsa-security mailing list as well as the
security-wg list, because this is probably of interest to both.
More information about the krbdev
mailing list