diff options
Diffstat (limited to 'doc/rfc/rfc3445.txt')
| -rw-r--r-- | doc/rfc/rfc3445.txt | 563 |
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc3445.txt b/doc/rfc/rfc3445.txt new file mode 100644 index 0000000..67f9b2d --- /dev/null +++ b/doc/rfc/rfc3445.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group D. Massey +Request for Comments: 3445 USC/ISI +Updates: 2535 S. Rose +Category: Standards Track NIST + December 2002 + + + Limiting the Scope of the KEY Resource Record (RR) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document limits the Domain Name System (DNS) KEY Resource Record + (RR) to only keys used by the Domain Name System Security Extensions + (DNSSEC). The original KEY RR used sub-typing to store both DNSSEC + keys and arbitrary application keys. Storing both DNSSEC and + application keys with the same record type is a mistake. This + document removes application keys from the KEY record by redefining + the Protocol Octet field in the KEY RR Data. As a result of removing + application keys, all but one of the flags in the KEY record become + unnecessary and are redefined. Three existing application key sub- + types are changed to reserved, but the format of the KEY record is + not changed. This document updates RFC 2535. + +1. Introduction + + This document limits the scope of the KEY Resource Record (RR). The + KEY RR was defined in [3] and used resource record sub-typing to hold + arbitrary public keys such as Email, IPSEC, DNSSEC, and TLS keys. + This document eliminates the existing Email, IPSEC, and TLS sub-types + and prohibits the introduction of new sub-types. DNSSEC will be the + only allowable sub-type for the KEY RR (hence sub-typing is + essentially eliminated) and all but one of the KEY RR flags are also + eliminated. + + + + + + +Massey & Rose Standards Track [Page 1] + +RFC 3445 Limiting the KEY Resource Record (RR) December 2002 + + + Section 2 presents the motivation for restricting the KEY record and + Section 3 defines the revised KEY RR. Sections 4 and 5 summarize the + changes from RFC 2535 and discuss backwards compatibility. It is + important to note that this document restricts the use of the KEY RR + and simplifies the flags, but does not change the definition or use + of DNSSEC keys. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + +2. Motivation for Restricting the KEY RR + + The KEY RR RDATA [3] consists of Flags, a Protocol Octet, an + Algorithm type, and a Public Key. The Protocol Octet identifies the + KEY RR sub-type. DNSSEC public keys are stored in the KEY RR using a + Protocol Octet value of 3. Email, IPSEC, and TLS keys were also + stored in the KEY RR and used Protocol Octet values of 1,2, and 4 + (respectively). Protocol Octet values 5-254 were available for + assignment by IANA and values were requested (but not assigned) for + applications such as SSH. + + Any use of sub-typing has inherent limitations. A resolver can not + specify the desired sub-type in a DNS query and most DNS operations + apply only to resource records sets. For example, a resolver can not + directly request the DNSSEC subtype KEY RRs. Instead, the resolver + has to request all KEY RRs associated with a DNS name and then search + the set for the desired DNSSEC sub-type. DNSSEC signatures also + apply to the set of all KEY RRs associated with the DNS name, + regardless of sub-type. + + In the case of the KEY RR, the inherent sub-type limitations are + exacerbated since the sub-type is used to distinguish between DNSSEC + keys and application keys. DNSSEC keys and application keys differ + in virtually every respect and Section 2.1 discusses these + differences in more detail. Combining these very different types of + keys into a single sub-typed resource record adds unnecessary + complexity and increases the potential for implementation and + deployment errors. Limited experimental deployment has shown that + application keys stored in KEY RRs are problematic. + + This document addresses these issues by removing all application keys + from the KEY RR. Note that the scope of this document is strictly + limited to the KEY RR and this document does not endorse or restrict + the storage of application keys in other, yet undefined, resource + records. + + + + + +Massey & Rose Standards Track [Page 2] + +RFC 3445 Limiting the KEY Resource Record (RR) December 2002 + + +2.1 Differences Between DNSSEC and Application Keys + + DNSSEC keys are an essential part of the DNSSEC protocol and are used + by both name servers and resolvers in order to perform DNS tasks. A + DNS zone key, used to sign and authenticate RR sets, is the most + common example of a DNSSEC key. SIG(0) [4] and TKEY [3] also use + DNSSEC keys. + + Application keys such as Email keys, IPSEC keys, and TLS keys are + simply another type of data. These keys have no special meaning to a + name server or resolver. + + The following table summarizes some of the differences between DNSSEC + keys and application keys: + + 1. They serve different purposes. + + 2. They are managed by different administrators. + + 3. They are authenticated according to different rules. + + 4. Nameservers use different rules when including them in + responses. + + 5. Resolvers process them in different ways. + + 6. Faults/key compromises have different consequences. + + 1. The purpose of a DNSSEC key is to sign resource records + associated with a DNS zone (or generate DNS transaction signatures in + the case of SIG(0)/TKEY). But the purpose of an application key is + specific to the application. Application keys, such as PGP/email, + IPSEC, TLS, and SSH keys, are not a mandatory part of any zone and + the purpose and proper use of application keys is outside the scope + of DNS. + + 2. DNSSEC keys are managed by DNS administrators, but application + keys are managed by application administrators. The DNS zone + administrator determines the key lifetime, handles any suspected key + compromises, and manages any DNSSEC key changes. Likewise, the + application administrator is responsible for the same functions for + the application keys related to the application. For example, a user + typically manages her own PGP key and a server manages its own TLS + key. Application key management tasks are outside the scope of DNS + administration. + + + + + + +Massey & Rose Standards Track [Page 3] + +RFC 3445 Limiting the KEY Resource Record (RR) December 2002 + + + 3. DNSSEC zone keys are used to authenticate application keys, but + by definition, application keys are not allowed to authenticate DNS + zone keys. A DNS zone key is either configured as a trusted key or + authenticated by constructing a chain of trust in the DNS hierarchy. + To participate in the chain of trust, a DNS zone needs to exchange + zone key information with its parent zone [3]. Application keys are + not configured as trusted keys in the DNS and are never part of any + DNS chain of trust. Application key data is not needed by the parent + and does not need to be exchanged with the parent zone for secure DNS + resolution to work. A resolver considers an application key RRset as + authenticated DNS information if it has a valid signature from the + local DNS zone keys, but applications could impose additional + security requirements before the application key is accepted as + authentic for use with the application. + + 4. It may be useful for nameservers to include DNS zone keys in the + additional section of a response, but application keys are typically + not useful unless they have been specifically requested. For + example, it could be useful to include the example.com zone key along + with a response that contains the www.example.com A record and SIG + record. A secure resolver will need the example.com zone key in + order to check the SIG and authenticate the www.example.com A record. + It is typically not useful to include the IPSEC, email, and TLS keys + along with the A record. Note that by placing application keys in + the KEY record, a resolver would need the IPSEC, email, TLS, and + other key associated with example.com if the resolver intends to + authenticate the example.com zone key (since signatures only apply to + the entire KEY RR set). Depending on the number of protocols + involved, the KEY RR set could grow unwieldy for resolvers, and DNS + administrators to manage. + + 5. DNS zone keys require special handling by resolvers, but + application keys are treated the same as any other type of DNS data. + The DNSSEC keys are of no value to end applications, unless the + applications plan to do their own DNS authentication. By definition, + secure resolvers are not allowed to use application keys as part of + the authentication process. Application keys have no unique meaning + to resolvers and are only useful to the application requesting the + key. Note that if sub-types are used to identify the application + key, then either the interface to the resolver needs to specify the + sub-type or the application needs to be able to accept all KEY RRs + and pick out the desired sub-type. + + 6. A fault or compromise of a DNS zone key can lead to invalid or + forged DNS data, but a fault or compromise of an application key + should have no impact on other DNS data. Incorrectly adding or + changing a DNS zone key can invalidate all of the DNS data in the + zone and in all of its subzones. By using a compromised key, an + + + +Massey & Rose Standards Track [Page 4] + +RFC 3445 Limiting the KEY Resource Record (RR) December 2002 + + + attacker can forge data from the effected zone and for any of its + sub-zones. A fault or compromise of an application key has + implications for that application, but it should not have an impact + on the DNS. Note that application key faults and key compromises can + have an impact on the entire DNS if the application key and DNS zone + keys are both stored in the KEY RR. + + In summary, DNSSEC keys and application keys differ in most every + respect. DNSSEC keys are an essential part of the DNS infrastructure + and require special handling by DNS administrators and DNS resolvers. + Application keys are simply another type of data and have no special + meaning to DNS administrators or resolvers. These two different + types of data do not belong in the same resource record. + +3. Definition of the KEY RR + + The KEY RR uses type 25 and is used as resource record for storing + DNSSEC keys. The RDATA for a KEY RR consists of flags, a protocol + octet, the algorithm number octet, and the public key itself. The + format is as follows: + + --------------------------------------------------------------------- + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | flags | protocol | algorithm | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / public key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + KEY RR Format + + --------------------------------------------------------------------- + + In the flags field, all bits except bit 7 are reserved and MUST be + zero. If Bit 7 (Zone bit) is set to 1, then the KEY is a DNS Zone + key. If Bit 7 is set to 0, the KEY is not a zone key. SIG(0)/TKEY + are examples of DNSSEC keys that are not zone keys. + + The protocol field MUST be set to 3. + + The algorithm and public key fields are not changed. + + + + + +Massey & Rose Standards Track [Page 5] + +RFC 3445 Limiting the KEY Resource Record (RR) December 2002 + + +4. Changes from RFC 2535 KEY RR + + The KEY RDATA format is not changed. + + All flags except for the zone key flag are eliminated: + + The A/C bits (bits 0 and 1) are eliminated. They MUST be set to 0 + and MUST be ignored by the receiver. + + The extended flags bit (bit 3) is eliminated. It MUST be set to 0 + and MUST be ignored by the receiver. + + The host/user bit (bit 6) is eliminated. It MUST be set to 0 and + MUST be ignored by the receiver. + + The zone bit (bit 7) remains unchanged. + + The signatory field (bits 12-15) are eliminated by [5]. They MUST + be set to 0 and MUST be ignored by the receiver. + + Bits 2,4,5,8,9,10,11 remain unchanged. They are reserved, MUST be + set to zero and MUST be ignored by the receiver. + + Assignment of any future KEY RR Flag values requires a standards + action. + + All Protocol Octet values except DNSSEC (3) are eliminated: + + Value 1 (Email) is renamed to RESERVED. + + Value 2 (IPSEC) is renamed to RESERVED. + + Value 3 (DNSSEC) is unchanged. + + Value 4 (TLS) is renamed to RESERVED. + + Value 5-254 remains unchanged (reserved). + + Value 255 (ANY) is renamed to RESERVED. + + The authoritative data for a zone MUST NOT include any KEY records + with a protocol octet other than 3. The registry maintained by IANA + for protocol values is closed for new assignments. + + Name servers and resolvers SHOULD accept KEY RR sets that contain KEY + RRs with a value other than 3. If out of date DNS zones contain + deprecated KEY RRs with a protocol octet value other than 3, then + simply dropping the deprecated KEY RRs from the KEY RR set would + + + +Massey & Rose Standards Track [Page 6] + +RFC 3445 Limiting the KEY Resource Record (RR) December 2002 + + + invalidate any associated SIG record(s) and could create caching + consistency problems. Note that KEY RRs with a protocol octet value + other than 3 MUST NOT be used to authenticate DNS data. + + The algorithm and public key fields are not changed. + +5. Backward Compatibility + + DNSSEC zone KEY RRs are not changed and remain backwards compatible. + A properly formatted RFC 2535 zone KEY would have all flag bits, + other than the Zone Bit (Bit 7), set to 0 and would have the Protocol + Octet set to 3. This remains true under the restricted KEY. + + DNSSEC non-zone KEY RRs (SIG(0)/TKEY keys) are backwards compatible, + but the distinction between host and user keys (flag bit 6) is lost. + + No backwards compatibility is provided for application keys. Any + Email, IPSEC, or TLS keys are now deprecated. Storing application + keys in the KEY RR created problems such as keys at the apex and + large RR sets and some change in the definition and/or usage of the + KEY RR would have been required even if the approach described here + were not adopted. + + Overall, existing nameservers and resolvers will continue to + correctly process KEY RRs with a sub-type of DNSSEC keys. + +6. Storing Application Keys in the DNS + + The scope of this document is strictly limited to the KEY record. + This document prohibits storing application keys in the KEY record, + but it does not endorse or restrict the storing application keys in + other record types. Other documents can describe how DNS handles + application keys. + +7. IANA Considerations + + RFC 2535 created an IANA registry for DNS KEY RR Protocol Octet + values. Values 1, 2, 3, 4, and 255 were assigned by RFC 2535 and + values 5-254 were made available for assignment by IANA. This + document makes two sets of changes to this registry. + + First, this document re-assigns DNS KEY RR Protocol Octet values 1, + 2, 4, and 255 to "reserved". DNS Key RR Protocol Octet Value 3 + remains unchanged as "DNSSEC". + + + + + + + +Massey & Rose Standards Track [Page 7] + +RFC 3445 Limiting the KEY Resource Record (RR) December 2002 + + + Second, new values are no longer available for assignment by IANA and + this document closes the IANA registry for DNS KEY RR Protocol Octet + Values. Assignment of any future KEY RR Protocol Octet values + requires a standards action. + +8. Security Considerations + + This document eliminates potential security problems that could arise + due to the coupling of DNS zone keys and application keys. Prior to + the change described in this document, a correctly authenticated KEY + set could include both application keys and DNSSEC keys. This + document restricts the KEY RR to DNS security usage only. This is an + attempt to simplify the security model and make it less user-error + prone. If one of the application keys is compromised, it could be + used as a false zone key to create false DNS signatures (SIG + records). Resolvers that do not carefully check the KEY sub-type + could believe these false signatures and incorrectly authenticate DNS + data. With this change, application keys cannot appear in an + authenticated KEY set and this vulnerability is eliminated. + + The format and correct usage of DNSSEC keys is not changed by this + document and no new security considerations are introduced. + +9. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [3] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC + 2930, September 2000. + + [4] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s)", RFC 2931, September 2000. + + [5] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + + + + + + + + + + + +Massey & Rose Standards Track [Page 8] + +RFC 3445 Limiting the KEY Resource Record (RR) December 2002 + + +10. Authors' Addresses + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-3460 + USA + + EMail: scott.rose@nist.gov + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Massey & Rose Standards Track [Page 9] + +RFC 3445 Limiting the KEY Resource Record (RR) December 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Massey & Rose Standards Track [Page 10] + |