< draft-ietf-dnssec-secext2-06.txt   draft-ietf-dnssec-secext2-07.txt >
DNS Security Working Group Donald E. Eastlake 3rd DNS Security Working Group Donald E. Eastlake 3rd
INTERNET-DRAFT IBM INTERNET-DRAFT IBM
OBSOLETES RFC 2065 OBSOLETES RFC 2065
UPDATES RFCs 1034, 1035, and 2181 UPDATES RFCs 1034, 1035, and 2181
Expires: May 1999 November 1998 Expires: June 1999 December 1998
Domain Name System Security Extensions Domain Name System Security Extensions
------ ---- ------ -------- ---------- ------ ---- ------ -------- ----------
Status of This Document Status of This Document
This draft, file name draft-ietf-dnssec-secext2-06.txt, is intended This draft, file name draft-ietf-dnssec-secext2-07.txt, is intended
to become a Proposed Standard RFC obsoleting Proposed Standard RFC to become a Proposed Standard RFC obsoleting Proposed Standard RFC
2065. Distribution of this document is unlimited. Comments should be 2065. Distribution of this document is unlimited. Comments should be
sent to the DNS Security Working Group mailing list <dns- sent to the DNS Security Working Group mailing list <dns-
security@tis.com> or to the author. security@tis.com> or to the author.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
other documents at any time. It is not appropriate to use Internet- other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.'' ``working draft'' or ``work in progress.''
To view the entire list of current Internet-Drafts, please check the To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
[[changed from previous draft: add IANA Considerations section, [[changed from draft 5 to draft 6: add IANA Considerations section,
update dates and file name, update author info, update references update dates and file name, update author info, update references
where new documents have superceded those previously referenced, add where new documents have superceded those previously referenced, add
reference to RFC 2119, clarify wording, minor change at 4.1.5 to reference to RFC 2119, clarify wording, minor change at 4.1.5 to
explain why modular time does not induce a security flaw, clarify explain why modular time does not induce a security flaw, clarify
that the zone key for a secure subzone need not be included at the that the zone key for a secure subzone need not be included at the
leaf node in the superzone, specify that algorithm 254 OIDs are BER leaf node in the superzone, specify that algorithm 254 OIDs are BER
encoded, add algorithm 253 for domain name encoded private encoded, add algorithm 253 for domain name encoded private
algorithm]] algorithm]] [[changed from draft 6 to draft 7: tweak IANA
Considerations section and add reference to RFC 2434, update author
info]]
Abstract Abstract
Extensions to the Domain Name System (DNS) are described that provide Extensions to the Domain Name System (DNS) are described that provide
data integrity and authentication to security aware resolvers and data integrity and authentication to security aware resolvers and
applications through the use of cryptographic digital signatures. applications through the use of cryptographic digital signatures.
These digital signatures are included in secured zones as resource These digital signatures are included in secured zones as resource
records. Security can also be provided through non-security aware records. Security can also be provided through non-security aware
DNS servers in some cases. DNS servers in some cases.
skipping to change at page 3, line 7 skipping to change at page 3, line 7
Charlie Kaufman Charlie Kaufman
Edward Lewis Edward Lewis
Thomas Narten Thomas Narten
Radia J. Perlman Radia J. Perlman
Jeffrey I. Schiller Jeffrey I. Schiller
Steven (Xunhua) Wang Steven (Xunhua) Wang
Brian Wellington Brian Wellington
Table of Contents Table of Contents
Status of This Document....................................1 Status of This Document....................................1
Abstract...................................................2 Abstract...................................................2
Acknowledgments............................................2 Acknowledgments............................................2
Table of Contents..........................................3 Table of Contents..........................................3
1. Overview of Contents....................................5 1. Overview of Contents....................................5
2. Overview of the DNS Extensions..........................6 2. Overview of the DNS Extensions..........................6
2.1 Services Not Provided..................................6 2.1 Services Not Provided..................................6
2.2 Key Distribution.......................................6 2.2 Key Distribution.......................................6
skipping to change at page 41, line 22 skipping to change at page 41, line 22
change. change.
A number of precautions in DNS implementation have evolved over the A number of precautions in DNS implementation have evolved over the
years to harden the insecure DNS against spoofing. These precautions years to harden the insecure DNS against spoofing. These precautions
should not be abandoned but should be considered to provide should not be abandoned but should be considered to provide
additional protection in case of key compromise in secure DNS. additional protection in case of key compromise in secure DNS.
11. IANA Considerations 11. IANA Considerations
KEY RR flag bits 2 and 8-11 and all flag extension field bits can be KEY RR flag bits 2 and 8-11 and all flag extension field bits can be
assigned by IETF consensus. The remaining values of the NAMTYP flag assigned by IETF consensus as defined in RFC 2434. The remaining
field and flag bits 4 and 5 (which could conceivably become an values of the NAMTYP flag field and flag bits 4 and 5 (which could
extension of the NAMTYP field) can only be assigned by an IETF conceivably become an extension of the NAMTYP field) can only be
standards action. assigned by an IETF Standards Action [RFC 2434].
Algorithm numbers 5 through 251 are available for assignment should Algorithm numbers 5 through 251 are available for assignment should
sufficient reason arise. However, the designation of a new algorithm sufficient reason arise. However, the designation of a new algorithm
could have a major impact on interoperability and requires an IETF could have a major impact on interoperability and requires an IETF
standards action. The existence of the private algorithm types 253 Standards Action [RFC 2434]. The existence of the private algorithm
and 254 should satify most needs for private or proprietary types 253 and 254 should satify most needs for private or proprietary
algorithms. algorithms.
Additional values of the Protocol Octet (5-254) can be assigned by Additional values of the Protocol Octet (5-254) can be assigned by
IETF consensus. IETF Consensus [RFC 2434].
The meaning of the first bit of the NXT RR "type bit map" being a one The meaning of the first bit of the NXT RR "type bit map" being a one
can only be assigned by a standards action. can only be assigned by a standards action.
References References
[RFC 1033] - M. Lottor, "Domain Administrators Operations Guide", [RFC 1033] - M. Lottor, "Domain Administrators Operations Guide",
November 1987. November 1987.
[RFC 1034] - P. Mockapetris, "Domain Names - Concepts and [RFC 1034] - P. Mockapetris, "Domain Names - Concepts and
skipping to change at page 42, line 35 skipping to change at page 42, line 35
09/03/1996. 09/03/1996.
[RFC 1995] - Masatka Ohta, "Incremental Zone Transfer in DNS", August [RFC 1995] - Masatka Ohta, "Incremental Zone Transfer in DNS", August
1996. 1996.
[RFC 2030] - D. Mills, "Simple Network Time Protocol (SNTP) Version 4 [RFC 2030] - D. Mills, "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", October 1996. for IPv4, IPv6 and OSI", October 1996.
[RFC 2045] - N. Freed & N. Borenstein, "Multipurpose Internet Mail [RFC 2045] - N. Freed & N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies", Extensions (MIME) Part One: Format of Internet Message Bodies",
November 1996. (xxx update?) November 1996.
[RFC 2065] - Donald Eastlake 3rd, Charles Kaufman, "Domain Name [RFC 2065] - Donald Eastlake 3rd, Charles Kaufman, "Domain Name
System Security Extensions", 01/03/1997. System Security Extensions", 01/03/1997.
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
[RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic [RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", 04/21/1997. Updates in the Domain Name System (DNS UPDATE)", 04/21/1997.
[RFC 2137] - Donald Eastlake 3rd, "Secure Domain Name System Dynamic [RFC 2137] - Donald Eastlake 3rd, "Secure Domain Name System Dynamic
Update", 04/21/1997. Update", 04/21/1997.
[RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS [RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS
Specification", July 1997. Specification", July 1997.
[RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", October 1998.
draft-ietf-dnssec-rsa-*.txt, D. Eastlake, "RSA/MD5 KEYs and SIGs in draft-ietf-dnssec-rsa-*.txt, D. Eastlake, "RSA/MD5 KEYs and SIGs in
the Domain Name System (DNS)". the Domain Name System (DNS)".
draft-ietf-dnssec-dhk-*.txt, D. Eastlake, "Storage of Diffie-Hellman draft-ietf-dnssec-dhk-*.txt, D. Eastlake, "Storage of Diffie-Hellman
Keys in the Domain Name System (DNS)". Keys in the Domain Name System (DNS)".
draft-ietf-dnssec-dss-*.txt, D. Eastlake, "DSA KEYs and SIGs in the draft-ietf-dnssec-dss-*.txt, D. Eastlake, "DSA KEYs and SIGs in the
Domain Name System (DNS)". Domain Name System (DNS)".
draft-ietf-dsnssec-certs-*.txt, D. Eastlake, O. Gudmundsson, "Storing draft-ietf-dsnssec-certs-*.txt, D. Eastlake, O. Gudmundsson, "Storing
skipping to change at page 44, line 9 skipping to change at page 44, line 9
draft-ietf-dnssec-secops-*.txt, D. Eastlake, "DNS Operational draft-ietf-dnssec-secops-*.txt, D. Eastlake, "DNS Operational
Security Considerations". Security Considerations".
[RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting.
Author's Address Author's Address
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
IBM IBM
318 Acton Street 65 Shindegan Hill Road
Carlisle, MA 01741 USA RR #1
Carmel, NY 10512
Telephone: +1-914-784-7913 Telephone: +1-914-784-7913 (w)
+1-978-287-4877 +1-914-276-2668 (h)
fax: +1-978-371-7148 fax: +1-914-784-3833 (w-fax)
email: dee3@us.ibm.com email: dee3@us.ibm.com
Expiration and File Name Expiration and File Name
This draft expires May 1999. This draft expires June 1999.
Its file name is draft-ietf-dnssec-secext2-06.txt. Its file name is draft-ietf-dnssec-secext2-07.txt.
Appendix A: Base 64 Encoding Appendix A: Base 64 Encoding
The following encoding technique is taken from [RFC 2045] by N. The following encoding technique is taken from [RFC 2045] by N.
Borenstein and N. Freed. It is reproduced here in an edited form for Borenstein and N. Freed. It is reproduced here in an edited form for
convenience. convenience.
A 65-character subset of US-ASCII is used, enabling 6 bits to be A 65-character subset of US-ASCII is used, enabling 6 bits to be
represented per printable character. (The extra 65th character, "=", represented per printable character. (The extra 65th character, "=",
is used to signify a special processing function.) is used to signify a special processing function.)
skipping to change at page 48, line 40 skipping to change at page 48, line 40
9. It was clarified that the presence of the AD bit in a response 9. It was clarified that the presence of the AD bit in a response
does not apply to the additional information section or to glue does not apply to the additional information section or to glue
address or delegation point NS RRs. The AD bit only indicates address or delegation point NS RRs. The AD bit only indicates
that the answer and authority sections of the response are that the answer and authority sections of the response are
authoritative. authoritative.
10. It is now required that KEY RRs and NXT RRs be signed only with 10. It is now required that KEY RRs and NXT RRs be signed only with
zone-level keys. zone-level keys.
11. Add IANA Considerations section. 11. Add IANA Considerations section and references to RFC 2434.
Appendix C: Key Tag Calculation Appendix C: Key Tag Calculation
The key tag field in the SIG RR is just a means of more efficiently The key tag field in the SIG RR is just a means of more efficiently
selecting the correct KEY RR to use when there is more than one KEY selecting the correct KEY RR to use when there is more than one KEY
RR candidate available, for example, in verifying a signature. It is RR candidate available, for example, in verifying a signature. It is
possible for more than one candidate key to have the same tag, in possible for more than one candidate key to have the same tag, in
which case each must be tried until one works or all fail. The which case each must be tried until one works or all fail. The
following reference implementation of how to calculate the Key Tag, following reference implementation of how to calculate the Key Tag,
for all algorithms other than algorithm 1, is in ANSI C. It is coded for all algorithms other than algorithm 1, is in ANSI C. It is coded
 End of changes. 15 change blocks. 
21 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/