idnits 2.17.1 draft-timms-encrypt-naptr-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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 480. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 491. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 498. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 504. 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 (November 12, 2007) is 6003 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3761 (ref. '2') (Obsoleted by RFC 6116, RFC 6117) ** Obsolete normative reference: RFC 3548 (ref. '5') (Obsoleted by RFC 4648) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM B. Timms 3 Internet-Draft J. Reid 4 Intended status: Experimental Telnic 5 Expires: May 15, 2008 J. Schlyter 6 Kirei AB 7 November 12, 2007 9 IANA Registration for Encrypted ENUM 10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 15, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document requests IANA registration of the "X-Crypto" 44 Enumservice. This Enumservice indicates that its NAPTR holds a 45 Uniform Resource Identifier that carries encrypted content from the 46 fields of another (unpublished) Protected NAPTR, for use in E.164 47 Number Mapping (ENUM). 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. The problem . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1.1. The requirements . . . . . . . . . . . . . . . . . . . 3 54 1.2. The solution . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2.1. Protected fields . . . . . . . . . . . . . . . . . . . 4 56 1.2.2. Protection process . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3. Enumservice Registration - X-Crypto . . . . . . . . . . . . . 7 59 4. Functional Specification . . . . . . . . . . . . . . . . . . . 8 60 4.1. Order . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.2. Preference . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.3. Services . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.4. Regexp . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.5. Replacement . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.6. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 9 66 5. Ciphersuite Subtypes . . . . . . . . . . . . . . . . . . . . . 10 67 5.1. Crypto Algoritms . . . . . . . . . . . . . . . . . . . . . 10 68 5.2. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 5.3. Hash . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 76 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 78 Intellectual Property and Copyright Statements . . . . . . . . . . 18 80 1. Introduction 82 1.1. The problem 84 DNS (RFC 1034 [6],RFC 1035 [7]) is a global system; it does not 85 differentiate on the data it returns. If a NAPTR [1] is published in 86 DNS, then by definition the same Resource Record Set (RRset) will be 87 returned in response to a query, regardless of the user placing that 88 query. 90 Where URIs [8] are published within DNS (inside NAPTRs), the 91 registrant may prefer to make these available only to groups of 92 individuals that he or she has selected. Given the global nature of 93 DNS, this can be a problem. 95 It is not reliably possible to return different RRset content to 96 different queries, depending on the user making the request. Even if 97 the authoritative server has been configured to discriminate based on 98 the source of the query, if there are any intermediary recursive 99 resolvers, the query may not even be passed to the authoritative 100 server and the response returned to the querying DNS client may not 101 be as the authoritative server would have chosen. It can also be 102 challenging to configure and maintain the authoritative server, and 103 this may also involve special configuration of each client that will 104 query for and use the data. 106 1.1.1. The requirements 108 The same content should be published in DNS and so made available to 109 all without discrimination. There should be no special processing 110 required of DNS components. This will match the distributed design 111 of the DNS and maintain the effectiveness of the cacheing 112 architecture. 114 However, the value of chosen content should be protected in such a 115 way that it is understandable only by a selected set of users. 117 It is important that the recipient of this data can detect 118 immediately that it is protected, and either process it to extract 119 the protected content, or immediately discard the data if it is not 120 interested in such protected records. 122 1.2. The solution 124 A general solution for all DNS resource records that meets these 125 requirements is very difficult; the performance requirements for DNS 126 in general are severe. NAPTRs stored in ENUM [2] domains may contain 127 personally identifying information, so finding a solution may be 128 considered more pressing for such NAPTRs, and some restrictions or 129 processing costs may therefore be acceptable. Also, in the case of 130 NAPTRs a solution may be possible, as the problem is more restricted. 131 NAPTRs hold a small number of well defined fields. Not all of these 132 fields in a NAPTR will be sensitive and so require protection. 134 Those fields to be protected can be encrypted using a key known to 135 the intended users. Thus a "Protected" NAPTR can be processed into 136 two parts; the protected fields carried in a ciphertext, and the 137 public fields. A "Container" NAPTR can itself be used to carry this 138 ciphertext (inside its Regexp field content, in a URI), along with 139 those fields that are considered public and are not protected. These 140 public fields can be copied from the Protected NAPTR into this 141 Container NAPTR. 143 The Container NAPTR can be stored and retrieved in the normal way. 144 It will have an Enumservice that indicates that it acts as a 145 container and MUST be decoded before the original Protected NAPTR can 146 be reconstructed and processed. When an ENUM client retrieves such a 147 Container NAPTR, it can immediately know that this requires special 148 processing, and if that client is not interested in such processing, 149 the NAPTR can be discarded. 151 1.2.1. Protected fields 153 There is no great benefit to encrypting all of the RRDATA for a 154 NAPTR. The ORDER and PREFERENCE/PRIORITY fields are used to indicate 155 the preferred order in which the records within a returned NAPTR 156 RRset should be processed. Whether a particular NAPTR acts as a 157 container for a Protected NAPTR's content or not, the order in which 158 it should be processed should remain the same. Otherwise, it might 159 be possible for a Container NAPTR to be considered first (as it had a 160 low numerical order value), but, once decoded, the Protected NAPTR 161 content it contained was of a much lower priority, and so should not 162 be processed at that point. 164 Thus the ORDER and PREFERENCE/PRIORITY field values should be 165 considered public and be copied from the Protected NAPTR into the 166 Container NAPTR. However, all the other fields (flags, services, 167 regexp, and replacement) are sensitive in nature, and so would form 168 the plaintext that would be protected before publication in DNS. 170 1.2.2. Protection process 172 The NAPTR to be protected can have these sensitive fields placed into 173 a plaintext buffer. The buffer content is then encrypted using an 174 appropriate key to create a ciphertext. The ciphertext can then be 175 "armoured" into a form that can be presented in a data URI[3]. That 176 URI can then be placed in a Container NAPTR, along with the "public" 177 ORDER and PREFERENCE/PRIORITY fields from the Protected NAPTR. 179 If this Container NAPTR has an appropriate Enumservice then its 180 nature will be immediately detectable by the recipient of that NAPTR. 181 If the recipient has the appropriate key to decode the URI data, then 182 it can decrypt the URI content to form a buffer with the plaintext 183 fields. These fields (in combination ORDER and PREFERENCE/PRIORITY 184 fields that have been copied into the Container NAPTR and have not 185 been encoded) can be reconstructed into the fields that would have 186 existed in the original Protected NAPTR. That Protected NAPTR 187 content can then be processed by the client in the normal way. 189 2. Terminology 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in RFC 2119 [4]. 195 3. Enumservice Registration - X-Crypto 197 The following template contains information required for the IANA 198 registrations of the 'X-Crypto' Enumservice, according to Section 3 199 of RFC 3761: 201 Enumservice Name: "X-Crypto" 203 Enumservice Type: "x-crypto" 205 Enumservice Subtype: "data" 207 Enumservice Sub-subtype: see Section 5 209 URI Schemes: "data" 211 Functional Specification: see Section 4 213 Security Specification: see Section 7 215 Intended Usage: COMMON 217 Author(s): Ben Timms, Jim Reid, Jakob Schlyter. (for authors contact 218 details see Authors' Addresses section). 220 Any other information that the author deems interesting: None 222 4. Functional Specification 224 The basic concept is covered in Section 1.2 and the process is 225 covered in Section 1.2.2. This section describes in detail how the 226 each of the fields are handled. 228 Publication and use of a NAPTR with this Enumservice is based on two 229 concepts: 231 A Protected NAPTR that contains sensitive field values, and is not 232 stored and published in DNS. 234 A Container NAPTR with this Enumservice that holds the protected 235 fields in encrypted form within its Regexp field. This NAPTR 236 carries the "x-crypto" Enumservice 238 The Container NAPTR resource record fields are as follows: 240 4.1. Order 242 The value of the order field is copied in clear from the Protected 243 NAPTR into the Container NAPTR. It is not encoded. 245 4.2. Preference 247 The value of the preference field is copied in clear from the 248 Protected NAPTR to the Container NAPTR. It is not encoded. 250 4.3. Services 252 The value of the services field for the Container NAPTR is set to 253 "E2U+x-crypto:data:" combined with the ciphersuite sub-subtype 254 (Section 5). 256 4.4. Regexp 258 The encrypted payload (Section 4.6) is encoded in Base64 [5], and 259 transported as a data URI [3] inside the Container NAPTR. 261 Container NAPTR Regexp Example: 262 !^.*$!data:;base64,bWVrbWl0YXNkaWdvYXQK! 264 4.5. Replacement 266 The value of the Container NAPTR's replacement field MUST be set to 267 ".". 269 4.6. Encrypted Payload 271 The processed content consists of encrypted, optionally padded 272 ciphertext reflecting a portion of the Protected NAPTR's RDATA. The 273 Flags, Services, Regexp and Replacement fields of the Protected NAPTR 274 are treated as the plaintext to be processed. 276 Once the encrypted payload has been generated, it is further encoded 277 in Base64, and this is then used as the value of the Container 278 NAPTR's URI. 280 5. Ciphersuite Subtypes 282 The enumservice sub-subtype carries the ciphersuite used for the 283 encrypted payload. 285 Ciphersuite sub-subtype example: RSA 1024-bit with PKCS#1.5 padding 286 and no hash would be encoded as 0x8210 and presented as enumservice 287 "E2U+x-crypto:data:8210". 289 5.1. Crypto Algoritms 291 A 1-byte field indicating the encryption algorithm used for the 292 encrypted payload (Section 4.6). 294 +-------+----------------------+ 295 | Value | Encryption Algorithm | 296 +-------+----------------------+ 297 | 0x00 | NULL | 298 | | | 299 | 0x81 | RSA-512 | 300 | | | 301 | 0x82 | RSA-1024 | 302 | | | 303 | 0x83 | RSA-1536 | 304 | | | 305 | 0x84 | RSA-2048 | 306 | | | 307 | 0x85 | RSA-3072 | 308 | | | 309 | 0x86 | RSA-4096 | 310 +-------+----------------------+ 312 5.2. Padding 314 A 4-bit field indicating what padding algorithm is used for the 315 encrypted payload (Section 4.6). 317 +-------+-------------------+ 318 | Value | Padding Algorithm | 319 +-------+-------------------+ 320 | 0x0 | NULL | 321 | | | 322 | 0x1 | PKCS #1.5 | 323 | | | 324 | 0x2 | OAEP | 325 +-------+-------------------+ 327 5.3. Hash 329 A 4-bit field indicating what hash algorithm used for the encrypted 330 payload (Section 4.6). 332 +-------+----------------+ 333 | Value | Hash Algorithm | 334 +-------+----------------+ 335 | 0x0 | NULL | 336 | | | 337 | 0x1 | MD2 | 338 | | | 339 | 0x2 | MD5 | 340 | | | 341 | 0x3 | SHA-1 | 342 | | | 343 | 0x4 | SHA-224 | 344 | | | 345 | 0x5 | SHA-256 | 346 | | | 347 | 0x6 | SHA-384 | 348 | | | 349 | 0x7 | SHA-512 | 350 +-------+----------------+ 352 6. Example 354 Move along, nothing to see here (yet). 356 7. Security Considerations 358 This is an Enumservice for a NAPTR intended to carry protected NAPTR 359 content in encrypted form. It does not discuss the means by which 360 the keys needed to decrypt the protected content are exchanged. For 361 this Enumservice registration, this is considered "out of scope". 362 However, the technique for key exchange is important, and must be 363 considered thoroughly; there is little point in using a complex 364 encryption scheme if the keys are available to eavesdroppers. 366 There are limitations on field size within DNS, so that, for example, 367 the Regexp field has a maximum length of 255 octets. Several of 368 these octets will be taken up with the sub-field delimiters, with the 369 ERE sub-field content, and with the URI scheme itself. There is 370 limited space to carry the armoured ciphertext as the data URI value, 371 given the armouring choice proposed here and the simple use of the 372 existing Regexp field to carry the protected data. This will in turn 373 limit the choices for encryption method, has algorithm, and any 374 padding. 376 Both of these issues mean that the environment in which NAPTRs with 377 this Enumservice can be used may be restricted, and further security 378 analysis will depend on deployment experience. 380 An analysis of threats specific to the dependence of ENUM on the DNS, 381 and the applicability of DNSSEC ("Domain Name Security") [9] to 382 these, is provided in [10]. 384 8. IANA Considerations 386 This document requests registration of the "X-Crypto" Enumservice 387 with the "x-crypto:data:" type according to the 388 guidelines and specifications in RFC 3761 [2] and the definitions in 389 this document. This Enumservice is intended for use with the "data:" 390 URI scheme. 392 9. Acknowledgements 394 The authors gratefully acknowledge the contributions of Romek 395 Szczesniak. He helped greatly to clarify some of the issues with 396 deployed security schemes and current implementations. We also 397 acknowledge the support of Khashayar Mahdavi whose original idea this 398 draft embodies, and Henri Asseily for driving the development of the 399 environment in which this is being used. 401 10. References 403 10.1. Normative References 405 [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 406 Three: The Domain Name System (DNS) Database", RFC 3403, 407 October 2002. 409 [2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 410 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 411 Application (ENUM)", RFC 3761, April 2004. 413 [3] Masinter, L., "The "data" URL scheme", RFC 2397, August 1998. 415 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 416 Levels", BCP 14, RFC 2119, March 1997. 418 [5] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 419 RFC 3548, July 2003. 421 10.2. Informative References 423 [6] Mockapetris, P., "Domain names - concepts and facilities", 424 STD 13, RFC 1034, November 1987. 426 [7] Mockapetris, P., "Domain names - implementation and 427 specification", STD 13, RFC 1035, November 1987. 429 [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 430 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 431 January 2005. 433 [9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 434 "Protocol Modifications for the DNS Security Extensions", 435 RFC 4035, March 2005. 437 [10] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name 438 System (DNS)", RFC 3833, August 2004. 440 Authors' Addresses 442 Ben Timms 443 Telnic 444 8 Wilfred Street 445 London SW1E 6PL 446 United Kingdom 448 Email: btimms@telnic.org 450 Jim Reid 451 Telnic 452 8 Wilfred Street 453 London SW1E 6PL 454 United Kingdom 456 Email: jim@telnic.org 458 Jakob Schlyter 459 Kirei AB 460 P.O. Box 53204 461 Goteborg SE-400 16 462 Sweden 464 Email: jakob@kirei.se 466 Full Copyright Statement 468 Copyright (C) The IETF Trust (2007). 470 This document is subject to the rights, licenses and restrictions 471 contained in BCP 78, and except as set forth therein, the authors 472 retain all their rights. 474 This document and the information contained herein are provided on an 475 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 476 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 477 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 478 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 479 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 480 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 482 Intellectual Property 484 The IETF takes no position regarding the validity or scope of any 485 Intellectual Property Rights or other rights that might be claimed to 486 pertain to the implementation or use of the technology described in 487 this document or the extent to which any license under such rights 488 might or might not be available; nor does it represent that it has 489 made any independent effort to identify any such rights. Information 490 on the procedures with respect to rights in RFC documents can be 491 found in BCP 78 and BCP 79. 493 Copies of IPR disclosures made to the IETF Secretariat and any 494 assurances of licenses to be made available, or the result of an 495 attempt made to obtain a general license or permission for the use of 496 such proprietary rights by implementers or users of this 497 specification can be obtained from the IETF on-line IPR repository at 498 http://www.ietf.org/ipr. 500 The IETF invites any interested party to bring to its attention any 501 copyrights, patents or patent applications, or other proprietary 502 rights that may cover technology that may be required to implement 503 this standard. Please address the information to the IETF at 504 ietf-ipr@ietf.org. 506 Acknowledgment 508 Funding for the RFC Editor function is provided by the IETF 509 Administrative Support Activity (IASA).