Cross-Realm Authentication

[Douglas E. Engert]

Saber Zrelli wrote:

> 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
> 
>  

By convention the client expects the server to be using a service
ticket with the host name it is trying to contact. All the "login"
type services use the service name host, as the services are run by root,
and in effect login in the user. So telnet, rlogin, ssh  console login
all use the host service name.

The trick then is how does the client determine what is the realm of the server
A database is needed to look up the realm. The krb5.conf file on the client
has the [domain_realm] section. There is a dns_lookup_realm (but this has
some security issues). There is some thing called referrals where the
client asks the user's KDC for a ticket, and the KDC says, its in this
other realm, go try it. And if the client application allows it, it could
let the user enter the full principal with realm. (SSPI on Windows allows
this.)

The point is the client and server applications agree on what
service principal will be used. Telnet uses host/<fqdn>@<realm>

> 
>>"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 ?
> 

Think of the remote KDC as a service, but it does not have a keytab file
like other servives, it stores the cross realm principal and key in its
database instead.

Note that if you want cross realm in the other direction, you would
create krbtgt/EXAMPLE1.COM at EXAMPLE.COM 	in both.

> 
>>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 
> 
If not found [domain_realms} the default to to uppercasethe DNS domain
and assume this for the Kerberos realm. See above on refferrals etc.

> 
>>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.
> 
>


Don't see your problem. The client will only trust foreign KDCs if it gts
a ticket from its own KDC.

> 
> 
>>(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.
>

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.


> 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.
> 

There is the "transited" field in tickets and the CA-PATH lsting what are
the trusted paths through multipe realms, that I think address your concerns.


> 
> 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
> 
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444