idnits 2.17.1 draft-ietf-dnssec-ar-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 148 has weird spacing: '... Server dna...' == Line 238 has weird spacing: '...sername rnw.a...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1997) is 9630 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Server' is mentioned on line 175, but not defined == Missing Reference: 'Realm' is mentioned on line 175, but not defined == Missing Reference: 'AuthMnemonic' is mentioned on line 175, but not defined == Missing Reference: 'Username' is mentioned on line 175, but not defined -- Duplicate reference: RFC1034, mentioned in 'RFC1035', was also mentioned in 'RFC1034'. ** Obsolete normative reference: RFC 2065 (ref. 'DNSSEC') (Obsoleted by RFC 2535) -- Possible downref: Non-RFC (?) normative reference: ref. 'HESIOD' ** Obsolete normative reference: RFC 1825 (ref. 'IPSEC') (Obsoleted by RFC 2401) == Outdated reference: A later version (-24) exists of draft-ietf-secsh-transport-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'KERBEROSIV' ** Obsolete normative reference: RFC 2138 (ref. 'RADIUS') (Obsoleted by RFC 2865) Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name System Security Working Group R. Watson 3 INTERNET DRAFT November 1997 4 Expires in six months 6 DNSsec Authentication Referral Record (AR) 8 Status of this Document 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 Authentication Referrals allow DNS to refer to authentication 29 mechanisms that supplement or replace the KEY RRs of DNSsec. 31 Five Authentication Service types are defined: DNSsec, Kerberos IV, 32 Kerberos V, Network Information Service (NIS+), and Radius. 34 Internet DRAFT DNSsec Authentication Referral November 1997 36 1. Introduction 38 Domain Name System Security [DNSSEC] extends the Domain Name System 39 (DNS) [RFC1034, RFC1035] to provide for data origin authentication, 40 public key distribution, and query and transaction authentication, 41 all based on public key cryptography and public key based digital 42 signatures. In many organizations, it is desirable to provide a 43 centralized source for authentication data, especially in 44 environments where multiple systems are used (for example, KerberosIV 45 and NIS+). Systems have been defined for distributing user 46 information in the DNS name-space [HESIOD], but DNS has traditionally 47 lacked the security necessary to safely distribute sensitive 48 authentication information. Authentication Referrals use DNSsec's 49 authenticated data capabilities to distribute mappings from entities 50 to authentication mechanisms. 52 1.1 Keywords Used 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119. 58 1.2 Definition of Terms 60 Service Desiring Authentication (SDA): A service requiring a user to 61 authenticate before providing access. For example, the login program 62 on a UNIX host is an SDA. 64 Authentication Service: A type of authentication system that allows 65 an SDA to verify the identity of a Client communicating with the SDA. 66 Services are typically accessed using an Authentication Server such 67 as a KerberosIV or Radius server. In a referral, both the type of 68 authentication service and the server address are provided. 70 Client: An entity that wishes to connect to a service, in particular, 71 to an SDA. Clients are identified using a unique DNS Fully Qualified 72 Domain Name (FQDN), which contains records providing information on 73 verifying authentication. Authentication Client may refer to both 74 humans and hosts in this document. 76 Authentication Username: In the event that an Authentication Service 77 is used, the Username may differ from the Client's FQDN in DNS. 79 Authentication Realm: Some distributed authentication systems allow 80 for multiple "realms" in which authentication takes place. Realms 81 typically represent a set of identities and services over which a 82 single authority is responsible for authentication. Where 83 appropriate, referrals contain the name of the realm against which 85 Internet DRAFT DNSsec Authentication Referral November 1997 87 they should be made. 89 Authentication Server: Many authentication systems rely on a 90 centralized database, which may be found on the Authentication 91 Server. This database can be identified using the DNS FQDN for the 92 host. It is assumed that the Authentication Service type will 93 provide all other information necessary to communicate with the 94 Authentication Server. 96 1.3 Authentication in DNSsec 98 DNSsec provides a mechanism for the authentication of entities it 99 describes via KEY records containing public keys. This is adequate 100 for IP Security [IPSEC] and other key-based protocols (such as Secure 101 Shell [SSH]), but it is not useful for individual user 102 authentication. Typically such an authentication process involves 103 the encryption of data using the Client's public key (extracted from 104 DNSsec), which must then be decrypted by the Client and returned in 105 some other form (often encrypted with the SDA's public key to protect 106 both the challenge and the response). Users may be reluctant to 107 replace their traditional alpha-numeric password with 514-bit private 108 keys and then perform computation-intensive key manipulation and 109 signature-operations in their heads. While devices are available 110 that perform this function in a more accessible manner, they are not 111 yet mainstream, and a standard has not yet been proposed for 112 interaction between these devices and DNSsec-based authentication 113 systems. 115 Existing distributed authentication systems commonly rely on a 116 password (shared secret) or a variable challenge-response mechanism 117 using a system-specific protocol. For example, both KerberosIV 118 [KERBEROSIV] and Radius [RADIUS] use protocols employing different 119 packet formats and privacy mechanisms. Because DNS was designed as a 120 publicly accessible distributed database, no mechanism for the 121 distribution of private data is provided, which makes the inclusion 122 of password data in the system both difficult and inappropriate. 124 The AR resource record (RR type TBD) allows DNSsec to refer an SDA to 125 an Authentication Service when direct authentication based on the KEY 126 RR cannot be used. 128 2. Authentication Referral Resource Record Format 130 To provide storage for authentication referral information, a new RR 131 type is defined with the mnemonic AR. More than one AR RR MAY exist 132 in an RRset; the RRset MUST contain the complete list of 133 authentication mechanisms allowed for the DNS name. 135 Internet DRAFT DNSsec Authentication Referral November 1997 137 2.1 Record Format 139 NAME The domain name of the entity to be authenticated. 140 TYPE AR (TBD) 141 CLASS IN (HS may also be appropriate) 142 TTL (as appropriate) 143 RdLen (variable) 144 RDATA 146 Field Name Data Type Notes 147 ------------------------ ----------- ------------------------- 148 Authentication Server dname FQDN of the server that 149 will provide 150 authentication data 151 Authentication Realm dname Realm in which 152 authentication occurs 153 Authentication Service 16-bit int Authentication Service 154 Type as defined in 2.3 155 Username Length 16-bit int Length of Authentication 156 Username string in octets 157 Authentication Username 8-bit int[] UTF-8 encoded name whose 158 use is defined by the 159 service type. 160 Other Data undefined Ignore any following 161 RDATA 163 All integer values are stored in network byte order. The 164 Authentication Username field is an octet stream of length Username 165 Length. 167 Meaning of Authentication Realm, Authentication Server, 168 Authentication Username are specific to each Authentication Service 169 type. 171 2.2 Text Representation 173 A simple text representation for the AR RR might be: 175 NAME. IN AR [Server] [Realm] [AuthMnemonic] [Username] 177 2.3 Authentication Service Types 179 Different Authentication Services types will be assigned numeric 180 value. New services MUST be registered with IANA.* A mnemonic is 181 associated with each type to simplify textual representation. 183 Internet DRAFT DNSsec Authentication Referral November 1997 185 Value Mnemonic Authentication Service Name 186 ------ ----------- --------------------------- 187 0 DNSSEC DNSsec 188 1 KERBEROS_V4 Kerberos IV 189 2 KERBEROS_V5 Kerberos V 190 3 RADIUS Radius 191 4 NISPLUS NIS+ 193 * A method for registration will be described in detail in a later 194 version of this document. 196 2.3.1 DNSsec Referral 198 It may be desirable to refer authentication to another FQDN. For 199 example, an organization may have several user zones defined, but one 200 Client may exist in several of them. Rather than requiring separate 201 AR RRs, authentication may be forwarded to one canonical AR RR 202 containing other useful data, or to a record with a KEY RR. Some 203 fields defined across the AR record are not used: 205 Field Name Value 206 ------------------------ ---------------------------------- 207 Authentication Server (empty) 208 Authentication Realm (empty) 209 Authentication Service 0 (DNSSEC) 210 Username Length (as appropriate) 211 Authentication Username FQDN of the entity referred to 213 When using DNSsec referrals, it is important to avoid referral loops. 214 The appropriate interpretation order of coexisting KEY and AR records 215 is discussed in section 3. Referrals may point to either another AR 216 record or a record with authentication KEYs. If a DNSsec referral 217 record points to a non-existent name or no authentication information 218 is available at that name, the authentication MUST fail. 220 2.3.1.1 DNSsec Referral Example 222 NAME ROBERT.USER.WATSON.ORG. 223 TYPE AR (TBD) 224 CLASS IN 225 TTL 3600 226 RdLen (as appropriate) 228 Internet DRAFT DNSsec Authentication Referral November 1997 230 RDATA 232 Field Name Value 233 ------------------------ ---------------------------------- 234 Authentication Server (empty) 235 Authentication Realm (empty) 236 Authentication Service 0 (DNSSEC) 237 Username Length 19 238 Authentication Username rnw.andrew.cmu.edu. 240 A textual representation of this record in zone USER.WATSON.ORG would 241 appears as: 243 ROBERT IN AR (. . DNSSEC "rnw.andrew.cmu.edu.") 245 2.3.2 Kerberos IV Referral 247 The Authentication Username is a "principal.instance" pair where 248 instance may be alphanumeric, null, or the wildcard "*". For 249 authentication against user robert in realm WATSON.ORG, an 250 appropriate Authentication Username would be "robert.", indicating 251 that no instance is to be used. To require authentication against 252 another instance, the form "robert.admin" is appropriate. In some 253 circumstances, a wild-card Username entry might be used, "robert.*", 254 indicating that the Client MAY be prompted for a specific instance. 256 Field Name Value 257 ----------------------- -------------------------------------- 258 Authentication Server Kerberos IV Server 259 Authentication Realm Kerberos IV Realm 260 Authentication Service 1 (Kerberos IV) 261 Username Length (length of Username in octets) 262 Authentication Username Kerberos IV principal.instance 264 2.3.2.1 Kerberos IV Referral Example 266 NAME ROBERT.USER.WATSON.ORG. 267 TYPE AR (TBD) 268 CLASS IN 269 TTL 3600 270 RdLen (as appropriate) 272 Internet DRAFT DNSsec Authentication Referral November 1997 274 RDATA 276 Field Name Value 277 ----------------------- ---------------------- 278 Authentication Server KERBEROS.WATSON.ORG. 279 Authentication Realm WATSON.ORG. 280 Authentication Service 1 (KERBEROS_V4) 281 Username Length 12 282 Authentication Username robert.admin 284 A textual representation of this record in zone USER.WATSON.ORG would 285 appear as: 287 ROBERT IN AR (KERBEROS.WATSON.ORG. WATSON.ORG. 288 KERBEROS_V4 "robert.admin") 290 2.3.3. Kerberos V Referral 292 The specifics of this type will be specified in a future draft. It 293 is expected that Kerberos V referrals will be almost identical to 294 Kerberos IV, but with the "." principal/instance separator replaced 295 with a "/". 297 2.3.4 Radius Referral 299 Field Name Value 300 ----------------------- --------------------------------- 301 Authentication Server Radius Server 302 Authentication Realm (empty) 303 Authentication Service 3 (RADIUS) 304 Username Length (as appropriate) 305 Authentication Username Radius Username 307 2.3.4.1 Radius Referral Example 309 NAME ROBERT.USER.WATSON.ORG. 310 TYPE AR (TBD) 311 CLASS IN 312 TTL 3600 313 RdLen (as appropriate) 315 Internet DRAFT DNSsec Authentication Referral November 1997 317 RDATA 319 Field Name Value 320 ----------------------- ---------------------- 321 Authentication Server RADIUS.WATSON.ORG. 322 Authentication Realm (empty) 323 Authentication Service 5 (RADIUS) 324 Username Length 6 325 Authentication Username robert 327 A textual representation of this record in zone USER.WATSON.ORG would 328 appear as: 330 ROBERT IN AR (RADIUS.WATSON.ORG. . 331 RADIUS "robert") 333 2.3.5 NIS+ Referral 335 NIS+ referral will be documented in a separate document. Due to the 336 complex interactions between NIS and DNS, there are additional 337 concerns that must be addressed in greater detail than is appropriate 338 here. 340 2.4 DNS Server Handling of the AR Resource Record 342 When returning an AR RR as part of an RRset, a DNS server MAY include 343 Additional Records [RFC1034: Section 3.7] that it anticipates the SDA 344 requires. 346 3. AR Resource Record Evaluation 348 When performing a lookup on a Client's DNS entry, a signed RRset is 349 returned containing KEY RRs, SIG RRs, other data, and possibly an AR 350 RR. If KEY RRs are present and are permitted for use in user 351 authentication, public/private key authentication may take place. 352 Alternatively, the SDA may choose a different authentication 353 mechanism from the list of AR RRs. 355 3.1 Authentication Rules 357 Multiple AR RRs of different Authentication Service types may exist. 358 Similarly, multiple RRs of the same type may exist in an RRset. When 359 multiple RRs are returned, the SDA must select some subset of these 360 to try. A combination of local policy and and the desire for load 361 balancing determines the correct use of these RRs. 363 Where multiple AR RRs of different Authentication Service type exist, 364 one of the available Services SHOULD be selected. This choice could 366 Internet DRAFT DNSsec Authentication Referral November 1997 368 be made by local site policy (i.e., only to accept authentication by 369 Kerberos, or to not allow AR referral to another DNSsec name), or 370 with Client interaction (the user is prompted for the mechanism they 371 wish to authenticate against). If one Authentication Service fails, 372 the choice to retry against the same service or against different 373 Services should be made in accordance with local security policy. 375 Where multiple RRs with the same Authentication Service Type exist 376 but different Authentication Realm or Username are present, the SDA 377 should make a choice in accordance with local site policy. For 378 example, a site might choose only to accept authentication to their 379 own Kerberos realm. 381 Load balancing is desirable in the event that multiple RRs with the 382 same Authentication Realm, Authentication Service, and Username are 383 present. Such sets of related AR RRs may be considered to be 384 redundant records. DNS round-robin may be relied upon to reorder 385 them. 387 3.1.1 Successful Authentication 389 If the chain of signatures validates the initial Client records as 390 well as any further records referenced if a DNSsec referral is 391 performed, an authentication attempt MAY be performed. If an 392 attempted authentication succeeds, the SDA MUST accept the 393 authentication as valid. 395 3.1.2 Failure in Authentication 397 If any break in the signature chain occurs in DNSsec verification of 398 the records required for authentication, the authentication SHOULD 399 fail. If alternate mechanisms exist for authenticating the 400 Authentication Server, they MAY be used. 402 If an Authentication Service is selected, and the authentication 403 fails for non-technical reasons [different word?], then the 404 authentication MUST fail. If a technical failure occurs (such as 405 being unable to contact the Authentication Server), the SDA MAY 406 select another AR record to attempt or MAY retry on the same server. 407 If no further AR records are present and any retries have also 408 failed, then the authentication MUST fail. 410 4. Security Considerations 412 It is expected that some system of access control will be used to 413 determine what, if any, services are provided to the authenticated 414 Client. 416 Internet DRAFT DNSsec Authentication Referral November 1997 418 4.1 DNSsec Use 420 Spoofing of AR RRs could result in unauthorized authentication. 421 DNSsec MUST be used to verify the authenticity of the AR RRs, as well 422 as the chain to the DNS root. For example, if an AR refers to 423 Kerberos IV, DNSsec MUST be used to verify the retrieval of the 424 Client's AR record, and the retrieval of the Kerberos IV Server's IP 425 address from Authentication Server FQDN. 427 4.2 The Weakest Link 429 While DNSsec provides strong cryptography to protect data 430 authenticity and to allow expiration, many distributed security 431 mechanisms are not as strong. For example, while an AR record may be 432 valid, an NIS server connection may be spoofed, hijacked, 433 eavesdropped, etc. 435 4.3 Local Site Policy 437 Local site policy is relied upon for a number of key decisions in the 438 authentication process. For example, before attempting to follow an 439 AR chain, the SDA must first confirm that the initial name provided 440 is allowed to authenticate to it. It must also determine which 441 authentication service types in the AR list for the name are 442 appropriate for use. An SDA MAY choose not to accept authenticatino 443 to a weak Authentication Service. The definition of weak SHOULD be 444 defined in a local site policy. 446 A site might accept initial attempts at authentication to 447 *.user.watson.org. On a successful and verified referral, it might 448 then be willing to accept authentication against any strong 449 Authentication Service (e.g., KerberosIV or KerberosV), but not 450 against weaker services (e.g., NIS). 452 If AR information can be verified externally, do so. For example, if 453 Kerberos IV server to realm mapping information exists in a local 454 krb.conf, consistency should be verified. 456 Correct logging practice, as well as approaches for dealing with 457 various types of failures given the varied mechanisms provided may 458 also involve significant local determination. All authentication 459 events SHOULD be logged. Selective reporting of errors to the Client 460 may also improve security. 462 Internet DRAFT DNSsec Authentication Referral November 1997 464 5. References 466 [RFC1034] P. Mockapetris, ``Domain Names - Concepts and 467 Facilities,'' RFC 1034, ISI, November 1987. 469 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 470 Specification,'' RFC 1034, ISI, November 1987. 472 [DNSSEC] D. Eastlake, C. Kaufman, ``Domain System Security 473 Extensions,'' RFC 2065, CyberCash & Irix, January 1997. 475 [HESIOD] S. Dryer, ``The Hesiod Name Server,'' MIT, January 1988. 477 [IPSEC] R. Atkinson, ``Security Architecture for the Internet 478 Protocol,'' RFC 1825, Navy Research Laboratory, August 479 1995. 481 [SSH] M. Ylonen, T. Kivinen, M. Saarinen, ``SSH Transport Layer 482 Protocol,'' draft-ietf-secsh-transport-02.txt, SSH, 483 October 1997. 485 [KERBEROSIV] S. Miller, B. Neuman, J. Schiller, J. Saltzer, ``Kerberos 486 Authentication and Authorization System,'' MIT, December 487 1988. 489 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, ``Remote 490 Authentication Dial In User Service (RADIUS),'' RFC 2138, 491 April 1997. 493 6. Author's Address 495 Robert Watson 496 Carnegie Mellon University 497 SMC 4105 498 PO Box 3015 499 Pittsburgh, PA 15230 501 Phone: (412) 862-2696 503 Email: robert+ietf@cyrus.watson.org