Cross-Realm Authentication

Fri Apr 22 17:36:37 EDT 2005

Thanks to all of you guys for making this an exciting thread. I have
learned a great deal about cross realm authentication and it will help me
approach my customers much more prepared.

On another note (and with gratitude), I wrote up a tutorial on how to
integrate Solaris 9 Kerberos clients with an MS Win2003 AD. Part of my job
is to figure out some of these complex interoperability issues, teach them
to clients, and document my work.

I am new to this list and I am not sure if Microsoft is a dirty word in
these parts. In any case, I offer this tutorial (and many others) in
thanks for your help:

www.ufsdump.org

Darren

> * Douglas E. Engert (deengert at anl.gov) wrote:
>> >If my understanding is correct, to establish cross-realm authentication
>> we
>> >need to follow these steps :
>> >
>> >
>> > 1 - Admin in EXAMPLE.COM creates the principal
>> krbtgt/EXAMPLE1.COM at EXAMPLE.COM
>>
>> Yes.
>>
>> >
>> >2 - Using the same key , admin in EXAMPLE1.COM creates
>> >krbtgt/EXAMPLE.COM at EXAMPLE1.COM
>>
>> No. Using same key, admin in EXAMPLE1.COM creates
>> krbtgt/EXAMPLE1.COM at EXAMPLE.COM
>> Same principal name in both realms. (This is the only place where a
>> principal in the
>> database in not for the same realm, it is used as if it was in a keytab
>> file.)
>>
>> The above gives you one way trust, if you want cross realm to work the
>> other way,
>> then using a new key, both admins create krbgt/EXAMPLE1.COM at EXAMPLE.COM
>> in
>> thier
>> realms with this new key.
>>
>> >
>> >3- when a user in EX1.COM asks for a service in EX.COM, his KDC give
>> this
>> >client a Service Ticket for krbtgt/EXAMPLE.COM at EXAMPLE1.COM encrypted
>> using
>> >the key of krbtgt/EXAMPLE.COM at EXAMPLE1.COM.
>> >
>>
>> Yes.
>>
>> >4- TGS in EX.COM can decrypt this ticket using the key of the principal
>> >krbtgt/EXAMPLE1.COM at EXAMPLE.COM which is the same key as the principal
>> >krbtgt/EXAMPLE.COM at EXAMPLE1.COM.
>>
>> No it uses the same principal, krbtgt/EXAMPLE1.COM at EXAMPLE.COM
>
> Ok, I think I got it now , thanks !
>
>> >>If the KDCs don't share keys, you can't do cross realm. There must
>> >>be a trusted path between the user's realm and the server's realm
>> >>by having two or more realms share keys.
>> >
>> >
>> >In the question above, I try to understand the motivations that made
>> the
>> >cross-realm operations the way they are.
>> >
>> >I meant that why the KDCs just communicate with each others to get the
>> TGT
>> >for the client.
>>
>> The KDCs do NOT communicate with each other. The client contacts a KDC
>> in a realm to get a ticket for the next realm.
>
> Yes, I think I miss expressed my self. I meant that if ever the protocol
> that allows a client to get a TGT for a remote realm, was transparent to
> the
> client it would be good.
>
>> In the MIT release there is a test program t_walk_rtree that can
>> show what TGTs the client would need to get.
>>
>> ./t_walk_rtree A.B.X.Y.Z    C.D.X.Y.Z
>> krbtgt/A.B.X.Y.Z at A.B.X.Y.Z
>> krbtgt/B.X.Y.Z at A.B.X.Y.Z
>> krbtgt/X.Y.Z at B.X.Y.Z
>> krbtgt/D.X.Y.Z at X.Y.Z
>> krbtgt/C.D.X.Y.Z at D.X.Y.Z
>
> I would be happy to try it out. I just need to have a couple of realms :-)
>
>> >If KDC-A and KDC-B in the realms A and B share keys. Then
>> >why does the client need to be involved in getting this TGT and have to
>> ask
>> >KDC-A and KDC-B respectively.
>> >
>> >Why not just make the KDC-A and KDC-B exchange messages (in an
>> inter-KDC
>> >protocol fashion) and get the KDC-A provide the TGT for realm B to the
>> >client in realm A.
>> >
>> >Is such protocol (inter-TGS) seems feasible ?
>>
>> If you thing you have a better idea, get involved with the IETF krb-wg
>> and propose the changes.
>
> I'm looking forward.
>
>> >In access networks the access routers need to get the credentials of
>> the
>> >user before granting him any access. Therefore kerberos based auth is
>> not
>> >possible in access networks (i.e. to authenticate users before
>> providing
>> >Internet connectivity).
>>
>> This sounds like the IAKERB from a few years ago:
>>
>> Initial and Pass Through Authentication Using Kerberos V5 and the
>> GSS-API
>> (IAKERB)
>>                      <draft-ietf-cat-iakerb-09.txt>
>>
>> 1. Abstract
>>
>>    This document defines extensions to the Kerberos protocol
>>    specification (RFC 1510 [1]) and GSSAPI Kerberos protocol mechanism
>>    (RFC 1964 [2]) that enables a client to obtain Kerberos tickets for
>>    services where the KDC is not accessible to the client, but is
>>    accessible to the application server. Some common scenarios where
>>    lack of accessibility would occur are when the client does not have
>>    an IP address prior to authenticating to an access point, the client
>>    is unable to locate a KDC, or a KDC is behind a firewall. The
>>    document specifies two protocols to allow a client to exchange KDC
>>    messages (which are GSS encapsulated) with an IAKERB proxy instead of
>>    a KDC.
>>
>
> This draft addresses exaclty my point about using kerberos in access
> networks.
>
>
> Thank you very much.
>
>
>
>
> --
> Saber ZRELLI <zrelli at jaist.ac.jp>
> Japan Advanced Institute of Science and Technology
> Center of Information Science
> Shinoda Laboratory
> url     : http://www.jaist.ac.jp/~zrelli
> gpg-id  : 0x7119EA78
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>