Cross-Realm Authentication

[Saber Zrelli]

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 (raeburn at MIT.EDU) 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/foo.example1.com at EXAMPLE1.COM" 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/foo.example1.com at EXAMPLE1.COM

 
> 
> "krbtgt/EXAMPLE.COM at EXAMPLE1.COM" 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/EXAMPLE1.COM at EXAMPLE.COM (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 darren at EXAMPLE.COM", so that second KDC 
> produces another message telling the telnet server, "the KDC for 
> EXAMPLE.COM says that this is darren at EXAMPLE.COM".  
>
> 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 <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