diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc3445.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc3445.txt | 563 |
1 files changed, 0 insertions, 563 deletions
diff --git a/contrib/bind9/doc/rfc/rfc3445.txt b/contrib/bind9/doc/rfc/rfc3445.txt deleted file mode 100644 index 67f9b2d..0000000 --- a/contrib/bind9/doc/rfc/rfc3445.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -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] - |
