+++ /dev/null
-
-
-
-INTERNET-DRAFT 31 January 2002
-
-
-
- D. Massey
- USC/ISI
- S. Rose
- NIST
-
-
-
- Limiting the Scope of the KEY Resource Record
-
- draft-ietf-dnsext-restrict-key-for-dnssec-01.txt
-
-
-
- Status of this Document
-
-
-
-This document is an Internet-Draft and is in full conformance with
-all provisions of Section 10 of RFC2026. Distribution of this document
-is unlimited. Comments regarding this document should be sent to
-the author.
-
-Internet-Drafts are working 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 months
-and may be updated, replaced, or obsoleted by other documents at
-any time. It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-
-
- Abstract
-
-
- This document limits the KEY resource record to only DNSSEC
- keys. The original KEY resource record used sub-typing
- to store both DNSSEC keys and arbitrary application keys.
- Storing both DNSSEC and application keys in one record was
- a mistake. This document removes application keys from
- the KEY record by redefining the Protocol Octet field in
- the KEY RDATA. As a result of removing application keys,
- all but one of the flags in the KEY record become unnecessary
- and are removed. Three existing application key sub-types
- are changed to historic, but the format of the KEY record
- is not changed. This document updates RFC 2535.
-
-
-
-Massey/Rose Page 1
-\f
-
-
-INTERNET-DRAFT 31 January 2002
-
-
-
-1 Introduction
-
-
-
-This document limits the scope the KEY resource record. The KEY
-resource record was defined in [DNSSEC] 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 record (hence
-sub-typing is essentially eliminated) and all but one of the KEY
-record flags are also eliminated.
-
-Section 2 presents the motivation for restricting the KEY record
-and Section ?? defines the revised KEY record. Section 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 record and simplifies the flabs, does not change DNSSEC keys.
-
-
-
-2 Motivation for Restricting the KEY Record
-
-
-
-The KEY record RDATA [DNSSEC] consists of flags, a Protocol Octet,
-an Algorithm type, and a public key. The Protocol Octet identifies
-the KEY record sub-type. DNSSEC public keys are stored in the KEY
-using a Protocol Octet value of 3. Email, IPSEC, and TLS keys are
-also stored in the KEY resource record and using Protocol Octet values
-of 1,2, and 4 (respectively). Protocol Octet values 5-254 are available
-for assignment by IANA and values have been 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 a example, a resolver can
-not directly request KEY records with a particular sub-type. Instead,
-the resolver must request all KEY records associated with a DNS name
-and then search the set for the desired sub-type. DNSSEC signatures
-also apply to the set of all KEY resource records associated with
-the DNS name, regardless of sub-type.
-
-In the case of the KEY record, 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
-
-
-
-Massey/Rose Page 2
-\f
-
-
-INTERNET-DRAFT 31 January 2002
-
-
-
-errors. Limited experimental deployment has shown that application
-keys stored in KEY records are problematic.
-
-This document addresses these issues by removing all application keys
-from the KEY resource record. Note that the scope of this document
-is strictly limited to the KEY record and this document does not
-endorse or restrict the storage of application keys in other resource
-records.
-
-
-
-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, used to sign and authenticate RR sets, is most common
-example of a DNSSEC key. SIG(0) and TKEY also use DNSSEC keys.
-
-Application keys such as Email keys, IPSEC keys, and TLS keys and
-are simply another type data. These keys have no special meaning
-to a name server or resolver.
-
-
-
- o They serve different purposes.
-
- o They are managed by different administrators.
-
- o They are authenticated according to different rules.
-
- o Nameservers use different rules when including them in responses.
-
- o Resolvers process them in different ways.
-
- o Faults/key compromises have different consequences.
-
-
-
-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.
-
-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 Page 3
-\f
-
-
-INTERNET-DRAFT 31 January 2002
-
-
-
-DNSSEC zone keys are used to authenticate application keys, but application
-keys MUST NOT be used to authenticate DNS zone keys. A DNS zone
-key is either configured as trusted key or authenticated by constructing
-a chain of trust in the DNS hierarchy. To participate in the chain
-of trust, a DNS zone must exchange zone key information with its
-parent zone [DNSSEC]. Application keys are not configured as trusted
-keys in the DNS and are never part of any DNS chain of trust. Application
-key data should not be exchanged with the parent zone. A resolver
-considers an application key authenticated if it has a valid signature
-from the local DNS zone keys, but applications may impose additional
-requirements before the application key is accepted as authentic.
-
-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 may be useful to include the isi.edu zone key along with a response
-that contain the www.isi.edu A record and SIG record. A secure resolver
-will need the isi.edu zone key in order to check the SIG and authenticate
-the www.isi.edu A record. It is typical 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 will need
-the IPSEC, email, TLS, and other key associated with isi.edu if the
-resolver intends to authenticate the isi.edu zone key (since signatures
-only apply to the entire KEY set).
-
-DNS zone keys require special handling by resolvers, but application
-keys should be 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. Secure resolvers MUST NOT
-use application keys as part of the authentication process. Application
-keys have no unique value 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 must specify the sub-type or the application must be able
-to accept all KEY records and pick out the desired the sub-type.
-
-A fault or compromise of 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 zone and in
-all of its subzones. By using a compromised key, an attacker can
-forge data from the effected zone and any 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 record.
-
-
-
-Massey/Rose Page 4
-\f
-
-
-INTERNET-DRAFT 31 January 2002
-
-
-
-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 Resource Record
-
-
-
-The KEY record 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 /
-/ /
-/ /
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-
-
-In the flags field, all bits except bit 7 are reserved should 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.
-
-
-
-4 Changes from RFC 2535 KEY Record
-
-
-
-The KEY RDATA format is not changed.
-
-All flags except for the zone key flag are eliminated:
-
-
- o The A/C bits (bits 0 and 1) are eliminated and must be 0.
-
- o The extended flags bit (bit 3) is eliminated and must be 0.
-
- o The host/user bit (bit 6) is eliminated and must be 0.
-
-
-
-Massey/Rose Page 5
-\f
-
-
-INTERNET-DRAFT 31 January 2002
-
-
-
- o The zone bit (bit 7) remains unchanged.
-
- o The signatory field (bits 12-15) are eliminated by [SDU] and
- must be 0.
-
- o Bits 2,4,5,8,9,10,11 remain unchanged. They are reserved and
- must be zero.
-
-
-
-All Protocol Octet values except DNSSEC (3) are eliminated:
-
-
-
- o Value 1 (Email) is renamed to reserved.
-
- o Value 2 (IPSEC) is renamed to reserved.
-
- o Value 3 (DNSSEC) is unchanged.
-
- o Value 4 (TLS) is renamed to reserved.
-
- o Value 5-254 remains unchanged (reserved).
-
- o Value 255 (ANY) is renamed to reserved.
-
-
-
-Name servers and resolvers SHOULD reject any KEY with a Protocol
-other than 3.
-
-The algorithm and public key fields are not changed.
-
-
-
-5 Backward Compatibility
-
-
-
-No backwards compatibility is provided for application keys. Any
-Email, IPSEC, or TLS keys are now deprecated and SHOULD be rejected
-by name servers and resolvers. However, problems with applications
-keys (such as keys at the apex and large RR sets) and have already
-been identified some change in the definition and/or usage of the
-KEY record would be required even if the approach described here
-were not required.
-
-DNSSEC zone KEY records are not change 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 records (SIG(0)/TKEY keys) are backwards compatible,
-but the distinction between host and user keys (flag bit 6) is lost.
-
-Overall, existing nameservers and resolvers will continue to correctly
-process KEY records with a sub-type of DNSSEC keys.
-
-
-
-Massey/Rose Page 6
-\f
-
-
-INTERNET-DRAFT 31 January 2002
-
-
-
-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 should describe how DNS handles
-application keys.
-
-
-
-7 IANA Consideration
-
-
-
-KEY record Protocol Octet values 1,2,4, and 255 should be changed
-to reserved.
-
-Assignment of any future KEY record Protocol Octet values requires
-a standards action.
-
-
-
-8 Security Consideration
-
-
-
-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 the document, a correctly authenticated
-KEY set could include both application keys and DNSSEC keys. If
-one of the application keys is compromised, it could be used as a
-false zone key to create phony DNS signatures (SIG records). Resolvers
-that do not carefully check the KEY sub-type may 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 Intellectual Property
-
-
-
-The IETF takes no position regarding the validity or scope of any
-intellectual property or other rights that might be claimed to pertain
-to the implementation or use of the technology described in this
-document or the extent to which any license under such rights might
-or might not be available; neither does it represent that it has
-made any effort to identify any such rights. Information on the
-IETF's procedures with respect to rights in standards-track and standards-
-related documentation can be found in BCP-11.
-
-
-
-Massey/Rose Page 7
-\f
-
-
-INTERNET-DRAFT 31 January 2002
-
-
-
-Copies of claims of rights made available for publication and any
-assurances of licenses to be made available, or the result of an
-attempt made to obtain a general license or permission for the use
-of such proprietary rights by implementors or users of this specification
-can be obtained from the IETF Secretariat.
-
-The IETF invites any interested party to bring to its attention any
-copyrights, patents or patent applications, or other proprietary rights
-which may cover technology that may be required to practice this
-standard. Please address the information to the IETF Executive Director.
-
-
-
-10 References
-
-
-
-[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC
-2535, March 1999.
-
-[SDU] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update",
-RFC 3007, November 2000.
-
-
-
-11 Author Information
-
-
-Daniel Massey <masseyd@isi.edu>
-USC Information Sciences Institute
-3811 North Fairfax Drive, Suite 200
-Arlington, VA 22203
-
-
-Scott Rose <scott.rose@nist.gov>
-National Institute for Standards and Technology
-Gaithersburg, MD
-
-
-
-Full Copyright Statement
-
-
-
-Copyright (C) The Internet Society (2001). 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 copy- right 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
-
-
-
-Massey/Rose Page 8
-\f
-
-
-INTERNET-DRAFT 31 January 2002
-
-
-
-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."
-
-
-
-Massey/Rose Page 9
--- /dev/null
+
+
+DNS Extensions D. Massey
+Internet-Draft USC/ISI
+Expires: March 11, 2003 S. Rose
+ NIST
+ September 10, 2002
+
+
+ Limiting the Scope of the KEY Resource Record
+ out
+
+ draft-ietf-dnsext-restrict-key-for-dnssec-04.txt
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working 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 months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at http://
+ www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on March 11, 2003.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document limits the Domain Name System KEY resource record to
+ only keys used by the Domain Name System Security Extensions
+ (DNSSEC). The original KEY resource record 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 Resource Record 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
+
+
+
+Massey & Rose Expires March 11, 2003 [Page 1]
+\f
+Internet-Draft Limiting the Scope of the KEY Resource Record September 2002
+
+
+ the KEY record is not changed. This document updates RFC 2535.
+
+ 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].
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Motivation for Restricting the KEY RR . . . . . . . . . . . . 4
+ 2.1 Differences Between DNSSEC and Application Keys . . . . . . . 4
+ 3. Definition of the KEY Resource Record . . . . . . . . . . . . 7
+ 4. Changes from RFC 2535 KEY RR . . . . . . . . . . . . . . . . . 8
+ 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 10
+ 6. Storing Application Keys in the DNS . . . . . . . . . . . . . 11
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
+ References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Massey & Rose Expires March 11, 2003 [Page 2]
+\f
+Internet-Draft Limiting the Scope of the KEY Resource Record September 2002
+
+
+1. Introduction
+
+ This document limits the scope of the KEY resource record. The KEY
+ resource record 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Massey & Rose Expires March 11, 2003 [Page 3]
+\f
+Internet-Draft Limiting the Scope of the KEY Resource Record September 2002
+
+
+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 resource records 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 resource record. 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.
+
+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 data. These keys have no special meaning to a
+ name server or resolver.
+
+
+
+
+Massey & Rose Expires March 11, 2003 [Page 4]
+\f
+Internet-Draft Limiting the Scope of the KEY Resource Record September 2002
+
+
+ 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.
+
+ 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 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.
+
+
+
+
+Massey & Rose Expires March 11, 2003 [Page 5]
+\f
+Internet-Draft Limiting the Scope of the KEY Resource Record September 2002
+
+
+ 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 the 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 zone
+ and in all of its subzones. By using a compromised key, an attacker
+ can forge data from the effected zone and any 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.
+
+
+
+
+
+Massey & Rose Expires March 11, 2003 [Page 6]
+\f
+Internet-Draft Limiting the Scope of the KEY Resource Record September 2002
+
+
+3. Definition of the KEY Resource Record
+
+ 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 Expires March 11, 2003 [Page 7]
+\f
+Internet-Draft Limiting the Scope of the KEY Resource Record September 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 assignemnts.
+
+ 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 Expires March 11, 2003 [Page 8]
+\f
+Internet-Draft Limiting the Scope of the KEY Resource Record September 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Massey & Rose Expires March 11, 2003 [Page 9]
+\f
+Internet-Draft Limiting the Scope of the KEY Resource Record September 2002
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Massey & Rose Expires March 11, 2003 [Page 10]
+\f
+Internet-Draft Limiting the Scope of the KEY Resource Record September 2002
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Massey & Rose Expires March 11, 2003 [Page 11]
+\f
+Internet-Draft Limiting the Scope of the KEY Resource Record September 2002
+
+
+7. IANA Considerations
+
+ RFC 2535 created an IANA registry for DNS KEY Resource Record
+ Protocol Octet values. Values to 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 Resource Record Protocol
+ Octet values 1, 2, 4, and 255 to ``reserved''. DNS Key Resource
+ Record Protocol Octet Value 3 remains unchanged as ``DNSSEC''.
+
+ Second, new values are no longer available for assignment by IANA and
+ this document closes the IANA registry for DNS KEY Resource Record
+ Protocol Octet Values. Assignment of any future KEY Resource Record
+ Protocol Octet values requires a standards action.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Massey & Rose Expires March 11, 2003 [Page 12]
+\f
+Internet-Draft Limiting the Scope of the KEY Resource Record September 2002
+
+
+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 draft
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Massey & Rose Expires March 11, 2003 [Page 13]
+\f
+Internet-Draft Limiting the Scope of the KEY Resource Record September 2002
+
+
+References (Normative)
+
+ [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.
+
+
+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 Expires March 11, 2003 [Page 14]
+\f
+Internet-Draft Limiting the Scope of the KEY Resource Record September 2002
+
+
+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 Expires March 11, 2003 [Page 15]
+\f
--- /dev/null
+Internet Engineering Task Force S. Thomson, Cisco
+INTERNET-DRAFT C. Huitema, Microsoft
+September 11, 2002 V. Ksinant, 6WIND
+Expires March 11, 2003 M. Souissi, AFNIC
+
+
+
+
+
+ DNS Extensions to support IP version 6
+ <draft-ietf-dnsext-rfc1886bis-00.txt>
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of [RFC2026].
+
+ Internet-Drafts are working 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 months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ To view the list Internet-Draft Shadow Directories, see
+ http://www.ietf.org/shadow.html.
+
+ This Internet Draft expires March 11, 2003.
+
+
+
+Abstract
+
+ This document defines the changes that need to be made to the Domain
+ Name System to support hosts running IP version 6 (IPv6). The
+ changes include a new resource record type to store an IPv6 address,
+ a new domain to support lookups based on an IPv6 address, and updated
+ definitions of existing query types that return Internet addresses as
+ part of additional section processing. The extensions are designed
+ to be compatible with existing applications and, in particular, DNS
+ implementations themselves.
+
+ This document updates RFC 1886 [5]. Changes mainly consist in
+ replacing the IP6.INT domain by IP6.ARPA as defined in RFC 3152 [6].
+
+
+
+
+
+
+draft-ietf-dnsext-rfc1886bis-00.txt [Page 1]
+\f
+INTERNET-DRAFT DNS Extensions to support IP version 6 September 2002
+
+
+Table of Contents
+
+ 1. Introduction............................................. 2
+ 2. New resource record definition and domain................ 2
+ 2.1. AAAA record type.................................... 3
+ 2.2. AAAA data format.................................... 3
+ 2.3. AAAA query.......................................... 3
+ 2.4. Textual format of AAAA records...................... 3
+ 2.5. IP6.ARPA domain..................................... 3
+ 3. Modifications to existing query types.................... 4
+ 4. Security Considerations.................................. 4
+ APPENDIX A: Changes from RFC-1886............................ 4
+ Acknowledgments.............................................. 5
+ References................................................... 5
+ Authors' Addresses........................................... 6
+ Full Copyright Statement..................................... 7
+
+
+1. INTRODUCTION
+
+ Current support for the storage of Internet addresses in the Domain
+ Name System (DNS)[1,2] cannot easily be extended to support IPv6
+ addresses[3] since applications assume that address queries return
+ 32-bit IPv4 addresses only.
+
+ To support the storage of IPv6 addresses we define the following
+ extensions:
+
+ o A new resource record type is defined to map a domain name to an
+ IPv6 address.
+
+ o A new domain is defined to support lookups based on address.
+
+ o Existing queries that perform additional section processing to
+ locate IPv4 addresses are redefined to perform additional
+ section processing on both IPv4 and IPv6 addresses.
+
+ The changes are designed to be compatible with existing software. The
+ existing support for IPv4 addresses is retained. Transition issues
+ related to the co-existence of both IPv4 and IPv6 addresses in DNS
+ are discussed in [4].
+
+
+2. NEW RESOURCE RECORD DEFINITION AND DOMAIN
+
+ A new record type is defined to store a host's IPv6 address. A host
+ that has more than one IPv6 address must have more than one such
+ record.
+
+draft-ietf-dnsext-rfc1886bis-00.txt [Page 2]
+\f
+INTERNET-DRAFT DNS Extensions to support IP version 6 September 2002
+
+2.1 AAAA record type
+
+ The AAAA resource record type is a new record specific to the
+ Internet class that stores a single IPv6 address.
+
+ The value of the type is 28 (decimal).
+
+
+2.2 AAAA data format
+
+ A 128 bit IPv6 address is encoded in the data portion of an AAAA
+ resource record in network byte order (high-order byte first).
+
+
+2.3 AAAA query
+
+ An AAAA query for a specified domain name in the Internet class
+ returns all associated AAAA resource records in the answer section of
+ a response.
+
+ A type AAAA query does not perform additional section processing.
+
+
+2.4 Textual format of AAAA records
+
+ The textual representation of the data portion of the AAAA resource
+ record used in a master database file is the textual representation
+ of a IPv6 address as defined in [3].
+
+
+2.5 IP6.ARPA Domain
+
+ A special domain is defined to look up a record given an address. The
+ intent of this domain is to provide a way of mapping an IPv6 address
+ to a host name, although it may be used for other purposes as well.
+ The domain is rooted at IP6.ARPA.
+
+ An IPv6 address is represented as a name in the IP6.ARPA domain by a
+ sequence of nibbles separated by dots with the suffix ".IP6.ARPA".
+ The sequence of nibbles is encoded in reverse order, i.e. the
+ low-order nibble is encoded first, followed by the next low-order
+ nibble and so on. Each nibble is represented by a hexadecimal digit.
+ For example, the inverse lookup domain name corresponding to the
+ address
+
+ 4321:0:1:2:3:4:567:89ab
+
+ would be
+
+b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.
+ ARPA.
+
+draft-ietf-dnsext-rfc1886bis-00.txt [Page 3]
+\f
+INTERNET-DRAFT DNS Extensions to support IP version 6 September 2002
+
+3. MODIFICATIONS TO EXISTING QUERY TYPES
+
+ All existing query types that perform type A additional section
+ processing, i.e. name server (NS), mail exchange (MX) and mailbox
+ (MB) query types, must be redefined to perform both type A and type
+ AAAA additional section processing. These new definitions mean that a
+ name server must add any relevant IPv4 addresses and any relevant
+ IPv6 addresses available locally to the additional section of a
+ response when processing any one of the above queries.
+
+
+4. SECURITY CONSIDERATIONS
+
+ Any information obtained from the DNS must be regarded as unsafe
+ unless techniques specified in [7] or [8] are used. The definitions
+ of the AAAA record type and of the IP6.ARPA domain do not change the
+ model for use of these techniques.
+
+ So, this specification is not believed to cause any new security
+ problems, nor to solve any existing ones.
+
+
+APPENDIX A: Changes from RFC 1886
+
+ The following changes were made from RFC 1886 "DNS Extensions to
+ support IP version 6":
+
+ - Replaced the "IP6.INT" domain by "IP6.ARPA".
+ - Added security considerations.
+ - Updated references :
+ * From RFC 1884 to RFC 2373 (IP Version 6 Addressing
+ Architecture).
+ * From "work in progress" to RFC 2893 (Transition Mechanisms for
+ IPv6 Hosts and Routers).
+ * Added reference to RFC 1886, RFC 3152, RFC 2535 and RFC 2845.
+ - Updated document abstract
+ - Added table of contents
+ - Added full copyright statement
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+draft-ietf-dnsext-rfc1886bis-00.txt [Page 4]
+\f
+INTERNET-DRAFT DNS Extensions to support IP version 6 September 2002
+
+Acknowledgements
+
+ Vladimir Ksinant and Mohsen Souissi would like to thank Sebastien
+ Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael
+ Guerin (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND),
+ Frederic Roudaut (IRISA) and G6 group for their help during the RFC
+ 1886 Interop tests sessions.
+
+ Many thanks to Alain Durand and Olafur Gudmundsson for their support.
+
+REFERENCES
+
+ [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
+ 13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+ [2] Mockapetris, P., "Domain Names - Implementation and Specifica-
+ tion", STD 13, RFC 1035, USC/Information Sciences Institute,
+ November 1987.
+
+ [3] Hinden, R., and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 2373, Nokia, Cisco, July 1998.
+ This RFC is being updated. The current draft is
+ "draft-ietf-ipngwg-addr-arch-v3-09.txt", Hinden, R., and
+ S. Deering, August 26, 2002
+
+ [4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6
+ Hosts and Routers", RFC 2893, FreeGate Corp., Sun Microsystems
+ Inc., August 2000.
+ This RFC is being updated. The current draft is
+ "draft-ietf-ngtrans-mech-v2-00.txt", Gilligan, R., and
+ E. Nordmark, July 17, 2002
+
+ [5] Thomson, S., and C. Huitema, "DNS Extensions to support IP
+ version 6", RFC 1886, Bellcore, INRIA, December 1995.
+
+ [6] Bush, R., "Delegation of IP6.ARPA", RFC 3152, RGnet, August
+ 2001.
+
+ [7] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, IBM, March 1999
+
+ [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+ "Secret Key Transaction Authentication for DNS (TSIG)",
+ RFC 2845, ISC, NAI Labs, Motorola, Nominum, May 2000.
+
+
+
+
+
+
+
+
+draft-ietf-dnsext-rfc1886bis-00.txt [Page 5]
+\f
+INTERNET-DRAFT DNS Extensions to support IP version 6 September 2002
+
+
+Authors' Addresses
+
+
+ Susan Thomson
+ Cisco Systems
+ 499 Thornall Street, 8th floor
+ Edison, NJ 08837
+ Telephone: 732-635-3086
+ Email: sethomso@cisco.com
+
+
+ Christian Huitema
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052-6399
+ Email: huitema@microsoft.com
+
+
+ Vladimir Ksinant
+ 6WIND S.A.
+ Immeuble Central Gare - Bat.C
+ 1, place Charles de Gaulle
+ 78180, Montigny-Le-Bretonneux - France
+ Phone: +33 1 39 30 92 36
+ Email: vladimir.ksinant@6wind.com
+
+
+ Mohsen Souissi
+ AFNIC
+ Immeuble International
+ 2, rue Stephenson,
+ 78181, Saint-Quentin en Yvelines Cedex - France
+ Phone: +33 1 39 30 83 40
+ Email: Mohsen.Souissi@nic.fr
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+draft-ietf-dnsext-rfc1886bis-00.txt [Page 6]
+\f
+INTERNET-DRAFT DNS Extensions to support IP version 6 September 2002
+
+Full Copyright Statement
+
+
+ Copyright (C) The Internet Society (date). 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 implmentation 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."
+
+ The IETF takes no position regarding the validity or scope of
+ any intellectual property or other rights that might be claimed
+ to pertain to the implementation or use of the technology
+ described in this document or the extent to which any license
+ under such rights might or might not be available; neither does
+ it represent that it has made any effort to identify any such
+ rights. Information on the IETF's procedures with respect to
+ rights in standards-track and standards-related documentation
+ can be found in BCP-11. Copies of claims of rights made
+ available for publication and any assurances of licenses to
+ be made available, or the result of an attempt made
+ to obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this
+ specification can be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its
+ attention any copyrights, patents or patent applications, or
+ other proprietary rights which may cover technology that may be
+ required to practice this standard. Please address the
+ information to the IETF Executive Director.
+
+
+draft-ietf-dnsext-rfc1886bis-00.txt [Page 7]
projects / thirdparty / bind9.git / commitdiff
