[Fwd: bridging of Kerberos realms]

Derek Atkins warlord at MIT.EDU
Tue Oct 1 11:00:00 EDT 2002

This is just using a transited realm.  It's already supported
in 1510 -- the more challenging aspect is determing the transit
routing.  In other words, if I am a client in realm A and want
to use a resource in realm B, how do I determine the realm transit
path to get from A to B?

Note that KDC referrals are part of a solution (although they are
neither necessary nor sufficient -- one could do it with client-only


"Douglas E. Engert" <deengert at anl.gov> writes:

> 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.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> http://mailman.mit.edu/mailman/listinfo/krbdev

       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the krbdev mailing list