cvs updates from Wed Dec 15 17:45:22 EST 2010

[tridge/bind9.git] / doc / expired / draft-ietf-dnssec-ar-00.txt

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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f