Next: Kerberos via TLS, Previous: Starting Shishid, Up: Administration Manual [Contents][Index]
Making sure the configuration files on all hosts running Shishi clients include the addresses of your server is tedious. If the configuration files do not mention the KDC address for a realm, Shishi will try to look up the information from DNS. In order for Shishi to find that information, you need to add the information to DNS. For this to work well, you need to set up a DNS zone with the same name as your Kerberos realm. The easiest is if you own the publicly visible DNS name, such as ‘example.org’ if your realm is ‘EXAMPLE.ORG’, but you can set up an internal DNS server with the information for your realm only. If this is done, you do not need to keep configuration files updated for the KDC addressing information.
In Kerberos, realm names are case sensitive. While it is strongly encouraged that all realm names be all upper case this recommendation has not been adopted by all sites. Some sites use all lower case names and other use mixed case. DNS on the other hand is case insensitive for queries but is case preserving for responses to TXT queries. Since "MYREALM", "myrealm", and "MyRealm" are all different it is necessary that only one of the possible combinations of upper and lower case characters be used. This restriction may be lifted in the future as the DNS naming scheme is expanded to support non-ASCII names.
KDC location information is to be stored using the DNS SRV RR [RFC 2052]. The format of this RR is as follows:
Service.Proto.Realm TTL Class SRV Priority Weight Port Target
The Service name for Kerberos is always "_kerberos".
The Proto can be either "_udp", "_tcp", or "_tls._tcp". If these SRV records are to be used, a "_udp" record MUST be included. If the Kerberos implementation supports TCP transport, a "_tcp" record MUST be included. When using "_tcp" with "_kerberos", this indicates a "raw" TCP connection without any additional encapsulation. A "_tls._tcp" record MUST be specified for all Kerberos implementations that support communication with the KDC across TCP sockets encapsulated using TLS [RFC2246] (see STARTTLS protected KDC exchanges).
The Realm is the Kerberos realm that this record corresponds to.
TTL, Class, SRV, Priority, Weight, and Target have the standard meaning as defined in RFC 2052.
As per RFC 2052 the Port number should be the value assigned to "kerberos" by the Internet Assigned Number Authority (88).
These are DNS records for a Kerberos realm ASDF.COM. It has two Kerberos servers, kdc1.asdf.com and kdc2.asdf.com. Queries should be directed to kdc1.asdf.com first as per the specified priority. Weights are not used in these records.
_kerberos._udp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. _kerberos._udp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com. _kerberos._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. _kerberos._tcp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com. _kerberos._tls._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. _kerberos._tls._tcp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com.
As DNS is deployed today, it is an unsecure service. Thus the infor- mation returned by it cannot be trusted.
Current practice for REALM to KDC mapping is to use hostnames to indicate KDC hosts (stored in some implementation-dependent location, but generally a local config file). These hostnames are vulnerable to the standard set of DNS attacks (denial of service, spoofed entries, etc). The design of the Kerberos protocol limits attacks of this sort to denial of service. However, the use of SRV records does not change this attack in any way. They have the same vulnerabilities that already exist in the common practice of using hostnames for KDC locations.
Implementations SHOULD provide a way of specifying this information locally without the use of DNS. However, to make this feature worthwhile a lack of any configuration information on a client should be interpretted as permission to use DNS.
Next: Kerberos via TLS, Previous: Starting Shishid, Up: Administration Manual [Contents][Index]