Cross-Realm Authentication

[Douglas E. Engert]

Saber Zrelli wrote:
> Hi Douglas ,
> 
> * Douglas E. Engert (deengert at anl.gov) wrote:
> 
> 
>>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.)
> 
> 
> I'm sorry I forgot about the section [domain_realm]. Thanks.
> 
> 
>>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.
> 
> 
> 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

> after checking the ticket the TGS in EX.COM provides a ticket for the user
> in EX1.COM
> 
> If some user in EX.COM wish to access a service in EX1.COM it's the other
> way around.
> 
> is it correct ?
>

See above.

> 
>>>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.
> 
> 
> I meant that, it is said that kerberos is vulnerable to DOS attacks.
> is this related to the fact that users in remote realms are allowed to
> communicate with local KDC directly ?

Yes Kerberos is subject to DOS,  but this is not a cross realm issue.
Any one can send any packet they want to a KDC. But the KDC will
discard invalid requests. You could do some Intrusion Detection and
have the firewalls stop some traffic.

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


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


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

> 
> 
>>>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.
> 
> 
> In the above I wanted to know if it is possible to use Kerberos as
> authentication system in access networks.
> 
> I meant that in roaming situation, the client is located away from his home
> realm. The visited realm is supposed to give Internet access for the
> client to communicate with his home KDC. This access is granted to the
> client before the authentication is actually performed.
> 
> 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).
> 
> For example, when using PKI, the client have his credentials and the AR can
> check them before granting access. Other way is to use Diameter in
> cross-realm authentication which fits very well in roaming situations.

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.


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