logo_kerberos.gif

Difference between revisions of "Projects/KREALM"

From K5Wiki
Jump to: navigation, search
(Resolved past controversy with different mechanism (iteration, but being clever about SOA records))
(Past Controversy)
 
(12 intermediate revisions by the same user not shown)
Line 13: Line 13:
   
 
# The DNS client requests the KREALM record for the sought server name, or otherwise a denial by the DNS server.
 
# The DNS client requests the KREALM record for the sought server name, or otherwise a denial by the DNS server.
# The DNS client validates the response through DNSSEC.
+
# The DNS client validates the response or denial through DNSSEC.
# 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.
+
# '''We dropped the following, as we couldn't agree on it:''' 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.
 
# The DNS client will validate any such default location to be the same or a higher-up name in the DNS hierarchy.
 
# The DNS client will validate any such default location to be the same or a higher-up name in the DNS hierarchy.
# The DNS client interprets the KREALM record to find the r=REALMNAME record
+
# The DNS client interprets the KREALM record to find the realm name
  +
# When multiple KREALM records exist, then each suggests an alternative realm name to try
   
 
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.
 
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.
   
  +
The DNS client mentioned above will usually be the KDC, which may be assumed to be setup to validate DNSSEC properly. For clients, this is less likely, less reliable and may fail in various contexts due to mediocre DNS infrastructure at end points. Having said that, a client that loads its own libunbound or other secure resolver may still succeed on most networks.
   
 
==Past Controversy==
 
==Past Controversy==
Line 29: Line 30:
 
* Iterating upward is not an efficient use of the DNS.
 
* Iterating upward is not an efficient use of the DNS.
   
This has now been overcome by specifying a secure manner of upward iteration through the DNS hierarchy. When no KREALM record is found, then before iterating in upward direction, a test is made whether a SOA record exists at that point. This can be efficienty seen by looking at the NSEC/NSEC3 secure denial for the KREALM query, which holds a type bit map.
 
  +
These points kept coming up, and so we have decided to not iterate upward along the DNS hierarchy at all. Every server or domain that wants to specify a Kerberos realm should set it up alongside the servername.
 
By not allowing the upward iteration to move beyond the zone apex for the zone holding the originally sought DNS name, we can assume that there is no change of operational control for the zone. There is a bit of impact administratively, when multiple DNS zones are covered by one Kerberos realm; all covered zones must then publish their own KREALM records.
 
   
 
==Policy Choices for this Mechanism==
 
==Policy Choices for this Mechanism==
Line 37: Line 36:
 
* The KDC may or may not want to find realms through KREALM records
 
* 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 client, provided that it can process DNSSEC, may want to find realms through KREALM records
  +
* The client that finds realms through KREALM records may treat them as overrides for anything else it would otherwise try -- when it finds KREALM records, that is
  +
* The client that looks for KREALM records may (at some point in the future) decide to discard other methods, perhaps exempting the the client's login realm
  +
* The client, if it doesn't process KREALM records itself, may delegate to the KDC by accepting canonicalisation and [https://tools.ietf.org/html/rfc6806#section-9 Cross-Realm Routing] suggestions
 
* The server administrator may or may not choose to publish the realm, and possibly more, for the service and/or the realm
 
* The server administrator may or may not choose to publish the realm, and possibly more, for the service and/or the realm
   
Line 42: Line 44:
   
 
* The KDC may process KREALM records, and for that purpose, rely on DNSSEC
 
* 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)
+
* The Kerberos client might process KREALM records, and for that purpose, require DNSSEC to be operational (which may not be completely reliable on all client networks)
   
 
==Changes to DNS==
 
==Changes to DNS==
   
 
* DNS servers would need to support KREALM records, as they do any other records
 
* DNS servers would need to support KREALM records, as they do any other records
  +
* Until they do, [https://tools.ietf.org/html/rfc3597 Handling of Unknown DNS RRtypes] can be used
   
 
==Comparison to Other Work==
 
==Comparison to Other Work==

Latest revision as of 10:07, 15 September 2015

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:

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 or denial through DNSSEC.
  3. We dropped the following, as we couldn't agree on it: 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 realm name
  6. When multiple KREALM records exist, then each suggests an alternative realm name to try

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.

The DNS client mentioned above will usually be the KDC, which may be assumed to be setup to validate DNSSEC properly. For clients, this is less likely, less reliable and may fail in various contexts due to mediocre DNS infrastructure at end points. Having said that, a client that loads its own libunbound or other secure resolver may still succeed on most networks.

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.

These points kept coming up, and so we have decided to not iterate upward along the DNS hierarchy at all. Every server or domain that wants to specify a Kerberos realm should set it up alongside the servername.

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 client that finds realms through KREALM records may treat them as overrides for anything else it would otherwise try -- when it finds KREALM records, that is
  • The client that looks for KREALM records may (at some point in the future) decide to discard other methods, perhaps exempting the the client's login realm
  • The client, if it doesn't process KREALM records itself, may delegate to the KDC by accepting canonicalisation and Cross-Realm Routing suggestions
  • 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 may not be completely reliable on all client networks)

Changes to DNS

Comparison to Other Work

None.

Related Projects

See KREALM-XOVER.

Specifications

None.