619 lines
22 KiB
Plaintext
619 lines
22 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
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
|
||
|
||
NAME ROBERT.USER.WATSON.ORG.
|
||
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
|
||
|
||
NAME ROBERT.USER.WATSON.ORG.
|
||
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
|
||
|
||
NAME ROBERT.USER.WATSON.ORG.
|
||
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]
|
||
|