* Douglas E. Engert ([EMAIL PROTECTED]) 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/[EMAIL PROTECTED] > > Yes. > > > > >2 - Using the same key , admin in EXAMPLE1.COM creates > >krbtgt/[EMAIL PROTECTED] > > No. Using same key, admin in EXAMPLE1.COM creates > krbtgt/[EMAIL PROTECTED] > 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/[EMAIL PROTECTED] 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/[EMAIL PROTECTED] encrypted using > >the key of krbtgt/[EMAIL PROTECTED] > > > > Yes. > > >4- TGS in EX.COM can decrypt this ticket using the key of the principal > >krbtgt/[EMAIL PROTECTED] which is the same key as the principal > >krbtgt/[EMAIL PROTECTED] > > No it uses the same principal, krbtgt/[EMAIL PROTECTED]
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/[EMAIL PROTECTED] > krbtgt/[EMAIL PROTECTED] > krbtgt/[EMAIL PROTECTED] > krbtgt/[EMAIL PROTECTED] > krbtgt/[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos