[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
configuration).
-derek
"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