idnits 2.17.1 draft-ietf-ipseckey-rr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 24 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([9]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 13 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (March 30, 2003) is 7691 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) == Unused Reference: '1' is defined on line 248, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 254, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 257, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2065 (ref. '4') (Obsoleted by RFC 2535) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '6') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3445 (ref. '9') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSECKEY WG M. Richardson 3 Internet-Draft SSW 4 Expires: September 28, 2003 March 30, 2003 6 A method for storing IPsec keying material in DNS. 7 draft-ietf-ipseckey-rr-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on September 28, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document describes a new resource record for DNS. This record 39 may be used to store public keys for use in IPsec systems. 41 This record replaces the functionality of the sub-type #1 of the KEY 42 Resource Record, which has been proposed to be obsoleted by RFC3445 43 [9]. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 4 50 2.1 IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 4 51 2.2 RDATA format - precedence . . . . . . . . . . . . . . . . . . 4 52 2.3 RDATA format - algorithm type . . . . . . . . . . . . . . . . 4 53 2.4 RDATA format - gateway . . . . . . . . . . . . . . . . . . . . 4 54 2.5 RDATA format - RSA public key . . . . . . . . . . . . . . . . 5 55 2.6 RDATA format - DSA public key . . . . . . . . . . . . . . . . 5 56 3. Presentation formats . . . . . . . . . . . . . . . . . . . . . 6 57 3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . . 6 58 3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 62 Normative references . . . . . . . . . . . . . . . . . . . . . 11 63 Non-normative references . . . . . . . . . . . . . . . . . . . 12 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 65 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 67 1. Introduction 69 1.1 Overview 71 The IPSECKEY resource record (RR) is used to publish a public key 72 that is to be associated with a Domain Name System (DNS) name. This 73 can be the public key of a host, network, or application (in the case 74 of per-port keying). 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC2119 [5]. 80 An IPSECKEY resource record SHOULD be authenticated DNSSEC resource 81 record. 83 It is expected that there will often be multiple IPSECKEY resource 84 records at the same terminal node. This will be due to the presence 85 of multiple gateways and the need to rollover keys. 87 This resource record is class independent. 89 2. Storage formats 91 The type number for the IPSECKEY RR is TBD. 93 2.1 IPSECKEY RDATA format 95 The RDATA for an IPSECKEY RR consists of a precedence value, a public 96 key (and algorithm type), and an optional gateway address. 98 0 1 2 3 99 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 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | precedence | algorithm | gateway | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 103 ~ gateway ~ 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | / 106 / public key / 107 / / 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 110 2.2 RDATA format - precedence 112 This is an 8-bit precedence for this record. This is interpreted in 113 the same way as the PREFERENCE field described in section 3.3.9 of 114 RFC1035 [2]. 116 2.3 RDATA format - algorithm type 118 aThe algorithm type field indicates the type of key that is present 119 in the public key field. A positive number, larger than 0 identifies 120 an algorithm type. The following values, which have been previously 121 defined by IANA are useful (see RFC2535 [6]). 123 A value of 0 indicates that no key is present. 125 The following values defined by IANA are useful: 127 3 A DSA key is present, in the format defined in RFC2536 [7] 129 5 A RSA key is present, in the format defined in RFC3110 [8] 131 2.4 RDATA format - gateway 133 The gateway field indicates a gateway to which an IPsec tunnel may be 134 created in order to reach the entity holding this resource record. 136 The gateway field is a normal wire-encoded domain name (section 3.3 137 of RFC1035 [2]). 139 If no gateway is to be represented, then a null domain name MUST be 140 present. 142 It is a simple fully qualified domain name (FQDN). IP version 4 and 143 IP version 6 addresses may be represented using the reverse name 144 format, from in-addr.arpa. and ip6.arpa. 146 For instance, the IP version 4 address 192.0.1.2 is represented as 147 the domain name 2.1.0.192.in-addr.arpa. 149 2.5 RDATA format - RSA public key 151 If the algorithm type has the value 5 then public key portion 152 contains an RSA public key, encoded as described in secion 2 of 153 RFC3110 [8]. 155 RFC2065 limited the exponent and modulus to 2552 bits in length, and 156 RFC3110 to 4096 bits. No such limit is specified here for the 157 purposes of encoding and decoding. 159 The length in octets of the public exponent length is represented as 160 one octet if it is in the range of 1 to 255 and by a zero octet 161 followed by a two octet unsigned length if it is longer than 255 162 bytes. The public key modulus field is a multiprecision unsigned 163 integer. The length of the modulus can be determined from the 164 RDLENGTH and the preceding RDATA fields including the exponent. 166 Leading zero bytes are prohibited in the exponent and modulus. 168 2.6 RDATA format - DSA public key 170 If the algorithm type has the value 3, then public key portion 171 contains an DSA public key, encoded as described in RFC2536 [7]. 173 3. Presentation formats 175 3.1 Representation of IPSECKEY RRs 177 IPSECKEY RRs may appear as lines in a zone data master file. The 178 precedence, algorithm and gateway fields are REQUIRED. There base64 179 encoded public key block is OPTIONAL. 181 If no gateway is to be indicated, then the root (".") SHOULD be used. 183 3.2 Examples 185 An example of a node 192.2.0.38 that will accept IPsec tunnels on its 186 own behalf. 188 38.0.2.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 5 189 38.0.2.192.in-addr.arpa. 190 AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ 191 Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La 192 9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1 193 49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC 194 MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8 195 cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3 196 fejrfi1H ) 198 An example of a node, 192.2.0.38 that has published its key only. 200 38.0.2.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 5 201 . 202 AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ 203 Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La 204 9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1 205 49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC 206 MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8 207 cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3 208 fejrfi1H ) 210 An example of a node, 192.2.0.38 that has delegated authority to the 211 node 192.2.3.5. 213 38.0.2.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 5 214 5.3.2.192.in-addr.arpa. 215 AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ 216 Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La 217 9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1 218 49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC 219 MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8 220 cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3 221 fejrfi1H ) 223 An example of a node, 192.1.0.38 that has delegated authority to the 224 node with the identity "mygateway.example.com". 226 38.0.2.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 5 227 mygateway.example.com. 228 AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ 229 Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La 230 9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1 231 49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC 232 MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8 233 cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3 234 fejrfi1H ) 236 4. Security Considerations 237 5. IANA Considerations 239 IANA is asked to assign a resource record type number from the normal 240 resource record number space. 242 The algorithm field does not require any IANA action, as it is 243 inherited from DNS KEY algorithm values. 245 6. Acknowledgments 246 Normative references 248 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 249 13, RFC 1034, November 1987. 251 [2] Mockapetris, P., "Domain names - implementation and 252 specification", STD 13, RFC 1035, November 1987. 254 [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 255 9, RFC 2026, October 1996. 257 [4] Eastlake, D. and C. Kaufman, "Domain Name System Security 258 Extensions", RFC 2065, January 1997. 260 Non-normative references 262 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 263 Levels", BCP 14, RFC 2119, March 1997. 265 [6] Eastlake, D., "Domain Name System Security Extensions", RFC 266 2535, March 1999. 268 [7] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 269 (DNS)", RFC 2536, March 1999. 271 [8] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 272 System (DNS)", RFC 3110, May 2001. 274 [9] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource 275 Record (RR)", RFC 3445, December 2002. 277 Author's Address 279 Michael C. Richardson 280 Sandelman Software Works 281 470 Dawson Avenue 282 Ottawa, ON K1Z 5V7 283 CA 285 EMail: mcr@sandelman.ottawa.on.ca 286 URI: http://www.sandelman.ottawa.on.ca/ 288 Full Copyright Statement 290 Copyright (C) The Internet Society (2003). All Rights Reserved. 292 This document and translations of it may be copied and furnished to 293 others, and derivative works that comment on or otherwise explain it 294 or assist in its implementation may be prepared, copied, published 295 and distributed, in whole or in part, without restriction of any 296 kind, provided that the above copyright notice and this paragraph are 297 included on all such copies and derivative works. However, this 298 document itself may not be modified in any way, such as by removing 299 the copyright notice or references to the Internet Society or other 300 Internet organizations, except as needed for the purpose of 301 developing Internet standards in which case the procedures for 302 copyrights defined in the Internet Standards process must be 303 followed, or as required to translate it into languages other than 304 English. 306 The limited permissions granted above are perpetual and will not be 307 revoked by the Internet Society or its successors or assigns. 309 This document and the information contained herein is provided on an 310 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 311 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 312 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 313 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 314 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 316 Acknowledgement 318 Funding for the RFC Editor function is currently provided by the 319 Internet Society.