draft-vanrein-dnstxt-krb1-01.txt   draft-vanrein-dnstxt-krb1-02.txt 
Network Working Group R. Van Rein Network Working Group R. Van Rein
Internet-Draft ARPA2.net Internet-Draft ARPA2.net
Intended status: Standards Track November 13, 2014 Intended status: Standards Track September 3, 2015
Expires: May 17, 2015 Expires: March 6, 2016
Kerberos Realm Descriptors in DNS (KREALM) Kerberos Realm Descriptors in DNS (KREALM)
draft-vanrein-dnstxt-krb1-01 draft-vanrein-dnstxt-krb1-02
Abstract Abstract
This specification defines methods to determine Kerberos realm This specification defines methods to determine Kerberos realm
descriptive information for services that are known by their DNS descriptive information for services that are known by their DNS
name. Currently, finding such information is done through static name. Currently, finding such information is done through static
mappings or educated guessing. DNS can make this process more mappings or educated guessing. DNS can make this process more
dynamic, provided that DNSSEC is used to ensure authenticity of dynamic, provided that DNSSEC is used to ensure authenticity of
resource records. resource records.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 17, 2015. This Internet-Draft will expire on March 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The KREALM Resource Record . . . . . . . . . . . . . . . . . 3 2. The KREALM Resource Record . . . . . . . . . . . . . . . . . 3
3. Defining Home Realms and Home Records . . . . . . . . . . . . 4 3. Defining Home Realms and Home Records . . . . . . . . . . . . 4
4. Querying Realm Descriptors . . . . . . . . . . . . . . . . . 5 4. Querying Kerberos Realm Descriptors . . . . . . . . . . . . . 5
4.1. Querying a Domain's Realm Descriptors . . . . . . . . . . 6 4.1. Querying a Domain's Kerberos Realm Descriptors . . . . . 6
4.2. Querying a Host's Realm Descriptors . . . . . . . . . . . 6 4.2. Querying a Host's Kerberos Realm Descriptors . . . . . . 6
5. Publishing Realm Descriptors . . . . . . . . . . . . . . . . 7 5. Publishing Kerberos Realm Descriptors . . . . . . . . . . . . 7
6. Tags in Realm Descriptors . . . . . . . . . . . . . . . . . . 7 6. Tags in Kerberos Realm Descriptors . . . . . . . . . . . . . 8
6.1. Realm Descriptor Tag "realm" . . . . . . . . . . . . . . 8 6.1. Kerberos Realm Descriptor Tag "realm" . . . . . . . . . . 8
6.2. Realm Descriptor Tag "service" . . . . . . . . . . . . . 9 6.2. Kerberos Realm Descriptor Tag "service" . . . . . . . . . 9
7. Efficiency Considerations . . . . . . . . . . . . . . . . . . 10 7. Efficiency Considerations . . . . . . . . . . . . . . . . . . 11
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
When a Kerberos client contacts a service, it needs to obtain a 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 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 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 name and then into a KDC, clients tend to use static mappings or
educated guesses; the client's KDC may or may not be involved in this educated guesses; the client's KDC may or may not be involved in this
process. Through DNS, such mappings could be dynamically expanded, process. Through DNS, such mappings could be dynamically expanded,
permitting more flexibility than under the current practice. permitting more flexibility than under the current practice.
Two mappings are needed for the given scenario. One is a mapping 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 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 from the realm name to the Kerberos-specific services such as the
KDC. The latter mapping is published in SRV records [RFC4120] and KDC. The latter mapping is published in SRV records [RFC4120] and
such traffic is protected by the Kerberos protocol itself. The first such traffic is protected by the Kerberos protocol itself. The first
mapping however, has hitherto not been standardised and is ill- mapping however, has hitherto not been standardised and is ill-
advised over unsecured DNS because the published information is then advised over unsecured DNS because the published information is then
neither validated by DNS nor does it lead to a protocol that could neither validated by DNS nor does it lead to a protocol that could
validate it. provide end-to-end validation for it.
With the recent uprise of DNSSEC, it is now possible to make a With the recent uprise of DNSSEC, it is now possible to make a
reliable judgement on the authenticity of such data in DNS, which reliable judgement on the authenticity of data in DNS, which enables
enables the standardisation of the first mapping in the form of the standardisation of the first mapping in the form of resource
resource records in secured DNS. records in secured DNS.
This specification defines how to publish and process Realm This specification defines how to publish and process Kerberos Realm
Descriptors using a newly defined resource record type KREALM. Each Descriptors using a newly defined resource record type KREALM. Each
of these records holds of a series of tagged string values. A few of of these records holds a series of tagged string values. A few of
these are defined below, others may be added by future these are defined below, others may be added by future
specifications. specifications.
2. The KREALM Resource Record 2. The KREALM Resource Record
This specification introduces a new DNS resource record that serves This specification introduces a new DNS resource record that serves
as a realm descriptor for Kerberos. The name for this DNS resource as a Kerberos Realm Descriptor. The name for this DNS resource
record type is KREALM, and its numeric value is TBD1. The record type is KREALM, and its numeric value is TBD1. The
corresponding RDATA format is as follows: corresponding RDATA format is as follows:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ KREALM-DATA / / KREALM-DATA /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The syntax of KREALM-DATA is the DER encoding of the following ASN.1 The syntax of KREALM-DATA is the DER encoding of the following ASN.1
syntax: syntax:
KREALM-DATA ::= SEQUENCE { KREALM-DATA ::= SEQUENCE {
versionNumber INTEGER (0..) DEFAULT 0, versionNumber INTEGER (0..) DEFAULT 0,
SET OF SEQUENCE { SET OF SEQUENCE {
tag IA5String, tag IA5String,
value UTF8String value UTF8String
}
} }
}
This specification makes the assumption that all values are This specification makes the assumption that all future tag
represented as strings. definitions will define their corresponding value fields to be
represented in strings.
DISCUSS: RFC 4120 defines realm names with the KerberosString type DISCUSS: RFC 4120 defines realm names with the KerberosString type
which is a GeneralString, but it then advises to constrain it to which is a GeneralString, but it then advises to constrain it to
IA5String or else risk interoperability problems. It is worth noting IA5String or else risk interoperability problems. It is worth noting
that the ESC "%" "G" prefix defined in ISO 2022 can be used to that the ESC "%" "G" prefix defined in ISO 2022 can be used to
introduce an UTF8String in the KerberosString, and that introduce an UTF8String in the KerberosString, and that
implementations even exist that insert UTF8String in KerberosString implementations even exist that insert UTF8String in KerberosString
fields without even that escape. It's a jungle out there! Defining fields without even that escape. It's a jungle out there! Defining
UTF-8 for this new field type does not seem to be such a stretch; it UTF-8 for this new field type does not seem to be such a stretch; it
includes the IA5String subset and it also keeps the door ajar for includes the IA5String subset and it also keeps the door ajar for
future attempts at I18N of realm names and other Kerberos parameters. future attempts at I18N of realm names and other Kerberos parameters.
OTOH, OCTETSTRING would probably be too general, and place too much OTOH, OCTETSTRING would probably be too general, and place too much
faith in wire representations to be suitable for comparison. faith in wire representations to be suitable for comparison.
The advised format for the resource data in master zone files is the The advised format for the resource data in master zone files is the
base64-encoded KREALM-DATA content in DER-encoding. Although most base64-encoded KREALM-DATA content in DER-encoding. Although most
data will be printable string data, it need not adhere to an ASCII data will be printable string data, it need not adhere to the ASCII
character set, may include NUL characters and have a somewhat complex character set or another constrained set the DNS processing software
may assume, it may include NUL bytes and have a somewhat complex
grammar; all these aspects would complicate master zone files and grammar; all these aspects would complicate master zone files and
thus make them more error-prone. thus make them more error-prone; hence the representation in base64
format.
Tags are registered with IANA, and this document defines the first Tags are registered with IANA, and this document defines the first
few. A special range of tags starting with "x-" is available for few. A special range of tags starting with "x-" is available for
local or experimental use. Implementations MAY safely ignore tags local or experimental use. Implementations MAY safely ignore tags
(and the corresponding value) that are not known to them. An (and the corresponding value) that are not known to them. An
application that does not recognise a tag name MUST silently discard application that does not recognise a tag name MUST silently discard
it. it.
The versionNumber 0 is used as a version number for this Software implementing this specification can be recognised by
specification; it is also the default versionNumber when absent from versionNumber 0; this is also the default versionNumber when absent
the encoding. Future updates to this specification MUST use another from the encoding. Future updates to this specification MUST use
versionNumber IF they are invalidate any assumptions made in this another versionNumber IF they invalidate any assumptions made in this
specification. Such new applications SHOULD advise how to setup DNS specification. Such new applications SHOULD advise how to setup DNS
in a backward-compatible manner; they might for instance publish both in a backward-compatible manner; they might for instance publish both
old and new styles of KREALM records. old and new styles of KREALM records.
Clients requesting KREALM records MUST ensure that the record uses Clients requesting KREALM records MUST ensure that the record uses
proper syntax, including the string formats specified for tag and proper syntax, including the string formats specified for tag and
value fields and a versionNumber that the client understands. value fields and a versionNumber that the client understands.
Multiple KREALM records may be supplied under a queried name, and Multiple KREALM records may be supplied under a queried name, and
there may be multiple that adhere to this syntax; these present there may be multiple that adhere to this syntax; these present
alternatives that can be tried. Since DNS does not supply them in alternatives that can be tried, possibly with different versionNumber
any order, the DNS client can choose freely in what order to process values. Since DNS does not supply them in any order, the DNS client
these records. can choose freely in what order to process these records. One
possibility is a DNS client that prefer certain KREALM records over
others.
In this general form, there are no constraints on the number of In this general form, there are no constraints on the number of
permissible occurrences of a tag in one or more KREALM records, but permissible occurrences of a tag in one or more KREALM records, but
tags MUST define whether multiple occurrences are permitted, and if tags MUST define whether multiple occurrences are permitted, and if
so, what their interpretation is. so, what their interpretation is.
3. Defining Home Realms and Home Records 3. Defining Home Realms and Home Records
One of the tags defined by this specification is the "realm" tag One of the tags defined by this specification is the "realm" tag
[Section 6.1] that specifies a realm name. Realm names can be mapped [Section 6.1] that specifies a realm name. Realm names can be mapped
[Section 7.2.3 of [RFC4120]] to DNS names. Those realm names in [Section 7.2.3 of [RFC4120]] to DNS names. Those realm names in
"realm" tags of KREALM records that that map to the FQDN at which "realm" tags of KREALM records that that map to the FQDN at which
that KREALM record was found, are hereby defined as "Home Realms". that KREALM record was found, are hereby defined as "Home Realms".
KREALM records of which all realm name tags are Home Realms, are KREALM records of which all "realm" tags are Home Realms, are hereby
hereby defined as "Home Records". Note how KREALM records are not defined as "Home Records". Note how KREALM records are not defined
defined to be Home Realms when they contain a mixture of Home Tags to be Home Realms when they contain a mixture of Home Tags and
and "realm" tags that are not Home Tags. "realm" tags that are not Home Tags. Note how a single DNS name may
hold many KREALM records, some of which are Home Records and some of
which are not.
In general, the DNS name to which a realm name maps can hold In general, the DNS name to which a realm name maps can hold
information about the location of a KDC [Section 7.2.3 of [RFC4120]] information about the location of a KDC [Section 7.2.3 of [RFC4120]]
and other realm-specific services. This does not change; but for and other realm-specific services. This is undeniable; but for Home
Home Realms, the same FQDN is the basis for finding the KREALM record Realms, the same FQDN is the basis for finding the KREALM record and
and the KDC and other services; for other KREALM records that Home the KDC and other services; for other KREALM records than Home
Records, the KREALM tag is a reference to a realm that translates to Records, the KREALM tag is a reference to a realm that translates to
another DNS name, which in turn serves as the basis for finding the another DNS name, which in turn serves as the basis for finding the
KDC and other realm services. KDC and other realm services.
The following specifications are strict about their reliance on The following specifications are strict about their reliance on
DNSSEC for KREALM records. The reason for this is to ensure that DNSSEC for KREALM records. The reason for this is to ensure that
both the pointer to the actual service and its containing realm are both the pointer to the actual service and its containing realm are
inserted into DNS by the same responsble party. When combined with inserted into DNS by the same responsble party. When combined with
cryptographic ensurance of reaching the proper KDC for a realm, this cryptographic ensurance of reaching the proper KDC for a realm, this
provides a secure mechanism for access to realms can be created, provides a secure mechanism through which realms can be contacted,
whether or not they are the realm into which a user logged on. regardless of whether they are the realm into which a user logged on.
Mechanisms for cryptographic ensurance of reaching realms is standard Mechanisms for cryptographic ensurance of reaching realms is standard
in Kerberos implementations; based on DNSSEC this may even be in Kerberos implementations; based on DNSSEC this may even be
extended with more dynamic mechanisms, but that is not defined in extended with more dynamic mechanisms, but that is not defined in
this specification. A result that this specification may have is this specification. A result that this specification may have is
that the user knows the realms to ask for, even if it is a realm that that the user knows the realms to ask for, even if it is a realm that
was hitherto unknown. In that sense, the KREALM record may be a was hitherto unknown. In that sense, the KREALM record can be a
stepping stone in loosely connected links between Kerberos realms. stepping stone in loosely connected links between Kerberos realms.
4. Querying Realm Descriptors 4. Querying Kerberos Realm Descriptors
The following subsections define two procedures for finding Kerberos The following subsections define two procedures for finding Kerberos
realm descriptors for the DNS name of a service. One procedure realm descriptors for the DNS name of a service. One procedure
starts from a domain name, the other starts from the host name of a starts from a domain name, the other starts from the host name of a
service. service.
When dealing with services found through DNS SRV [RFC2782], a choice When dealing with services found through DNS SRV [RFC2782], a choice
between the use of a domain name or host name is possible. In these between the use of a domain name or host name is possible. In these
situations, the FQDN of the SRV queries, without the _Service._Proto situations, the FQDN of the SRV queries, without the _Service._Proto
prefix, MUST be used in the procedure for domain name queries, and prefix, MUST be used in the procedure for domain name queries, and
the procedure for querying a domain should be followed rather than the procedure for querying a domain should be followed rather than
the procedure for a host name. the procedure for a host name.
Since DNS in general cannot be considered secure, the client MUST Since DNS in general cannot be considered secure, the client MUST
dismiss any DNS responses that are Insecure, Bogus or Indeterminate dismiss any DNS responses that are Insecure, Bogus or Indeterminate
[Section 5 of [RFC4033]]. Only the remaining Secure responses are [Section 5 of [RFC4033]]. Only the remaining Secure responses are to
taken into account. This specification does not require that the be taken into account. This specification does not require that the
client validates the responses by itself, but a client deployment client validates the responses by itself, but a client deployment
SHOULD NOT accept DNS responses from a trusted validating DNS SHOULD NOT accept DNS responses from a trusted validating DNS
resolver over untrusted communication channels. resolver over untrusted communication channels.
To give one possible implementation, a Kerberos client may send DNS To give one possible implementation, a Kerberos client may send DNS
queries with the DNSSEC OK bit [RFC3225] set to enable DNSSEC, and queries with the DNSSEC OK bit [RFC3225] set to enable DNSSEC, and
require that the Authenticated Data bit [RFC3655] is set in the require that the Authenticated Data bit [RFC3655] is set in the
response to indicate the Secure state for answer and authority response to indicate the Secure state for answer and authority
sections of the response. When the DNS traffic to and from the sections of the response. When the DNS traffic to and from the
validating resolver is protected, for instance because that resolver validating resolver is protected, for instance because that resolver
skipping to change at page 6, line 24 skipping to change at page 6, line 31
be tags that are unknown; such tags and their value MUST be ignored be tags that are unknown; such tags and their value MUST be ignored
when further processing the results. Finally, some tags are when further processing the results. Finally, some tags are
specifically registered with IANA for use in Home Tags, and those specifically registered with IANA for use in Home Tags, and those
MUST be ignored if the KREALM record is not a Home Record. MUST be ignored if the KREALM record is not a Home Record.
When no Secure DNS responses are received, this procedure MUST be When no Secure DNS responses are received, this procedure MUST be
terminated without extracting realm descriptive information from DNS. terminated without extracting realm descriptive information from DNS.
Such termination need not be fatal; non-DNS procedures may exist to Such termination need not be fatal; non-DNS procedures may exist to
find a realm name. find a realm name.
4.1. Querying a Domain's Realm Descriptors 4.1. Querying a Domain's Kerberos Realm Descriptors
To find Kerberos realm descriptors for a domain name, a DNS client To find Kerberos Realm Descriptors for a domain name, a DNS client
conducts a KREALM query targeted directly at the domain name. conducts a KREALM query targeted directly at the domain name.
Where this specification speaks of querying a domain, its Where this specification speaks of querying a domain, its
interpretation of a domain is that of a name space, which may or may interpretation of a domain is that of a name space, which may or may
not have a host attached, but which is likely to have services not have a host attached, but which is likely to have services
attached, for instance through MX or SRV records. Domain names also attached, for instance through AAAA, MX or SRV records. Domain names
occur in many naming schemes after an optional username and @ symbol, also occur in many naming schemes after an optional username and @
such as the domain name (that also happens to be termed "realm", but symbol, such as the domain name (that also happens to be termed
without connection to Kerberos realms) in a Network Access Identifier "realm", but without connection to Kerberos realms) in a Network
[RFC4282]. Access Identifier [RFC4282].
4.2. Querying a Host's Realm Descriptors 4.2. Querying a Host's Kerberos Realm Descriptors
To find a realm descriptor for a host name, a KREALM query is To find a Kerberos Realm Descriptor for a host name, a KREALM query
performed to the same FQDN as that of the host name. If this fails is performed by upward iteration towards the DNS root, but never
with a secure denial, a fallback KREALM query is done on the FQDN of crossing over the zone apex, as marked by a SOA record.
the zone apex. The reason to use the zone apex in this role is that
it signifies the start of administrative control over a zone,
generally making it cover a larger DNS name range than a single host
name, while still residing under the same operational control as the
host name itself -- which is valuable from a security viewpoint.
Without a signed denial, no fallback query is performed; this Although upward iteration through the DNS could in extreme cases be
mitigates denial of service attacks on that host name's FQDN. With a detrimental to DNS performance, most practical zones will not have
signed denial, evidence of non-existence of the KREALM record is many levels of host names, and as a result the search for the KREALM
returned, and part of that is a field named the Signer's Name. This records should not take long. Also, as described in Section 5 below,
field must contain the zone name [Section 3.1.7 of [RFC4034]], and operators do have the ability to define additional KREALM records at
this value is used as the FQDN of the zone apex for the fallback strategic names.
query. The querying client MUST ensure that this property holds;
that is, it MUST NOT proceed with the fallback query if the Signer's
Name does not have the original host name as a subordinate name.
DISCUSS: Note that most name servers will also return a SOA record The algorithm starts by setting the current name to the host name.
with a negative response; this addition however, is not guaranteed Then, it goes through the following loop:
and it may be removed from the response due to frame size
constraints. This is why the SOA record is not preferred for finding
the secondary description.
5. Publishing Realm Descriptors 1. A KREALM query is launched against the current name.
The default position for KREALM records that describe a realm is in 2. When the query times out in spite of resending or attempting
the apex of a zone. Such KREALM records may be Home Records, but other name servers, then the algorithm ends in failure.
that is not a requirement, because on Kerberos realm may cover any
number of DNS zones.
When a KREALM record is published in the zone apex, it will cover all 3. When a Secure DNS response arrives holding one or more KREALM
SRV records for that domain name, as well as all host names defined records, then these can be processed; the algorithm ends
in the same zone. SRV records for subordinate names to the zone apex successfully.
need a separate KREALM record. If a host name requires overridden
KREALM record, then this may be specified in a KREALM record with the
same FQDN as the host name.
One form of overriding KREALM definitions worth noting is one that 4. When a Secure denial is received in the form of an NSEC [RFC3845]
does not define a Kerberos realm at all; such a record can be used to or NSEC3 [RFC5155] record, the algorithm continues.
undefine any realm names that are defined in the zone apex.
5. When the type bit map in the secure denial indicates the presence
of a SOA record under the current name, then no further
iterations are possible, and the algorithm ends in failure.
6. The first label is removed from the current name, and the loop
repeats.
A failure from the above algorithm indicates that no Kerberos Realm
Descriptor records could be found, and so that no assumptions may be
made on those.
5. Publishing Kerberos Realm Descriptors
KREALM records are best published at the DNS-mapped name for a
Kerberos realm, where they can be setup as Home Records. In many
practical situations, this DNS-mapped realm name will match the apex
of a zone. It is also possible to strategically position KREALM
records at lower positions in the DNS hierarchy, although those could
not be setup as Home Records.
When a KREALM record is published for a certain DNS name, it will
cover all MX and SRV records for that DNS name, as well as all host
names defined at the same DNS name or hierarchically lower but in the
same zone. SRV and MX records for hierarchically lower DNS names
need a separate KREALM record.
For child zones that contain service definitions that fall under a
parent zone, the KREALM records must be repeated to supporting
finding the Kerberos Realm Descriptor for the child zones' services.
This is a result of the refusal of the algorithms to cross-over to
parent zones.
The additional mentioning of KREALM records on hierarchically lower
names than the DNS-mapped realm name is also useful when the contents
of the KREALM records needs to be modified. One form of overriding
KREALM definitions worth noting is one that does not define a
Kerberos realm at all; such a record is useful to undefine any realm
names that are defined higher up the DNS hierarchy.
Note that KREALM records with wildcard names will not work. All host Note that KREALM records with wildcard names will not work. All host
names and most domain names define at least one resource record (of names and most domain names define at least one resource record (of
any type) with the name that the wildcard should cover. These any type) with the name that the wildcard should cover. These
defined names cause the wildcards to be suppressed [RFC4592] from DNS defined names cause the wildcards to be suppressed [RFC4592] from DNS
responses. responses, even when querying a non-existent KREALM record.
6. Tags in Realm Descriptors 6. Tags in Kerberos Realm Descriptors
The names of tags are partitioned into two types: The names of tags are partitioned into two types:
o General Tags can be used in any KREALM records; o General Tags can be used in any KREALM records;
o Home Tags can only be used in Home Records. o Home Tags can only be used in Home Records.
Any Home Tags that occur in other KREALM records than Home Records Any Home Tags that occur in other KREALM records than Home Records
MUST be ignored. MUST be ignored.
6.1. Realm Descriptor Tag "realm" 6.1. Kerberos Realm Descriptor Tag "realm"
The tag "realm" MAY be present in all KREALM records, and it MUST be The tag "realm" MAY be present in all KREALM records, and it MUST be
recognised and processed by implementations of this specification; in recognised and processed by implementations of this specification; in
other words, the tag is not optional. other words, the tag is not optional.
The value of a "realm" tag provides a realm name for the queried The value of a "realm" tag provides a realm name for the queried
FQDN. The permissible values of this tag conform to the permissible FQDN. The permissible values of this tag conform to the permissible
names of realm names [Section 6.1 of [RFC4120]], which a conforming names of realm names [Section 6.1 of [RFC4120]], which a conforming
application MUST validate before processing the value. This application MUST validate before processing the value. This
includes, but is not limited to, domain-style realm names. Since the includes, but is not limited to, domain-style realm names. Since the
skipping to change at page 9, line 8 skipping to change at page 9, line 38
concerned: concerned:
ftp.example.com. IN KREALM "MAIxAA==" ftp.example.com. IN KREALM "MAIxAA=="
The RDATA for this KREALM record encodes no tags and no values at The RDATA for this KREALM record encodes no tags and no values at
all: all:
SEQUENCE SEQUENCE
SET SET
6.2. Realm Descriptor Tag "service" 6.2. Kerberos Realm Descriptor Tag "service"
The tag "service" MAY be present in any KREALM record, and it SHOULD The tag "service" MAY be present in any KREALM record, and it SHOULD
be recognised by implementations of this specification. The tag is be recognised by implementations of this specification. The tag is
optional. optional.
The value of a "service" tag is the name of a service, as used in The value of a "service" tag is the name of a service, as used in
principal names. This can be used as a hint to clients that need to principal names. This can be used as a hint to clients that need to
match "service" tags. The occurrence of a "service" tag and a match "service" tags. The occurrence of a "service" tag and a
"realm" tag in the same KREALM record is a hint that a service ticket "realm" tag in the same KREALM record is a hint that a service ticket
for the combination probably exists. Note that the value of this tag for the combination probably exists. Note that the value of this tag
skipping to change at page 11, line 22 skipping to change at page 11, line 44
Limiting the length of the list of ticket requests is especially Limiting the length of the list of ticket requests is especially
useful for situations with realm crossover when this involves public- useful for situations with realm crossover when this involves public-
key cryptography, because such algorithms are much slower than the key cryptography, because such algorithms are much slower than the
symmetric algorithms that are normally used for Kerberos. symmetric algorithms that are normally used for Kerberos.
The combined publication of multiple "realm" tags with multiple The combined publication of multiple "realm" tags with multiple
"service" tags enables a compact representation of variations that a "service" tags enables a compact representation of variations that a
client should iterate over, without the need to store the resulting client should iterate over, without the need to store the resulting
cartesian product in DNS. cartesian product in DNS.
The use of an iterative procedure that moves up along the DNS
hierarchy could in theory end up hogging DNS bandwidth, but practical
zones have only very few levels (and Kerberos is not used in reverse
DNS) so the number of iterations is very limited. Furthermore, any
nuisance would concentrate at the authoritative DNS servers, which
are operated by the parties that can insert additional KREALM records
to overcome any problems. In short, the burden on DNS should not be
aggravated by this iterative approach.
8. Privacy Considerations 8. Privacy Considerations
It is common to spread service information in DNS, but for internal It is common to spread service information in DNS, but for internal
use this may be considered less desirable. This is why the "service" use this may be considered less desirable. This is why the "service"
tag [Section 6.2], is optional. tag [Section 6.2], is optional.
Similarly, internal applications may still prefer local definitions Similarly, internal applications may still prefer local definitions
for realm names that a client should consider; this specification for realm names that a client should consider; this specification
does not enforce the KREALM record in those situations. does not enforce the KREALM record in those situations.
skipping to change at page 11, line 43 skipping to change at page 12, line 26
static configuration in files and KDC configuration versus a dynamic static configuration in files and KDC configuration versus a dynamic
configuration in DNS is still a choice; the dynamic option based on configuration in DNS is still a choice; the dynamic option based on
DNS publishes more information, but dynamic applications are more DNS publishes more information, but dynamic applications are more
likely to desire such information to be publicly and securely likely to desire such information to be publicly and securely
available. available.
9. Security Considerations 9. Security Considerations
This specification defines a mechanism to redirect from a FQDN to a This specification defines a mechanism to redirect from a FQDN to a
realm name that may not map to that same FQDN, or that define that no realm name that may not map to that same FQDN, or that define that no
realm name exists for the originating FQDN. Publishing such a realm realm name exists for the originating FQDN. Publishing such a
descriptor is the prerogative of the DNS administrator who is also in Kerberos Realm Descriptor is the prerogative of the DNS administrator
charge of publishing the location of the service that is protected by who is also in charge of publishing the location of the service that
Kerberos. This administrator is generally trusted not to attack the is protected by Kerberos. This administrator is generally trusted
security of a zone; DNSSEC makes this assumption even stronger than not to attack the security of a zone; DNSSEC makes this assumption
unsecured DNS, and this specification does not reduce or expand on even stronger than unsecured DNS, and this specification does not
that assumption. reduce or expand on that assumption.
When an external attacker would be permitted to spoof a KREALM record 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 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 convince the client that the attacker is the authentic provider for
the service. Additional spoofing of host name references could then the service. Additional spoofing of host name references could then
complete the attack. This has been mitigated by requiring DNSSEC for complete the attack. This has been mitigated by requiring DNSSEC for
all such KREALM records. all such KREALM records.
Another angle of attack could be due to suppression of KREALM Another angle of attack could be due to suppression of KREALM
records, specifically the ones for a host name which have a fallback records, specifically the ones for a host name which have a fallback
option at the zone apex. Such attacks could direct a client to rely option at the zone apex. Such attacks could direct a client to rely
on information that may form a alternative of lesser security. Such on information that may form a alternative of lesser security. Such
attacks have been mitigated by insisting on signed denials, and by attacks have been mitigated by insisting on signed denials, and by
stating that a non-responsive DNS server should not lead to the stating that a non-responsive DNS server should not lead to the
assumption that one can move up in the DNS hierarchy. assumption that one can move up in the DNS hierarchy.
The process of finding the zone apex relies on a strict prescription The process of detecting the zone apex relies on the inclusion of a
in DNSSEC standards. The field from which the zone apex is taken is SOA record in each zone apex, and only in the zone apex. Doing this
validated by the signature field of the RRSIG record that holds it. properly is common practice, and it is in the interest of the zone
This field is necessarily part of a signed denial under DNSSEC. being protected, so no rogue constructs are to be expected for Secure
DNS. The presence of a SOA record is not done through an explicit
query but rather from inspection of a secure denial on a previously
queried domain; this is a secure practice.
The ability to create a KREALM record that references a realm The ability to create a KREALM record that references a realm
operated under another DNS name introduces a potential of setting operated under another DNS name introduces a potential of setting
flags for that remote realm that may be counter-productive. Given flags for that remote realm that may be counter-productive. Given
the open-endedness of the IANA registry for tags, problems that this the open-endedness of the IANA registry for tags, problems that this
may cause are mitigated by ignoring unknown tags, and treating known may cause are mitigated by ignoring unknown tags, and treating known
tags differently when they are registered as Home Tags; such tags are tags differently when they are registered as Home Tags; such tags are
not processed for references to realms operated under another DNS not processed for references to realms operated under another DNS
name. name.
10. IANA Considerations 10. IANA Considerations
This specification defines a new "Resource Record (RR) Type", to be This specification defines a new "Resource Record (RR) Type", to be
registered in IANA registry of Domain Name System (DNS) Parameters". registered in IANA registry of Domain Name System (DNS) Parameters".
The name of the RRType is KREALM, its value is TBD1 and its meaning The name of the RRType is KREALM, its value is TBD1 and its meaning
is "Kerberos realm descriptor". is "Kerberos Realm Descriptor".
This specification establishes a new registry with IANA, whose This specification establishes a new registry with IANA, whose
entries are subject to expert review and whose definition must be entries are subject to expert review and whose definition must be
described in a publicly available specification. The new registry described in a publicly available specification. The new registry
will be known as the "DNS KREALM Tag Registry". Each entry must will be known as the "DNS KREALM Tag Registry". Each entry must
provide a Yes/No flag to indicate if the tag is a Home Tag, meaning provide a Yes/No flag to indicate if the tag is a Home Tag, meaning
that it may only be interpreted as part of Home Records. that it may only be interpreted as part of Home Records.
The initial entries for this new registry introduced by this The initial entries for this new registry introduced by this
specification are: specification are:
skipping to change at page 13, line 30 skipping to change at page 14, line 11
reserved for local and experimental use, for which registration is reserved for local and experimental use, for which registration is
neither possible nor required. These unregistered tags will not be neither possible nor required. These unregistered tags will not be
protected from name clashes. protected from name clashes.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. DOI 10.17487/RFC2782, February 2000,
<http://www.rfc-editor.org/info/rfc2782>.
[RFC3845] Schlyter, J., Ed., "DNS Security (DNSSEC) NextSECure
(NSEC) RDATA Format", RFC 3845, DOI 10.17487/RFC3845,
August 2004, <http://www.rfc-editor.org/info/rfc3845>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005. 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120, Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005. DOI 10.17487/RFC4120, July 2005,
<http://www.rfc-editor.org/info/rfc4120>.
[RFC4343] Eastlake, D., "Domain Name System (DNS) Case Insensitivity [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case
Clarification", RFC 4343, January 2006. Insensitivity Clarification", RFC 4343, DOI 10.17487/
RFC4343, January 2006,
<http://www.rfc-editor.org/info/rfc4343>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<http://www.rfc-editor.org/info/rfc5155>.
11.2. Informative References 11.2. Informative References
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
3225, December 2001. 3225, DOI 10.17487/RFC3225, December 2001,
<http://www.rfc-editor.org/info/rfc3225>.
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
Authenticated Data (AD) bit", RFC 3655, November 2003. Authenticated Data (AD) bit", RFC 3655, DOI 10.17487/
RFC3655, November 2003,
<http://www.rfc-editor.org/info/rfc3655>.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005. Network Access Identifier", RFC 4282, DOI 10.17487/
RFC4282, December 2005,
<http://www.rfc-editor.org/info/rfc4282>.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, July 2006. System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
<http://www.rfc-editor.org/info/rfc4592>.
[RFC6806] Hartman, S., Raeburn, K., and L. Zhu, "Kerberos Principal [RFC6806] Hartman, S., Ed., Raeburn, K., and L. Zhu, "Kerberos
Name Canonicalization and Cross-Realm Referrals", RFC Principal Name Canonicalization and Cross-Realm
6806, November 2012. Referrals", RFC 6806, DOI 10.17487/RFC6806, November 2012,
<http://www.rfc-editor.org/info/rfc6806>.
Author's Address Author's Address
Rick van Rein Rick van Rein
ARPA2.net ARPA2.net
Haarlebrink 5 Haarlebrink 5
Enschede, Overijssel 7544 WP Enschede, Overijssel 7544 WP
The Netherlands The Netherlands
Email: rick@openfortress.nl Email: rick@openfortress.nl
 End of changes. 51 change blocks. 
133 lines changed or deleted 191 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/