[Fwd: bridging of Kerberos realms]

[Douglas E. Engert]

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.