Domain Name System Security Working Group R. Watson
INTERNET DRAFT November 1997
<draft-ietf-dnssec-ar-00.txt> Expires in six months
DNSsec Authentication Referral Record (AR)
Status of this Document
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
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."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
Authentication Referrals allow DNS to refer to authentication
mechanisms that supplement or replace the KEY RRs of DNSsec.
Five Authentication Service types are defined: DNSsec, Kerberos IV,
Kerberos V, Network Information Service (NIS+), and Radius.
Watson [Page 1]
Internet DRAFT DNSsec Authentication Referral November 1997
1. Introduction
Domain Name System Security [DNSSEC] extends the Domain Name System
(DNS) [RFC1034, RFC1035] to provide for data origin authentication,
public key distribution, and query and transaction authentication,
all based on public key cryptography and public key based digital
signatures. In many organizations, it is desirable to provide a
centralized source for authentication data, especially in
environments where multiple systems are used (for example, KerberosIV
and NIS+). Systems have been defined for distributing user
information in the DNS name-space [HESIOD], but DNS has traditionally
lacked the security necessary to safely distribute sensitive
authentication information. Authentication Referrals use DNSsec's
authenticated data capabilities to distribute mappings from entities
to authentication mechanisms.
1.1 Keywords Used
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
1.2 Definition of Terms
Service Desiring Authentication (SDA): A service requiring a user to
authenticate before providing access. For example, the login program
on a UNIX host is an SDA.
Authentication Service: A type of authentication system that allows
an SDA to verify the identity of a Client communicating with the SDA.
Services are typically accessed using an Authentication Server such
as a KerberosIV or Radius server. In a referral, both the type of
authentication service and the server address are provided.
Client: An entity that wishes to connect to a service, in particular,
to an SDA. Clients are identified using a unique DNS Fully Qualified
Domain Name (FQDN), which contains records providing information on
verifying authentication. Authentication Client may refer to both
humans and hosts in this document.
Authentication Username: In the event that an Authentication Service
is used, the Username may differ from the Client's FQDN in DNS.
Authentication Realm: Some distributed authentication systems allow
for multiple "realms" in which authentication takes place. Realms
typically represent a set of identities and services over which a
single authority is responsible for authentication. Where
appropriate, referrals contain the name of the realm against which
Watson [Page 2]
Internet DRAFT DNSsec Authentication Referral November 1997
they should be made.
Authentication Server: Many authentication systems rely on a
centralized database, which may be found on the Authentication
Server. This database can be identified using the DNS FQDN for the
host. It is assumed that the Authentication Service type will
provide all other information necessary to communicate with the
Authentication Server.
1.3 Authentication in DNSsec
DNSsec provides a mechanism for the authentication of entities it
describes via KEY records containing public keys. This is adequate
for IP Security [IPSEC] and other key-based protocols (such as Secure
Shell [SSH]), but it is not useful for individual user
authentication. Typically such an authentication process involves
the encryption of data using the Client's public key (extracted from
DNSsec), which must then be decrypted by the Client and returned in
some other form (often encrypted with the SDA's public key to protect
both the challenge and the response). Users may be reluctant to
replace their traditional alpha-numeric password with 514-bit private
keys and then perform computation-intensive key manipulation and
signature-operations in their heads. While devices are available
that perform this function in a more accessible manner, they are not
yet mainstream, and a standard has not yet been proposed for
interaction between these devices and DNSsec-based authentication
systems.
Existing distributed authentication systems commonly rely on a
password (shared secret) or a variable challenge-response mechanism
using a system-specific protocol. For example, both KerberosIV
[KERBEROSIV] and Radius [RADIUS] use protocols employing different
packet formats and privacy mechanisms. Because DNS was designed as a
publicly accessible distributed database, no mechanism for the
distribution of private data is provided, which makes the inclusion
of password data in the system both difficult and inappropriate.
The AR resource record (RR type TBD) allows DNSsec to refer an SDA to
an Authentication Service when direct authentication based on the KEY
RR cannot be used.
2. Authentication Referral Resource Record Format
To provide storage for authentication referral information, a new RR
type is defined with the mnemonic AR. More than one AR RR MAY exist
in an RRset; the RRset MUST contain the complete list of
authentication mechanisms allowed for the DNS name.
Watson [Page 3]
Internet DRAFT DNSsec Authentication Referral November 1997
2.1 Record Format
NAME The domain name of the entity to be authenticated.
TYPE AR (TBD)
CLASS IN (HS may also be appropriate)
TTL (as appropriate)
RdLen (variable)
RDATA
Field Name Data Type Notes
------------------------ ----------- -------------------------
Authentication Server dname FQDN of the server that
will provide
authentication data
Authentication Realm dname Realm in which
authentication occurs
Authentication Service 16-bit int Authentication Service
Type as defined in 2.3
Username Length 16-bit int Length of Authentication
Username string in octets
Authentication Username 8-bit int[] UTF-8 encoded name whose
use is defined by the
service type.
Other Data undefined Ignore any following
RDATA
All integer values are stored in network byte order. The
Authentication Username field is an octet stream of length Username
Length.
Meaning of Authentication Realm, Authentication Server,
Authentication Username are specific to each Authentication Service
type.
2.2 Text Representation
A simple text representation for the AR RR might be:
NAME. IN AR [Server] [Realm] [AuthMnemonic] [Username]
2.3 Authentication Service Types
Different Authentication Services types will be assigned numeric
value. New services MUST be registered with IANA.* A mnemonic is
associated with each type to simplify textual representation.
Watson [Page 4]
Internet DRAFT DNSsec Authentication Referral November 1997
Value Mnemonic Authentication Service Name
------ ----------- ---------------------------
0 DNSSEC DNSsec
1 KERBEROS_V4 Kerberos IV
2 KERBEROS_V5 Kerberos V
3 RADIUS Radius
4 NISPLUS NIS+
* A method for registration will be described in detail in a later
version of this document.
2.3.1 DNSsec Referral
It may be desirable to refer authentication to another FQDN. For
example, an organization may have several user zones defined, but one
Client may exist in several of them. Rather than requiring separate
AR RRs, authentication may be forwarded to one canonical AR RR
containing other useful data, or to a record with a KEY RR. Some
fields defined across the AR record are not used:
Field Name Value
------------------------ ----------------------------------
Authentication Server (empty)
Authentication Realm (empty)
Authentication Service 0 (DNSSEC)
Username Length (as appropriate)
Authentication Username FQDN of the entity referred to
When using DNSsec referrals, it is important to avoid referral loops.
The appropriate interpretation order of coexisting KEY and AR records
is discussed in section 3. Referrals may point to either another AR
record or a record with authentication KEYs. If a DNSsec referral
record points to a non-existent name or no authentication information
is available at that name, the authentication MUST fail.
2.3.1.1 DNSsec Referral Example
TYPE AR (TBD)
CLASS IN
TTL 3600
RdLen (as appropriate)
Watson [Page 5]
Internet DRAFT DNSsec Authentication Referral November 1997
RDATA
Field Name Value
------------------------ ----------------------------------
Authentication Server (empty)
Authentication Realm (empty)
Authentication Service 0 (DNSSEC)
Username Length 19
Authentication Username rnw.andrew.cmu.edu.
A textual representation of this record in zone USER.WATSON.ORG would
appears as:
ROBERT IN AR (. . DNSSEC "rnw.andrew.cmu.edu.")
2.3.2 Kerberos IV Referral
The Authentication Username is a "principal.instance" pair where
instance may be alphanumeric, null, or the wildcard "*". For
authentication against user robert in realm WATSON.ORG, an
appropriate Authentication Username would be "robert.", indicating
that no instance is to be used. To require authentication against
another instance, the form "robert.admin" is appropriate. In some
circumstances, a wild-card Username entry might be used, "robert.*",
indicating that the Client MAY be prompted for a specific instance.
Field Name Value
----------------------- --------------------------------------
Authentication Server Kerberos IV Server
Authentication Realm Kerberos IV Realm
Authentication Service 1 (Kerberos IV)
Username Length (length of Username in octets)
Authentication Username Kerberos IV principal.instance
2.3.2.1 Kerberos IV Referral Example
TYPE AR (TBD)
CLASS IN
TTL 3600
RdLen (as appropriate)
Watson [Page 6]
Internet DRAFT DNSsec Authentication Referral November 1997
RDATA
Field Name Value
----------------------- ----------------------
Authentication Server KERBEROS.WATSON.ORG.
Authentication Realm WATSON.ORG.
Authentication Service 1 (KERBEROS_V4)
Username Length 12
Authentication Username robert.admin
A textual representation of this record in zone USER.WATSON.ORG would
appear as:
ROBERT IN AR (KERBEROS.WATSON.ORG. WATSON.ORG.
KERBEROS_V4 "robert.admin")
2.3.3. Kerberos V Referral
The specifics of this type will be specified in a future draft. It
is expected that Kerberos V referrals will be almost identical to
Kerberos IV, but with the "." principal/instance separator replaced
with a "/".
2.3.4 Radius Referral
Field Name Value
----------------------- ---------------------------------
Authentication Server Radius Server
Authentication Realm (empty)
Authentication Service 3 (RADIUS)
Username Length (as appropriate)
Authentication Username Radius Username
2.3.4.1 Radius Referral Example
TYPE AR (TBD)
CLASS IN
TTL 3600
RdLen (as appropriate)
Watson [Page 7]
Internet DRAFT DNSsec Authentication Referral November 1997
RDATA
Field Name Value
----------------------- ----------------------
Authentication Server RADIUS.WATSON.ORG.
Authentication Realm (empty)
Authentication Service 5 (RADIUS)
Username Length 6
Authentication Username robert
A textual representation of this record in zone USER.WATSON.ORG would
appear as:
ROBERT IN AR (RADIUS.WATSON.ORG. .
RADIUS "robert")
2.3.5 NIS+ Referral
NIS+ referral will be documented in a separate document. Due to the
complex interactions between NIS and DNS, there are additional
concerns that must be addressed in greater detail than is appropriate
here.
2.4 DNS Server Handling of the AR Resource Record
When returning an AR RR as part of an RRset, a DNS server MAY include
Additional Records [RFC1034: Section 3.7] that it anticipates the SDA
requires.
3. AR Resource Record Evaluation
When performing a lookup on a Client's DNS entry, a signed RRset is
returned containing KEY RRs, SIG RRs, other data, and possibly an AR
RR. If KEY RRs are present and are permitted for use in user
authentication, public/private key authentication may take place.
Alternatively, the SDA may choose a different authentication
mechanism from the list of AR RRs.
3.1 Authentication Rules
Multiple AR RRs of different Authentication Service types may exist.
Similarly, multiple RRs of the same type may exist in an RRset. When
multiple RRs are returned, the SDA must select some subset of these
to try. A combination of local policy and and the desire for load
balancing determines the correct use of these RRs.
Where multiple AR RRs of different Authentication Service type exist,
one of the available Services SHOULD be selected. This choice could
Watson [Page 8]
Internet DRAFT DNSsec Authentication Referral November 1997
be made by local site policy (i.e., only to accept authentication by
Kerberos, or to not allow AR referral to another DNSsec name), or
with Client interaction (the user is prompted for the mechanism they
wish to authenticate against). If one Authentication Service fails,
the choice to retry against the same service or against different
Services should be made in accordance with local security policy.
Where multiple RRs with the same Authentication Service Type exist
but different Authentication Realm or Username are present, the SDA
should make a choice in accordance with local site policy. For
example, a site might choose only to accept authentication to their
own Kerberos realm.
Load balancing is desirable in the event that multiple RRs with the
same Authentication Realm, Authentication Service, and Username are
present. Such sets of related AR RRs may be considered to be
redundant records. DNS round-robin may be relied upon to reorder
them.
3.1.1 Successful Authentication
If the chain of signatures validates the initial Client records as
well as any further records referenced if a DNSsec referral is
performed, an authentication attempt MAY be performed. If an
attempted authentication succeeds, the SDA MUST accept the
authentication as valid.
3.1.2 Failure in Authentication
If any break in the signature chain occurs in DNSsec verification of
the records required for authentication, the authentication SHOULD
fail. If alternate mechanisms exist for authenticating the
Authentication Server, they MAY be used.
If an Authentication Service is selected, and the authentication
fails for non-technical reasons [different word?], then the
authentication MUST fail. If a technical failure occurs (such as
being unable to contact the Authentication Server), the SDA MAY
select another AR record to attempt or MAY retry on the same server.
If no further AR records are present and any retries have also
failed, then the authentication MUST fail.
4. Security Considerations
It is expected that some system of access control will be used to
determine what, if any, services are provided to the authenticated
Client.
Watson [Page 9]
Internet DRAFT DNSsec Authentication Referral November 1997
4.1 DNSsec Use
Spoofing of AR RRs could result in unauthorized authentication.
DNSsec MUST be used to verify the authenticity of the AR RRs, as well
as the chain to the DNS root. For example, if an AR refers to
Kerberos IV, DNSsec MUST be used to verify the retrieval of the
Client's AR record, and the retrieval of the Kerberos IV Server's IP
address from Authentication Server FQDN.
4.2 The Weakest Link
While DNSsec provides strong cryptography to protect data
authenticity and to allow expiration, many distributed security
mechanisms are not as strong. For example, while an AR record may be
valid, an NIS server connection may be spoofed, hijacked,
eavesdropped, etc.
4.3 Local Site Policy
Local site policy is relied upon for a number of key decisions in the
authentication process. For example, before attempting to follow an
AR chain, the SDA must first confirm that the initial name provided
is allowed to authenticate to it. It must also determine which
authentication service types in the AR list for the name are
appropriate for use. An SDA MAY choose not to accept authenticatino
to a weak Authentication Service. The definition of weak SHOULD be
defined in a local site policy.
A site might accept initial attempts at authentication to
*.user.watson.org. On a successful and verified referral, it might
then be willing to accept authentication against any strong
Authentication Service (e.g., KerberosIV or KerberosV), but not
against weaker services (e.g., NIS).
If AR information can be verified externally, do so. For example, if
Kerberos IV server to realm mapping information exists in a local
krb.conf, consistency should be verified.
Correct logging practice, as well as approaches for dealing with
various types of failures given the varied mechanisms provided may
also involve significant local determination. All authentication
events SHOULD be logged. Selective reporting of errors to the Client
may also improve security.
Watson [Page 10]
Internet DRAFT DNSsec Authentication Referral November 1997
5. References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and
Facilities,'' RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1034, ISI, November 1987.
[DNSSEC] D. Eastlake, C. Kaufman, ``Domain System Security
Extensions,'' RFC 2065, CyberCash & Irix, January 1997.
[HESIOD] S. Dryer, ``The Hesiod Name Server,'' MIT, January 1988.
[IPSEC] R. Atkinson, ``Security Architecture for the Internet
Protocol,'' RFC 1825, Navy Research Laboratory, August
1995.
[SSH] M. Ylonen, T. Kivinen, M. Saarinen, ``SSH Transport Layer
Protocol,'' draft-ietf-secsh-transport-02.txt, SSH,
October 1997.
[KERBEROSIV] S. Miller, B. Neuman, J. Schiller, J. Saltzer, ``Kerberos
Authentication and Authorization System,'' MIT, December
1988.
[RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, ``Remote
Authentication Dial In User Service (RADIUS),'' RFC 2138,
April 1997.
6. Author's Address
Robert Watson
Carnegie Mellon University
SMC 4105
PO Box 3015
Pittsburgh, PA 15230
Phone: (412) 862-2696
Email: robert+ietf@cyrus.watson.org
Watson [Page 11]