idnits 2.17.1 draft-reid-dnsext-rkey-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 250. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 261. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 274. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 4, 2008) is 5775 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-timms-enum-encrypt - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.timms-enum-encrypt' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT J. Reid 3 Internet-Draft Telnic Ltd 4 Intended status: Standards Track J. Schlyter 5 Expires: January 5, 2009 Kirei AB 6 B. Timms 7 Telnic Ltd 8 July 4, 2008 10 The RKEY DNS Resource Record 11 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 5, 2009. 38 Abstract 40 A DNS Resource record which can be used to encrypt NAPTR records is 41 described in this document. 43 Table of Contents 45 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 3. Definition of RKEY Resource Record . . . . . . . . . . . . . . 5 48 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 49 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 50 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 51 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 52 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 53 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 55 Intellectual Property and Copyright Statements . . . . . . . . . . 12 57 1. Terminology 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in BCP 14, RFC2119 62 [refs.RFC2119]. 64 2. Introduction 66 The DNS protocol is defined in RFC1034 [refs.RFC1034], RFC1035 67 [refs.RFC1035] and clarified in RFC2181 [refs.RFC2181]. The scope 68 for using DNS KEY Resource Records was limited in RFC3445 69 [refs.RFC3445] to keys used by the Domain Name System Security 70 Extensions (DNSSEC) which is defined in RFC4033 [refs.RFC4033], 71 RFC4034 [refs.RFC4034] and RFC4035 [refs.RFC4035]. The original KEY 72 RR used sub-typing to store both DNSSEC keys and arbitrary 73 application keys. Storing both DNSSEC and application keys with the 74 same record type is a mistake so RFC3445 removed application keys 75 from the KEY record by redefining the Protocol Octet field in the KEY 76 RR Data. This means that any other uses of keying material in the 77 DNS need to define a new RRtype and mnemonic. 79 Although this document advocates the introduction of a new resource 80 record specifically to provide this type of information for keys that 81 encrypt NAPTR records [refs.RFC3403], it can be used for more 82 generalised encryption of DNS resource records. A scheme for 83 encrypting NAPTR records is outlined in draft-timms-encrypt-naptr 84 [I-D.timms-enum-encrypt]. 86 3. Definition of RKEY Resource Record 88 The RKEY RR uses an IANA-assigned type code and is used as resource 89 record for storing keys which encrypt NAPTR records. The RDATA for 90 an RKEY RR consists of flags, a protocol octet, the algorithm number 91 octet, and the public key itself. The format is as follows: 93 RKEY RDATA format 95 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 96 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 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | flags | protocol | algorithm | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | / 101 / public key / 102 / / 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 All bits of the flags field are reserved and MUST be zero. The 106 protocol field MUST be set to 1. The algorithm and public key fields 107 are identical to the definitions used in RFC4034 [refs.RFC4034]. 109 4. Security Considerations 111 The format and correct usage of DNSSEC keys is not changed by this 112 document and no new security considerations are introduced. 114 5. IANA Considerations 116 IANA is requested to issue a new type code and mnemonic for the 117 proposed resource record. No other IANA services are required by 118 this document. 120 6. Acknowledgements 122 The authors would like to thank Klaus Malorny, Lawrence Conroy and 123 Roy Arends for their constructive suggestions to this document and 124 for helping to identify potential uses for the proposed record type. 126 7. References 128 7.1. Normative References 130 [I-D.timms-enum-encrypt] 131 Timms, B., Reid, J., and J. Schlyter, "IANA Registration 132 for Encrypted ENUM", draft-timms-enum-encrypt-00 (work in 133 progress), November 2007. 135 [refs.RFC1034] 136 Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", 137 RFC 1034, November 1987. 139 [refs.RFC1035] 140 Mockapetris, P., "Domain names - implementation and 141 specification", STD 13, RFC 1035, November 1987. 143 [refs.RFC1123] 144 Braden, R., "Requirements for Internet Hosts -- 145 Application and Support", RFC 1123, October 1989. 147 [refs.RFC2181] 148 Elz, R. and R. Bush, "Clarifications to the DNS 149 Specification", RFC 2181, July 1997. 151 [refs.RFC3403] 152 Mealling, M., "Dynamic Delegation Discovery System (DDDS) 153 Part Three: The Domain Name System (DNS) Database", 154 RFC 3403, October 2002. 156 [refs.RFC3445] 157 Massey, D. and S. Rose, "Limiting the Scope of the KEY 158 Resource Record (RR)", RFC 3445, December 2002. 160 [refs.RFC3986] 161 Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 162 Resource Identifier (URI): Generic Syntax", STD 66, 163 RFC 3986, January 2005. 165 [refs.RFC4033] 166 Arends, R., Austein, R., Larson, M., Massey, D., and S. 167 Rose, "DNS Security Introduction and Requirements", 168 RFC 4033, March 2005. 170 [refs.RFC4034] 171 Arends, R., Austein, R., Larson, M., Massey, D., and S. 172 Rose, "Resource Records for the DNS Security Extensions", 173 RFC 4034, March 2005. 175 [refs.RFC4035] 176 Arends, R., Austein, R., Larson, M., Massey, D., and S. 177 Rose, "Protocol Modifications for the DNS Security 178 Extensions", RFC 4035, March 2005. 180 7.2. Informative References 182 [refs.RFC2026] 183 Bradner, S., "The Internet Standards Process -- Revision 184 3", RFC 2026, BCP 9, October 1996. 186 [refs.RFC2119] 187 Bradner, S., "Key words for use in RFCs to Indicate 188 Requirement Levels", RFC 2119, BCP 14, March 1997. 190 [refs.RFC3761] 191 Faltstrom, P. and M. Mealling, "The E.164 to Uniform 192 Resource Identifiers (URI) Dynamic Delegation Discovery 193 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 195 [refs.RFC3833] 196 Atkins, D. and R. Austein, "Threat Analysis of the Domain 197 Name System (DNS)", RFC 3833, August 2004. 199 [refs.RFC3978] 200 Bradner, S., "IETF Rights in Contributions", BCP 78, 201 RFC 3978, March 2005. 203 [refs.RFC3979] 204 Bradner, S., "Intellectual Property Rights in IETF 205 Technology", BCP 79, RFC 3979, March 2005. 207 Authors' Addresses 209 Jim Reid 210 Telnic Ltd 211 6 Langside Court 212 Bothwell, SCOTLAND 213 United Kingdom 215 Phone: +44 20 7467 6400 216 Email: jim@telnic.org 218 Jakob Schlyter 219 Kirei AB 220 PO Box 53204 221 Goteborg, SE 40016 222 Sweden 224 Phone: +46 31 787 8007 225 Email: jakob@kirei.se 227 Ben Timms 228 Telnic Ltd 229 37 Percy Street 230 London, W1T 2DJ 231 United Kingdom 233 Phone: +44 20 7467 6450 234 Email: btimms@telnic.org 236 Full Copyright Statement 238 Copyright (C) The IETF Trust (2008). 240 This document is subject to the rights, licenses and restrictions 241 contained in BCP 78, and except as set forth therein, the authors 242 retain all their rights. 244 This document and the information contained herein are provided on an 245 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 246 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 247 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 248 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 249 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 250 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 252 Intellectual Property 254 The IETF takes no position regarding the validity or scope of any 255 Intellectual Property Rights or other rights that might be claimed to 256 pertain to the implementation or use of the technology described in 257 this document or the extent to which any license under such rights 258 might or might not be available; nor does it represent that it has 259 made any independent effort to identify any such rights. Information 260 on the procedures with respect to rights in RFC documents can be 261 found in BCP 78 and BCP 79. 263 Copies of IPR disclosures made to the IETF Secretariat and any 264 assurances of licenses to be made available, or the result of an 265 attempt made to obtain a general license or permission for the use of 266 such proprietary rights by implementers or users of this 267 specification can be obtained from the IETF on-line IPR repository at 268 http://www.ietf.org/ipr. 270 The IETF invites any interested party to bring to its attention any 271 copyrights, patents or patent applications, or other proprietary 272 rights that may cover technology that may be required to implement 273 this standard. Please address the information to the IETF at 274 ietf-ipr@ietf.org.