Network Working Group R. Van Rein
Internet-Draft ARPA2.net
Intended status: Experimental October 19, 2014
Expires: April 22, 2015
Finding the Kerberos Realm of a Service in DNS
draft-vanrein-dnstxt-krb1-00
Abstract
This specification defines methods to determine realm names for
services being contacted by their DNS name. Currently, finding realm
names is done through guessing or local configuration. DNS can make
this process more dynamic, provided that DNSSEC is used to ensure
authenticity of resource records.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 22, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Van Rein Expires April 22, 2015 [Page 1]
Internet-Draft DNS TXT "v=krb1" October 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Kerberos TXT record syntax . . . . . . . . . . . . . . . . . 3
3. Defining Home Records and Home Tags . . . . . . . . . . . . . 3
4. Querying Realm Descriptions . . . . . . . . . . . . . . . . . 4
4.1. Querying a Domain's Realm Descriptions . . . . . . . . . 4
4.2. Querying a Host's Realm Descriptions . . . . . . . . . . 5
5. Publishing Realm Descriptions . . . . . . . . . . . . . . . . 5
6. Realm Descriptor Tags . . . . . . . . . . . . . . . . . . . . 6
6.1. Realm Descriptor Tag "realm" . . . . . . . . . . . . . . 6
6.2. Realm Descriptor tag "service" . . . . . . . . . . . . . 7
6.3. Realm Descriptor Tag "user" . . . . . . . . . . . . . . . 8
7. Efficiency Considerations . . . . . . . . . . . . . . . . . . 8
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
When a client contacts a Kerberised service, it needs to obtain a
service ticket, and for that it needs to contact the realm under
which the service is run. To map a service name into a realm name
and then into a KDC, the client uses local mappings, or it can
contact its KDC which look into its local mappings. Through DNS,
such mappings could be dynamically expanded, thus permitting more
flexibility without explicit configuration.
There are two important mappings that 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
Kerberos5-specific services such as the KDC. The latter mapping is
published in SRV records [RFC4120] and the traffic is protected by
the protocols themselves. The first mapping however, has never been
standardised and are ill-advised because unsecured DNS cannot be
considered a reliable source.
With the recent rise of DNSSEC however, it is possible to make a
reliable judgement on the authenticity of such data, which enables
the standardisation of the first mapping in the form of TXT records
in DNS. This specification defines how to publish and process such
records.
Van Rein Expires April 22, 2015 [Page 2]
Internet-Draft DNS TXT "v=krb1" October 2014
Each TXT record holds of a series of tagged string values. A few of
these are defined below, others may be added by future
specifications.
2. Kerberos TXT record syntax
The TXT record for Kerberos is a simple sequence of ABNF terminals:
"v" "=" "krb1" *( ";" tag "=" value )
The initial v=krb1 is used as a hint to applications that this
specification is followed. Space and tab character sequences after
terminals are ignored; a tag is a sequence of letters, digits, dashes
and underscores; a value is anything but whitespace or semicolons.
Note that the entire TXT record is case-insensitive. TODO: Really?
"The ASCII case insensitivity conventions only apply to ASCII labels"
[Section 3.2 of [RFC4343]]
When a TXT record does not adhere to this syntax, it MUST NOT be
processed as described in this specification, but this MUST NOT be
fatal to the processing of other TXT records. When the initial
v=krb1 matches the syntax but the rest does not, then a processing
application MAY release a warning message.
Tags are registered with IANA, and this document defines the first
few. New additions are always optional. An application that does
not recognise a tag name MUST silently discard it.
Multiple TXT records may be supplied under a queried name, and there
may be multiple that adhere to this syntax; these present
alternatives that can be tried. Since DNS does not supply them in
any order, the DNS client can choose freely in what order to process
these records. When no TXT record adheres to this syntax, then no
alternative is available through DNS.
3. Defining Home Records and Home Tags
The TXT records defined here may be used to define realm names that
do not look similar to the FQDN at which it is found. Other TXT
records may define one domain-styled [Section 6.1 of [RFC4120]] realm
name that translates back to the FQDN at which the TXT record was
found. The latter category of TXT record is called a "home record"
in this specification.
TXT records which are not home records can be used to reference from
a DNS name to a realm that maps onto another DNS name. The use of
DNSSEC makes this safe; the same party that masters the server
settings also determines the authentication service to use.
Van Rein Expires April 22, 2015 [Page 3]
Internet-Draft DNS TXT "v=krb1" October 2014
Some tags may be defined to be used in home record only. Such tags
are defined by the term "home tags". Specification whether a tag is
a home tag is intended to avoid claims about realms being made
outside its control.
4. Querying Realm Descriptions
The following subsections define two procedures for finding a
Kerberos realm. One procedure starts from a domain name, the other
starts from the hostame of a server.
When dealing with services found through DNS SRV [RFC 2782], a choice
between the use of a domain name or hostname is possible. In these
situations, the FQDN of the SRV queries MUST be used in the procedure
for domain name queries.
Since DNS in general cannot be considered secure, the client MUST
dismiss any DNS responses that are not Insecure, Bogus or
Indeterminite [Section 5 of [RFC4033]]. Only Secure responses are
taken into account. This specification does not prescribe that the
client validates the responses by itself, but the deployment used
SHOULD NOT accept validation states of DNS responses from a reliable
validating source over unreliable communication channels.
The result may contain TXT records that do not adhere to the syntax
of this specification; such TXT records MUST be removed from the
result. Within the syntax, there may be tags that are unknown; such
tags and their value MUST be ignored when further processing the
results. Finally, some tags are defined as "home tags", and those
MUST be ignored if the TXT record is not a home record.
When no Secure DNS responses are received, this procedure MUST be
terminated without extracting realm descriptive information from DNS.
Such termination need not be fatal; other procedures may exist to
find a realm name.
4.1. Querying a Domain's Realm Descriptions
To find the Kerberos realm definition for a domain name, a DNS client
conducts a TXT query targeted at the domain name.
Where this specification speaks of querying a domain, its
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
attached, for instance through MX or SRV records. Domain names also
occur in many naming schemes after an optional username and @ symbol,
such as the domain name (that also happens to be termed "realm", but
Van Rein Expires April 22, 2015 [Page 4]
Internet-Draft DNS TXT "v=krb1" October 2014
without connection to Kerberos realms) in a Network Access Identifier
[RFC4282].
4.2. Querying a Host's Realm Descriptions
The query of a hostname may be done at two levels, namely the
hostname itself and the apex of the zone holding the hostname. The
latter requires a signed denial for the hostname; the signature of
this denial holds a field named the "Signer's Name" which must
contain the zone name [Section 3.1.7 of [RFC4034]], which is used for
the second query if the name differs from the initial hostname.
Note that most name servers will also return a SOA record with a
negative response; this addition however, is not guaranteed 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 Descriptions
The default position for realm-descriptive TXT records is in the apex
of a zone. These may be home records, but that is not a requirement;
it is possible to authenticate multiple domain names with a single
Kerberos realm.
It is possible to override entries underneath the zone apex. This
may be done for individual host names, or through a wildcard that
catches a range of undefined names. Note that wildcards receive
special treatment [RFC4592] when used with DNSSEC, but that they are
supported.
The various entries in DNS override each other in a particular order;
the zone apex is the fallback default; wildcards cator to unspecific
subordinate names, and an accurately matched hostname has the highest
priority.
Note that a domain is not always the same as a zone apex. So, when
querying a domain name as specified in Section 4.1, there will be no
fallback to a zone apex. An entry similar to the one in a zone apex
should then be defined; and similarly, it may be overridden with
wildcards and hostnames that define subordinate DNS names.
The syntax supports TXT records that define no realm at all. These
are interpreted as the absense of Kerberos for the given name.
Van Rein Expires April 22, 2015 [Page 5]
Internet-Draft DNS TXT "v=krb1" October 2014
6. Realm Descriptor Tags
The names of tags fall apart in two types:
o "General tags" can be used in any v=krb1 TXT records;
o "Home tags" can only be used in TXT records that describe a realm
that matches the FQDN of the TXT record.
When home tags occur in a TXT record that does not define a realm
name that matches the FQDN of the TXT record, then these home tags
MUST be ignored.
6.1. Realm Descriptor Tag "realm"
The tag "realm" MAY be present in all TXT records that adhere to this
specification, and it MUST be processed by implementations of this
specification.
The value of a "realm" tag names a realm connected to the TXT
record's FQDN. Since the content of a TXT record is case-
insensitive, a mapping to case-sensitive realm names is needed. In
this mapping, a realm-value letter is mapped to a lowercase letter if
it is preceded by an equals sign and mapped to an uppercase letter if
not; equals signs are not mapped to realm characters; all other
characters are mapped without modification. The result MUST be a
domain-style realm name [Section 6.1 of [RFC4120] to be accepted for
further processing along the lines of this specification.
When multiple "realm" tags occur in one TXT record, then they present
alternative suggestions to combine with all other tags in the same
TXT record. Note that a TXT record with multiple "realm" tags is
never a home record.
The absense of a "realm" tag in a TXT record conforms to this
specification; it does not provide any realm names for the given FQDN
in DNS. One such TXT record can be used to specify the absense of
Kerberos tickets for the FQDN of that TXT record; this can be used to
override TXT records in a wildcard or at the zone apex.
An example use of the "realm" tag in a TXT record is
example.com. IN TXT "v=krb1; realm=EXAMPLE.COM"
Since the FQDN of this TXT record is example.com, this TXT record may
also hold home tags.
Van Rein Expires April 22, 2015 [Page 6]
Internet-Draft DNS TXT "v=krb1" October 2014
In addtion to the previous example, the following tag indicates that
there is no realm, and so it is useless to lookup a Kerberos ticket
for ftp.example.com:
ftp.example.com. IN TXT "v=krb1"
6.2. Realm Descriptor tag "service"
The tag "service" MAY be present in any TXT record that adheres to
this specification, and it SHOULD be recognised by implementations of
this specification. The tag is optional.
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
match service tags. The occurrence of a service tag and a realm tag
in the same TXT record may be read to suggest that a principal ticket
for the combination exists. Since service names are used to match,
and act as a hint, their representation without case in DNS is not a
problem; they are matched through case-insensitive comparison.
The purpose of this tag is to enable clients an early selection
between alternatives that it may wish to pursue; adding a service tag
may improve the speed of resolution when multilple alternatives are
listed in DNS, especially when future initatives would require public
key cryptography for realm crossover. Since the tag is optional and
its presence may not lead to a single combination of realm, service
and FQDN, clients must still be prepared to iterate over
alternatives.
When multiple "service" tags occur in one TXT record, then they
present alternative suggestions to combine with all other tags in the
same TXT record. The set is then to be considered complete; that is,
when one or more "service" tags occur but none matches to a service
that a client requires, then the realm description in that TXT record
does not apply.
An example use of this tag in a TXT record is
www.example.com. IN TXT "v=krb1; realm=example.com;
realm=example.org; service=http; service=ftp"
This would match with the following principal names:
o HTTP/www.example.com@EXAMPLE.COM
o HTTP/www.example.com@EXAMPLE.ORG
o ftp/www.example.com@EXAMPLE.COM
Van Rein Expires April 22, 2015 [Page 7]
Internet-Draft DNS TXT "v=krb1" October 2014
o ftp/www.example.com@EXAMPLE.ORG
A service named "krbtgt" is not offered for this service name, as far
as this TXT record is concerned.
6.3. Realm Descriptor Tag "user"
TODO: Also define a "user" tag? RFC 3645 uses DNS@ krb4-style names,
but in general I doubt if users should occur in DNS?
7. Efficiency Considerations
The TXT records introduced in this specification are useful to define
realm names for servers whose DNS information is not statically
configured in a Kerberos setup. This may release the pressure on
such local configurations, and it may introduce more dynamicity,
which may be useful for such things as realm crossover.
Since realm names cannot always be derived from DNS names, clients
tend to construct various principal names by attaching all the realm
names that they can think 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 [RFC6806] to a realm for
consideration. In general, the list of service ticket names that may
be considered can be relatively long.
Limiting the length of the list of ticket requests is going to be
especially useful for situations with realm crossover when this
involves public-key cryptography, as such algorithms are much slower
than the symmetric algorithms normally used for Kerberos.
The use of "realm" tags can help the client to focus on those realms
for which a service has a name defined. Similarly, the use of
"service" tags is helpful to select only those TXT records that hold
the service name sought by an application. The presence of multiple
"realm" and/or multiple "service" tags in one TXT record enables
iteration over multiple combinations, without a need to store the
resulting cartesian product in DNS.
8. Privacy Considerations
It is common to spread service information in DNS, but for internal
use this may be considered less desirable. This is why the "service"
tag, as specified in Section 6.2, is optional.
Van Rein Expires April 22, 2015 [Page 8]
Internet-Draft DNS TXT "v=krb1" October 2014
9. Security Considerations
This specification defines a mechanism to redirect from a FQDN to a
realm that may be located elsewhere, or to indicate that no realm is
available for that FQDN. Publishing such a realm definition is the
prerogative of the service administrator, and is therefore well-
positioned in a DNS record at the same FQDN as the service, or at its
zone apex.
However, when an attacker would be permitted to spoof such a record
in a victim's DNS, then it could be possible for the attacker to
convince the client that the attacker is the authentic provider for
the service. Additional spoofing of hostname references could then
complete the attack. This has been mitigated by requiring DNSSEC for
all such TXT records.
Another angle of attack could be due to suppression of a TXT record,
for instance for a hostname. Such attacks could direct a client to
rely on the information stored in the zone apex, which may differ
from an overridden value that is less desirable to the attacker.
Such attacks have been mitigated by insisting on signed denials, and
by stating that a non-responsive DNS server should not lead to the
assumption that one can move up in the DNS hierarchy.
The process of finding the zone apex relies on a strict prescription
in DNSSEC standards. The field from which it is taken is
incorporated into the RRSIG record that holds it TODO:check, so this
does not provide an opening to redirect the TXT queries to a domain
of choice either.
The ability to create a TXT record that references a realm operated
under another DNS name introduces a potential of setting flags for
that remote realm that may be counter-productive. Given the open-
endedness of the registry for these, problems due to this are
mitigated by ignoring unknown tags, and treating known tags
differently when they are registered as "home" tags; such tags are
not processed for references to realms operated under another DNS
name.
10. IANA Considerations
This specification establishes a new registry with IANA, whose
entries are subject to expert review and whose definition must be
described in a publicly available specification. The new registry
will be known as the "Kerberos DNS TXT Tag Registry". Each entry
must provide a flag to indicate if the tag may only be interpreted in
home tags.
Van Rein Expires April 22, 2015 [Page 9]
Internet-Draft DNS TXT "v=krb1" October 2014
The initial entries for this new registry introduced by this
specification are:
+----------+-----------+--------------------------------+
| Tag name | Home tag? | Definition |
+----------+-----------+--------------------------------+
| v | N/A | Not to be used [TBD:THIS-SPEC] |
| realm | No | [TBD:THIS-SPEC] |
| service | No | [TBD:THIS-SPEC] |
+----------+-----------+--------------------------------+
Tag names are case-insensitive. The tag name "v" is reserved, and
shall not be assigned.
In addition to the foregoing, tag names starting with "x-" are
reserved for experimental use, for which no registration is possible,
or required. For these unregistered tags there will be no protection
from name clashes.
11. References
11.1. Normative References
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[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
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC4343] Eastlake, D., "Domain Name System (DNS) Case Insensitivity
Clarification", RFC 4343, January 2006.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, July 2006.
11.2. Informative References
[RFC6806] Hartman, S., Raeburn, K., and L. Zhu, "Kerberos Principal
Name Canonicalization and Cross-Realm Referrals", RFC
6806, November 2012.
Van Rein Expires April 22, 2015 [Page 10]
Internet-Draft DNS TXT "v=krb1" October 2014
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
Author's Address
Rick van Rein
ARPA2.net
Haarlebrink 5
Enschede, Overijssel 7544 WP
The Netherlands
Email: rick@openfortress.nl
Van Rein Expires April 22, 2015 [Page 11]