contrib/bind9/doc/draft/draft-baba-dnsext-acl-reqts-01.txt

   1
   2
   3
   4
   5 Internet-Draft                                                   T. Baba
   6 Expires: March 11, 2004                                         NTT Data
   7                                                       September 11, 2003
   8
   9
  10          Requirements for Access Control in Domain Name Systems
  11                    draft-baba-dnsext-acl-reqts-01.txt
  12
  13 Status of this Memo
  14
  15    This document is an Internet-Draft and is subject to all provisions
  16    of Section 10 of RFC2026.
  17
  18    Internet-Drafts are working documents of the Internet Engineering
  19    Task Force (IETF), its areas, and its working groups.  Note that
  20    other groups may also distribute working documents as Internet-
  21    Drafts.
  22
  23    Internet-Drafts are draft documents valid for a maximum of six months
  24    and may be updated, replaced, or obsoleted by other documents at any
  25    time.  It is inappropriate to use Internet-Drafts as reference
  26    material or to cite them other than as "work in progress."
  27
  28    The list of current Internet-Drafts can be accessed at
  29    http://www.ietf.org/1id-abstracts.html
  30
  31    The list of Internet-Draft Shadow Directories can be accessed at
  32    http://www.ietf.org/shadow.html
  33
  34    Distribution of this memo is unlimited.
  35
  36    This Internet-Draft will expire on March 11, 2004.
  37
  38 Abstract
  39
  40    This document describes the requirements for access control
  41    mechanisms in the Domain Name System (DNS), which authenticate
  42    clients and then allow or deny access to resource records in the
  43    zone according to the access control list (ACL).
  44
  45 1. Introduction
  46
  47    The Domain Name System (DNS) is a hierarchical, distributed, highly
  48    available database used for bi-directional mapping between domain
  49    names and IP addresses, for email routing, and for other information
  50    [RFC1034, 1035].  DNS security extensions (DNSSEC) have been defined
  51    to authenticate the data in DNS and provide key distribution services
  52    using SIG, KEY, and NXT resource records (RRs) [RFC2535].
  53
  54
  55
  56 Baba                     Expires March 11, 2004                 [Page 1]
  57 \f
  58 Internet-Draft       DNS Access Control Requirements      September 2003
  59
  60
  61    At the 28th IETF Meeting in Houston in 1993, DNS security design team
  62    started a discussion about DNSSEC and agreed to accept the assumption
  63    that "DNS data is public".  Accordingly, confidentiality for queries
  64    or responses is not provided by DNSSEC, nor are any sort of access
  65    control lists or other means to differentiate inquirers.  However,
  66    about ten years has passed, access control in DNS has been more
  67    important than before.  Currently, new RRs are proposed to add new
  68    functionality to DNS such as ENUM [RFC2916].  Such new RRs may
  69    contain private information.  Thus, DNS access control will be
  70    needed.
  71
  72    Furthermore, with DNS access control mechanism, access from
  73    unauthorized clients can be blocked when they perform DNS name
  74    resolution.  Thus, for example, Denial of Service (DoS) attacks
  75    against a server used by a closed user group can be prevented using
  76    this mechanism if IP address of the server is not revealed by other
  77    sources.
  78
  79    This document describes the requirements for access control
  80    mechanisms in DNS.
  81
  82 2. Terminology
  83
  84    AC-aware client
  85       This is the client that understands the DNS access control
  86       extensions. This client may be an end host which has a stub
  87       resolver, or a cashing/recursive name server which has a
  88       full-service resolver.
  89
  90    AC-aware server
  91       This is the authoritative name server that understands the DNS
  92       access control extensions.
  93
  94    ACE
  95       An Access Control Entry.  This is the smallest unit of access
  96       control policy.  It grants or denies a given set of access
  97       rights to a set of principals.  An ACE is a component of an ACL,
  98       which is associated with a resource.
  99
 100    ACL
 101       An Access Control List.  This contains all of the access control
 102       policies which are directly associated with a particular
 103       resource.  These policies are expressed as ACEs.
 104
 105    Client
 106       A program or host which issues DNS requests and accepts its
 107       responses. A client may be an end host or a cashing/recursive name
 108       server.
 109
 110
 111
 112 Baba                     Expires March 11, 2004                 [Page 2]
 113 \f
 114 Internet-Draft       DNS Access Control Requirements      September 2003
 115
 116
 117    RRset
 118       All resource records (RRs) having the same NAME, CLASS and TYPE
 119       are called a Resource Record Set (RRset).
 120
 121 3. Requirements
 122
 123    This section describes the requirements for access control in DNS.
 124
 125 3.1 Authentication
 126
 127 3.1.1 Client Authentication Mechanism
 128
 129    The AC-aware server must identify AC-aware clients based on IP
 130    address and/or domain name (user ID or host name), and must
 131    authenticate them using strong authentication mechanism such as
 132    digital signature or message authentication code (MAC).
 133
 134    SIG(0) RR [RFC2931] contains a domain name associated with sender's
 135    public key in its signer's name field, and TSIG RR [RFC2845] also
 136    contains a domain name associated with shared secret key in its key
 137    name field.  Each of these domain names can be a host name or a user
 138    name, and can be used as a sender's identifier for access control.
 139    Furthermore, SIG(0) uses digital signatures, and TSIG uses MACs for
 140    message authentication.  These mechanisms can be used to authenticate
 141    AC-aware clients.
 142
 143    Server authentication may be also provided.
 144
 145 3.1.2 End-to-End Authentication
 146
 147    In current DNS model, caching/recursive name servers are deployed
 148    between end hosts and authoritative name servers.  Although
 149    authoritative servers can authenticate caching/recursive name servers
 150    using SIG(0) or TSIG, they cannot authenticate end hosts behind them.
 151    For end-to-end authentication, the mechanism for an end host to
 152    discover the target authoritative name server and directly access to
 153    it bypassing caching/recursive name servers is needed.  For example,
 154    an end host can get the IP addresses of the authoritative name
 155    servers by retrieving NS RRs for the zone via local caching/recursive
 156    name server.
 157
 158    In many enterprise networks, however, there are firewalls that block
 159    all DNS packets other than those going to/from the particular
 160    caching/recursive servers.  To deal with this problem, one can
 161    implement packet forwarding function on the caching/recursive servers
 162    and enable end-to-end authentication via the caching/recursive
 163    servers.
 164
 165
 166
 167
 168 Baba                     Expires March 11, 2004                 [Page 3]
 169 \f
 170 Internet-Draft       DNS Access Control Requirements      September 2003
 171
 172
 173 3.1.3 Authentication Key Retrieval
 174
 175    Keys which are used to authenticate clients should be able to be
 176    automatically retrieved.  The KEY RR is used to store a public key
 177    for a zone or a host that is associated with a domain name.  SIG(0)
 178    RR uses a public key in KEY RR for verifying the signature.  If
 179    DNSSEC is available, the KEY RR would be protected by the SIG RR.
 180    KEY RR or newly defined RR can be used to automatic key retrieval.
 181
 182 3.2 Confidentiality
 183
 184 3.2.1 Data Encryption
 185
 186    To avoid disclosure to eavesdroppers, the response containing the
 187    RRsets which are restricted to access from particular users should be
 188    encrypted.  Currently, no encryption mechanism is specified in DNS.
 189    Therefore, new RRs should be defined for DNS message encryption.
 190    Instead, IPsec [RFC2401] can be used to provide confidentiality if
 191    name server and resolver can set up security associations dynamically
 192    using IPsec API [IPSECAPI] when encryption is required.
 193
 194    In case encryption is applied, entire DNS message including DNS
 195    header should be encrypted to hide information including error code.
 196
 197    Query encryption may be also provided for hiding query information.
 198
 199 3.2.2 Key Exchange
 200
 201    If DNS message encryption is provided, automatic key exchange
 202    mechanism should be also provided.  [RFC2930] specifies a TKEY RR
 203    that can be used to establish and delete shared secret keys used by
 204    TSIG between a client and a server.  With minor extensions, TKEY can
 205    be used to establish shared secret keys used for message encryption.
 206
 207 3.2.3 Caching
 208
 209    The RRset that is restricted to access from particular users must not
 210    be cached.  To avoid caching, the TTL of the RR that is restricted to
 211    access should be set to zero during transit.
 212
 213 3.3 Access Control
 214
 215 3.3.1 Granularity of Access Control
 216
 217    Control of access on a per-user/per-host granularity must be
 218    supported.  Control of access to individual RRset (not just the
 219    entire zone) must be also supported.  However, SOA, NS, SIG, NXT,
 220    KEY, and DS RRs must be publicly accessible to avoid unexpected
 221    results.
 222
 223
 224 Baba                     Expires March 11, 2004                 [Page 4]
 225 \f
 226 Internet-Draft       DNS Access Control Requirements      September 2003
 227
 228
 229 3.3.2 ACL Representation
 230
 231    Access Control List (ACL) format must be standardized so that both
 232    the primary and secondary AC-aware servers can recognize the same
 233    ACL.  Although ACL may appear in or out of zone data, it must be
 234    transferred to the secondary AC-aware server with associated zone
 235    data.  It is a good idea to contain ACL in zone data, because ACL can
 236    be transferred with zone data using existing zone transfer mechanisms
 237    automatically.  However, ACL must not be published except for
 238    authorized secondary master servers.
 239
 240    In zone data master files, ACL should be specified using TXT RRs or
 241    newly defined RRs.  In each access control entry (ACE), authorized
 242    entities (host or user) must be described using domain name (host
 243    name, user name, or IP address in in-addr.arpa/ip6.arpa format).
 244    There may be other access control attributes such as access time.
 245
 246    It must be possible to create publicly readable entries, which may be
 247    read even by unauthenticated clients.
 248
 249 3.3.3 Zone/ACL Transfer
 250
 251    As mentioned above, ACL should be transferred from a primary AC-aware
 252    server to a secondary AC-aware server with associated zone data.
 253    When an AC-aware server receives a zone/ACL transfer request, the
 254    server must authenticate the client, and should encrypt the zone
 255    data and associated ACL during transfer.
 256
 257 3.4 Backward/co-existence Compatibility
 258
 259    Any new protocols to be defined for access control in DNS must be
 260    backward compatible with existing DNS protocol.  AC-aware servers
 261    must be able to process normal DNS query without authentication, and
 262    must respond if retrieving RRset is publicly accessible.
 263
 264    Modifications to root/gTLD/ccTLD name servers are not allowed.
 265
 266 4. Security Considerations
 267
 268    This document discusses the requirements for access control
 269    mechanisms in DNS.
 270
 271 5. Acknowledgements
 272
 273    This work is funded by the Telecommunications Advancement
 274    Organization of Japan (TAO).
 275
 276    The author would like to thank the members of the NTT DATA network
 277    security team for their important contribution to this work.
 278
 279
 280 Baba                     Expires March 11, 2004                 [Page 5]
 281 \f
 282 Internet-Draft       DNS Access Control Requirements      September 2003
 283
 284
 285 6. References
 286
 287    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
 288               STD 13, RFC 1034, November 1987.
 289
 290    [RFC1035]  Mockapetris, P., "Domain names - implementation and
 291               specification", STD 13, RFC 1035, November 1987.
 292
 293    [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
 294               Internet Protocol", RFC 2401, November 1998.
 295
 296    [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
 297               RFC 2535, March 1999.
 298
 299    [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
 300               "Secret Key Transaction Authentication for DNS (TSIG)",
 301               RFC 2845, May 2000.
 302
 303    [RFC2916]  Faltstrom, P., "E.164 number and DNS", RFC 2916,
 304               September 2000.
 305
 306    [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
 307               RFC 2930, September 2000.
 308
 309    [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
 310               (SIG(0)s)", RFC 2931, September 2000.
 311
 312    [IPSECAPI] Sommerfeld, W., "Requirements for an IPsec API",
 313               draft-ietf-ipsp-ipsec-apireq-00.txt, June 2003, Work in
 314               Progress.
 315
 316
 317 Author's Address
 318
 319    Tatsuya Baba
 320    NTT Data Corporation
 321    Research and Development Headquarters
 322    Kayabacho Tower, 1-21-2, Shinkawa, Chuo-ku,
 323    Tokyo 104-0033, Japan
 324
 325    Tel: +81 3 3523 8081
 326    Fax: +81 3 3523 8090
 327    Email: babatt@nttdata.co.jp
 328
 329
 330
 331
 332
 333
 334
 335
 336 Baba                     Expires March 11, 2004                 [Page 6]