Declaring Kerberos Realm Names in DNS (KREALM)ARPA2.netHaarlebrink 5EnschedeOverijssel7544 WPThe Netherlandsrick@openfortress.nlThis specification defines a method to determine Kerberos realm
names for services that are known by their DNS name.
Currently, such information can only be found in static mappings or
through educated guesswork.
DNS can make this process more flexible, provided that DNSSEC is used
to ensure authenticity of resource records.When a Kerberos client contacts a service, it needs to obtain a service
ticket, and for that it needs to contact the KDC for a realm under which the
service is run. To map a service name into a realm name and then into a KDC,
clients tend to use static mappings or educated guessing; the client's KDC may
or may not be involved in this process. Through DNS, the static mappings could
be made more dynamic, and be moved from local client configuration into the
hands of the party administrating a server's presence in DNS. This permits
more flexibility than under the current practice.Two mappings are needed for the given scenario.
One is a mapping from the FQDN of a service to its realm name; the other is
a mapping from the realm name to the Kerberos-specific services such as
the KDC. The latter mapping is published in SRV records
and such traffic is protected by the Kerberos protocol itself. The first mapping
however, has hitherto not been standardised and is ill-advised over unsecured DNS
because the published information is then neither validated by DNS nor does it
lead to a protocol that could provide end-to-end validation for it.With the recent uprise of DNSSEC, it is now possible to make a reliable judgement on the
authenticity of data in DNS, which enables the standardisation of the first mapping in the form of
resource records in secured DNS.This specification defines how to publish and process Kerberos realm names using a newly defined resource record type KREALM. These records hold a case-sensitive string with the realm name. Multiple KREALM records may be defined as alternatives and suggest iterating over them until a ticket can be procured.This specification introduces a new DNS resource record type that contains a
Kerberos realm name. The name for this DNS resource record type is
KREALM, and its numeric value is TBD1. The corresponding RDATA format is as follows:The REALMNAME is represented as a <character-string> which starts with a single-byte length, followed by as many bytes of realm name as the length byte's value. The RDATA field therefore has a length of 1 up to 256 bytes, to hold a realm name of 0 up to 255 bytes.
For instance, a realm EXAMPLE.ORG would be represented with the same RDATA as the following generic RDATA section that is also used for unkonwn resource record types :The REALMNAME represents a Kerberos realm name, not a DNS name. As a result, there cannot be a trailing dot unless it is actually part of the Kerberos realm name. The realm name is never relative to the DNS name at which the KREALM record was found. Finally, there is no required relationship (such as partial overlap) between the realm name and the DNS name at which the KREALM record was found.Realm names in Kerberos are often domain-styled [Section 6.1 of ], in which case they look like DNS names but are case sensitive; unlike the DNS names used as lookup keys in the DNS hierarchy, the REALMNAME format follows the <character-string> format in being case-sensitive.In fact, the <character-string> format is a binary format, and DNS notation \DDD [Section 5.1 of ] exists to put arbitatrary bytes in the string notation, including even interior NUL bytes. This binary format leaves the door ajar for future internationalisation of Kerberos realm names. Realm names are defined with the KerberosString type [Section 5.2.1 of ] which is an ASN.1 GeneralString, but its specification currently advises to constrain the use of this string type to an IA5String (basically using only the first 128 codes of the ASCII table) to avoid interoperability problems. After the <character-string>'s length byte, the REALMNAME holds the value of the GeneralString, but not the corresponding ASN.1 tag and length.It is worth noting that the ESC "%" "G" prefix [TODO:xref target="ISO2022"/] can be used to introduce an UTF8String in a GeneralString, and that implementations exist that insert UTF8String values in KerberosString fields without even that escape. All this precedes formal standardisation of internationalisation, but it suggests that the RDATA definition for KREALM can be supportive of future internationalisation of realm names, even if its current advised use is limited to the value of an IA5String.The format for the resource data in master zone files is the same
as for TXT records, which also have the same RDATA representation. The vital
difference of KREALM lies its different record type, which declares that its
RDATA has a well-defined meaning as a realm name, and can therefore be
automatically processed without risking arbitrary coincidences that could lead to
security problems. An example declaration of realm name EXAMPLE.ORG for a server
named imap.example.org would be:The RDATA for this KREALM record has already been shown above,
in the generic RDATA section notation.Multiple KREALM records may be supplied for the same DNS name; these represent alternatives that can be tried by the DNS client. Since DNS delivers the resource records as a set without any particular order, the DNS client can choose freely in what order to process these records.It is possible to create a KREALM record for any DNS name, but this specification only provides query procedures for host names and domain names. The use with a domain name had the additional use of denoting the precise spelling for a realm name under its DNS-mapped name. DNS-mapped names currently would not modify more than the case of a DNS name, and even that is only done as the result of DNS compression ; but in a future with internationalised realm names there might be more to guess, in which case this facility is likely to be helpful. Since KREALM records in general pose no constraints on the relation between the contained realm name and the DNS name at which it is found, it is advised for this one application to map the realm name back to a DNS name and compare the result.This sections defines a procedure for finding Kerberos realm names for
the servers, as well as for a DNS-mapped realm name.When applications directly know their server host name, perhaps because it is
mentioned in a ticket as a service principal name, they will lookup the KREALM
record at the same name as the server host name.When applications locate their servers through a domain name, for example via
MX or SRV records , a choice
between the use of the domain name or the appointed server host names
is to be made. In these situations, the KREALM query MUST use only
the domain name, without adding prefixes such as _Service._Proto for SRV records.
The appointed servers for a domain service MUST NOT be queried for KREALM
records, since these may reside under operational control foreign to the
service domain. In addition, their possible shared use by many domains would
mean that they may have to specify a
long list of realms, most of which would be unusable to the client. The domain
name is closer to the client's context and can provide a better-targeted list
of KREALM records.Since DNS in general cannot be considered secure,
the client MUST dismiss any DNS responses that are Insecure, Bogus or
Indeterminate [Section 5 of ]. Only the remaining
Secure responses are to be taken into account. This specification does
not require that the client validates the responses by itself, but a
client deployment SHOULD NOT accept DNS responses from
a trusted validating DNS resolver over untrusted communication channels.To give one possible implementation, a Kerberos client or its KDC may send
DNS queries with the Authentic Data (AD) bit set to enable DNSSEC
[Section 5.7 of ],
and require that the Authenticated Data bit is set in the
response to indicate
the Secure state for answer and authority sections of
the response. When the DNS traffic to and from the validating resolver is
protected, for instance because the validating resolver is reached over a loopback
interface, then the Kerberos client or its KDC has implemented the requirements for
Secure use of the answer and authority sections in DNS responses.When no Secure DNS responses are received when DNS timesout,
then the KREALM query MUST be terminated without extracting realm names from DNS.
This termination MAY be done immediately upon receiving Secure denial
for the requested KREALM record.
KREALM query termination need not be fatal; non-DNS procedures may exist to
find a realm name, including the current practice of static mappings and
educated guessing.KREALM records should generally be published at the domain names and
server host names that a Kerberos application may want to approach.As an exception to this general rule, server host names may be exempted
if they are always looked up through a domain name. Note however, that most
query mechanisms that lookup domain names through special resource record
types have fallbacks to plain server host name lookups. When such direct
server host names are supported in a deployment of those applications, usually
meaning that these server host names may occur in Kerberos service principal
names, and when the realm name cannot be detected through a preferred mechanism
for such server host names, then an additional KREALM record located at the
server name is also going to be helpful.There may be situations where a domain represents a Kerberos realm, but
uses domain-style references such as MX and SRV records to point to
foreign server host names. Such foreign server host names are often unsuitable
to accompany with a KREALM record, so it is advisable to either not refer to
the server host names directly in service tickets, or to see to it that a
realm name is always attached by the KDC.These instructions are somewhat flexible, as a result of the pre-existing
mechanisms
for finding a realm name for a given service principal name. Assuming that
the more flexible approach of KREALM records is preferred, a suitable test would
be to run the targeted applications from an unconfigured Kerberos client.Zones that intend to provide applications with Kerberos realm names
through KREALM records MUST be protected by DNSSEC to make them usable
to those applications.Note that KREALM records with wildcard names will not work. All host
names and most domain names define at least one resource record (of any type)
with the name that the wildcard should cover. These defined names cause the
wildcards to be suppressed from DNS responses,
even when querying a non-existent KREALM record.KREALM records are useful to
define realm names for servers whose DNS information is not statically
mapped in a Kerberos setup. This may simplify operative control of such
static mappings. It may also introduce more dynamicity, which may be
useful for such things as realm crossover.The lookup of KREALM records can be done by a KDC, which can send back
Cross-Realm Routing suggestions [Section 9 of ]
to Kerberos clients that enable canonicalization. The cached DNS records,
their validation and possibly realm-crossover caching at the KDC can all
benefit fast responses for future lookups by all Kerberos clients.Since realm names cannot be derived directly from DNS names, clients
tend to construct various principal names by appending all the realm
names that they are aware of, and attempting to obtain a service ticket
for each in turn, until one is found. The KDC may also perform such
actions, and return a reference to a realm for
consideration. In general, the list of service principal names that
may be considered can be relatively long.The use of KREALM records helps both the Kerberos client and its KDC to
focus on those realms for which a service ought to have a name defined.
This limits the list of potential realm names
to those realm names that the service suggests. The client
does not need to guess as heavily. Similarly, the combined use of
"service" tags helps to select only those KREALM records that further
constrain the scope to search.The definition of KREALM records under a domain rather than under a
server host name (for cases where a choice exists, such as for applications
that use SRV or MX records) should give less potential realm names, because
the domain is closer to the client's domain/realm than the server might be.Limiting the length of the list of possible ticket requests to try is
especially useful for situations with realm crossover when this involves
public-key cryptography, because such algorithms are much slower than the
symmetric algorithms that are normally used for Kerberos.The information contained in a KREALM record for a domain is barely more
than the domain's
DNS name already holds; the KREALM record spells out the case-sensitive realm name,
and implies the use of Kerberos. The use of Kerberos is usually also
implied by the presence of certain SRV records.The KREALM records also mark the names of Kerberised servers. Internal
use may prohibit such disclosure, but in those use cases it is often
possible to rely on existing mechanisms for guessing a realm name,
including simply using the realm name under which a client logged on
with Kerberos.There is no restriction for KREALM records to mention realm names
that map back to DNS names in a disjoint part of the DNS hierarcy.
The records could therefore specify realm names for
a service even if the service is not recognised by the realm. The KDC
for the appointed realm would be very clear about that when trying to
procure a service ticket, so there is no
security issue with such misguided use of KREALM records.The general point is that the use of DNSSEC makes us rely on the party
that publishes the KREALM record, and that party could specify improper realm names
or drop realm names that are vital to the client. This is not expected to
be a security risk either; the party publishing the KREALM record is the
same party that publishes the service's records, namely the DNS operator.
By publishing the service's record in DNS, this operator already has
potential control over service denial and other MITM-type attacks, so
the KREALM record does not add any new abusive powers.When an external attacker would be permitted to
spoof a KREALM record in a victim's DNS, then it could be possible for that
attacker to convince the client that the attacker is the authentic provider
for the service. Additional spoofing of host name references could then
complete the attack. This has been mitigated by strictly requiring DNSSEC for all
KREALM records.This specification defines a new "Resource Record (RR) Type", to be
registered in the IANA registry of "Domain Name System (DNS) Parameters".
The name of the RRType is KREALM, its value is TBD1
and its meaning is "Kerberos realm name".