draft-ietf-dnssec-secext2-07.txt   rfc2535.txt 
DNS Security Working Group Donald E. Eastlake 3rd Network Working Group D. Eastlake
INTERNET-DRAFT IBM Request for Comments: 2535 IBM
OBSOLETES RFC 2065 Obsoletes: 2065 March 1999
UPDATES RFCs 1034, 1035, and 2181 Updates: 2181, 1035, 1034
Expires: June 1999 December 1998 Category: Standards Track
Domain Name System Security Extensions Domain Name System Security Extensions
------ ---- ------ -------- ----------
Status of This Document
This draft, file name draft-ietf-dnssec-secext2-07.txt, is intended
to become a Proposed Standard RFC obsoleting Proposed Standard RFC
2065. Distribution of this document is unlimited. Comments should be
sent to the DNS Security Working Group mailing list <dns-
security@tis.com> or to the author.
This document is an Internet-Draft. Internet-Drafts are working Status of this Memo
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 This document specifies an Internet standards track protocol for the
months. Internet-Drafts may be updated, replaced, or obsoleted by Internet community, and requests discussion and suggestions for
other documents at any time. It is not appropriate to use Internet- improvements. Please refer to the current edition of the "Internet
Drafts as reference material or to cite them other than as a Official Protocol Standards" (STD 1) for the standardization state
``working draft'' or ``work in progress.'' and status of this protocol. Distribution of this memo is unlimited.
To view the entire list of current Internet-Drafts, please check the Copyright Notice
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
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).
[[changed from draft 5 to draft 6: add IANA Considerations section, Copyright (C) The Internet Society (1999). All Rights Reserved.
update dates and file name, update author info, update references
where new documents have superceded those previously referenced, add
reference to RFC 2119, clarify wording, minor change at 4.1.5 to
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
leaf node in the superzone, specify that algorithm 254 OIDs are BER
encoded, add algorithm 253 for domain name encoded private
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 2, line 35 skipping to change at page 2, line 11
This document incorporates feedback on RFC 2065 from early This document incorporates feedback on RFC 2065 from early
implementers and potential users. implementers and potential users.
Acknowledgments Acknowledgments
The significant contributions and suggestions of the following The significant contributions and suggestions of the following
persons (in alphabetic order) to DNS security are gratefully persons (in alphabetic order) to DNS security are gratefully
acknowledged: acknowledged:
James M. Galvin James M. Galvin
John Gilmore John Gilmore
Olafur Gudmundsson Olafur Gudmundsson
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 Abstract...................................................1
Acknowledgments............................................2
Abstract...................................................2 1. Overview of Contents....................................4
Acknowledgments............................................2 2. Overview of the DNS Extensions..........................5
2.1 Services Not Provided..................................5
Table of Contents..........................................3 2.2 Key Distribution.......................................5
2.3 Data Origin Authentication and Integrity...............6
1. Overview of Contents....................................5 2.3.1 The SIG Resource Record..............................7
2. Overview of the DNS Extensions..........................6 2.3.2 Authenticating Name and Type Non-existence...........7
2.1 Services Not Provided..................................6 2.3.3 Special Considerations With Time-to-Live.............7
2.2 Key Distribution.......................................6 2.3.4 Special Considerations at Delegation Points..........8
2.3 Data Origin Authentication and Integrity...............7 2.3.5 Special Considerations with CNAME....................8
2.3.1 The SIG Resource Record..............................8 2.3.6 Signers Other Than The Zone..........................9
2.3.2 Authenticating Name and Type Non-existence...........8 2.4 DNS Transaction and Request Authentication.............9
2.3.3 Special Considerations With Time-to-Live.............8 3. The KEY Resource Record................................10
2.3.4 Special Considerations at Delegation Points..........9 3.1 KEY RDATA format......................................10
2.3.5 Special Considerations with CNAME....................9 3.1.1 Object Types, DNS Names, and Keys...................11
2.3.6 Signers Other Than The Zone.........................10 3.1.2 The KEY RR Flag Field...............................11
2.4 DNS Transaction and Request Authentication............10 3.1.3 The Protocol Octet..................................13
3. The KEY Resource Record................................11 3.2 The KEY Algorithm Number Specification................14
3.1 KEY RDATA format......................................12 3.3 Interaction of Flags, Algorithm, and Protocol Bytes...15
3.1.1 Object Types, DNS Names, and Keys...................12 3.4 Determination of Zone Secure/Unsecured Status.........15
3.1.2 The KEY RR Flag Field...............................13 3.5 KEY RRs in the Construction of Responses..............17
3.1.3 The Protocol Octet..................................14 4. The SIG Resource Record................................17
3.2 The KEY Algorithm Number Specification................15 4.1 SIG RDATA Format......................................17
3.3 Interaction of Flags, Algorithm, and Protocol Bytes...16 4.1.1 Type Covered Field..................................18
3.4 Determination of Zone Secure/Unsecured Status.........16 4.1.2 Algorithm Number Field..............................18
3.5 KEY RRs in the Construction of Responses..............18 4.1.3 Labels Field........................................18
4. The SIG Resource Record................................18 4.1.4 Original TTL Field..................................19
4.1 SIG RDATA Format......................................19 4.1.5 Signature Expiration and Inception Fields...........19
4.1.1 Type Covered Field..................................19 4.1.6 Key Tag Field.......................................20
4.1.2 Algorithm Number Field..............................19 4.1.7 Signer's Name Field.................................20
4.1.3 Labels Field........................................19 4.1.8 Signature Field.....................................20
4.1.4 Original TTL Field..................................20 4.1.8.1 Calculating Transaction and Request SIGs..........21
4.1.5 Signature Expiration and Inception Fields...........20 4.2 SIG RRs in the Construction of Responses..............21
4.1.6 Key Tag Field.......................................21 4.3 Processing Responses and SIG RRs......................22
4.1.7 Signer's Name Field.................................21 4.4 Signature Lifetime, Expiration, TTLs, and Validity....23
4.1.8 Signature Field.....................................22 5. Non-existent Names and Types...........................24
4.1.8.1 Calculating Transaction and Request SIGs..........22 5.1 The NXT Resource Record...............................24
4.2 SIG RRs in the Construction of Responses..............23 5.2 NXT RDATA Format......................................25
4.3 Processing Responses and SIG RRs......................24 5.3 Additional Complexity Due to Wildcards................26
4.4 Signature Lifetime, Expiration, TTLs, and Validity....25 5.4 Example...............................................26
5. Non-existent Names and Types...........................25 5.5 Special Considerations at Delegation Points...........27
5.1 The NXT Resource Record...............................26 5.6 Zone Transfers........................................27
5.2 NXT RDATA Format......................................27 5.6.1 Full Zone Transfers.................................28
5.3 Additional Complexity Due to Wildcards................27 5.6.2 Incremental Zone Transfers..........................28
5.4 Example...............................................28 6. How to Resolve Securely and the AD and CD Bits.........29
5.5 Special Considerations at Delegation Points...........28 6.1 The AD and CD Header Bits.............................29
5.6 Zone Transfers........................................29 6.2 Staticly Configured Keys..............................31
5.6.1 Full Zone Transfers.................................29 6.3 Chaining Through The DNS..............................31
5.6.2 Incremental Zone Transfers..........................30 6.3.1 Chaining Through KEYs...............................31
6. How to Resolve Securely and the AD and CD Bits.........30 6.3.2 Conflicting Data....................................33
6.1 The AD and CD Header Bits.............................31 6.4 Secure Time...........................................33
6.2 Staticly Configured Keys..............................32 7. ASCII Representation of Security RRs...................34
6.3 Chaining Through The DNS..............................33 7.1 Presentation of KEY RRs...............................34
6.3.1 Chaining Through KEYs...............................33 7.2 Presentation of SIG RRs...............................35
6.3.2 Conflicting Data....................................34 7.3 Presentation of NXT RRs...............................36
6.4 Secure Time...........................................35 8. Canonical Form and Order of Resource Records...........36
7. ASCII Representation of Security RRs...................35 8.1 Canonical RR Form.....................................36
7.1 Presentation of KEY RRs...............................36 8.2 Canonical DNS Name Order..............................37
7.2 Presentation of SIG RRs...............................37 8.3 Canonical RR Ordering Within An RRset.................37
7.3 Presentation of NXT RRs...............................38 8.4 Canonical Ordering of RR Types........................37
8. Canonical Form and Order of Resource Records...........38 9. Conformance............................................37
8.1 Canonical RR Form.....................................38 9.1 Server Conformance....................................37
8.2 Canonical DNS Name Order..............................38 9.2 Resolver Conformance..................................38
8.3 Canonical RR Ordering Within An RRset.................39 10. Security Considerations...............................38
8.4 Canonical Ordering of RR Types........................39 11. IANA Considerations...................................39
9. Conformance............................................39 References................................................39
9.1 Server Conformance....................................39 Author's Address..........................................41
9.2 Resolver Conformance..................................40 Appendix A: Base 64 Encoding..............................42
10. Security Considerations...............................40 Appendix B: Changes from RFC 2065.........................44
11. IANA Considerations...................................41 Appendix C: Key Tag Calculation...........................46
Full Copyright Statement..................................47
References................................................42
Author's Address..........................................44
Expiration and File Name..................................44
Appendix A: Base 64 Encoding..............................45
Appendix B: Changes from RFC 2065.........................47
Appendix C: Key Tag Calculation...........................49
1. Overview of Contents 1. Overview of Contents
This document standardizes extensions of the Domain Name System (DNS) This document standardizes extensions of the Domain Name System (DNS)
protocol to support DNS security and public key distribution. It protocol to support DNS security and public key distribution. It
assumes that the reader is familiar with the Domain Name System, assumes that the reader is familiar with the Domain Name System,
particularly as described in RFCs 1033, 1034, 1035 and later RFCs. An particularly as described in RFCs 1033, 1034, 1035 and later RFCs. An
earlier version of these extensions appears in RFC 2065. This earlier version of these extensions appears in RFC 2065. This
replacement for that RFC incorporates early implementation experience replacement for that RFC incorporates early implementation experience
and requests from potential users. and requests from potential users.
skipping to change at page 5, line 51 skipping to change at page 4, line 51
records for use in master files and elsewhere. records for use in master files and elsewhere.
Section 8 defines the canonical form and order of RRs for DNS Section 8 defines the canonical form and order of RRs for DNS
security purposes. security purposes.
Section 9 defines levels of conformance for resolvers and servers. Section 9 defines levels of conformance for resolvers and servers.
Section 10 provides a few paragraphs on overall security Section 10 provides a few paragraphs on overall security
considerations. considerations.
Sectuion 11 specified IANA considerations for allocation of Section 11 specified IANA considerations for allocation of additional
additional values of paramters defined in this document. values of paramters defined in this document.
Appendix A gives details of base 64 encoding which is used in the Appendix A gives details of base 64 encoding which is used in the
file representation of some RRs defined in this document. file representation of some RRs defined in this document.
Appendix B summarizes changes between this draft and RFC 2065. Appendix B summarizes changes between this memo and RFC 2065.
Appendix C specified how to calculate the simple checksum used as a Appendix C specified how to calculate the simple checksum used as a
key tag in most SIG RRs. key tag in most SIG RRs.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Overview of the DNS Extensions 2. Overview of the DNS Extensions
skipping to change at page 6, line 36 skipping to change at page 5, line 38
2.1 Services Not Provided 2.1 Services Not Provided
It is part of the design philosophy of the DNS that the data in it is It is part of the design philosophy of the DNS that the data in it is
public and that the DNS gives the same answers to all inquirers. public and that the DNS gives the same answers to all inquirers.
Following this philosophy, no attempt has been made to include any Following this philosophy, no attempt has been made to include any
sort of access control lists or other means to differentiate sort of access control lists or other means to differentiate
inquirers. inquirers.
No effort has been made to provide for any confidentiality for No effort has been made to provide for any confidentiality for
queries or responses. (This service may be available via IPSEC [RFC queries or responses. (This service may be available via IPSEC [RFC
1825], TLS, or other security protocols.) 2401], TLS, or other security protocols.)
Protection is not provided against denial of service. Protection is not provided against denial of service.
2.2 Key Distribution 2.2 Key Distribution
A resource record format is defined to associate keys with DNS names. A resource record format is defined to associate keys with DNS names.
This permits the DNS to be used as a public key distribution This permits the DNS to be used as a public key distribution
mechanism in support of DNS security itself and other protocols. mechanism in support of DNS security itself and other protocols.
The syntax of a KEY resource record (RR) is described in Section 3. The syntax of a KEY resource record (RR) is described in Section 3.
skipping to change at page 7, line 25 skipping to change at page 6, line 22
Authentication is provided by associating with resource record sets Authentication is provided by associating with resource record sets
(RRsets [RFC 2181]) in the DNS cryptographically generated digital (RRsets [RFC 2181]) in the DNS cryptographically generated digital
signatures. Commonly, there will be a single private key that signatures. Commonly, there will be a single private key that
authenticates an entire zone but there might be multiple keys for authenticates an entire zone but there might be multiple keys for
different algorithms, signers, etc. If a security aware resolver different algorithms, signers, etc. If a security aware resolver
reliably learns a public key of the zone, it can authenticate, for reliably learns a public key of the zone, it can authenticate, for
signed data read from that zone, that it is properly authorized. The signed data read from that zone, that it is properly authorized. The
most secure implementation is for the zone private key(s) to be kept most secure implementation is for the zone private key(s) to be kept
off-line and used to re-sign all of the records in the zone off-line and used to re-sign all of the records in the zone
periodically. However, there are cases, for example dynamic update periodically. However, there are cases, for example dynamic update
[RFCs 2136, 2137], where DNS private keys need to be on-line. [RFCs 2136, 2137], where DNS private keys need to be on-line [RFC
[draft-ietf-dnssec-secops-*.txt] 2541].
The data origin authentication key(s) are associated with the zone The data origin authentication key(s) are associated with the zone
and not with the servers that store copies of the data. That means and not with the servers that store copies of the data. That means
compromise of a secondary server or, if the key(s) are kept off line, compromise of a secondary server or, if the key(s) are kept off line,
even the primary server for a zone, will not necessarily affect the even the primary server for a zone, will not necessarily affect the
degree of assurance that a resolver has that it can determine whether degree of assurance that a resolver has that it can determine whether
data is genuine. data is genuine.
A resolver could learn a public key of a zone either by reading it A resolver could learn a public key of a zone either by reading it
from the DNS or by having it staticly configured. To reliably learn from the DNS or by having it staticly configured. To reliably learn
skipping to change at page 12, line 22 skipping to change at page 11, line 16
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | protocol | algorithm | | flags | protocol | algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| / | /
/ public key / / public key /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
The KEY RR is not intended for storage of certificates and a separate The KEY RR is not intended for storage of certificates and a separate
certificate RR has been developed for that purpose, defined in certificate RR has been developed for that purpose, defined in [RFC
[draft-ietf-dnssec-certs-*.txt]. 2538].
The meaning of the KEY RR owner name, flags, and protocol octet are The meaning of the KEY RR owner name, flags, and protocol octet are
described in Sections 3.1.1 through 3.1.5 below. The flags and described in Sections 3.1.1 through 3.1.5 below. The flags and
algorithm must be examined before any data following the algorithm algorithm must be examined before any data following the algorithm
octet as they control the existence and format of any following data. octet as they control the existence and format of any following data.
The algorithm and public key fields are described in Section 3.2. The algorithm and public key fields are described in Section 3.2.
The format of the public key is algorithm dependent. The format of the public key is algorithm dependent.
KEY RRs do not specify their validity period but their authenticating KEY RRs do not specify their validity period but their authenticating
SIG RR(s) do as described in Section 4 below. SIG RR(s) do as described in Section 4 below.
skipping to change at page 13, line 9 skipping to change at page 11, line 46
account foo@host.example. Thus, there are flag bits, as described account foo@host.example. Thus, there are flag bits, as described
below, in the KEY RR to indicate with which of these roles the owner below, in the KEY RR to indicate with which of these roles the owner
name and public key are associated. Note that an appropriate zone name and public key are associated. Note that an appropriate zone
KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs
occur only at delegation points. occur only at delegation points.
3.1.2 The KEY RR Flag Field 3.1.2 The KEY RR Flag Field
In the "flags" field: In the "flags" field:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A/C | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z | SIG | | A/C | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z | SIG |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Bit 0 and 1 are the key "type" bits whose values have the following Bit 0 and 1 are the key "type" bits whose values have the following
meanings: meanings:
10: Use of the key is prohibited for authentication. 10: Use of the key is prohibited for authentication.
01: Use of the key is prohibited for confidentiality. 01: Use of the key is prohibited for confidentiality.
00: Use of the key for authentication and/or confidentiality 00: Use of the key for authentication and/or confidentiality
is permitted. Note that DNS security makes use of keys for is permitted. Note that DNS security makes use of keys
authentication only. Confidentiality use flagging is provided for for authentication only. Confidentiality use flagging is
use of keys in other protocols. Implementations not intended to provided for use of keys in other protocols.
support key distribution for confidentiality MAY require that the Implementations not intended to support key distribution
confidentiality use prohibited bit be on for keys they serve. for confidentiality MAY require that the confidentiality
use prohibited bit be on for keys they serve.
11: If both bits are one, the "no key" value, there is no key 11: If both bits are one, the "no key" value, there is no key
information and the RR stops after the algorithm octet. By the information and the RR stops after the algorithm octet.
use of this "no key" value, a signed KEY RR can authenticatably By the use of this "no key" value, a signed KEY RR can
assert that, for example, a zone is not secured. See section 3.4 authenticatably assert that, for example, a zone is not
below. secured. See section 3.4 below.
Bits 2 is reserved and must be zero. Bits 2 is reserved and must be zero.
Bits 3 is reserved as a flag extension bit. If it is a one, a second Bits 3 is reserved as a flag extension bit. If it is a one, a second
16 bit flag field is added after the algorithm octet and before 16 bit flag field is added after the algorithm octet and
the key data. This bit MUST NOT be set unless one or more such before the key data. This bit MUST NOT be set unless one or
additional bits have been defined and are non-zero. more such additional bits have been defined and are non-zero.
Bits 4-5 are reserved and must be zero. Bits 4-5 are reserved and must be zero.
Bits 6 and 7 form a field that encodes the name type. Field values Bits 6 and 7 form a field that encodes the name type. Field values
have the following meanings: have the following meanings:
00: indicates that this is a key associated with a "user" or 00: indicates that this is a key associated with a "user" or
"account" at an end entity, usually a host. The coding of the "account" at an end entity, usually a host. The coding
owner name is that used for the responsible individual mailbox in of the owner name is that used for the responsible
the SOA and RP RRs: The owner name is the user name as the name of individual mailbox in the SOA and RP RRs: The owner name
a node under the entity name. For example, "j_random_user" on is the user name as the name of a node under the entity
host.subdomain.example could have a public key associated through name. For example, "j_random_user" on
a KEY RR with name j_random_user.host.subdomain.example. It could host.subdomain.example could have a public key associated
be used in a security protocol where authentication of a user was through a KEY RR with name
desired. This key might be useful in IP or other security for a j_random_user.host.subdomain.example. It could be used
user level service such a telnet, ftp, rlogin, etc. in a security protocol where authentication of a user was
desired. This key might be useful in IP or other
security for a user level service such a telnet, ftp,
rlogin, etc.
01: indicates that this is a zone key for the zone whose name 01: indicates that this is a zone key for the zone whose name
is the KEY RR owner name. This is the public key used for the is the KEY RR owner name. This is the public key used
primary DNS security feature of data origin authentication. Zone for the primary DNS security feature of data origin
KEY RRs occur only at delegation points. authentication. Zone KEY RRs occur only at delegation
points.
10: indicates that this is a key associated with the non-zone 10: indicates that this is a key associated with the non-zone
"entity" whose name is the RR owner name. This will commonly be a "entity" whose name is the RR owner name. This will
host but could, in some parts of the DNS tree, be some other type commonly be a host but could, in some parts of the DNS
of entity such as a telephone number [RFC 1530] or numeric IP tree, be some other type of entity such as a telephone
address. This is the public key used in connection with DNS number [RFC 1530] or numeric IP address. This is the
request and transaction authentication services. It could also be public key used in connection with DNS request and
used in an IP-security protocol where authentication at the host, transaction authentication services. It could also be
rather than user, level was desired, such as routing, NTP, etc. used in an IP-security protocol where authentication at
the host, rather than user, level was desired, such as
routing, NTP, etc.
11: reserved. 11: reserved.
Bits 8-11 are reserved and must be zero. Bits 8-11 are reserved and must be zero.
Bits 12-15 are the "signatory" field. If non-zero, they indicate Bits 12-15 are the "signatory" field. If non-zero, they indicate
that the key can validly sign things as specified in DNS dynamic that the key can validly sign things as specified in DNS
update [RFC 2137]. Note that zone keys (see bits 6 and 7 above) dynamic update [RFC 2137]. Note that zone keys (see bits
always have authority to sign any RRs in the zone regardless of 6 and 7 above) always have authority to sign any RRs in
the value of the signatory field. the zone regardless of the value of the signatory field.
3.1.3 The Protocol Octet 3.1.3 The Protocol Octet
It is anticipated that keys stored in DNS will be used in conjunction It is anticipated that keys stored in DNS will be used in conjunction
with a variety of Internet protocols. It is intended that the with a variety of Internet protocols. It is intended that the
protocol octet and possibly some of the currently unused (must be protocol octet and possibly some of the currently unused (must be
zero) bits in the KEY RR flags as specified in the future will be zero) bits in the KEY RR flags as specified in the future will be
used to indicate a key's validity for different protocols. used to indicate a key's validity for different protocols.
The following values of the Protocol Octet are reserved as indicated: The following values of the Protocol Octet are reserved as indicated:
skipping to change at page 14, line 47 skipping to change at page 13, line 45
2 email 2 email
3 dnssec 3 dnssec
4 IPSEC 4 IPSEC
5-254 - available for assignment by IANA 5-254 - available for assignment by IANA
255 All 255 All
In more detail: In more detail:
1 is reserved for use in connection with TLS. 1 is reserved for use in connection with TLS.
2 is reserved for use in connection with email. 2 is reserved for use in connection with email.
3 is used for DNS security. The protocol field SHOULD be set to 3 is used for DNS security. The protocol field SHOULD be set to
this value for zone keys and other keys used in DNS security. this value for zone keys and other keys used in DNS security.
Implementations that can determine that a key is a DNS security key Implementations that can determine that a key is a DNS
by the fact that flags label it a zone key or the signatory flag security key by the fact that flags label it a zone key or the
field is non-zero are NOT REQUIRED to check the protocol field. signatory flag field is non-zero are NOT REQUIRED to check the
4 is reserved to refer to the Oakley/IPSEC [RFC 1825] protocol protocol field.
4 is reserved to refer to the Oakley/IPSEC [RFC 2401] protocol
and indicates that this key is valid for use in conjunction with that and indicates that this key is valid for use in conjunction
security standard. This key could be used in connection with secured with that security standard. This key could be used in
communication on behalf of an end entity or user whose name is the connection with secured communication on behalf of an end
owner name of the KEY RR if the entity or user flag bits are set. entity or user whose name is the owner name of the KEY RR if
The presence of a KEY resource with this protocol value is an the entity or user flag bits are set. The presence of a KEY
assertion that the host speaks Oakley/IPSEC. resource with this protocol value is an assertion that the
host speaks Oakley/IPSEC.
255 indicates that the key can be used in connection with any 255 indicates that the key can be used in connection with any
protocol for which KEY RR protocol octet values have been defined. protocol for which KEY RR protocol octet values have been
The use of this value is discouraged and the use of different keys defined. The use of this value is discouraged and the use of
for different protocols is encouraged. different keys for different protocols is encouraged.
3.2 The KEY Algorithm Number Specification 3.2 The KEY Algorithm Number Specification
This octet is the key algorithm parallel to the same field for the This octet is the key algorithm parallel to the same field for the
SIG resource as described in Section 4.1. The following values are SIG resource as described in Section 4.1. The following values are
assigned: assigned:
VALUE Algorithm VALUE Algorithm
0 - reserved, see Section 11 0 - reserved, see Section 11
1 RSA/MD5 [draft-ietf-dnssec-rsa-*.txt] - recommended 1 RSA/MD5 [RFC 2537] - recommended
2 Diffie-Hellman [draft-ietf-dnssec-dhk-*.txt] - optional, key only 2 Diffie-Hellman [RFC 2539] - optional, key only
3 DSA [draft-ietf-dnssec-dss-*.txt] - MANDATORY 3 DSA [RFC 2536] - MANDATORY
4 reserved for elliptic curve crypto 4 reserved for elliptic curve crypto
5-251 - available, see Section 11 5-251 - available, see Section 11
252 reserved for indirect keys 252 reserved for indirect keys
253 private - domain name (see below) 253 private - domain name (see below)
254 private - OID (see below) 254 private - OID (see below)
255 - reserved, see Section 11 255 - reserved, see Section 11
Algorithm specific formats and procedures are given in separate Algorithm specific formats and procedures are given in separate
documents. The mandatory to implement for interoperability algorithm documents. The mandatory to implement for interoperability algorithm
is number 3, DSA. It is recommended that the RSA/MD5 algorithm, is number 3, DSA. It is recommended that the RSA/MD5 algorithm,
number 1, also be implemented. Algorithm 2 is used to indicate number 1, also be implemented. Algorithm 2 is used to indicate
Diffie-Hellman keys and algorithm 4 is reserved for elliptic curve. Diffie-Hellman keys and algorithm 4 is reserved for elliptic curve.
Algorithm number 252 indicates an indirect key format where the Algorithm number 252 indicates an indirect key format where the
actual key material is elsewhere. This format is to be defined in a actual key material is elsewhere. This format is to be defined in a
separate document. separate document.
skipping to change at page 21, line 4 skipping to change at page 19, line 37
4.1.5 Signature Expiration and Inception Fields 4.1.5 Signature Expiration and Inception Fields
The SIG is valid from the "signature inception" time until the The SIG is valid from the "signature inception" time until the
"signature expiration" time. Both are unsigned numbers of seconds "signature expiration" time. Both are unsigned numbers of seconds
since the start of 1 January 1970, GMT, ignoring leap seconds. (See since the start of 1 January 1970, GMT, ignoring leap seconds. (See
also Section 4.4.) Ring arithmetic is used as for DNS SOA serial also Section 4.4.) Ring arithmetic is used as for DNS SOA serial
numbers [RFC 1982] which means that these times can never be more numbers [RFC 1982] which means that these times can never be more
than about 68 years in the past or the future. This means that these than about 68 years in the past or the future. This means that these
times are ambiguous modulo ~136.09 years. However there is no times are ambiguous modulo ~136.09 years. However there is no
security flaw because keys are required to be changed to new random security flaw because keys are required to be changed to new random
keys by [draft-ietf-dnssec-secops-*.txt] at least every five years. keys by [RFC 2541] at least every five years. This means that the
This means that the probability that the same key is in use N*136.09 probability that the same key is in use N*136.09 years later should
years later should be the same as the probability that a random guess be the same as the probability that a random guess will work.
will work.
A SIG RR may have an expiration time numerically less than the A SIG RR may have an expiration time numerically less than the
inception time if the expiration time is near the 32 bit wrap around inception time if the expiration time is near the 32 bit wrap around
point and/or the signature is long lived. point and/or the signature is long lived.
(To prevent misordering of network requests to update a zone (To prevent misordering of network requests to update a zone
dynamically, monotonically increasing "signature inception" times may dynamically, monotonically increasing "signature inception" times may
be necessary.) be necessary.)
A secure zone must be considered changed for SOA serial number A secure zone must be considered changed for SOA serial number
purposes not only when its data is updated but also when new SIG RRs purposes not only when its data is updated but also when new SIG RRs
are inserted (ie, the zone or any part of it is re-signed). are inserted (ie, the zone or any part of it is re-signed).
4.1.6 Key Tag Field 4.1.6 Key Tag Field
The "key Tag" is a two octet quantity that is used to efficiently The "key Tag" is a two octet quantity that is used to efficiently
select between multiple keys which may be applicable and thus check select between multiple keys which may be applicable and thus check
that a public key about to be used for the computationally expensive that a public key about to be used for the computationally expensive
effort to check the signature is possibly valid. For algorithm 1 effort to check the signature is possibly valid. For algorithm 1
(MD5/RSA) as defined in [draft-ietf-dnssec-rsa-*.txt], it is the next (MD5/RSA) as defined in [RFC 2537], it is the next to the bottom two
to the bottom two octets of the public key modulus needed to decode octets of the public key modulus needed to decode the signature
the signature field. That is to say, the most significant 16 of the field. That is to say, the most significant 16 of the least
least significant 24 bits of the modulus in network (big endian) significant 24 bits of the modulus in network (big endian) order. For
order. For all other algorithms, including private algorithms, it is all other algorithms, including private algorithms, it is calculated
calculated as a simple checksum of the KEY RR as described in as a simple checksum of the KEY RR as described in Appendix C.
Appendix C.
4.1.7 Signer's Name Field 4.1.7 Signer's Name Field
The "signer's name" field is the domain name of the signer generating The "signer's name" field is the domain name of the signer generating
the SIG RR. This is the owner name of the public KEY RR that can be the SIG RR. This is the owner name of the public KEY RR that can be
used to verify the signature. It is frequently the zone which used to verify the signature. It is frequently the zone which
contained the RRset being authenticated. Which signers should be contained the RRset being authenticated. Which signers should be
authorized to sign what is a significant resolver policy question as authorized to sign what is a significant resolver policy question as
discussed in Section 6. The signer's name may be compressed with discussed in Section 6. The signer's name may be compressed with
standard DNS name compression when being transmitted over the standard DNS name compression when being transmitted over the
skipping to change at page 28, line 20 skipping to change at page 27, line 5
big.foo.nil, big.foo.nil,
medium.foo.nil. medium.foo.nil.
small.foo.nil. small.foo.nil.
tiny.foo.nil. tiny.foo.nil.
Then a query to a security aware server for huge.foo.nil would Then a query to a security aware server for huge.foo.nil would
produce an error reply with an RCODE of NXDOMAIN and the authority produce an error reply with an RCODE of NXDOMAIN and the authority
section data including something like the following: section data including something like the following:
foo.nil. NXT big.foo.nil NS KEY SOA NXT ;prove no *.foo.nil foo.nil. NXT big.foo.nil NS KEY SOA NXT ;prove no *.foo.nil
foo.nil. SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2 foo.nil. SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2
19970102030405 ;signature expiration 19970102030405 ;signature expiration
19961211100908 ;signature inception 19961211100908 ;signature inception
2143 ;key identifier 2143 ;key identifier
foo.nil. ;signer foo.nil. ;signer
AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCm AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCm
fiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM= ;signature (640 bits) fiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM= ;signature (640 bits)
) )
big.foo.nil. NXT medium.foo.nil. A MX SIG NXT ;prove no huge.foo.nil big.foo.nil. NXT medium.foo.nil. A MX SIG NXT ;prove no huge.foo.nil
big.foo.nil. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3 big.foo.nil. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3
19970102030405 ;signature expiration 19970102030405 ;signature expiration
19961211100908 ;signature inception 19961211100908 ;signature inception
2143 ;key identifier 2143 ;key identifier
foo.nil. ;signer foo.nil. ;signer
MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU
1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits) 1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits)
) )
Note that this response implies that big.foo.nil is an existing name Note that this response implies that big.foo.nil 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.nil, which is a non-existent name. query for huge.foo.nil, which is a non-existent name.
5.5 Special Considerations at Delegation Points 5.5 Special Considerations at Delegation Points
A name (other than root) which is the head of a zone also appears as A name (other than root) which is the head of a zone also appears as
the leaf in a superzone. If both are secure, there will always be the leaf in a superzone. If both are secure, there will always be
two different NXT RRs with the same name. They can be easily two different NXT RRs with the same name. They can be easily
skipping to change at page 42, line 7 skipping to change at page 39, line 42
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 [RFC 2434]. 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] Lottor, M., "Domain Administrators Operations Guide", RFC
November 1987. 1033, November 1987.
[RFC 1034] - P. Mockapetris, "Domain Names - Concepts and [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, November 1987. Facilities", STD 13, RFC 1034, November 1987.
[RFC 1035] - P. Mockapetris, "Domain Names - Implementation and [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, November 1987. Specifications", STD 13, RFC 1035, November 1987.
[RFC 1305] - D. Mills, "Network Time Protocol (v3)", March 1992. [RFC 1305] Mills, D., "Network Time Protocol (v3)", RFC 1305, March
1992.
[RFC 1530] - C. Malamud, and M. Rose, "Principles of Operation for [RFC 1530] Malamud, C. and M. Rose, "Principles of Operation for the
the TPC.INT Subdomain: General Principles and Policy", October 1993. TPC.INT Subdomain: General Principles and Policy", RFC
1530, October 1993.
[RFC 1825] - Ran Atkinson, "Security Architecture for the Internet [RFC 2401] Kent, S. and R. Atkinson, "Security Architecture for the
Protocol", August 1995. Internet Protocol", RFC 2401, November 1998.
[RFC 1982] - Robert Elz, Rrandy Bush, "Serial Number Arithmetic", [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC
09/03/1996. 1982, September 1996.
[RFC 1995] - Masatka Ohta, "Incremental Zone Transfer in DNS", August [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
1996. August 1996.
[RFC 2030] - D. Mills, "Simple Network Time Protocol (SNTP) Version 4 [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", October 1996. for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC 2045] - N. Freed & N. Borenstein, "Multipurpose Internet Mail [RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies", Extensions (MIME) Part One: Format of Internet Message
November 1996. Bodies", RFC 2045, November 1996.
[RFC 2065] - Donald Eastlake 3rd, Charles Kaufman, "Domain Name [RFC 2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
System Security Extensions", 01/03/1997. Extensions", RFC 2065, January 1997.
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
Updates in the Domain Name System (DNS UPDATE)", 04/21/1997. "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC 2137] - Donald Eastlake 3rd, "Secure Domain Name System Dynamic [RFC 2137] Eastlake, D., "Secure Domain Name System Dynamic Update",
Update", 04/21/1997. RFC 2137, April 1997.
[RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS [RFC 2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", July 1997. Specification", RFC 2181, July 1997.
[RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", October 1998. IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
draft-ietf-dnssec-rsa-*.txt, D. Eastlake, "RSA/MD5 KEYs and SIGs in [RFC 2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
the Domain Name System (DNS)". System (DNS)", RFC 2537, March 1999.
draft-ietf-dnssec-dhk-*.txt, D. Eastlake, "Storage of Diffie-Hellman [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
Keys in the Domain Name System (DNS)". Domain Name System (DNS)", RFC 2539, March 1999.
draft-ietf-dnssec-dss-*.txt, D. Eastlake, "DSA KEYs and SIGs in the [RFC 2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name
Domain Name System (DNS)". System (DNS)", RFC 2536, March 1999.
draft-ietf-dsnssec-certs-*.txt, D. Eastlake, O. Gudmundsson, "Storing [RFC 2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in
Certificates in the Domain Name System". the Domain Name System", RFC 2538, March 1999.
draft-ietf-dnssec-secops-*.txt, D. Eastlake, "DNS Operational [RFC 2541] Eastlake, D., "DNS Operational Security Considerations",
Security Considerations". RFC 2541, March 1999.
[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
65 Shindegan Hill Road 65 Shindegan Hill Road
RR #1 RR #1
Carmel, NY 10512 Carmel, NY 10512
Telephone: +1-914-784-7913 (w) Phone: +1-914-784-7913 (w)
+1-914-276-2668 (h) +1-914-276-2668 (h)
fax: +1-914-784-3833 (w-fax) Fax: +1-914-784-3833 (w-fax)
email: dee3@us.ibm.com EMail: dee3@us.ibm.com
Expiration and File Name
This draft expires June 1999.
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 47, line 12 skipping to change at page 44, line 12
exactly 16 bits; here, the final unit of encoded output will be three exactly 16 bits; here, the final unit of encoded output will be three
characters followed by one "=" padding character. characters followed by one "=" padding character.
Appendix B: Changes from RFC 2065 Appendix B: Changes from RFC 2065
This section summarizes the most important changes that have been This section summarizes the most important changes that have been
made since RFC 2065. made since RFC 2065.
1. Most of Section 7 of [RFC 2065] called "Operational 1. Most of Section 7 of [RFC 2065] called "Operational
Considerations", has been removed and may be made into a separate Considerations", has been removed and may be made into a separate
document [draft-ietf-dnssec-secops-*.txt]. document [RFC 2541].
2. The KEY RR has been changed by (2a) eliminating the "experimental" 2. The KEY RR has been changed by (2a) eliminating the "experimental"
flag as unnecessary, (2b) reserving a flag bit for flags flag as unnecessary, (2b) reserving a flag bit for flags
expansion, (2c) more compactly encoding a number of bit fields in expansion, (2c) more compactly encoding a number of bit fields in
such a way as to leave unchanged bits actually used by the limited such a way as to leave unchanged bits actually used by the limited
code currently deployed, (2d) eliminating the IPSEC and email flag code currently deployed, (2d) eliminating the IPSEC and email flag
bits which are replaced by values of the protocol field and adding bits which are replaced by values of the protocol field and adding
a protocol field value for DNS security itself, (2e) adding a protocol field value for DNS security itself, (2e) adding
material to indicate that zone KEY RRs occur only at delegation material to indicate that zone KEY RRs occur only at delegation
points, and (2f) removing the description of the RSA/MD5 algorithm points, and (2f) removing the description of the RSA/MD5 algorithm
to a separate document [draft-ietf-dnssec-rsa-*.txt]. Section 3.4 to a separate document [RFC 2537]. Section 3.4 describing the
describing the meaning of various combinations of "no-key" and key meaning of various combinations of "no-key" and key present KEY
present KEY RRs has been added and the secure / unsecure status of RRs has been added and the secure / unsecure status of a zone has
a zone has been clarified as being per algorithm. been clarified as being per algorithm.
3. The SIG RR has been changed by (3a) renaming the "time signed" 3. The SIG RR has been changed by (3a) renaming the "time signed"
field to be the "signature inception" field, (3b) clarifying that field to be the "signature inception" field, (3b) clarifying that
signature expiration and inception use serial number ring signature expiration and inception use serial number ring
arithmetic, (3c) changing the definition of the key footprint/tag arithmetic, (3c) changing the definition of the key footprint/tag
for algorithms other than 1 and adding Appendix C to specify its for algorithms other than 1 and adding Appendix C to specify its
calculation. In addition, the SIG covering type AXFR has been calculation. In addition, the SIG covering type AXFR has been
eliminated while one covering IXFR [RFC 1995] has been added (see eliminated while one covering IXFR [RFC 1995] has been added (see
section 5.6). section 5.6).
skipping to change at page 48, line 31 skipping to change at page 45, line 34
Section 6.3.1. It is now clearly stated that authenticated data Section 6.3.1. It is now clearly stated that authenticated data
has a validity period of the intersection of the validity periods has a validity period of the intersection of the validity periods
of the SIG RRs in its authentication chain. The requirement to of the SIG RRs in its authentication chain. The requirement to
staticly configure a superzone's key signed by a zone in all of staticly configure a superzone's key signed by a zone in all of
the zone's authoritative servers has been removed. The the zone's authoritative servers has been removed. The
recommendation to continue DNS security checks in a secure island recommendation to continue DNS security checks in a secure island
of DNS data that is separated from other parts of the DNS tree by of DNS data that is separated from other parts of the DNS tree by
insecure zones and does not contain a zone for which a key has insecure zones and does not contain a zone for which a key has
been staticly configured was dropped. been staticly configured was dropped.
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 and references to RFC 2434. 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
for clarity, not efficiency. (See section 4.1.6 for how to determine for clarity, not efficiency. (See section 4.1.6 for how to determine
the Key Tag of an algorithm 1 key.) the Key Tag of an algorithm 1 key.)
/* assumes int is at least 16 bits /* assumes int is at least 16 bits
first byte of the key tag is the most significant byte of return value first byte of the key tag is the most significant byte of return
second byte of the key tag is the least significant byte of return value value
second byte of the key tag is the least significant byte of
return value
*/ */
int keytag ( int keytag (
unsigned char key[], /* the RDATA part of the KEY RR */ unsigned char key[], /* the RDATA part of the KEY RR */
unsigned int keysize, /* the RDLENGTH */ unsigned int keysize, /* the RDLENGTH */
) )
{ {
long int ac; /* assumed to be 32 bits or larger */ long int ac; /* assumed to be 32 bits or larger */
for ( ac = 0, i = 0; i < keysize; ++i ) for ( ac = 0, i = 0; i < keysize; ++i )
ac += (i&1) ? key[i] : key[i]<<8; ac += (i&1) ? key[i] : key[i]<<8;
ac += (ac>>16) & 0xFFFF; ac += (ac>>16) & 0xFFFF;
return ac & 0xFFFF; return ac & 0xFFFF;
} }
Full Copyright Statement
Copyright (C) The Internet Society (1999). 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
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.
 End of changes. 59 change blocks. 
295 lines changed or deleted 265 lines changed or added

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