summaryrefslogtreecommitdiff
path: root/doc/draft/draft-ietf-dnsext-ad-is-secure-03.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/draft/draft-ietf-dnsext-ad-is-secure-03.txt')
-rw-r--r--doc/draft/draft-ietf-dnsext-ad-is-secure-03.txt278
1 files changed, 0 insertions, 278 deletions
diff --git a/doc/draft/draft-ietf-dnsext-ad-is-secure-03.txt b/doc/draft/draft-ietf-dnsext-ad-is-secure-03.txt
deleted file mode 100644
index 70e805d2..00000000
--- a/doc/draft/draft-ietf-dnsext-ad-is-secure-03.txt
+++ /dev/null
@@ -1,278 +0,0 @@
-
-DNSEXT Working Group Brian Wellington
-INTERNET-DRAFT Olafur Gudmundsson
-<draft-ietf-dnsext-ad-is-secure-03.txt> July 2001
-
-Updates: RFC 2535
-
- Redefinition of DNS AD bit
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- 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.''
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- Comments should be sent to the authors or the DNSEXT WG mailing list
- namedroppers@ops.ietf.org
-
- This draft expires on January 17, 2002.
-
- Copyright Notice
-
- Copyright (C) The Internet Society (2001). All rights reserved.
-
-
-
-Abstract
-
- Based on implementation experience, the current definition of the AD
- bit in the DNS header is not useful. This draft changes the
- specification so that the AD bit is only set on answers where
- signatures have been cryptographically verified.
-
-
-
-
-Expires January 2002 [Page 1]
-
-INTERNET-DRAFT AD bit set on secure answers July 2001
-
-
-1 - Introduction
-
- Familiarity with the DNS system [RFC1035] and DNS security extensions
- [RFC2535] is helpful but not necessary.
-
- As specified in RFC 2535 (section 6.1), the AD bit indicates in a
- response that all the data included in the answer and authority
- portion of the response has been authenticated by the server
- according to the policies of that server. This is not especially
- useful in practice, since a conformant server should never reply with
- data that failed its security policy.
-
- This draft proposes to redefine the AD bit such that it is only set
- if all data in the response has been cryptographically verified.
- Thus, a response containing properly delegated insecure data will not
- have AD set, neither will a response from a server configured without
- DNSSEC keys. As before, data which failed to verify will not be
- returned. An application can then use the value of the AD bit to
- determine if the data is secure or not.
-
-1.1 - Requirements
-
- The key words "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this
- document are to be interpreted as described in RFC2119.
-
-
-1.2 - Updated documents and sections
-
- The definition of the AD bit in RFC2535, Section 6.1, is changed.
-
-2 - Setting of AD bit
-
- Section 6.1 of RFC2535 says:
-
- "The AD bit MUST NOT be set on a response unless all of the RRs in
- the answer and authority sections of the response are either
- Authenticated or Insecure."
-
- The changes are to delete the words "either" and "or Insecure" from
- the sentence.
-
- The replacement text reads:
-
- "The AD bit MUST NOT be set on a response unless all of the RRsets in
- the answer and authority sections of the response are Authenticated."
-
- "The AD bit SHOULD be set if and only if all RRs in the answer
- section and any relevant negative response RRs in that authority
-
-
-
-Expires January 2002 [Page 2]
-
-INTERNET-DRAFT AD bit set on secure answers July 2001
-
-
- section are Authenticated."
-
- AD should be set if and only if all RRs in the answer section, and
- any relevant negative response RRs in the authority section are
- Authenticated.
-
- The AD bit MUST NOT be set on a response unless all of the RRsets in
- the answer and authority sections are Authenticated.
- A resolver MUST NOT blindly trust the AD bit unless it communicates
- with the server over secure transport mechanism or using message
- authentication such as TSIG[RFC2845] or SIG(0)[RFC2931], and the
- resolver policy is that it can trust the server.
-
- Any DNS server supporting the OK bit MUST support this definition of
- the AD bit. A DNS server following this modified specification will
- only set the AD bit when it has cryptographically verified the data
- in the answer. In the case of a primary server for a secure zone,
- the data MAY be considered Authenticated, depending on local policy.
- Secondary servers SHOULD NOT consider data Authenticated unless the
- zone was transfered securely or the data was verified.
-
-3 - Interpretation of the AD bit
-
- A response containing data marked Insecure in the answer or authority
- section will never have the AD bit set. In this case, the resolver
- SHOULD treat the data as Insecure whether or not SIG records are
- present.
-
-4 - Security Considerations:
-
- This document redefines a bit in the DNS header. If a resolver
- trusts the value of the AD bit, it must be sure that the server is
- using the updated definition, which is any server supporting the OK
- bit.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires January 2002 [Page 3]
-
-INTERNET-DRAFT AD bit set on secure answers July 2001
-
-
-5 - IANA Considerations:
-
- None
-
-6 - Acknowledgments:
-
- The following people have provided input on this document: Andreas
- Gustafsson, Bob Halley, Steven Jacob.
-
-References:
-
-[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
- Specification'', STD 13, RFC 1035, November 1987.
-
-[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC
- 2535, March 1999.
-
-[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
- ``Secret Key Transaction Authentication for DNS (TSIG)'', RFC
- 2845, May 2000.
-
-[RFC2931] D. Eastlake, ``DNS Request and Transaction Signatures
- (SIG(0))'', RFC 2931, September 2000.
-
-
-Authors Addresses
-
- Brian Wellington Olafur Gudmundsson
- Nominum Inc.
- 950 Charter Street 3826 Legation Street, NW
- Redwood City, CA, 94063 Washington, DC, 20015
- USA USA
- <Brian.Wellington@nominum.com> <ogud@ogud.com>
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
-
-
-
-Expires January 2002 [Page 4]
-
-INTERNET-DRAFT AD bit set on secure answers July 2001
-
-
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires January 2002 [Page 5]
-