Hi , I would like to thank you, Ken, for these explanations , and sorry to be a third man, I have some questions and comments about cross-realm authentication.
* Ken Raeburn ([EMAIL PROTECTED]) wrote: > > The telnet is to a host named foo.example1.com, in Kerberos realm > EXAMPLE1.COM (which is what one would expect from the names, but that > isn't *always* the way it's set up). > "host/[EMAIL PROTECTED]" is the name of the service > principal used by the telnet server. How does the telnet client knows the service name that corresponds to the telnet server in the host foo.example1.com foo.example1.com <--> host/[EMAIL PROTECTED] > > "krbtgt/[EMAIL PROTECTED]" is created in both databases (that on > the EXAMPLE KDC and that on the EXAMPLE1 KDC), and must have the same > key in both. Why does the krbtgt principals have to use same key, is it design choice for the cross-realm operations ? > The telnet program run by the user on bar.example.com (no > "host/bar.example.com" principal needs to exist anywhere, in this > example) contacts the EXAMPLE.COM KDC, sending the user's > ticket-granting ticket and requesting a ticket for the service > krbtgt/[EMAIL PROTECTED] (not host/kdc.example1.com), which that > KDC issues. The kerberized telnet program knows that the host foo.exemple1.com is in the domain EXEMPLE1.COM according to the configuration file on the client's krb5.conf file ? or is it translated automatically from the domain name example1.com > > Another way to think about it is: The ticket is essentially a message a > KDC gives to the client to give to a server, which tells the server who > the KDC thinks the client is. (With a bunch of encryption stuff > happening to prevent forgery of the messages.) So, by way of the > telnet (or ftp) client, the KDC for EXAMPLE.COM tells the KDC for > EXAMPLE1.COM "this guy is [EMAIL PROTECTED]", so that second KDC > produces another message telling the telnet server, "the KDC for > EXAMPLE.COM says that this is [EMAIL PROTECTED]". > > The messages always > go by way of the client program; the KDCs don't talk to each other or > to the telnet service. from now , it's just comments about kerberos cross-realm operations , About kerberos corss-realm operations, I think that the fact that clients communicate directly with foreign KDCs is not safe, IMHO the cross-realm operations would be better if only the KDCs are involved to obtain service ticket for the clients. > > (By the way, this process can be repeated through KDCs for multiple > realms, but don't think too much about that until you understand the > two-realm case well.) In the case where the KDCs involved in the cross-realm authentication does not share keys, the protocol seems to be non optimal and the client is involved whereas the KDCs could just communicate with each other in a recursive manner and provide just the final result to the client. About roaming situations , If a client principal in realm R-A visits a foreign realm R-B , to be able to access resources in R-A, the kerberos protocol have to proceed as if the client was located in his home realm. This will involve several problems I think. That is why maybe kerberos may not be adapted to roaming situations and in access networks. I would appreciate very much your comments. Best Regards. -- 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