idnits 2.17.1 draft-yourtchenko-opsec-humansafe-ipv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 2, 2012) is 4430 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '8' on line 297 -- Looks like a reference, but probably isn't: '16' on line 317 -- Looks like a reference, but probably isn't: '42' on line 318 -- Looks like a reference, but probably isn't: '0' on line 339 -- Looks like a reference, but probably isn't: '1' on line 325 -- Looks like a reference, but probably isn't: '2' on line 326 -- Looks like a reference, but probably isn't: '3' on line 334 -- Looks like a reference, but probably isn't: '4' on line 329 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 opsec A. Yourtchenko 3 Internet-Draft S. Asadullah 4 Intended status: Standards Track Cisco 5 Expires: September 3, 2012 M. Pisica 6 BT 7 March 2, 2012 9 Human-safe IPv6: Cryptographic transformation of hostnames as a base for 10 secure and manageable addressing 11 draft-yourtchenko-opsec-humansafe-ipv6-00 13 Abstract 15 Although the IPv6 address space within a single /64 subnet is very 16 large, the typical distribution of the addresses in this space is 17 very non-uniform. This non-uniformity, together with the dictionary- 18 based DNS brute-force enumeration, allows practical remote mapping of 19 the IPv6 addresses in these subnets. This document proposes a 20 technique which can be used to decrease the exposure of the server 21 subnets to trivial scanning. As a side effect, the proposed 22 technique allows to drastically simplify the address management. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 3, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Caveats of version -00 . . . . . . . . . . . . . . . . . . . . 3 60 3. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 61 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 62 5. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 3 63 6. Deriving the Cleartext Blob from Hostname . . . . . . . . . . . 4 64 7. Encrypting the Cleartext Blob . . . . . . . . . . . . . . . . . 4 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 68 11. Normative References . . . . . . . . . . . . . . . . . . . . . 5 69 Appendix A. A Sample Implementation . . . . . . . . . . . . . . . 5 70 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 The conventional wisdom says that a typical IPv6 subnet has the 76 address space of 2^64 addresses, which makes it impossible to scan. 77 This results in commonly held assertion that it is impossible to scan 78 the IPv6 subnets, and the protocol is inherently more secure against 79 scanning than IPv4. However, the currently deployed addressing 80 techniques do not provide for a uniform distribution of the hosts 81 within the entirety of the space - certain addresses are much more 82 frequently used than the others. As a result, for the mostly-server 83 subnets, more often than not one can realistically map the hosts that 84 are present on that segment. 86 2. Caveats of version -00 88 (section to be removed in the -01) 90 This version of the document does assume the 64-bit Interface ID can 91 have any values, whereas there are various restrictions that need to 92 be taken into account (e.g., the U/L bit value). This is done 93 deliberately as -00 is aimed at illustrating the principle and 94 collecting the feedback from the community. Addressing these will be 95 done as part of the future work on the document and the accompanying 96 code. 98 3. Notational Conventions 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 4. Problem Statement 106 The problem is twofold: first, from the security point of view, one 107 should try to avoid the easy to guess patterns that the traditional 108 address assignment entails. At the same time, the naive approach of 109 assigning purely random addresses to servers is not very scalable in 110 real world for maintenance reasons 112 5. Proposed Solution 114 The idea is to exploit the randomness property of the encryption 115 function output. The interface identifier, used within the IPv6 116 address of the host, would be derived from the 64-bit data 117 corresponding to hostname, encrypted with a site-wide "secret". 119 This satisfies the requirement of having the interface identifiers 120 evenly distributed within the 2^64 space within the subnet; At the 121 same time, such a formal mechanism of generating the host ID allows 122 to reduce the maintenance overhead for the assignment and operation 123 of the IPv6 addresses. Also it would allow, if needed, a DNS-less 124 operation - after the network-wide secret is disseminated, the 125 generation of the interface IDs can be distributed. 127 For flexibility, we define the forward and reverse transformation 128 between the hostname and interface identifier as a two step process - 129 the first step is to derive from the hostname the 64-bit "cleartext 130 blob", which is being encrypted in the second step. Of course for 131 the decryption the steps are reversed. 133 This document does not propose to replace/eliminate any of the 134 existing address definition schemes, nor does it require the 135 implementation in the devices - the addresses can be generated and 136 assigned manually, and the enclosed algorithm can be used within the 137 address management application. 139 6. Deriving the Cleartext Blob from Hostname 141 The method that is used to perform a 1:1 mapping of the hostname into 142 the cleartext blob will determine the maximum length of the hostname. 143 The most simple and obvious method used to illustrate the principle 144 is an identity transform - therefore the hostname is itself the 145 cleartext blob, and therefore the maximum length is 8 characters. 146 Assuming the host name is using the characters from the range 147 [0-9a-z-_], this would mean using 6 bits per character - therefore 148 allowing to increase the maximum stored hostname length up to 10 149 characters. Potentially one can use other compression mechanisms - 150 e.g. Huffman encoding or arithmetic encoding - however, one must 151 leave a sufficient number of invalid values to detect the possible 152 typos in the address. 154 7. Encrypting the Cleartext Blob 156 Any good enough encryption mechanism with the block size of 64 bit 157 will suffice. For the demonstration purposes we choose DES - but 158 possibly other encryption mechanisms can be used. 160 8. Security Considerations 162 Since the hostnames are not a secret data after one makes a 163 connection to the server, one may argue that if an encryption 164 algorithm is vulnerable to a known plaintext attack, this approach 165 may make the mapping job easier. 167 Also, the fact that the encryption key distribution is rather wide, 168 one may have concerns about the exposure of the hostnames from the 169 addresses. However, we note that the scope of this proposal is 170 merely to raise the barrier for the anonymous remote mapping, as well 171 as to make the address management easier. 173 9. Acknowledgements 175 The authors are thankful to the following people for their review and 176 valuable comments: Gunter Van de Velde, Warren Kumari, Ron Broersma, 177 Jan Zorz, Ragnar Anfinsen, ... 179 10. IANA Considerations 181 This document has no IANA actions. 183 11. Normative References 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, March 1997. 188 Appendix A. A Sample Implementation 190 #include 191 #include 192 #include 193 #include 194 #include 195 #include 197 /* 198 * A sample implementation of the human-safe 199 * IPv6 addressing algorithm. 200 * Requires the OpenSSL library, please compile 201 * with "gcc human-safe.c -lssl" 202 */ 204 /* 205 * Encrypt and Decrypt routines are using DES as an example of 206 * a symmetric encryption that has a 64-bit block size. 207 */ 209 int encrypt(char *dst, char *src, char *key) { 210 int n=0; 211 DES_cblock k; 212 DES_key_schedule sch; 214 memset(k, 0, sizeof(k)); 215 memcpy(k, key, 8); 216 DES_set_odd_parity(&k); 217 if (DES_set_key_checked(&k, &sch) < 0) { 218 printf("Error checking key\n"); 219 } 220 DES_ecb_encrypt( (unsigned char (*)[8])src, 221 (unsigned char (*)[8])dst, &sch, DES_ENCRYPT); 222 return n; 223 } 225 int decrypt(char *dst, char *src, char *key) { 226 int n=0; 227 DES_cblock k; 228 DES_key_schedule sch; 230 memset(k, 0, sizeof(k)); 231 memcpy(k, key, 8); 232 DES_set_odd_parity(&k); 233 if (DES_set_key_checked(&k, &sch) < 0) { 234 printf("Error checking key\n"); 235 } 236 DES_ecb_encrypt( (unsigned char (*)[8])src, 237 (unsigned char (*)[8])dst, &sch, DES_DECRYPT); 239 return n; 240 } 242 /* 243 * For the reference implementation, the mapping of the hostname 244 * to cleartext blob is an identity transform 245 */ 247 int hostname_enc(char *dst, char *src) { 248 memcpy(dst, src, 8); 249 return 1; 250 } 252 int hostname_dec(char *dst, char *src) { 253 int i; 254 for(i=0;i<8;i++) { 255 if(!isalnum(src[i])) { 256 return 0; 257 } 258 } 259 memcpy(dst, src, 8); 260 /* If it was the full-length string, null-terminate it */ 261 dst[8] = 0; 262 return 1; 263 } 265 /* Main functions */ 267 host_to_addr(char *addr, char *host, char *prefix, char *secret) { 268 int i; 269 char blob[8]; 270 char xor_block[8]; 272 inet_pton(AF_INET6, prefix, addr); 273 /* zero out the interface id part of /64 */ 274 for (i=8; i<16; i++) { 275 addr[i] = 0; 276 } 277 hostname_enc(blob, host); 278 encrypt(&addr[8], blob, secret); 279 encrypt(xor_block, addr, secret); 280 for(i=0; i<8; i++) { 281 addr[i+8] ^= xor_block[i]; 282 } 283 return i; 284 } 286 int addr_to_host(char *host, char *addr, char *secret) { 287 char aptr[16]; 288 char blob[8]; 289 char xor_block[8]; 290 int i; 291 memcpy(aptr, addr, 16); 293 encrypt(xor_block, addr, secret); 294 for(i=0;i<8;i++) { 295 aptr[8+i] ^= xor_block[i]; 296 } 297 decrypt(blob, &aptr[8], secret); 298 if (!hostname_dec(host, blob)) { 299 printf("Hostname decode failed, address error ?\n"); 300 return 0; 301 } 302 return 1; 303 } 305 void usage(char *name) { 306 printf("Usage: \n"); 307 printf(" %s encode \n", name); 308 printf(" %s decode
\n", name); 309 } 311 int main(int argc, char* argv[]) { 312 char *secret; 313 char *operation; 314 char *prefix; 315 char *hostname; 316 char hostname_decoded[42]; 317 char addr_encoded[16]; 318 char buf[42]; 320 if (argc < 4) { 321 usage(argv[0]); 322 exit(1); 323 } 325 secret = argv[1]; 326 operation = argv[2]; 327 if (0 == strcmp(operation, "encode")) { 328 prefix = argv[3]; 329 hostname = argv[4]; 330 host_to_addr(addr_encoded, hostname, prefix, secret); 331 inet_ntop(AF_INET6, addr_encoded, buf, sizeof(buf)); 332 printf("%s\n", buf); 333 } else if (0 == strcmp(operation, "decode")) { 334 prefix = argv[3]; 335 inet_pton(AF_INET6, prefix, addr_encoded); 336 addr_to_host(hostname_decoded, addr_encoded, secret); 337 printf("%s\n", hostname_decoded); 338 } else { 339 usage(argv[0]); 340 exit(1); 341 } 342 exit(0); 343 } 345 Appendix B. Changes 347 Authors' Addresses 349 Andrew Yourtchenko 350 Cisco Systems, Inc. 351 De Kleetlaan, 7 352 Brussels, Diegem B-1831 353 Belgium 355 Email: ayourtch@cisco.com 357 Salman Asadullah 358 Cisco Systems, Inc. 359 170 West Tasman Drive 360 San Jose, CA 95134 361 USA 363 Email: sasad@cisco.com 365 Mircea Pisica 366 BT 368 Email: mircea.pisica@bt.com