Cross-Realm Authentication

[Saber Zrelli]

* 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