< draft-ietf-dnssec-secext-08.txt   draft-ietf-dnssec-secext-09.txt >
DNS Security Working Group Donald E. Eastlake, 3rd
DNS Security Working Group Donald E. Eastlake 3rd
INTERNET-DRAFT CyberCash INTERNET-DRAFT CyberCash
UPDATES RFC 1034, 1035 Charles W. Kaufman UPDATES RFC 1034, 1035 Charles W. Kaufman
Iris Iris
Expires: 8 July 1996 9 January 1996 Expires: 29 July 1996 30 January 1996
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-secext-08.txt, is intended to This draft, file name draft-ietf-dnssec-secext-09.txt, is intended to
be become a Proposed Standard RFC. Distribution of this document is be become a Proposed Standard RFC. Distribution of this document is
unlimited. Comments should be sent to the DNS Security Working Group unlimited. Comments should be sent to the DNS Security Working Group
mailing list <dns-security@tis.com> or to the authors. mailing list <dns-security@tis.com> or to the authors.
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.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
skipping to change at page 3, line 47 skipping to change at page 3, line 47
4. The SIG Resource Record................................19 4. The SIG Resource Record................................19
4.1 SIG RDATA Format......................................19 4.1 SIG RDATA Format......................................19
4.1.1 Signature Data......................................21 4.1.1 Signature Data......................................21
4.1.2 MD5/RSA Algorithm Signature Calculation.............22 4.1.2 MD5/RSA Algorithm Signature Calculation.............22
4.1.3 Zone Transfer (AXFR) SIG............................23 4.1.3 Zone Transfer (AXFR) SIG............................23
4.1.4 Transaction and Request SIGs........................24 4.1.4 Transaction and Request SIGs........................24
4.2 SIG RRs in the Construction of Responses..............24 4.2 SIG RRs in the Construction of Responses..............24
4.3 Processing Responses and SIG RRs......................25 4.3 Processing Responses and SIG RRs......................25
4.4 Signature Expiration, TTLs, and Validity..............26 4.4 Signature Expiration, TTLs, and Validity..............26
4.5 File Representation of SIG RRs........................26 4.5 File Representation of SIG RRs........................27
5. Non-existent Names and Types...........................28 5. Non-existent Names and Types...........................28
5.1 The NXT Resource Record...............................28 5.1 The NXT Resource Record...............................28
5.2 NXT RDATA Format......................................29 5.2 NXT RDATA Format......................................29
5.3 Example...............................................30 5.3 Example...............................................30
5.4 Interaction of NXT RRs and Wildcard RRs...............30 5.4 Interaction of NXT RRs and Wildcard RRs...............30
5.5 Blocking NXT Pseudo-Zone Transfers....................31 5.5 Blocking NXT Pseudo-Zone Transfers....................31
5.6 Special Considerations at Delegation Points...........32 5.6 Special Considerations at Delegation Points...........32
6. The AD and CD Bits and How to Resolve Securely.........33 6. The AD and CD Bits and How to Resolve Securely.........33
6.1 The AD and CD Header Bits.............................33 6.1 The AD and CD Header Bits.............................33
6.2 Boot File Format......................................34 6.2 Boot File Format......................................34
6.3 Chaining Through Zones................................35 6.3 Chaining Through Zones................................35
6.4 Secure Time...........................................36 6.4 Secure Time...........................................36
7. Operational Considerations.............................37 7. Operational Considerations.............................37
7.1 Key Size Considerations...............................37 7.1 Key Size Considerations...............................37
7.2 Key Storage...........................................37 7.2 Key Storage...........................................37
7.3 Key Generation........................................38 7.3 Key Generation........................................38
skipping to change at page 23, line 23 skipping to change at page 23, line 23
confidentiality uses since, if the same data can be collected confidentiality uses since, if the same data can be collected
encrypted under three different keys with an exponent of 3 then, encrypted under three different keys with an exponent of 3 then,
using the Chinese Remainder Theorem, the original plain text can be using the Chinese Remainder Theorem, the original plain text can be
easily recovered. This weakness is not significant for DNS because easily recovered. This weakness is not significant for DNS because
we seek only authentication, not confidentiality. we seek only authentication, not confidentiality.
4.1.3 Zone Transfer (AXFR) SIG 4.1.3 Zone Transfer (AXFR) SIG
The above SIG mechanisms assure the authentication of all zone signed The above SIG mechanisms assure the authentication of all zone signed
RRs of a particular name, class and type. However, to efficiently RRs of a particular name, class and type. However, to efficiently
secure complete zone transfers, a SIG RR owned by the zone name must assure the completeness of and secure zone transfers, a SIG RR owned
be created with a type covered of AXFR that covers all zone signed by the zone name must be created with a type covered of AXFR that
RRs other than the SIG AXFR itself. It will be calculated by hashing covers all RRs in the zone other than those signed by dynamic update
together all other zone signed RRs, including SIGs. The RRs are keys and the SIG AXFR itself. The RRs are ordered and concatenated
ordered and concatenated for hashing as described in Section 4.1.1. for hashing as described in Section 4.1.1. (See also ordering
(See also ordering discussion in Section 5.1.) discussion in Section 5.1.)
The AXFR SIG must be calculated last of all zone key signed SIGs in The AXFR SIG must be calculated last of all zone key signed SIGs in
the zone. It really belongs to the zone as a whole, not to the zone the zone. In effect, when signing the zone, you order, as described
name. The AXFR SIG is only retrieved as part of a zone transfer. above, all RRs to be signed by the zone. You can then make one pass
After validation of the AXFR SIG, the zone MAY be considered valid inserting all the zone SIGs. As you proceed you hash RRs into both
without verification of all the internal zone SIGs in the zone; an RRset hash and the zone hash. When the name or type changes you
however, any SIGs signed by entity keys or the like must still be calculate and insert the RRset SIG, clear the RRset hash, and hash
validated. The AXFR SIG SHOULD be transmitted first in a zone that SIG into the zone hash. When you have finished processing all
transfer so the receiver can tell immediately that they may be able the starting RRs as described above, you can then use the cumulative
to avoid verifying other zone signed SIGs. zone hash RR to calculate and insert an AXFR SIG covering the zone.
Of course any computational technique producing the same results as
above is permitted.
RRs which might be added by a dynamic zone update protocol or are The AXFR SIG really belongs to the zone as a whole, not to the zone
otherwise signed by an end entity or user key and not by the zone key name. Although it should be correct for the zone name, the labels
(see Section 3.2) are not included in the AXFR SIG. They may field of an AXFR SIG is otherwise meaningless. The AXFR SIG is only
retrieved as part of a zone transfer. After validation of the AXFR
SIG, the zone MAY be considered valid without verification of the
internal zone signed SIGs in the zone; however, any SIGs signed by
entity keys or the like must still be validated. The AXFR SIG SHOULD
be transmitted first in a zone transfer so the receiver can tell
immediately that they may be able to avoid verifying other zone
signed SIGs.
RRs which are authenticated by a dynamic update key and not by the
zone key (see Section 3.2) are not included in the AXFR SIG. They may
originate in the network and might not, in general, be migrated to originate in the network and might not, in general, be migrated to
the recommended off line zone signing procedure (see Section 7.2). the recommended off line zone signing procedure (see Section 7.2).
Thus, such RRs are not directly signed by the zone, are not included Thus, such RRs are not directly signed by the zone, are not included
in the AXFR SIG, and are protected against omission from zone in the AXFR SIG, and are protected against omission from zone
transfers only to the extent that the server and communication can be transfers only to the extent that the server and communication can be
trusted. trusted.
4.1.4 Transaction and Request SIGs 4.1.4 Transaction and Request SIGs
A response message from a security aware server may optionally A response message from a security aware server may optionally
skipping to change at page 43, line 13 skipping to change at page 43, line 13
[RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting.
Authors Addresses Authors Addresses
Donald E. Eastlake, 3rd Donald E. Eastlake, 3rd
CyberCash, Inc. CyberCash, Inc.
318 Acton Street 318 Acton Street
Carlisle, MA 01741 USA Carlisle, MA 01741 USA
Telephone: +1 508-287-4877 Telephone: +1 508-287-4877
FAX: +1 508-371-7148 +1 508-371-7148(fax)
+1 703-620-4200(main office, Reston, Virginia, USA)
EMail: dee@cybercash.com EMail: dee@cybercash.com
Charles W. Kaufman Charles W. Kaufman
Iris Associates Iris Associates
1 Technology Park Drive 1 Technology Park Drive
Westford, MA 01886 USA Westford, MA 01886 USA
Telephone: +1 508-392-5276 Telephone: +1 508-392-5276
EMail: charlie_kaufman@iris.com EMail: charlie_kaufman@iris.com
Expiration and File Name Expiration and File Name
This draft expires 8 July 1996. This draft expires 29 July 1996.
Its file name is draft-ietf-dnssec-secext-08.txt. Its file name is draft-ietf-dnssec-secext-09.txt.
Appendix: Base 64 Encoding Appendix: Base 64 Encoding
The following encoding technique is taken from RFC 1521 by N. Borenstein The following encoding technique is taken from RFC 1521 by N. Borenstein
and N. Freed. It is reproduced here in an edited form for convenience. and N. Freed. It is reproduced here in an edited form for 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.)
 End of changes. 11 change blocks. 
26 lines changed or deleted 37 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/