idnits 2.17.1 draft-rafiee-intarea-cga-tsig-07.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 10 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 341 has weird spacing: '...6 octet the...' == Line 347 has weird spacing: '...ariable the...' == Line 351 has weird spacing: '...ariable the...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: - section 4.2: The server MUST not generate a signed response to an unsigned request => The server MUST not generate a signed response to an unsigned request, unless the Algorithm Name filed contains CGA-TSIG. -- The document date (February 15, 2014) is 3723 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: 'RFC2930' is defined on line 1094, but no explicit reference was found in the text == Unused Reference: 'RFC2136' is defined on line 1104, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 1118, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1122, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1127, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1142, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions H. Rafiee 3 INTERNET-DRAFT Ciber AG 4 Updates RFC 2845 (if approved) M. v. Loewis 5 Intended Status: Standards Track C. Meinel 6 Hasso Plattner Institute 7 Expires: August 15, 2014 February 15, 2014 9 Secure DNS Authentication using CGA/SSAS Algorithm in IPv6 10 12 Abstract 14 This document describes a new mechanism that can be used to reduce 15 the need for human intervention during DNS authentication and secure 16 DNS authentication in various scenarios such as the DNS 17 authentication of resolvers to stub resolvers, authentication during 18 zone transfers, authentication of root DNS servers to recursive DNS 19 servers, and authentication during the FQDN (RFC 4703) update. 21 Especially in the last scenario, i.e., FQDN, if the node uses the 22 Neighbor Discovery Protocol (NDP) (RFC 4861, RFC 4862), unlike the 23 Dynamic Host Configuration Protocol (DHCP) (RFC 3315), the node has 24 no way of updating his FQDN records on the DNS and has no means for a 25 secure authentication with the DNS server. While this is a major 26 problem in NDP-enabled networks, this is a minor problem in DHCPv6. 27 This is because the DHCP server updates the FQDN records on behalf of 28 the nodes on the network. This document also introduces a possible 29 algorithm for DNS data confidentiality. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute working 38 documents as Internet-Drafts. The list of current Internet-Drafts is 39 at http://datatracker.ietf.org/drafts/current. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 15, 2014. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. This document is subject to 52 BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 53 Documents (http://trustee.ietf.org/license-info) in effect on the 54 date of publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 65 2. Conventions used in this document . . . . . . . . . . . . . . 5 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Algorithm overview . . . . . . . . . . . . . . . . . . . . . 7 68 4.1. The CGA-TSIG DATA structure . . . . . . . . . . . . . . 7 69 4.2. Generation of CGA-TSIG DATA . . . . . . . . . . . . . . . 9 70 5. Authentication during Zone Transfer . . . . . . . . . . . . . 12 71 5.1. Verification process . . . . . . . . . . . . . . . . . . 13 72 6. Authentication during the FQDN or PTR Update . . . . . . . . 14 73 6.1. Verification Process . . . . . . . . . . . . . . . . . . 15 74 7. Authentication during Query Resolving (stub to recursive) . . 15 75 7.1. Verification process . . . . . . . . . . . . . . . . . . 15 76 8. Authentication during Query Resolving (Auth. to recursive) . 17 77 9. No cache parameters available or SeND is not supported . . . 17 78 10. How to obtain the IP address of resolvers . . . . . . . . . 17 79 11. CGA-TSIG Data confidentiality . . . . . . . . . . . . . . . 17 80 11.1. Generation of secret key . . . . . . . . . . . . . . . . 18 81 11.2. DNS message generation . . . . . . . . . . . . . . . . . 18 82 11.3. CGA-TSIGe DATA generation . . . . . . . . . . . . . . . 18 83 11.4. Process of encrypted DNS message . . . . . . . . . . . . 18 84 12. CGA-TSIG/CGA-TSIGe Applications . . . . . . . . . . . . . . 19 85 12.1. IP Spoofing . . . . . . . . . . . . . . . . . . . . . . 20 86 12.2. DNS Dynamic Update Spoofing . . . . . . . . . . . . . . 20 87 12.3. Resolver Configuration Attack . . . . . . . . . . . . . 20 88 12.4. Exposing Shared Secret . . . . . . . . . . . . . . . . . 20 89 12.5. Replay attack . . . . . . . . . . . . . . . . . . . . . 20 90 12.6. Data confidentiality . . . . . . . . . . . . . . . . . . 21 91 13. Security Considerations . . . . . . . . . . . . . . . . . . . 21 92 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 93 15. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 22 94 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 95 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 17.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 24 97 17.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 25 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 100 1. Introduction 102 Transaction SIGnature (TSIG) [RFC2845] is a protocol that provides 103 endpoint authentication and data integrity through the use of one-way 104 hashing and shared secret keys in order to establish a trust 105 relationship between two/group of hosts, which can be either a client 106 and a server, or two servers. The TSIG keys, which are manually 107 exchanged between a group of hosts, need to be maintained in a secure 108 manner. This protocol is today mostly used to secure a Dynamic 109 Update, or to give assurance to the slave name server that the zone 110 transfer is from the original master name server and that it has not 111 been spoofed by hackers. It does this by verifying the signature 112 using a cryptographic key that is shared with the receiver. 114 But, handling this shared secret in a secure manner and exchanging 115 it, does not seem to be easy. This is especially true if the IP 116 addresses are dynamic due to privacy reasons or the shared secret is 117 exposed to attacker. To address the existing problems with TSIG, this 118 document proposes the use of Cryptographically Generated Addresses 119 (CGA) [RFC3972] or Secure Simple Addressing Scheme for IPv6 120 Authoconfiguration (SSAS) as a new algorithm in the TSIG Resource 121 Record (RR). CGA is an important option available in Secure Neighbor 122 Discovery (SeND) [RFC3971], which provides nodes with the necessary 123 proof of IP address ownership by providing a cryptographic binding 124 between a host?s public key and its IP address without the need for 125 the introduction of a new infrastructure. 127 This document also addresses the DNS data confidentiality by using 128 both asymmetric and symmetric cryptography as well as data integrity. 129 This document updates the following sections in TSIG document 131 - section 4.2: The server MUST not generate a signed response to an 132 unsigned request => The server MUST not generate a signed response to 133 an unsigned request, unless the Algorithm Name filed contains 134 CGA-TSIG. 136 - Section 4.5.2: It MUST include the client's current time in the 137 time signed field, the server's current time (a u_int48_t) in the 138 other data field, and 6 in the other data length field => It MUST 139 include the client's current time in the time signed field, the 140 server's current time (a u_int48_t) in the other data field, and if 141 the Algorithm Name is CGA-TSIG, then add the length of this client?s 142 current time to the total length of Other DATA field. The client?s 143 current time in this case will be placed after the CGA-TSIG Data. 145 1.1. Problem Statement 147 The authentication during any DNS query process is solely based on 148 the source IP address when no secure mechanism is in use either 149 during the DNS update (zone transfer, FQDN update) or during the DNS 150 query resolving process. This makes the DNS query process vulnerable 151 to several types of spoofing attacks -- man in the middle, source IP 152 spoofing, etc. One example is the problem that exists between a 153 client and a DNS resolver. When a client sends a DNS query to a 154 resolver, an attacker can send a response to this client containing 155 the spoofed source IP address for this resolver. The client checks 156 the resolver's source IP address for authentication. If the attacker 157 spoofed the resolver's IP address, and if the attacker responds 158 faster than the legitimate resolver, then the client's cache will be 159 updated with the attacker's response. The client does not have any 160 way to authenticate the resolver. 162 If DNSSEC (RFC 6840) or TSIG, as a security mechanism is in use, then 163 the problem would be the manual step required for the configuration. 164 For instance, when a DNSSEC needs to sign the zone offline. The 165 public key verification in DNSSEC creates chicken and eggs situation. 166 In other words, the key for verifying messages should be obtained 167 from DNSSEC server itself. This is why the query requestor needed to 168 ask other DNS servers up to top level in root to be able to verify 169 the key. If this does not happen, DNSSEC is vulnerable to IP spoofing 170 attack. This problem could easily be handled by the use of CGA-TSIG 171 as a means of providing the proof of IP address ownership. 173 If TSIG is in use, the shared secret exchange is done offline. 174 Currently there is little deployment of TSIG for resolver 175 authentication with clients. One reason is that resolvers respond to 176 anonymous queries and can be located in any part of the network. A 177 second reason is that the manual TSIG process makes it difficult to 178 configure each new client with the shared secret of the resolver. 179 Another catastrophic problem with TSIG would be when this shared 180 secret, that is shared between a group of hosts, leaks and makes it 181 necessary to repeat this manual step. The reason is, that for each 182 group of hosts there needs to be one shared secret and the 183 administrator will need to manually add it to the DNS configuration 184 file for each of these hosts. This manual process will need to be 185 invoked in the case where one of these hosts is compromised and the 186 shared secret is well known to the attacker. It will also have to be 187 invoked in the case where any of these hosts needs to change their IP 188 addresses, because of different reasons such as privacy issues, as 189 explained in RFC 4941 [RFC4941], or when moving to another subnet 190 within the same network, etc. Therefore, the problem that exists 191 today with the authentication processes used in different scenarios 192 is what this document addresses. The various scenarios include 193 authentication during zone transfer, authentication of the nodes 194 during DNS query resolving and authentication during updating PTR and 195 FQDN (RFC 4703). 197 2. Conventions used in this document 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 201 document are to be interpreted as described in RFC 2119 [RFC2119]. 203 In this document, these words will appear with that interpretation 204 only when in ALL CAPS. Lower case uses of these words are not to be 205 interpreted as carrying RFC 2119 significance. 207 => This sign in the document should be interpreted as "change to". 209 3. Terminology 211 The terms used in this document have the following standard meaning: 213 - Name server: A server that supports DNS service. 215 - Resolver/recursive DNS server: A resolver/recursive name server 216 responds to queries where the query does not contain an entry for the 217 node in its database. It first checks its own records and cache for 218 the answer to the query and then, if it cannot find an answer there, 219 it may recursively query name servers higher up in the hierarchy and 220 then pass the response back to the originator of the query. This is 221 known as a recursive query or recursive lookup. 223 - Stub resolver: A specific kind of DNS resolver that is unable to 224 resolve the queries recursively. So, it relies on a recursive DNS 225 resolver to resolve the queries. 227 - Authoritative: An authoritative name server provides the answers to 228 DNS queries. For example, it would respond to a query about a mail 229 server IP address or website IP address. It provides original, 230 first-hand, definitive answers (authoritative answers) to DNS 231 queries. It does not provide 'just cached' answers that were obtained 232 from another name server. Therefore it only returns answers to 233 queries about domain names that are installed in its system 234 configuration. 236 There are two types of Authoritative Name Servers: 238 1. Master server (primary name server): A master server stores the 239 original master copies of all zone records. A host master is only 240 allowed to change the master server?s zone records. Each slave server 241 gets updated via a special automatic updating mechanism within the 242 DNS protocol. All slave servers maintain identical copies of the 243 master records. 245 2. Slave server (secondary name server): A slave server is an exact 246 replica of the master server. It is used to share the DNS server's 247 load and to improve DNS zone availability in cases where the master 248 server fails. It is recommended that there be at least 2 slave 249 servers and one master server for each domain name. 251 - Root DNS server: An authoritative DNS server for a specific root 252 domain. For example, .com 254 - Client: a client can be any computer (server, laptop, etc) that 255 only supports stub DNS servers and not other DNS services. It can be 256 a mail server, web server or a laptop computer. 258 - Node: a node can be anything such as a client, a DNS server 259 (resolver, authoritative) or a router. 261 - Host: all nodes except routers 263 4. Algorithm overview 265 The following sections explain the use of CGA or any other future 266 algorithm in place of CGA for securing the DNS process by adding a 267 CGA-TSIG data structure as an option to the TSIG Resource Record 268 (RR). 270 4.1. The CGA-TSIG DATA structure 272 The CGA-TSIG data structure SHOULD be added to the Other DATA section 273 of the RDATA field in the TSIG Resource Record (RR) (see figures 1 274 and 2). The DNS RRTYPE MUST be set to TSIG [RFC2845]. The RDATA 275 Algorithm Name MUST be set to CGA-TSIG. The Name MUST be set to root 276 (.).This is the smallest possible value that can be used. The MAC 277 Size MUST be set to 0. A detailed explanation of the standard RDATA 278 fields can be found in section 2.3 RFC 2845. This document focuses 279 only on the new structure added to the Other DATA section. These new 280 fields are CGA-TSIG Len and CGA-TSIG DATA. The TSIG RR is added to an 281 additional section of the DNS message. If another algorithm is used 282 in place of CGA for SeND, such as SSAS [4 , 5], then the CGA-TSIG Len 283 will be the length for the parameters of this algorithm and CGA-TSIG 284 DATA will consist of the parameters required for verification of that 285 algorithm, like signature, public key, etc. 287 +---------------------------------------+ 288 | Algorithm Name | 289 | (CGA-TSIG) | 290 +---------------------------------------+ 291 | Time Signed | 292 | | 293 +---------------------------------------+ 294 | Fudge | 295 | | 296 +---------------------------------------+ 297 | MAC Size | 298 | | 299 +---------------------------------------+ 300 | Mac | 301 | | 302 +---------------------------------------+ 303 | Original ID | 304 | | 305 +---------------------------------------+ 306 | Error | 307 | | 308 +---------------------------------------+ 309 | OTHER LEN | 310 | | 311 +---------------------------------------+ 312 | OTHER DATA | 313 | | 314 +---------------------------------------+ 315 Figure 1 Modified TSIG RDATA 317 The CGA-TSIG DATA Field and the CGA-TSIG Len will occupy the first 318 two slots of Other DATA. Figure 2 shows the layout. Any extra 319 options/data should be placed after CGA-TSIG field. CGA-TSIG Len is 320 the length of CGA-TSIG DATA in byte. This value is multiple of 8. 322 +---------------------------------------+ 323 | CGA-TSIG Len | 324 | (1 byte) | 325 +---------------------------------------+ 326 | CGA-TSIG DATA | 327 | | 328 +---------------------------------------+ 329 | Other Options | 330 | | 331 +---------------------------------------+ 332 Figure 2 Other DATA section of RDATA field 334 CGA-TSIG DATA Field Name Data Type Notes 335 -------------------------------------------------------------- 336 Algorithm type u_int16_t IANA numeric value of 337 the algorithm 338 for RSA 1.2.840.113549.1.1.1 339 type u_int16_t Name of the algorithm used in 340 SEND 341 IP tag 16 octet the tag used to identify the IP 342 address 343 Parameters Len Octet the length of CGA parameters 344 Parameters variable CGA parameters Section 3 RFC 3972 345 Signature Len Octet the length of CGA signature 346 Signature variable Section 3.2.1 This document 347 old pubkey Len variable the length of old public key 348 field 349 old pubkey variable Old public key in ASN.1 DER 350 format (the same format as public key) 351 old Signature Len variable the length of old signature field 352 old Signature variable Old signature generated by old 353 public key. 355 Type indicates the Interface ID generation algorithm that was used in 356 SeND (An Interface ID is the 64 leftmost bits of an IPv6 address.). 357 This field allows for the use of future, optional algorithms in SeND. 358 The default value for CGA is 1. The IP tag is a node's old IP 359 address. A client's public key can be associated with several IP 360 addresses on a server. The DNS server, or the DNS message verifier 361 node, SHOULD store the IP addresses and the public keys so as to 362 indicate their association to each other. If a client wants to add 363 RRs to the server by using a new IP address, then the IP tag field 364 will be set to binary zeroes. The server will then store the new IP 365 address that was passed to it in storage. If the client wants to 366 replace an existing IP address in a DNS server with a new one, then 367 the IP tag field will be populated with the IP address which is to be 368 replaced. The DNS server will then look for the IP address referenced 369 by the IP tag stored in its storage and replace that IP address with 370 the new one. This enables the client to update his own RRs using 371 multiple IP addresses while, at the same time, giving him the ability 372 to change IP addresses. If a node changes its public key in order to 373 maintain privacy, then it MUST add the old public key to the old 374 pubkey field. It MUST also retrieve the current time from Time Signed 375 field, sign it using the old private key, and then add the digest 376 (signature) to the old signature field. This enables the verifier 377 node to authenticate a host with a new public key. The detailed 378 verification steps are explained in sections 5.1, 6.1 and 7.1. 380 4.2. Generation of CGA-TSIG DATA 382 In order to use CGA-TSIG as an authentication approach, some of the 383 parameters need to be cached during IP address generation. If no 384 parameters are available in cache, please see section 8. If the Type 385 (section 4.1) is CGA, then the parameters that SHOULD be cached are 386 the modifier, algorithm type, location of the public/private keys and 387 the IP addresses of this host generated by the use of CGA. 389 1. Obtain required parameters from cache. 391 The CGA-TSIG algorithm obtains the old IP address, modifier, subnet 392 prefix, collision count and public key from cache. It concatenates 393 the old IP address with the CGA parameters, i.e., modifier, subnet 394 prefix, collision count, public key (the order of CGA parameters are 395 shown in section 3 RFC 3972). If the old IP address is not available, 396 then CGA-TSIG must set the old IP address (IP tag) to zero. 398 Note: If the node is a DNS server (resolver or authoritative DNS 399 server) which does not support SeND, but wants to use CGA-TSIG 400 algorithm, then it is possible to use a script to generate the CGA 401 parameters, which are needed to manually configure this server's IP 402 address. Then this server can make use these parameters for 403 authentication purposes. 405 +---------------------------------------+ 406 | Algorithm Name | 407 | | 408 +---------------------------------------+ 409 | Type | 410 | | 411 +---------------------------------------+ 412 | IP tag | 413 | (16 bytes) | 414 +---------------------------------------+ 415 | Parameter Len | 416 | (1 byte) | 417 +---------------------------------------+ 418 | Parameters | 419 | (variable) | 420 +---------------------------------------+ 421 | Signature Len | 422 | (1 byte) | 423 +---------------------------------------+ 424 | Signature | 425 | (variable) | 426 +---------------------------------------+ 427 | old pubkey Len | 428 | (1 byte) | 429 +---------------------------------------+ 430 | old pubkey | 431 | (variable) | 432 +---------------------------------------+ 433 | old Signature Len | 434 | (1 byte) | 435 +---------------------------------------+ 436 | old Signature | 437 | (variable) | 438 +---------------------------------------+ 439 Figure 3 CGA-TSIG DATA Field 441 2. Generate signature 443 For signature generation, The 128-bit CGA Message Type tag value for 444 SeND that is 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08, is 445 concatenated with the whole DNS message from Type to additional data 446 sections (Please refer to figure 4 and figure 5) excluding the 447 signature fields itself in the CGA-TSIG DATA is signed by using a RSA 448 algorithm, by default, or any future algorithm used in place of RSA, 449 and the private key which was obtained from cache in the first step. 450 This signature must be added to the signature field of the CGA-TSIG 451 DATA. Time Signed is the same timestamp as is used in RDATA. This 452 value is the number of seconds since 1 January 1970 in UTC obtained 453 from the signature generator. This approach will prevent replay 454 attacks by changing the content of the signature each time a node 455 wants to send a DNS message. The format of DNS messages is explained 456 in section 4.1.3 RFC 1035 [RFC1035]. Figure 6 shows this signature. 458 +-----+------+--------+ 459 |Type |Length|Reserved| 460 |1byte|1 byte| 1 byte | 461 +---------------------+ 462 | Header | 463 | 12 bytes | 464 +---------------------+ 465 | Zone section | 466 | variable length | 467 +---------------------+ 468 | prerequisite | 469 | variable length | 470 +---------------------+ 471 | Update section | 472 | variable length | 473 +---------------------+ 474 | Additional Data | 475 | variable length | 476 +---------------------+ 477 Figure 4 DNS update message 479 +-----+------+--------+ 480 |Type |Length|Reserved| 481 |1byte|1 byte| 1 byte | 482 +---------------------+ 483 | Header | 484 | 12 bytes | 485 +---------------------+ 486 | Question | 487 | variable length | 488 +---------------------+ 489 | Answer | 490 | variable length | 491 +---------------------+ 492 | Authority | 493 | variable length | 494 +---------------------+ 495 | Additional Data | 496 | variable length | 497 +---------------------+ 498 Figure 5 DNS Query message (section 4.1 RFC 1035) 499 +------------------+ 500 | CGA message tag | 501 | 16 bytes | 502 +------------------+ 503 | DNS message | 504 | (excluding | 505 | signature fields | 506 |in CGA-TSIG DATA) | 507 +------------------+ 508 Figure 6 CGA-TSIG Signature content 510 3. Generate old signature 512 If the nodes generated new key pairs, then they need to add the old 513 public key and message, signed by the old private key, to CGA-TSIG 514 DATA. A node will retrieve the timestamp from Time Signed, will use 515 the old private key to sign it, and then will add the content of this 516 signature to the old signature field of CGA-TSIG DATA. This step MUST 517 be skipped when the node did not generate new key pairs. 519 5. Authentication during Zone Transfer 521 This section discusses the use of CGA-TSIG for the authentication of 522 two DNS servers (a master and a slave). In the case of processing a 523 DNS update for multiple DNS servers (authentication of two DNS 524 servers), there are two possible scenarios with regard to the 525 authentication process, which differs from that of the authentication 526 of a node (client) with one DNS server. This is because of the need 527 for human intervention. 529 a. Add the DNS servers' IP address to a slave configuration file 531 A DNS server administrator should only manually add the IP address of 532 the master DNS server to the configuration file of the slave DNS 533 server. When the DNS update message is processed, the slave DNS 534 server can authenticate the master DNS server based on the source IP 535 address and then, prove the ownership of this address by use of the 536 CGA-TSIG option from the TSIG RR. This scenario will be valid until 537 the IP address in any of these DNS servers, changes. 539 To automate this process, the sender's public key of the DNS Update 540 message must be saved on the other DNS server, after the source IP 541 address has been successfully verified for the first time. In this 542 case, when the sender generates a new IP address by executing the CGA 543 algorithm using the same public key, the other DNS server can still 544 verify it and add its new IP address to the DNS configuration file 545 automatically. 547 b. Retrieve public/private keys from a third party Trusted Authority 548 (TA) 550 The message exchange option of SeND [RFC3971] may be used for the 551 retrieval of the third party certificate. This may be done 552 automatically from the TA by using the Certificate Path Solicitation 553 and the Certificate Path Advertisement messages. Like in scenario b, 554 the certificate should be saved on the DNS server for later use for 555 the generation of its address or for the DNS update process. In this 556 case, whenever any of these servers want to generate a new IP 557 address, then the DNS update process can be accomplished 558 automatically without the need for human intervention. 560 5.1. Verification process 562 Sender authentication is necessary in order to prevent attackers from 563 making unauthorized modifications to DNS servers through the use of 564 spoofed DNS messages. The verification process executes the following 565 steps: 567 1. Verify the signature 569 The signature contained in CGA-TSIG DATA should be verified. This can 570 be done by retrieving the public key and signature from CGA-TSIG DATA 571 and using this public key to verify the signature. If the 572 verification process is successful, then step 2 will be executed. If 573 the verification fails, then the message should be discarded without 574 further action. 576 2. Check the Time Signed 578 The Time Signed value is obtained from TSIG RDATA and is called t1. 579 The current system time is then obtained and converted to UTC time 580 and is called t2. Fudge time is obtained from TSIG RDATA. If t1 is in 581 the range of t2 and t2 minus/plus fudge (see formula 1) then step 3 582 will be executed. Otherwise, the message will be considered a spoofed 583 message and the message should be discarded without further action. 584 The range is used in consideration of the delays that can occur 585 during its transmission over TCP or UDP. Both times must use UTC time 586 in order to avoid differences in time based on different geographical 587 locations. 589 (t1 - fudge) <= t2 <=(t1 + fudge) (1) 591 3. Execute the CGA verification 593 These steps are found in section 5 RFC 3972. If the sender of the DNS 594 message uses another algorithm, instead of CGA, then this step 595 becomes the verification step for that algorithm. If the verification 596 process is successful, then step 4 will be executed. Otherwise the 597 message will be discarded without further action. 599 4. Verify the source IP address 601 The source IP address of the Update requester MUST be checked against 602 the one contained in the DNS configuration file. If it is the same, 603 then the Update Message should be processed, otherwise, step 5 will 604 be executed. 606 5. Verify the public key 608 The DNS server checks whether or not the public key retrieved from 609 CGA-TSIG DATA is the same as what was available in the storage where 610 the public keys and IP addresses were saved. If no entry is found in 611 storage for this public key, then the update will be rejected without 612 further action. Otherwise, when the old public key length is not zero 613 go to step 6. 615 6. Verify the old public key 617 If the old public key length is zero, then skip this step and discard 618 the DNS update message without further action. If the old public key 619 length is not zero, then the DNS server will retrieve the old public 620 key from CGA-TSIG DATA and will check to see whether or not it is the 621 same as what was saved in the DNS server's storage where the public 622 keys and IP addresses are stored. If it is the same, then step 6 will 623 be executed, otherwise the message should be discarded without 624 further action. 626 7. Verify the old signature 628 The old signature contained in CGA-TSIG DATA should be verified. This 629 can be done by retrieving the old public key and the old signature 630 from CGA-TSIG DATA and then using this old public key to verify the 631 old signature. If the verification is successful, then the Update 632 Message should be processed and the new public key should be replaced 633 with the old public key in the DNS server. If the verification 634 process fails, then the message should be discarded without further 635 action. 637 6. Authentication during the FQDN or PTR Update 639 Normally the DHCPv6 server will update the client's RRs on their 640 behalf in the scenario where SeND is used as a secure NDP, the nodes 641 will need to do this process themselves unless there is stateless 642 DHCPv6 server available. CGA-TSIG can be used to give nodes the 643 ability of doing this process themselves. In this case the clients 644 need to include the CGA-TSIG option in order to allow the DNS server 645 to verify them. The verification process is the same as that 646 explained in section except for step 4. 648 6.1. Verification Process 650 The verification steps are the same as those is explained in section 651 5.1, but removing step 4 and modifying step 5. 653 1- Verify the signature 655 2- Check the Time Signed 657 3- Execute the CGA verification 659 4. Verify the public key 661 The DNS server checks whether or not the public key retrieved from 662 CGA-TSIG DATA is the same as what was available in the storage where 663 the public keys and IP addresses were saved. If no entry is found in 664 storage for this public key, and the FQDN or PTR is also not 665 available in the DNS server, then the DNS server will store the 666 public key of this node in his database and add this node's PTR and 667 FQDN. Otherwise if any PTR is available, and the node IP tag is 668 empty, or there is currently another public key associated with the 669 node's FQDN, then the update will be rejected without further action. 670 Otherwise go to step 5 when the old public key length is not zero. 672 5- Verify the public key 674 6- Verify the old public key 676 7- Verify the old signature 678 7. Authentication during Query Resolving (stub to recursive) 680 A DNS query request sent by a host, such as a client or a mail 681 server, does not need to generate CGA-TSIG DATA because the resolver 682 responds to anonymous queries. But the resolver's response SHOULD 683 contain the CGA-TSIG DATA field in order to enable this client to 684 verify him. However, the client needs to include the TSIG RDATA and 685 set the Algorithm type to CGA-TSIG. It MUST set the CGA-TSIG Len to 686 zero. This allows the resolver to know when to include CGA-TSIG for 687 verification process in client. 689 In generation of the CGA-TSIG for a resolver, there is no need to 690 include the IP tag. This is because resolvers do not usually have 691 several IP addresses so the client does not need to keep several IP 692 addresses for the same resolver. 694 7.1. Verification process 695 When a resolver responds to the host's query request for the first 696 time, the client saves its public key in a file. This allows the 697 client to verify this resolver when it changes its IP address due to 698 privacy or security concerns. The steps 2 and 3 of the verification 699 process are the same as those steps explained in section 5.1. These 700 steps are as follows: 702 1. Verify the signature 704 The signature contained in CGA-TSIG DATA should be verified. This can 705 be done by retrieving the public key and signature from CGA-TSIG DATA 706 and using this public key to verify the signature. If the 707 verification process is successful, then step 2 will be executed. If 708 the verification fails, then the message should be discarded without 709 further action. 711 2. Check the Time Signed 713 3. Execute the CGA verification 715 4. Verify the Source IP address 717 If the resolver's source IP address is the same as that which is 718 known for the host, then step 5 will be executed. Otherwise the 719 message SHOULD be discarded without further action. 721 5. Verify the public key 723 The host checks whether or not the public key retrieved from CGA-TSIG 724 DATA matches any public key that was previously saved in the storage 725 where the public keys and IP addresses of resolvers are saved. If 726 there is a match, then the message is processed. If not, then step 5 727 will be executed. 729 5. Verify the old public key 731 If the old public key length is zero, then skip this step and discard 732 the DNS query response without further action. If the old public key 733 length is not zero, then the host will retrieve the old public key 734 from CGA-TSIG DATA and will check whether or not it is the same as 735 what was saved in the host's storage where the public keys and IP 736 addresses are stored. If it is the same, then step 6 will be 737 executed, otherwise the message should be discarded without further 738 action. 740 6. Verify the old signature 742 The old signature contained in CGA-TSIG DATA should be verified. This 743 can be done by retrieving the old public key and old signature from 744 CGA-TSIG DATA and then using this old public key to verify the old 745 signature. If the verification is successful, then the DNS Message 746 should be processed and the new public key should be replaced with 747 the old public key of the resolver in the host. If the verification 748 process fails, then the message should be discarded without further 749 action. 751 8. Authentication during Query Resolving (Auth. to recursive) 753 This verification step in the authentication of authoritative to 754 recursive DNS server is the same as that explained in section 7.1. In 755 this case the recursive DNS server does not need to generate CGA-TSIG 756 DATA, but the root DNS server does need to include it in order to 757 enable the recursive DNS server to verify it. The recursive DNS 758 server needs to include the TSIG RDATA and set the Algorithm type to 759 CGA-TSIG. It MUST set the CGA-TSIG Len to zero. This allows the root 760 DNS server to know when to include CGA-TSIG for verification process 761 in client. 763 9. No cache parameters available or SeND is not supported 765 In the case where there are no cache parameters available during the 766 IP address generation, there are then two scenarios that come into 767 play here. In the first scenario there is the case where the sender 768 of a DNS message needs to generate a key pair and generate the 769 CGA-TSIG data structure as explained in section 4. The node SHOULD 770 skip the first section of the verification processes explained in 771 section 5.1 , section 6.1 and section 7.1. 773 In the second scenario, as explained in section 4.2 (step 1), it is 774 not necessary for the server to support the SeND or CGA algorithm. 775 The DNS administrator can make a one-time use of a CGA script to 776 generate the CGA parameters and then manually configure the IP 777 address of this DNS server. Then later, this DNS server can use those 778 values as a means for authenticating other nodes. The verifier nodes 779 also do not necessarily need to support SeND. They only need to 780 support CGA-TSIG. 782 10. How to obtain the IP address of resolvers 784 Nodes can obtain the IP address of resolvers from the DHCPv6 server 785 (that will not be secure) or from a DNS option of Router 786 Advertisement message [RFC6106] after authenticating the router via a 787 trusted authority. The IP addresses can be generated using CGA, SSAS 788 or other mechanisms. 790 11. CGA-TSIG Data confidentiality 792 One possible solution to provide the DNS server with data 793 confidentiality during DNS update or other DNS query processes is the 794 use of symmetric encryption with CGA-TSIG that is called CGA-TSIGe. 795 In this case, the node MUST set the Algorithm type in TSIG RDATA to 796 CGA-TSIGe. 798 11.1. Generation of secret key 800 To encrypt the DNS message using a symmetric algorithm for 801 performance purposes, first, a node needs to retrieve the public key 802 of the DNS server. It is possible to use the current DNSKEY RR (RFC 803 3757) to send the public key of the DNS server. When the client wants 804 to update any records on the DNS server, it first sends a DNS message 805 and asks for the public key of the DNS server. DNS server then 806 answers to this query and includes the public key contained in the 807 DNSKEY RR with the SEP flag set to zero. This is done to indicate 808 that it is not the zone key. The DNS server SHOULD include CGA-TSIG 809 DATA so that the client can verify its IP address. In this case, 810 there will be a binding between DNS server?s public key and its IP 811 address. After a successful verification, the node then generates a 812 16 byte random number and calls it a secret key. It encrypts this 813 secret key using the DNS server public key. This allows only the DNS 814 server to decrypt this secret key. In this case, the node sets the 815 MAC in TSIG RDATA to the digest of secret key and set the MAC Size to 816 the length of this digest. The DNS server knows what to do with MAC 817 field from the Algorithm type in TSIG. If it is CGA-TSIGe, then it 818 looks for an encrypted secret key. 820 11.2. DNS message generation 822 The node MUST encrypt all DNS message sections that required 823 protections using the secret key generated in last section and AES 824 symmetric algorithm. It excludes TSIG RDATA (That usually added in 825 the additional section of the DNS messages) from the encryption text. 826 They are explained in figure 4 and figure 5 of section 4.2 of this 827 document. 829 11.3. CGA-TSIGe DATA generation 831 The CGA-TSIGe generation is the same as that explained in section 4.2 832 of this document. But only the Algorithm type MUST be set to 833 CGA-TSIGe. 835 11.4. Process of encrypted DNS message 837 When the DNS server receives the message from any node with TSIG 838 RDATA Algorithm type set to CGA-TSIGe, it execute the following 839 steps: 841 1- Retrieve the secret key 843 The DNS server retrieves the secret key from MAC field. It then 844 decrypts this secret key using its own private key. 846 2- Decrypt the DNS message 848 The DNS server decrypts the DNS server message using this secret key 849 and the symmetric algorithm, which by default is AES. 851 Then the DNS server can starts the verification process as explained 852 in section 5.1, 6.1, 7.1 of this document. 854 12. CGA-TSIG/CGA-TSIGe Applications 856 The purpose of CGA-TSIG [7] is to minimize the amount of human 857 intervention required to accomplish shared secret or key exchange 858 and, as a byproduct, to reduce the process's vulnerability to attacks 859 introduced by human errors (during changing the DNS configuration) 860 when Secure Neighbor Discovery (SeND) is used for addressing purposes 861 or when SeND is not available for use. 863 As explained in a prior section, CGA-TSIG can be used in different 864 scenarios. For the FQDN update scenario CGA-TSIG is useful in dynamic 865 networks where the nodes want to change their IP addresses frequently 866 in order to maintain privacy. If the Dynamic Host Configuration 867 Protocol (DHCP) is in use, then the DHCP server can do this update on 868 behalf of the nodes in this network on a DNS server but in Neighbor 869 Discovery Protocol (NDP), there is no feature available that allows 870 the host security update process for its own FQDN. CGA-TSIG can be a 871 solution. 873 For the resolver scenario, usually the resolver can add the TSIG 874 Resource Record (RR) to the DNS query response and use the CGA-TSIG 875 algorithm in order to permit a useful authentication of the result. 876 CGA-TSIG assures the client that the query response comes from the 877 true originator and not from an attacker. It also ensures the 878 integrity of the data by signing the data. 880 There are several types of attack that CGA-TSIG can prevent. Here we 881 will evaluate some of them. The use of CGA-TSIG will also reduce the 882 number of messages needed in exchange between a client and a server 883 in order to establish a secure channel. To exchange the shared secret 884 between a DNS resolver and a client, when TSIG is used, a minimum of 885 four messages are required for the establishment of a secure channel. 886 Modifying RFC 2845 to use CGA-TSIG will decrease the number of 887 messages needed in this exchange. The messages used in RFC 2930 (TKEY 888 RR) are not needed when CGA-TSIG is used. 890 12.1. IP Spoofing 892 During the DNS Update process or the query resolving process it is 893 important that both communicating parties know that the one that they 894 are communicating with is the actual owner of that IP address and 895 that the messages are not being sent from a spoofed IP address. This 896 can be accomplished by the use of the CGA algorithm which utilizes 897 the node for IP address verification of other nodes. 899 12.2. DNS Dynamic Update Spoofing 901 Dynamic Update Spoofing is eliminated because the signature contains 902 both the CGA parameters and the DNS update message. This will offer 903 proof of the sender's IP address ownership (CGA parameters) and the 904 validity of the update message. 906 12.3. Resolver Configuration Attack 908 When using CGA-TSIG, the DNS server, or the client, would not need 909 further configuration. This would reduce the possibility of human 910 errors being introduced into the DNS configuration file. Since this 911 type of attack is predicated on human error, the chances of it 912 occurring, when this extension is used, are minimized. 914 12.4. Exposing Shared Secret 916 Using CGA-TSIG will decrease the number of manual steps required in 917 generating the new shared secret and in exchanging it among the hosts 918 where the old shared secret was shared between them for updating 919 purposes. This manual step is required after a leakage has occurred 920 of the shared secret to an attacker via any of these hosts. 922 12.5. Replay attack 924 Using the Time Signed value in the signature modifies the content of 925 the signature each time the node generates and sends it to the DNS 926 server. If the attacker tries to spoof this value with another 927 timestamp, to show that the update message is current, the DNS server 928 checks this message by verifying the signature. In this case, the 929 verification process will fail thus also preventing the replay 930 attack. 932 12.6. Data confidentiality 934 Encrypting the whole DNS message will avoid the attacker to know the 935 content of DNS messages. This will avoid zone walking and many other 936 attacks on DNS RRs. This also provides the higher privacy for hosts 937 that has DNS records. 939 13. Security Considerations 941 The approach explained in this draft, CGA-TSIG, is a solution for 942 securing DNS messages from spoofing type attacks like those explained 943 in section 3. 945 A problem that may arise here concerns attacks against the CGA 946 algorithm. In this section we will explain the possibility of such 947 attacks against CGA [5] and explain the available solutions that we 948 considered in this draft. 950 a) Discover an Alternative Key Pair Hashing of the Victim's Node 951 Address 953 In this case an attacker would have to find an alternate key pair 954 hashing of the victim?s address. The probability for success of this 955 type of attack will rely on the security properties of the underlying 956 hash function, i.e., an attacker will need to break the second 957 pre-image resistance of that hash function. The attacker will perform 958 a second pre-image attack on a specific address in order to match 959 other CGA parameters using Hash1 and Hash2. The cost of doing this is 960 (2^59+1) * 2^(16*1). If the user uses a sufficient security level, it 961 will be not feasible for an attacker to carry out this type of attack 962 due to the cost involved. Changing the IP address frequently will 963 also decrease the chance for this type of attack succeeding. 965 b) DoS to Kill a CGA Node 967 Sending a valid or invalid CGA signed message with high frequency 968 across the network can keep the destination node(s) busy with the 969 verification process. This type of DoS attack is not specific to CGA, 970 but it can be applied to any request-response protocol. One possible 971 solution ,to mitigate this attack, is to add a controller to the 972 verifier side of the process to determine how many messages a node 973 has received over a certain period of time from a specific node. If a 974 determined threshold rate is exceeded, then the node will stop 975 further receipt of incoming messages from that node. 977 c) CGA Privacy Implication 979 Due to the high computational complexity necessary for the creation 980 of a CGA, it is likely that once a node generates an acceptable CGA 981 it will continue its use at that subnet. The result is that nodes 982 using CGAs are still susceptible to privacy related attacks. One 983 solution to these types of attacks is setting a lifetime for the 984 address as explained in RFC 4941. 986 14. IANA Considerations 988 The IANA has allowed for choosing new algorithm(s) for use in the 989 TSIG Algorithm name. Algorithm name refers to the algorithm described 990 in this document. The requirement to have this name registered with 991 IANA is specified. 993 In section 4.1, Type should allow for the use of future optional 994 algorithms with regard to SeND. The default value for CGA might be 1. 995 Other algorithms would be assigned a new number sequentially. For 996 example, a new algorithm called SSAS [4,5] could be assigned a value 997 of 2. 999 IANA also needs to define a numeric algorithm number for ECC. The 1000 similar way that is defined for RSA. 1002 15. Appendix 1004 - A sample key storage for CGA-TSIG 1006 create table cgatsigkeys ( 1008 id INT auto_increment, 1010 pubkey VARCHAR(300), 1012 primary key(id) 1014 ); 1015 create table cgatsigips ( 1017 id INT auto_increment, 1019 idkey INT, 1021 IP VARCHAR(20), 1023 FOREIGN KEY (idkey) REFERENCES cgatsigkeys(id) 1025 primary key(id) 1027 ); 1029 CGA-TSIG tables on mysql backend database 1031 - a sample format of stored parameters in the node 1033 For example, the modifier is stored as bytes and each byte might be 1034 separated by a comma (for example : 284,25,14,...). Algorithmtype is 1035 the algorithm used in signing the message. Zero is the default 1036 algorithm for RSA. Secval is the CGA Sec value that is, by default, 1037 one. GIP is the global IP address of this node (for example: 1038 2001:abc:def:1234:567:89a). oGIP is the old IP address of this node, 1039 before the generation of the new IP address. Keys contains the path 1040 where the CGA-TSIG algorithm can find the PEM format used for the 1041 public/private keys (for example: /home/myuser/keys.pem ). 1043 1045
1047 1049 1051 1053 1055 1057 1059 1061 1063
1064 XML file contains the cached DATA 1066 16. Acknowledgements 1068 The continual improvement of this document is as a result of the 1069 helps and assistance of its supporters. 1071 The authors would like to thank all those people who directly helped 1072 in improving this draft and all supporters of this draft, especially 1073 Ralph Droms, Andrew Sullivan, Ted Lemon, Brian Haberman. The authors 1074 would like also to special acknowledge the supports of NLnet Labs 1075 director and researchers; Olaf Kolkman, Matthijs Mekking and their 1076 master student Marc Buijsman. 1078 17. References 1080 17.1. Normative References 1082 [RFC2119] Bradner, S., "Key words for use in RFCs to 1083 Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 1085 [RFC3972] Aura, T., "Cryptographically Generated Addresses 1086 (CGA)," RFC 3972, March 2005. 1088 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, 1089 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 1091 [RFC2119] Bradner, S., "Key words for use in RFCs to 1092 Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 1094 [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for 1095 DNS (TKEY RR)", RFC 2930, September 2000. 1097 [RFC1035] Mockapetris, P., "Domain Names - Implementation 1098 And Specification", RFC 1035, November 1987. 1100 [RFC4941] Narten, T., Draves, R., Krishnan, S., "Privacy 1101 Extensions for Stateless Address Autoconfiguration in 1102 IPv6", RFC 4941, September 2007. 1104 [RFC2136] Vixie, P. (Editor), Thomson, S., Rekhter, Y., 1105 Bound, J., "Dynamic Updates in the Domain Name System (DNS 1106 UPDATE)", RFC 2136, April 1997. 1108 [RFC2845] Vixie, P., Gudmundsson, O. , Eastlake 3rd, D., 1109 Wellington, B., " Secret Key Transaction Authentication for 1110 DNS (TSIG)", RFC 2845, May 2000. 1112 [RFC6106] Jeong, J., Park, S., Beloeil, L., Madanapalli, 1113 S.,"IPv6 Router Advertisement Options for DNS 1114 Configuration",RFC 6106, November 2010. 1116 17.2. Informative References 1118 [1] Aura, T., "Cryptographically Generated Addresses (CGA)", 1119 Lecture Notes in Computer Science, Springer, vol. 2851/2003, pp. 1120 29-43, 2003. 1122 [2] Montenegro, G. and Castelluccia, C., "Statistically Unique 1123 and Cryptographically Verifiable (SUCV) Identifiers and 1124 Addresses," ISOC Symposium on Network and Distributed System 1125 Security (NDSS 2002), the Internet Society, 2002. 1127 [3] AlSa'deh, A., Rafiee, H., Meinel, C., "IPv6 Stateless Address 1128 Autoconfiguration: Balancing Between Security, Privacy and 1129 Usability". Lecture Notes in Computer Science, Springer(5th 1130 International Symposium on Foundations & Practice of Security 1131 (FPS). October 25 - 26, 2012 Montreal, QC, Canada), 2012. 1133 [4] Rafiee, H., Meinel, C., "A Simple Secure Addressing 1134 Generation Scheme for IPv6 AutoConfiguration (SSAS)". Work in 1135 progress, http://tools.ietf.org/html/draft-rafiee-6man-ssas, 1136 2013. 1138 [5] Rafiee, H., Meinel, C., "A Simple Secure Addressing Scheme 1139 for IPv6 AutoConfiguration (SSAS)", 11th International conference 1140 on Privacy, Security and Trust (IEEE PST), 2013. 1142 [6] AlSa'deh, A., Rafiee, H., Meinel, C., "Cryptographically 1143 Generated Addresses (CGAs): Possible Attacks and Proposed 1144 Mitigation Approaches," in proceedings of 12th IEEE International 1145 Conference on Computer and Information Technology (IEEE CIT'12), 1146 pp.332-339, 2012. 1148 [7] Rafiee, H., Meinel, C., "A Secure, Flexible Framework for DNS 1149 Authentication in IPv6 Autoconfiguration" in proceedings of The 1150 12th IEEE International Symposium on Network Computing and 1151 Applications (IEEE NCA13), 2013. 1153 Authors' Addresses 1155 Hosnieh Rafiee 1156 Ciber AG 1157 KoelnTurm 1158 Im Mediapark 8 1159 50670, Cologne 1160 http://www.ciber.com 1161 Phone: +49 (0221) 272 67- 122 1162 Email: ietf@rozanak.com 1164 Christoph Meinel 1165 Hasso-Plattner-Institute 1166 Prof.-Dr.-Helmert-Str. 2-3 1167 Potsdam, Germany 1168 Email: meinel@hpi.uni-potsdam.de 1170 Martin von Loewis 1171 Hasso-Plattner-Institute 1172 Prof.-Dr.-Helmert-Str. 2-3 1173 Potsdam, Germany