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]
