Projects/KREALM

This project introduces Kerberos description records in DNS. At present, there is no formally acceptable manner of deducing a realm name from a server name. The KREALM record enables such translations, and possibly more. The record's security hinges on DNSSEC.

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.

External project links:

• Specification

We use KREALM as a name for the protocol proposed on this page.

Mechanics of the Project

Actors: The Kerberos actor wanting to establish the realm name for a given server name is called the DNS client. The server name is supported by a DNS zone run in a DNS server.

1. The DNS client requests the KREALM record for the sought server name, or otherwise a denial by the DNS server.
2. The DNS client validates the response through DNSSEC.
3. The DNS client may retry at a default location (usually the apex of the DNS zone) based on the location for a DNSKEY signing a denial.
4. The DNS client will validate any such default location to be the same or a higher-up name in the DNS hierarchy.
5. The DNS client interprets the KREALM record to find the r=REALMNAME record

It should be pointed out that rogue intermediates might add RRSIG records of their own, pointing to parts outside the DNS hierarchy for the requested server name. This should be detected and ignored.

Past Controversy

The default location has been subject of some controversy. This was because:

• The DNS does not formally define where a zone apex lies;
• Iterating upward may land up in a DNS zone under different operational control;
• Iterating upward is not an efficient use of the DNS.

The solution is probably to not specify the zone apex as the fallback location, but the same location as where the DNSKEY records are. In both cases, the RRSIG record(s) provide the location without iteration. The choice for the same location as the DNSKEY for fallback is that

• It centralises spread-out parts of a zone into one place
• It is part of the same DNS zone
• The party controlling the DNSKEY records already has the ability to sabotage the KREALM setup, so no new dangers are introduced
• The party controlling the DNSKEY must also co-operate for KREALM records at the server name, doing that centrally for the zone is not different
• It can be verified to match the server name or lie upward from it

Policy Choices for this Mechanism

• The KDC may or may not want to find realms through KREALM records
• The client, provided that it can process DNSSEC, may want to find realms through KREALM records
• The server administrator may or may not choose to publish the realm, and possibly more, for the service and/or the realm

Changes to Kerberos

• The KDC may process KREALM records, and for that purpose, rely on DNSSEC
• The Kerberos client might process KREALM records, and for that purpose, require DNSSEC to be operational (which is not a solid thing to build on)

Changes to DNS

• DNS servers would need to support KREALM records, as they do any other records

Comparison to Other Work

None.

Related Projects

See KREALM-XOVER.

Specifications

None.