ZeroShell    Forum
   Feed RSS Feed
EnglishEnglish     ItalianoItaliano     French     Spanish                Zeroshell on LinkedIn LinkedIn       Facebook      Twitter ZeroTruth an interface for Captive Portal


      What is it?
      Screenshots
      License
      Announcements
      Mailing List
      Forum
      Documentation  
      FAQ
      Hardware
      Download
      On-line Updates
      Kerberos Tutorial  
      Terms of use
      Contact me


  In greater details:
      Hotspot Router
      RADIUS Accounting
      Shibboleth SP
      Performances
      Net Balancer
      UMTS Router
      Soekris Net5501
      Proxy with Antivirus
      WiFi Access Point
      OpenVPN Client
      OpenVPN Server
      QoS
      OpenDNS
      Kerberos 5
      NIS and LDAP
      X.509 Certificates
      RADIUS
      VPN
      Firewall


Valid HTML 4.01 Transitional

Kerberos Authentication Protocol

Kerberos   Introduction   Aims   Definitions   Operation   Tickets   Cross Authentication

1.6  Cross Authentication

We've already mentioned the possibility for a user belonging to a certain realm to authenticate and access the services of another realm. This characteristic known as cross-authentication is based on the assumption that there is a trust relationship between the realms involved. This may be mono-directional, meaning that the users of realm A can access the services of realm B but not vice versa, or bi-directional, where, as one might expect, the opposite is also possible. In the following paragraphs we will look at cross authentication, breaking down the trust relationships into direct, transitive and hierarchical.

1.6.1  Direct trust relationships

This type of trust relationship is elementary and is the basis of cross-authentication and is used to construct the other two types of relationships we will look at later. It occurs when the KDC of realm B has direct trust in the KDC of realm A, thus allowing the users of the latter realm to access its resources. From a practical point of view, a direct trust relationship is obtained by having the two involved KDCs share a key (the keys become two if a bi-directional trust is desired). To do this the concept of a remote Ticket Granting Ticket is introduced which, in the example of the two realms A and B, assumes the form krbtgt/B@A and is added to both the KDCs with the same key. This key is the secret which will guarantee the trust between the two realms. Obviously, to make it bi-directional (i.e. that A also trusts B), it is necessary to create the remote TGT krbtgt/A@B in both KDCs, associating them with another secret key.
As we'll see shortly in the following example, the introduction of the remote TGTs makes cross authentication a natural generalization of normal intra-realm authentication: this underlines that the previous description of Kerberos operation continues to be valid as long as it is accepted that the TGS of one realm can validate the remote TGTs issued by the TGS of another. Note the formal anomaly arising when the remote TGTs are not issued by the AS, as happens for the local ones, but by the local Ticket Granting Server upon presentation of the local TGT.
Now let's look at an example to clarify all this. Let's suppose that the user pippo of the realm EXAMPLE.COM, whose associated principal is pippo@EXAMPLE.COM, wishes to access the pluto.test.com server belonging to the TEST.COM realm, via ssh:
  • If Pippo does not already have a TGT in the realm EXAMPLE.COM he makes an initial authentication request (kinit). Obviously, the reply comes from the AS of his realm;
  • He gives the ssh pippo@pluto.test.com command which should open the remote shell on pluto.test.com without having to re-enter the password;
  • the ssh client makes two queries to DNS: it works out the IP of pluto.test.com and on the just obtained address carries out the reverse in order to obtain the hostname (FQDN) in canonical form (in this case it coincides with pluto.test.com);
  • ssh client then realizes, thanks to the previous result, that the destination does not belong to the user's realm and thus asks the TGS of the realm EXAMPLE.COM (note that it asks the TGS of its realm for this) for the remote TGT krbtgt/TEST.COM@EXAMPLE.COM;
  • With the remote TGT it asks the TGS of the realm TEST.COM for the host/pluto.test.com@TEST.COM service ticket;
  • When the TEST.COM Ticket Granting Service receives the request, it checks for the existence of the principal krbtgt/TEST.COM@EXAMPLE.COM in its database with which it can verify the trust relationship. If this verification is positive the service ticket (encrypted with the key of host/pluto.test.com@TEST.COM) is finally issued which pippo will send to the host pluto.test.com to obtain the remote shell.

1.6.2  Transitive trust relationships

When the number of realms in which cross-authentication must be possible increases, the number of keys to exchange increases quadratically. For example, if there are 5 realms and the relationships must be bi-directional, the administrators must generate 20 keys (double the combinations of 5 elements by 2 by 2).
To get around this problem, Kerberos 5 has introduced transitivity in the trust relationship: if realm A trusts realm B and realm B trusts realm C then A will automatically trust C. This relationship property drastically reduces the number of keys (even if the number of authentication passages increases).
However, there is still a problem: the clients cannot guess the authentication path (capath) if it is not direct. So they must be informed of the correct path by creating a special stanza ([capaths]) in the configuration of each of the clients. These paths must also be known to the KDCs which will use them to check the transits.

1.6.3  Hierarchical trust relationships

If, within organizations, the convention of naming realms with the name of DNS domains in upper case letters is used (highly recommended choice) and if the latter belong to a hierarchy, then Kerberos 5 will support adjacent realms (hierarchically) having a trust relationship (naturally this assumed trust must be supported by the presence of appropriate keys) and will automatically construct (without the need for capaths) the transitive authentication paths. However, administrators can alter this automatic mechanism (for example for reasons of efficiency) by forcing the capaths in the client configuration.



    Copyright (C) 2005-2016 by Fulvio Ricciardi