draft-ietf-dnssec-secext-04.txt   draft-ietf-dnssec-secext-05.txt 
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com
318 Acton Street +1 508-371-7148(fax) dee@world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
DNS Security Working Group Donald E. Eastlake, 3rd DNS Security Working Group Donald E. Eastlake, 3rd
INTERNET-DRAFT CyberCash INTERNET-DRAFT CyberCash
Charles W. Kaufman UPDATES RFC 1034, 1035 Charles W. Kaufman
Iris Iris
Expires: 15 February 1996 16 August 1995
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-04.txt, is intended to This draft, file name draft-ietf-dnssec-secext-05.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
months. Internet-Drafts may be updated, replaced, or obsoleted by months. Internet-Drafts may be updated, replaced, or obsoleted by
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 learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, 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 ds.internic.net, nic.nordu.net, ftp.isi.edu, Directories on ds.internic.net, ftp.isi.edu, nic.nordu.net,
munnari.oz.au, or ftp.is.co.za. ftp.nis.garr.it, munnari.oz.au, or ftp.is.co.za.
Abstract Abstract
The Domain Name System (DNS) has become a critical operational part The Domain Name System (DNS) has become a critical operational part
of the Internet infrastructure yet it has no strong security of the Internet infrastructure yet it has no strong security
mechanisms to assure data integrity or authentication. Extensions to mechanisms to assure data integrity or authentication. Extensions to
the DNS are described that provide these services to security aware the DNS are described that provide these services to security aware
resolvers or applications through the use of cryptographic digital resolvers or applications through the use of cryptographic digital
signatures. These digital signatures are included in secured zones signatures. These digital signatures are included in secured zones
as resource records. Security can still be provided even through as resource records. Security can still be provided even through
skipping to change at page 2, line 33 skipping to change at page 2, line 33
algorithms. algorithms.
In addition, the security extensions provide for the optional In addition, the security extensions provide for the optional
authentication of DNS protocol transactions. authentication of DNS protocol transactions.
Acknowledgements Acknowledgements
The significant contributions of the following persons (in alphabetic The significant contributions of the following persons (in alphabetic
order) to this draft are gratefully acknowledged: order) to this draft are gratefully acknowledged:
Madelyn Badger, Matt Crawford, James M. Galvin, Olafur Madelyn Badger
Gudmundsson, Sandy Murphy, Masataka Ohta, Michael A. Patton, Matt Crawford
Jeffrey I. Schiller. James M. Galvin
Olafur Gudmundsson
Sandy Murphy
Masataka Ohta
Michael A. Patton
Jeffrey I. Schiller
Table of Contents Table of Contents
Status of This Document....................................1 Status of This Document....................................1
Abstract...................................................2 Abstract...................................................2
Acknowledgements...........................................2 Acknowledgements...........................................2
Table of Contents..........................................3 Table of Contents..........................................3
skipping to change at page 3, line 33 skipping to change at page 3, line 33
2.3.4 Special Considerations at Delegation Points..........9 2.3.4 Special Considerations at Delegation Points..........9
2.3.5 Special Considerations with CNAME RRs................9 2.3.5 Special Considerations with CNAME RRs................9
2.3.6 Signers Other Than The Zone..........................9 2.3.6 Signers Other Than The Zone..........................9
2.4 DNS Transaction Authentication........................10 2.4 DNS Transaction Authentication........................10
3. The KEY Resource Record................................11 3. The KEY Resource Record................................11
3.1 KEY RDATA format......................................11 3.1 KEY RDATA format......................................11
3.2 Object Types, DNS Names, and Keys.....................11 3.2 Object Types, DNS Names, and Keys.....................11
3.3 The KEY RR Flag Field.................................12 3.3 The KEY RR Flag Field.................................12
3.4 The Protocol Octet....................................14 3.4 The Protocol Octet....................................14
3.5 The KEY Algorithm Number and the MD5/RSA Algorithm....14 3.5 The KEY Algorithm Number and the MD5/RSA Algorithm....15
3.6 Interaction of Flags, Algorithm, and Protocol Bytes...15 3.6 Interaction of Flags, Algorithm, and Protocol Bytes...15
3.7 KEY RRs in the Construction of Responses..............16 3.7 KEY RRs in the Construction of Responses..............16
3.8 File Representation of KEY RRs........................16 3.8 File Representation of KEY RRs........................16
4. The SIG Resource Record................................18 4. The SIG Resource Record................................18
4.1 SIG RDATA Format......................................18 4.1 SIG RDATA Format......................................18
4.1.1 Signature Data......................................20 4.1.1 Signature Data......................................20
4.1.2 MD5/RSA Algorithm Signature Calculation.............21 4.1.2 MD5/RSA Algorithm Signature Calculation.............21
4.1.3 Zone Transfer (AXFR) SIG............................22 4.1.3 Zone Transfer (AXFR) SIG............................22
4.1.4 Transaction SIGs....................................22 4.1.4 Transaction SIGs....................................22
4.2 SIG RRs in the Construction of Responses..............23 4.2 SIG RRs in the Construction of Responses..............23
4.3 Processing Responses and SIG RRs......................23 4.3 Processing Responses and SIG RRs......................24
4.4 Signature Expiration, TTLs, and Validity..............24 4.4 Signature Expiration, TTLs, and Validity..............24
4.5 File Representation of SIG RRs........................25 4.5 File Representation of SIG RRs........................25
5. Non-existent Names and Types...........................26 5. Non-existent Names and Types...........................26
5.1 The NXT Resource Record...............................26 5.1 The NXT Resource Record...............................26
5.2 NXT RDATA Format......................................27 5.2 NXT RDATA Format......................................27
5.3 Example...............................................27 5.3 Example...............................................27
5.4 Interaction of NXT RRs and Wildcard RRs...............28 5.4 Interaction of NXT RRs and Wildcard RRs...............28
5.5 Blocking NXT Pseudo-Zone Transfers....................28 5.5 Blocking NXT Pseudo-Zone Transfers....................29
5.6 Special Considerations at Delegation Points...........29 5.6 Special Considerations at Delegation Points...........29
6. The AD and CD Bits and How to Resolve Securely.........30 6. The AD and CD Bits and How to Resolve Securely.........30
6.1 The AD and CD Header Bits.............................30 6.1 The AD and CD Header Bits.............................30
6.2 Boot File Format......................................31 6.2 Boot File Format......................................31
6.3 Chaining Through Zones................................32 6.3 Chaining Through Zones................................32
6.4 Secure Time...........................................33 6.4 Secure Time...........................................33
7. Operational Considerations.............................34 7. Operational Considerations.............................34
7.1 Key Size Considerations...............................34 7.1 Key Size Considerations...............................34
7.2 Key Storage...........................................35 7.2 Key Storage...........................................35
7.3 Key Generation........................................35 7.3 Key Generation........................................35
skipping to change at page 13, line 30 skipping to change at page 13, line 30
*.txt]. This is the public key used in connection with the optional *.txt]. This is the public key used in connection with the optional
DNS transaction authentication service that can be used if the owner DNS transaction authentication service that can be used if the owner
name is a DNS server host. It could also be used in an IP-security name is a DNS server host. It could also be used in an IP-security
protocol where authentication of a host was desired such as routing, protocol where authentication of a host was desired such as routing,
NTP, etc. NTP, etc.
Bit 7 is the "zone" bit and indicates that this is a zone key Bit 7 is the "zone" bit and indicates that this is a zone key
for the zone whose name is the KEY RR owner name. This is the for the zone whose name is the KEY RR owner name. This is the
fundamental type of DNS data origin authentication public key. fundamental type of DNS data origin authentication public key.
Bits 8 is reserved to be the "IPSEC" bit and indicate that this Bit 8 is reserved to be the "IPSEC" bit and indicate that this
key is valid for use in a future IP level security protocol. This key is valid for use in conjunction with the IP level security
key could be used in connection with secured communication on behalf standard. This key could be used in connection with secured
of an end entity or user whose name is the owner name of the KEY RR communication on behalf of an end entity or user whose name is the
if the entity or user bits are on. The presence of a KEY resource owner name of the KEY RR if the entity or user bits are on. The
with the IPSEC and entity bits on and experimental and no-key bits presence of a KEY resource with the IPSEC and entity bits on and
off is a guarantee that the host speaks IPSEC. experimental and no-key bits off is a guarantee that the host speaks
IPSEC.
Bits 9-11 are reserved and must be zero. Bit 9 is reserved to be the "MOSS" bit and indicate that this
key is valid for use in conjunction with MIME object security
standard. This key could be used in connection with secured
communication on behalf of an end entity or user whose name is the
owner name of the KEY RR if the entity or user bits are on. The
presence of a KEY resource with the MOSS and entity bits on and
experimental and no-key bits off is a guarantee that the host speaks
MOSS.
Bits 10-11 are reserved and must be zero.
Bits 12-15 are the "signatory" field. If non-zero, it indicates Bits 12-15 are the "signatory" field. If non-zero, it indicates
that the key can validly sign RRs of the same name. If the owner that the key can validly sign RRs of the same name. If the owner
name is a wildcard, then RRs with any name which is in the wildcard's name is a wildcard, then RRs with any name which is in the wildcard's
scope can be signed. Fifteen different non-zero values are possible scope can be signed. Fifteen different non-zero values are possible
for this field and any differences in their meaning are reserved for for this field and any differences in their meaning are reserved for
definition in connection with possible future DNS dynamic update or definition in connection with possible future DNS dynamic update or
other new DNS commands. This field is meaningless for zone keys other new DNS commands. This field is meaningless for zone keys
which always have authority to sign any RRs in the zone. The which always have authority to sign any RRs in the zone. The
signatory field, like all other aspects of the KEY RR, is only signatory field, like all other aspects of the KEY RR, is only
skipping to change at page 19, line 51 skipping to change at page 19, line 51
that unscrupulous servers could otherwise cause by manipulating the that unscrupulous servers could otherwise cause by manipulating the
real TTL field. This original TTL is protected by the signature real TTL field. This original TTL is protected by the signature
while the current TTL field is not. while the current TTL field is not.
NOTE: The "original TTL" must be restored into the covered RRs when NOTE: The "original TTL" must be restored into the covered RRs when
the signature is verified. This implies that the RRs for a the signature is verified. This implies that the RRs for a
particular type need to all have the same TTL to start with. particular type need to all have the same TTL to start with.
The SIG is valid until the "signature expiration" time which is an The SIG is valid until the "signature expiration" time which is an
unsigned number of seconds since the start of 1 January 1970, GMT, unsigned number of seconds since the start of 1 January 1970, GMT,
ignoring leap seconds. (See also Section 4.4.) ignoring leap seconds. (See also Section 4.4.) SIG RRs should not
have a date signed significantly in the future. To prevent
misordering of network request to update a zone dynamically,
monotonically increasing "time signed" dates are necessary.
The "time signed" field is an unsigned number of seconds since the The "time signed" field is an unsigned number of seconds since the
start of 1 January 1970, GMT, ignoring leap seconds. start of 1 January 1970, GMT, ignoring leap seconds.
A SIG RR with an expiration date before the date signed is
ineffective.
The "key footprint" is a 16 bit quantity that is used to help The "key footprint" is a 16 bit quantity that is used to help
efficiently select between multiple keys which may be applicable and efficiently select between multiple keys which may be applicable and
as a quick check that a public key about to be used for the as a quick check that a public key about to be used for the
computationally expensive effort to check the signature is possibly computationally expensive effort to check the signature is possibly
valid. Its exact meaning is algorithm dependent. For the MD5/RSA valid. Its exact meaning is algorithm dependent. For the MD5/RSA
algorithm, it is the next to the bottom two octets of the public key algorithm, it is the next to the bottom two octets of the public key
modulus needed to decode the signature field. That is to say, the modulus needed to decode the signature field. That is to say, the
most significant 16 of the lest significant 24 bits of this quantity most significant 16 of the lest significant 24 bits of this quantity
in network order. in network order.
skipping to change at page 21, line 21 skipping to change at page 21, line 26
How this data sequence is processed into the signature is algorithm How this data sequence is processed into the signature is algorithm
dependent. dependent.
4.1.2 MD5/RSA Algorithm Signature Calculation 4.1.2 MD5/RSA Algorithm Signature Calculation
For the MD5/RSA algorithm, the signature is as follows For the MD5/RSA algorithm, the signature is as follows
hash = MD5 ( data ) hash = MD5 ( data )
signature = ( 01 | FF* | 00 | hash ) ** e (mod n) signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n)
where MD5 is the message digest algorithm documented in RFC 1321, "|" where MD5 is the message digest algorithm documented in RFC 1321, "|"
is concatenation, "e" is the secret key exponent of the signer, and is concatenation, "e" is the secret key exponent of the signer, and
"n" is the public modulus of the signer's public key. 01, FF, and 00 "n" is the public modulus of the signer's public key. 01, FF, and 00
are fixed octets of the corresponding hexadecimal value. The FF are fixed octets of the corresponding hexadecimal value. "prefix" is
octet is repeated the maximum number of times such that the value of the ASN.1 BER MD5 algorithm designator prefix specified in PKCS1,
the quantity being exponentiated is one octet shorter than the value that is,
of n. hex 3020300c06082a864886f70d020505000410 [NETSEC].
The FF octet is repeated the maximum number of times such that the
value of the quantity being exponentiated is one octet shorter than
the value of n.
The above specifications are exactly Public Key Cryptographic
Standard #1 [PKCS1].
The size of n, including most and least significant bits (which will The size of n, including most and least significant bits (which will
be 1) SHALL be not less than 512 bits and not more than 2552 bits. n be 1) SHALL be not less than 512 bits and not more than 2552 bits. n
and e SHOULD be chosen such that the public exponent is small. and e SHOULD be chosen such that the public exponent is small.
Leading zeros bytes are not permitted in the MD5/RSA algorithm Leading zeros bytes are not permitted in the MD5/RSA algorithm
signature. signature.
The above specifications are similar to Public Key Cryptographic
Standard #1 [PKCS1].
A public exponent of 3 minimizes the effort needed to decode a A public exponent of 3 minimizes the effort needed to decode a
signature. Use of 3 as the public exponent may be weak for signature. Use of 3 as the public exponent may be weak for
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
skipping to change at page 27, line 28 skipping to change at page 27, line 28
The type number for the NXT RR is 30. The type number for the NXT RR is 30.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next domain name / | next domain name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type bit map / | type bit map /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The NXT RR type bit map is one bit per RR type present for the owner
name similar to the WKS socket bit map. The first bit represents RR
type zero (an illegal type which should not be present.) A one bit
indicates that at least one RR of that type is present for the owner
name. A zero indicates that no such RR is present. All bits not
specified because they are beyond the end of the bit map are assumed
to be zero. Note that bit 30, for NXT, will always be on so the
minimum bit map length is actually four octets. The NXT bit map
should be printed as a list of type mnemonics or decimal numbers
similar to the WKS RR.
The size of the bit map can be inferred from the RDLENGTH and the The size of the bit map can be inferred from the RDLENGTH and the
length of the next domain name. length of the next domain name.
5.3 Example 5.3 Example
Assume zone foo.bar has entries for Assume zone foo.bar has entries for
big.foo.bar, big.foo.bar,
medium.foo.bar. medium.foo.bar.
small.foo.bar. small.foo.bar.
tiny.foo.bar. tiny.foo.bar.
Then a query to a security aware server for huge.foo.bar would Then a query to a security aware server for huge.foo.bar would
produce an error reply with the authority section data including the produce an error reply with the authority section data including the
following: following:
big.foo.bar. NXT medium.foo.bar. 130 big.foo.bar. NXT medium.foo.bar. A, MX, SIG, NXT
big.foo.bar. SIG NXT ...
Note that this response implies that big.foo.bar is an existing name Note that this response implies that big.foo.bar is an existing name
in the zone and thus has other RR types associated with it than NXT. in the zone and thus has other RR types associated with it than NXT.
However, only the NXT (and its SIG) RR appear in the response to this However, only the NXT (and its SIG) RR appear in the response to this
query for huge.foo.bar, which is a non-existent name. query for huge.foo.bar, which is a non-existent name.
5.4 Interaction of NXT RRs and Wildcard RRs 5.4 Interaction of NXT RRs and Wildcard RRs
Since, in some sense, a wildcard RR causes all possible names in an Since, in some sense, a wildcard RR causes all possible names in an
interval to exist, there should not be an NXT RR that would cover any interval to exist, there should not be an NXT RR that would cover any
skipping to change at page 38, line 25 skipping to change at page 38, line 25
problems. For example, using secure DNS you can have high confidence problems. For example, using secure DNS you can have high confidence
in the IP address you retrieve for a host; however, this does not in the IP address you retrieve for a host; however, this does not
stop someone for substituting an unauthorized host at that address or stop someone for substituting an unauthorized host at that address or
capturing packets sent to that address and responding with packets capturing packets sent to that address and responding with packets
apparently from that address. Any reasonably complete security apparently from that address. Any reasonably complete security
system will require the protection of many other facets of the system will require the protection of many other facets of the
Internet. Internet.
References References
[NETSEC] - Network Security: PRIVATE Communications in a PUBLIC
World, Charlie Kaufman, Radia Perlman, & Mike Speciner, Prentice Hall
Series in Computer Networking and Distributed Communications 1995.
[PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., [PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, Inc.,
3 June 1991, Version 1.4. 3 June 1991, Version 1.4.
[RFC1032] - Domain Administrators Guide, M. Stahl, November 1987 [RFC1032] - Domain Administrators Guide, M. Stahl, November 1987
[RFC1033] - Domain Administrators Operations Guide, M. Lottor, [RFC1033] - Domain Administrators Operations Guide, M. Lottor,
November 1987 November 1987
[RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
November 1987 November 1987
skipping to change at page 39, line 25 skipping to change at page 39, line 25
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 24 December 1995. This draft expires 15 February1995.
Its file name is draft-ietf-dnssec-secext-04.txt. Its file name is draft-ietf-dnssec-secext-05.txt.
Appendix: Base 64 Encoding Appendix: Base 64 Encoding
The following encoding technique is taken from RFC 1521 by Borenstein The following encoding technique is taken from RFC 1521 by Borenstein
and Freed. It is reproduced here in an edited form for convenience. and 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. 22 change blocks. 
35 lines changed or deleted 71 lines changed or added

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