idnits 2.17.1 draft-ietf-hip-cert-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) == The document has an IETF Trust Provisions of 28 Dec 2009, Section 6.c(i) Publication Limitation clause. 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 are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (January 12, 2011) is 4852 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1779 (Obsoleted by RFC 2253, RFC 3494) ** Obsolete normative reference: RFC 2255 (Obsoleted by RFC 4510, RFC 4516) ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Host Identity Protocol Heer 3 Internet-Draft Distributed Systems Group, RWTH 4 Intended status: Experimental Aachen University 5 Expires: July 16, 2011 Varjonen 6 Helsinki Institute for Information 7 Technology 8 January 12, 2011 10 Host Identity Protocol Certificates 11 draft-ietf-hip-cert-07 13 Abstract 15 The CERT parameter is a container for X.509.v3 certificates and 16 Simple Public Key Infrastructure (SPKI) certificates. It is used for 17 carrying these certificates in Host Identity Protocol (HIP) control 18 packets. This document specifies the certificate parameter and the 19 error signaling in case of a failed verification. Additionally, this 20 document specifies the representations of Host Identity Tags in 21 X.509.v3 and SPKI certificates. 23 The concrete use of certificates including how certificates are 24 obtained, requested, and which actions are taken upon successful or 25 failed verification are specific to the scenario in which the 26 certificates are used. Hence, the definition of these scenario- 27 specific aspects are left to the documents that use the CERT 28 parameter. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. This document may not be modified, 34 and derivative works of it may not be created, except to format it 35 for publication as an RFC or to translate it into languages other 36 than English. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt. 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 This Internet-Draft will expire on July 16, 2011. 56 Copyright Notice 58 Copyright (c) 2011 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the BSD License. 71 1. Introduction 73 Digital certificates bind a piece of information to a public key by 74 means of a digital signature, and thus, enable the holder of a 75 private key to generate cryptographically verifiable statements. The 76 Host Identity Protocol (HIP) [RFC5201] defines a new cryptographic 77 namespace based on asymmetric cryptography. The identity of each 78 host is derived from a public key, allowing hosts to digitally sign 79 data and issue certificates with their private key. This document 80 specifies the CERT parameter, which is used to transmit digital 81 certificates in HIP. It fills the placeholder specified in Section 82 5.2 of [RFC5201]. 84 1.1. Requirements Language 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [RFC2119]. 90 2. CERT Parameter 92 The CERT parameter is a container for certain types of digital 93 certificates. It MAY either carry SPKI certificates or X.509.v3 94 certificates. It does not specify any certificate semantics. 96 However, it defines supplementary parameters that help HIP hosts to 97 transmit semantically grouped CERT parameters in a more systematic 98 way. The specific use of the CERT parameter for different use cases 99 is intentionally not discussed in this document because it is 100 specific to a concrete use case. Hence, the use of the CERT 101 parameter will be defined in the documents that use the CERT 102 parameter. 104 The CERT parameter is covered, when present, by the HIP SIGNATURE 105 field and is a non-critical parameter. 107 The CERT parameter can be used in all HIP packets. However, using it 108 in the I1 packet is not recommended because it can increase the 109 processing times of I1s, which can be problematic when processing 110 storms of I1s. Each HIP control packet MAY contain multiple CERT 111 parameters. These parameters MAY be related or unrelated. Related 112 certificates are managed in Cert groups. A Cert group specifies a 113 group of related CERT parameters that SHOULD be interpreted in a 114 certain order (e.g., for expressing certificate chains). For 115 grouping CERT parameters, the Cert group and the Cert count field 116 MUST be set. Ungrouped certificates exhibit a unique Cert group 117 field and set the Cert count to 1. CERT parameters with the same 118 Cert group number in the group field indicate a logical grouping. 119 The Cert count field indicates the number of CERT parameters in the 120 group. 122 CERT parameters that belong to the same Cert group MAY be contained 123 in multiple sequential HIP control packets. This is indicated by a 124 higher Cert count than the amount of CERT parameters with matching 125 Cert group fields in a HIP control packet. The CERT parameters MUST 126 be placed in ascending order, within a HIP control packet, according 127 to their Cert group field. Cert groups MAY only span multiple 128 packets if the Cert group does not fit the packet. A HIP packet MUST 129 NOT contain more than one incomplete Cert group that continues in the 130 next HIP control packet. 132 The Cert ID acts as a sequence number to identify the certificates in 133 a Cert group. The numbers in the Cert ID field MUST start from 1 up 134 to Cert count. 136 The Cert Group and Cert ID namespaces are managed locally by each 137 host that sends CERT parameters in HIP control packets. 139 0 1 2 3 140 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Type | Length | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Cert group | Cert count | Cert ID | Cert type | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Certificate / 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 / | Padding | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Type 768 152 Length Length in octets, excluding Type, Length, and Padding 153 Cert group Group ID grouping multiple related CERT parameters 154 Cert count Total count of certificates that are sent, possibly 155 in several consecutive HIP control packets. 156 Cert ID The sequence number for this certificate 157 Cert Type Indicates the type of the certificate 158 Padding Any Padding, if necessary, to make the TLV a multiple 159 of 8 bytes. 161 The following certificate types are defined: 163 +--------------------------------+-------------+ 164 | Cert format | Type number | 165 +--------------------------------+-------------+ 166 | X.509.v3 | 1 | 167 | SPKI | 2 | 168 | Hash and URL of X.509.v3 | 3 | 169 | Hash and URL of SPKI | 4 | 170 | LDAP URL of X.509.v3 | 5 | 171 | LDAP URL of SPKI | 6 | 172 | Distinguished Name of X.509.v3 | 7 | 173 | Distinguished Name of SPKI | 8 | 174 +--------------------------------+-------------+ 176 The next sections outline the use of HITs in X.509.v3 and in SPKI 177 certificates. X.509.v3 certificates are defined in [RFC3280]. The 178 wire format for X.509.v3 is Distinguished Encoding Rules format as 179 defined in [X.690]. The SPKI and its formats are defined in 180 [RFC2693]. 182 Hash and URL encodings (3 and 4) are used as defined in [RFC4306] 183 Section 3.6. Using hash and URL encodings results in smaller HIP 184 control packets, but requires the receiver to resolve the URL or 185 check a local cache against the hash. 187 LDAP URL encodings (5 and 6) are used as defined in [RFC2255]. Using 188 LDAP URL encoding results in smaller HIP control packets but requires 189 the receiver to retrieve the certificate or check a local cache 190 against the URL. 192 Distinguished name (DN) encodings (7 and 8) are used as defined in 193 [RFC1779]. Using the DN encoding results in smaller HIP control 194 packets, but requires the receiver to retrieve the certificate or 195 check a local cache against the DN. 197 3. X.509.v3 Certificate Object and Host Identities 199 When using X.509.v3 certificates to transmit information related to 200 HIP hosts, HITs MAY be enclosed within the certificates. HITs can 201 represent an issuer, a subject, or both. In X.509.v3 HITs are 202 represented as issuer or subject alternative name extensions as 203 defined in [RFC2459]. If only the HIT of the host is presented as 204 either the issuer or the subject the respective HIT MUST be placed 205 into the respective entity's DN's Common Name (CN) section in a colon 206 delimited presentation format defined in [RFC5952]. Inclusion of CN 207 is not necessary if DN contains any other naming information. It is 208 RECOMMENDED to use the FQDN/NAI from the hosts HOST_ID parameter in 209 the DN if one exists. The full HIs are presented in the public key 210 entries of X.509.v3 certificates. 212 The following examples illustrate how HITs are presented as issuer 213 and subject in the DN and in the X.509.v3 extension alternative 214 names. 216 Format of DN: 217 Issuer: CN=hit-of-issuer 218 Subject: CN=hit-of-subject 220 Example DN: 221 Issuer: CN=2001:14:6cf:fae7:bb79:bf78:7d64:c056 222 Subject: CN=2001:1c:5a14:26de:a07c:385b:de35:60e3 224 Format of X509v3 extensions: 225 X509v3 Issuer Alternative Name: 226 IP Address:hit-of-issuer 227 X509v3 Subject Alternative Name: 228 IP Address:hit-of-subject 230 Example X509v3 extensions: 231 X509v3 Issuer Alternative Name: 232 IP Address:2001:14:6cf:fae7:bb79:bf78:7d64:c056 233 X509v3 Subject Alternative Name: 234 IP Address:2001:1C:5a14:26de:a07C:385b:de35:60e3 236 Appendix B shows a full example X.509.v3 certificate with HIP 237 content. 239 As another example, consider a managed PKI environment in which the 240 peers have certificates that are anchored in (potentially different) 241 managed trust chains. In this scenario, the certificates issued to 242 HIP hosts are signed by intermediate Certificate Authorities (CAs) up 243 to a root CA. In this example, the managed PKI environment is 244 neither HIP aware, nor can it be configured to compute HITs and 245 include them in the certificates. 247 In this scenario, it is RECOMMENDED that the HIP peers have and use 248 some mechanism of defining trusted root CAs for the purpose of 249 establishing HIP communications. Furthermore it is recommended that 250 the HIP peers have and use some mechanism of checking peer 251 certificate validity for revocation, signature, minimum cryptographic 252 strength, etc., up to the trusted root CA. 254 When HIP communications are established, the HIP hosts not only need 255 to send their identity certificates (or pointers to their 256 certificates), but also the chain of intermediate CAs (or pointers to 257 the CAs) up to the root CA, or to a CA that is trusted by the remote 258 peer. This chain of certificates MUST be sent in a Cert group as 259 specified in Section 2. The HIP peers validate each other's 260 certificates and compute peer HITs based on the certificate public 261 keys. 263 4. SPKI Cert Object and Host Identities 265 When using SPKI certificates to transmit information related to HIP 266 hosts, HITs need to be enclosed within the certificates. HITs can 267 represent an issuer, a subject, or both. In the following we define 268 the representation of those identifiers for SPKI given as 269 S-expressions. Note that the S-expressions are only the human- 270 readable representation of SPKI certificates. Full HIs are presented 271 in the public key sequences of SPKI certificates. 273 As an example the Host Identity Tag of a host is expressed as 274 follows: 276 Format: (hash hit hit-of-host) 277 Example: (hash hit 2001:13:724d:f3c0:6ff0:33c2:15d8:5f50) 279 Appendix A shows a full example SPKI certificate with HIP content. 281 5. Revocation of Certificates 283 Revocation of X.509.v3 certificates is handled as defined in Section 284 5 of [RFC2459]. Revocation of SPKI certificates is handled as 285 defined in Section 5 of [RFC2693]. 287 6. Error signaling 289 If the Initiator does not send the certificate that the Responder 290 requires the Responder may take actions (e.g. reject the connection). 291 The Responder MAY signal this to the Initiator by sending a HIP 292 NOTIFY message with NOTIFICATION parameter error type 293 CREDENTIALS_NEEDED. 295 If the verification of a certificate fails, a verifier MAY signal 296 this to the provider of the certificate by sending a HIP NOTIFY 297 message with NOTIFICATION parameter error type INVALID_CERTIFICATE. 299 NOTIFICATION PARAMETER - ERROR TYPES Value 300 ------------------------------------ ----- 302 CREDENTIALS_REQUIRED 48 304 The Responder is unwilling to set up an association 305 as the Initiator did not send the needed credentials. 307 INVALID_CERTIFICATE 50 309 Sent in response to a failed verification of a certificate. 310 Notification Data MAY contain n groups of 2 octets (n calculated 311 from the NOTIFICATION parameter length), in order Cert group and 312 Cert ID of the certificate parameter that caused the failure. 314 7. IANA Considerations 316 This document defines the CERT parameter for the Host Identity 317 Protocol [RFC5201]. This parameter is defined in Section 2 with type 318 768. The parameter type number is also defined in [RFC5201]. 320 The CERT parameter has 8-bit unsigned integer field for different 321 certificate types, for which IANA is to create and maintain a new 322 sub-registry entitled "HIP certificate types" under the "Host 323 Identity Protocol (HIP) Parameters". Initial values for the 324 Certificate type registry are given in Section 2. 326 In Section 6 this document defines two new types for "NOTIFY message 327 types" sub-registry under "Host Identity Protocol (HIP) Parameters". 329 8. Security Considerations 331 Certificate grouping allows the certificates to be sent in multiple 332 consecutive packets. This might allow similar attacks as IP-layer 333 fragmentation allows, for example sending of fragments in wrong order 334 and skipping some fragments to delay or stall packet processing by 335 the victim in order to use resources (e.g. CPU or memory). Hence, 336 hosts SHOULD implement mechanisms to discard certificate groups with 337 outstanding certificates if state space is scarce. 339 9. Acknowledgements 341 The authors would like to thank A. Keranen, D. Mattes, M. Komu and T. 342 Henderson for the fruitful conversations on the subject. D. Mattes 343 most notably contributed the non-HIP aware use case in Section 3. 345 10. References 347 10.1. Normative References 349 [RFC1779] Kille, S., "A String Representation of Distinguished 350 Names", RFC 1779, March 1995. 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, March 1997. 355 [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, 356 December 1997. 358 [RFC2459] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet 359 X.509 Public Key Infrastructure Certificate and CRL 360 Profile", RFC 2459, January 1999. 362 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 363 B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 364 September 1999. 366 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 367 X.509 Public Key Infrastructure Certificate and 368 Certificate Revocation List (CRL) Profile", RFC 3280, 369 April 2002. 371 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 372 RFC 4306, December 2005. 374 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 375 "Host Identity Protocol", RFC 5201, April 2008. 377 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 378 Address Text Representation", RFC 5952, August 2010. 380 10.2. Informative References 382 [X.690] ITU-T, "Recommendation X.690 Information Technology - 383 ASN.1 encoding rules: Specification of Basic Encoding 384 Rules (BER), Canonical Encoding Rules (CER) and 385 Distinguished Encoding Rules (DER)", July 2002, . 389 Appendix A. SPKI certificate example 391 This section shows a SPKI certificate with encoded HITs. The example 392 has been indented for readability. 394 (sequence 395 (public_key 396 (rsa-pkcs1-sha1 397 (e #010001#) 398 (n |yDwznOwX0w+zvQbpWoTnfWrUPLKW2NFrpXbsIcH/QBSLb 399 k1RKTZhLasFwvtSHAjqh220W8gRiQAGIqKplyrDEqSrJp 400 OdIsHIQ8BQhJAyILWA1Sa6f5wAnWozDfgdXoKLNdT8ZNB 401 mzluPiw4ozc78p6MHElH75Hm3yHaWxT+s83M=| 402 ) 403 ) 404 ) 405 (cert 406 (issuer 407 (hash hit 2001:15:2453:698a:9aa:253a:dcb5:981e) 408 ) 409 (subject 410 (hash hit 2001:12:ccd6:4715:72a3:2ab1:77e4:4acc) 411 ) 412 (not-before "2011-01-12_13:43:09") 413 (not-after "2011-01-22_13:43:09") 414 ) 415 (signature 416 (hash sha1 |h5fC8HUMATTtK0cjYqIgeN3HCIMA|) 417 |u8NTRutINI/AeeZgN6bngjvjYPtVahvY7MhGfenTpT7MCgBy 418 NoZglqH5Cy2vH6LrQFYWx0MjWoYwHKimEuBKCNd4TK6hrCyAI 419 CIDJAZ70TyKXgONwDNWPOmcc3lFmsih8ezkoBseFWHqRGISIm 420 MLdeaMciP4lVfxPY2AQKdMrBc=| 421 ) 422 ) 424 Appendix B. X.509.v3 certificate example 426 This section shows a X.509.v3 certificate with encoded HITs. 428 Certificate: 429 Data: 430 Version: 3 (0x2) 431 Serial Number: 0 (0x0) 432 Signature Algorithm: sha1WithRSAEncryption 433 Issuer: CN=2001:1e:d709:1980:5c6a:bb0c:7650:a027 434 Validity 435 Not Before: Jun 22 13:39:32 2010 GMT 436 Not After : Jul 2 13:39:32 2010 GMT 437 Subject: CN=2001:1c:5a14:26de:a07c:385b:de35:60e3 438 Subject Public Key Info: 439 Public Key Algorithm: rsaEncryption 440 RSA Public Key: (1024 bit) 441 Modulus (1024 bit): 442 00:b9:5e:cc:d5:d9:7b:39:c2:42:3e:79:49:ad:7f: 443 0c:bd:0f:12:98:4e:b0:9d:ee:62:76:7a:7b:55:f0: 444 cc:a2:57:ac:b6:e2:6a:bc:1e:bd:cf:75:30:95:5b: 445 92:af:75:55:69:0b:c3:48:0f:b5:e4:15:30:79:89: 446 22:b3:fd:7e:51:59:d2:0d:d7:12:5d:44:f3:e8:05: 447 13:1f:5b:4f:89:fa:1e:6d:83:e9:e2:cf:bd:5c:6f: 448 ef:02:1e:c8:db:9a:48:9a:35:b8:b8:be:89:be:ab: 449 c8:dd:60:44:df:ac:01:b7:76:66:ab:5d:a1:a5:d0: 450 3c:8d:22:04:d4:24:59:60:0f 451 Exponent: 65537 (0x10001) 452 X509v3 extensions: 453 X509v3 Issuer Alternative Name: 454 IP Address:2001:1e:d709:1980:5c6a:bb0C:7650:a027 455 X509v3 Subject Alternative Name: 456 IP Address:2001:1c:5a14:26de:a07c:385b:de35:60e3 457 Signature Algorithm: sha1WithRSAEncryption 458 48:a1:25:fb:01:31:d9:80:76:1b:1a:2d:00:f1:26:22:3c:3b: 459 20:a0:cb:b2:28:d2:0c:21:d3:9e:3b:4a:ab:3d:f6:ea:ad:46: 460 f6:f5:c4:4f:71:ce:3e:7b:65:8d:58:75:2e:99:25:82:5f:73: 461 10:c6:c2:f0:4b:35:ff:5c:65:ac:fc:a4:a7:76:50:ab:62:50: 462 b8:86:21:e6:83:e1:c1:3d:20:c9:8e:13:ab:d7:4b:d4:ab:2d: 463 72:9d:f0:9f:5f:e0:6f:95:fa:a1:95:64:3f:74:63:e5:a8:1d: 464 f7:e6:48:98:33:53:7b:91:6d:b0:cb:af:32:15:8c:e0:01:a0: 465 a0:b8 467 Appendix C. Change log 469 Changes from version 00 to 01: 471 o Revised text on DN usage. 473 o Revised text on Cert group usage. 475 Changes from version 01 to 02: 477 o Revised the type numbers. 479 o Added a section on signaling. 481 Changes from version 02 to 03: 483 o Revised text on CERT usage in control packets. 485 Changes from version 03 to 04: 487 o Added the non-HIP aware use case to the Section 3. 489 o Clarified that the HITs are not always required in the 490 certificates. 492 o Rewrote the signaling section. 494 o LDAP URL to LDAP DN in Section 2 last paragraph. 496 o CERT is always covered by a signature as it's type number requires 498 o New example certificates 500 o Style and language clean-ups 502 o Changed IANA considerations 504 o Revised the type numbers 506 o RFC 2119 keywords 508 o Updated the IANA considerations section 510 o Rewrote the abstract 512 Changes from version 04 to 05: 514 o Clarified the examples in Section 3. 516 o Clarifications to Section Section 3. 518 o Modified the explanation of INVALID_CERTIFICATE to allow multiple 519 certs. 521 o Added reference to the IPv6 colon delimited presentation format. 523 o Small editorial changes. 525 Changes from version 05 to 06: 527 o Editorial changes. 529 o Unified the example in Section 3. 531 Changes from version 06 to 07: 533 o Editorial changes. 535 o Removed a the second paragraph in section 8. 537 o Changed the example in Appendix A (Cert created without the 538 leading zeroes in HITs). 540 Authors' Addresses 542 Tobias Heer 543 Distributed Systems Group, RWTH Aachen University 544 Ahornstrasse 55 545 Aachen 546 Germany 548 Phone: +49 241 80 214 36 549 Email: heer@cs.rwth-aachen.de 550 URI: http://ds.cs.rwth-aachen.de/members/heer 552 Samu Varjonen 553 Helsinki Institute for Information Technology 554 Gustaf Haellstroemin katu 2b 555 Helsinki 556 Finland 558 Email: samu.varjonen@hiit.fi 559 URI: http://www.hiit.fi