idnits 2.17.1 draft-ietf-hip-cert-05.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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 8, 2010) is 4911 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 (~~), 4 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: May 12, 2011 Varjonen 6 Helsinki Institute for Information 7 Technology 8 November 8, 2010 10 Host Identity Protocol Certificates 11 draft-ietf-hip-cert-05 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 only specifies the certificate parameter and 19 the error signaling in case of a failed verification. The use of 20 certificates including how certificates are obtained, requested, and 21 which actions are taken upon successful or failed verification are to 22 be defined in the documents that use the certificate parameter. 23 Additionally, this document specifies the representations of Host 24 Identity Tags in X.509.v3 and SPKI certificates. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. This document may not be modified, 30 and derivative works of it may not be created, except to format it 31 for publication as an RFC or to translate it into languages other 32 than English. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on May 12, 2011. 52 Copyright Notice 54 Copyright (c) 2010 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the BSD License. 67 1. Introduction 69 Digital certificates bind a piece of information to a public key by 70 means of a digital signature, and thus, enable the holder of a 71 private key to generate cryptographically verifiable statements. The 72 Host Identity Protocol (HIP) [RFC5201] defines a new cryptographic 73 namespace based on asymmetric cryptography. The identity of each 74 host is derived from a public key, allowing hosts to digitally sign 75 data with their private key. This document specifies the CERT 76 parameter, which is used to transmit digital certificates in HIP. It 77 fills the placeholder specified in Section 5.2 of [RFC5201]. 79 1.1. Requirements Language 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC2119]. 85 2. CERT Parameter 87 The CERT parameter is a container for certain types of digital 88 certificates. It MAY either carry SPKI certificates or X.509.v3 89 certificates. It does not specify any certificate semantics. 90 However, it defines supplementary parameters that help HIP hosts to 91 transmit semantically grouped CERT parameters in a more systematic 92 way. The specific use of the CERT parameter for different use cases 93 is intentionally not discussed in this document. 95 The CERT parameter is covered, when present, by the HIP SIGNATURE 96 field and is a non-critical parameter. 98 The CERT parameter can be used in all HIP packets but using it in the 99 I1 packet is not recommended because it can increase the processing 100 times of I1s, which can be problematic when processing storms of I1s. 101 Each HIP control packet MAY contain multiple CERT parameters. These 102 parameters MAY be related or unrelated. Related certificates are 103 managed in Cert groups. A Cert group specifies a group of related 104 CERT parameters that SHOULD be interpreted in a certain order (e.g. 105 for expressing certificate chains). For grouping CERT parameters, 106 the Cert group and the Cert count field MUST be set. Ungrouped 107 certificates exhibit a unique Cert group field and set the Cert count 108 to 1. CERT parameters with the same Cert group number in the group 109 field indicate a logical grouping. The Cert count field indicates 110 the number of CERT parameters in the group. 112 CERT parameters that belong to the same Cert group MAY be contained 113 in multiple sequential HIP control packets. This is indicated by a 114 higher Cert count than the amount of CERT parameters with matching 115 Cert group fields in a HIP control packet. The CERT parameters MUST 116 be placed in ascending order, within a HIP control packet, according 117 to their Cert group field. Cert groups MAY only span multiple 118 packets if the Cert group does not fit the packet. Only a single 119 Cert group MAY span two subsequent packets. 121 The Cert ID acts as a sequence number to identify the certificates in 122 a Cert group. The numbers in the Cert ID field MUST start from 1 up 123 to Cert count. 125 The Cert Group and Cert ID namespaces are managed locally by each 126 host that sends CERT parameters in HIP control packets. 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Type | Length | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Cert group | Cert count | Cert ID | Cert type | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Certificate / 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 / | Padding | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 Type 768 141 Length Length in octets, excluding Type, Length, and Padding 142 Cert group Group ID grouping multiple related CERT parameters 143 Cert count Total count of certificates that are sent, possibly 144 in several consecutive HIP control packets. 145 Cert ID The sequence number for this certificate 146 Cert Type Indicates the type of the certificate 147 Padding Any Padding, if necessary, to make the TLV a multiple 148 of 8 bytes. 150 The following certificate types are defined: 152 +--------------------------------+-------------+ 153 | Cert format | Type number | 154 +--------------------------------+-------------+ 155 | X.509.v3 | 1 | 156 | SPKI | 2 | 157 | Hash and URL of X.509.v3 | 3 | 158 | Hash and URL of SPKI | 4 | 159 | LDAP URL of X.509.v3 | 5 | 160 | LDAP URL of SPKI | 6 | 161 | Distinguished Name of X.509.v3 | 7 | 162 | Distinguished Name of SPKI | 8 | 163 +--------------------------------+-------------+ 165 The next sections outline the use of HITs in X.509.v3 and in SPKI 166 certificates. X.509.v3 certificates are defined in [RFC3280]. The 167 wire format for X.509.v3 is Distinguished Encoding Rules format as 168 defined in [X.690]. The SPKI and its formats are defined in 169 [RFC2693]. 171 Hash and URL encodings (3 and 4) are used as defined in [RFC4306] 172 Section 3.6. Using hash and URL encodings results in smaller HIP 173 control packets, but requires the receiver to resolve the URL or 174 check a local cache against the hash. 176 LDAP URL encodings (5 and 6) are used as defined in [RFC2255]. Using 177 LDAP URL encoding results in smaller HIP control packets but requires 178 the receiver to retrieve the certificate or check a local cache 179 against the URL. 181 Distinguished name (DN) encodings (7 and 8) are used as defined in 182 [RFC1779]. Using the DN encoding results in smaller HIP control 183 packets, but requires the receiver to retrieve the certificate or 184 check a local cache against the DN. 186 3. X.509.v3 Certificate Object and Host Identities 188 When using X.509.v3 certificates to transmit information related to 189 HIP hosts, HITs MAY be enclosed within the certificates. HITs can 190 represent an issuer, a subject, or both. In X.509.v3 HITs are 191 represented as issuer or subject alternative name extensions as 192 defined in [RFC2459]. If only HIT of the host is presented as either 193 the issuer or the subject the respective HIT MUST be placed into the 194 respective entity's DN's Common Name (CN) section in a colon 195 delimited presentation format defined in [RFC5952]. Inclusion of CN 196 is not necessary if DN contains any other naming information. It is 197 RECOMMENDED to use the FQDN/NAI from the hosts HOST_ID parameter in 198 the DN if one exists. The full HIs are presented in the public key 199 entries of X.509.v3 certificates. 201 The following examples illustrate how HITs are presented as issuer 202 and subject in the DN and in the X.509.v3 extension alternative 203 names. 205 Format of DN: 206 Issuer: CN=hit-of-issuer 207 Subject: CN=hit-of-issuer 209 Example DN: 210 Issuer: CN=2001:14:6cf:fae7:bb79:bf78:7d64:c056 211 Subject: CN=2001:1c:5a14:26de:a07c:385b:de35:60e3 213 Format of X509v3 extensions: 214 X509v3 Issuer Alternative Name: 215 IP Address:HIT-OF-ISSUER 216 X509v3 Subject Alternative Name: 217 IP Address:HIT-OF-SUBJECT 219 Example X509v3 extensions: 220 X509v3 Issuer Alternative Name: 221 IP Address:2001:14:6CF:FAE7:BB79:BF78:7D64:C056 222 X509v3 Subject Alternative Name: 223 IP Address:2001:1C:5A14:26DE:A07C:385B:DE35:60E3 225 Appendix B shows a full example X.509.v3 certificate with HIP 226 content. 228 As another example, consider a managed PKI environment in which the 229 peers have certificates that are anchored in (potentially different) 230 managed trust chains. In this scenario, the certificates issued to 231 HIP hosts are signed by intermediate Certificate Authorities (CAs) up 232 to a root CA. In this example, the managed PKI environment is 233 neither HIP aware, nor can it be configured to compute HITs and 234 include them in the certificates. 236 In this scenario, it is RECOMMENDED that the HIP peers have and use 237 some mechanism of defining trusted root CAs for the purpose of 238 establishing HIP communications. Furthermore it is recommended that 239 the HIP peers have and use some mechanism of checking peer 240 certificate validity for revocation, signature, minimum cryptographic 241 strength, etc., up to the trusted root CA. 243 When HIP communications are established, the HIP hosts not only need 244 to send their identity certificates (or pointers to their 245 certificates), but also the chain of intermediate CAs (or pointers to 246 the CAs) up to the root CA, or to a CA that is trusted by the remote 247 peer. This chain of certificates MUST be sent in a Cert group as 248 specified in Section 2. The HIP peers validate each other's 249 Certificates and compute peer HITs based on the Certificate public 250 keys. 252 4. SPKI Cert Object and Host Identities 254 When using SPKI certificates to transmit information related to HIP 255 hosts, HITs need to be enclosed within the certificates. HITs can 256 represent an issuer, a subject, or both. In the following we define 257 the representation of those identifiers for SPKI given as 258 S-expressions. Note that the S-expressions are only the human- 259 readable representation of SPKI certificates. Full HIs are presented 260 in the public key sequences of SPKI certificates. 262 As an example the Host Identity Tag of a host is expressed as 263 follows: 265 Format: (hash hit hit-of-host) 266 Example: (hash hit 2001:13:724d:f3c0:6ff0:33c2:15d8:5f50) 268 Appendix A shows a full example SPKI certificate with HIP content. 270 5. Revocation of Certificates 272 Revocation of X.509.v3 certificates is handled as defined in Section 273 5 in [RFC2459]. Revocation of SPKI certificates is handled as 274 defined in Section 5 in [RFC2693]. 276 6. Error signaling 278 If the Initiator does not send the certificate that the Responder 279 requires the Responder may take actions (e.g. reject the connection). 280 The Responder MAY signal this to the Initiator by sending a HIP 281 NOTIFY message with NOTIFICATION parameter error type 282 CREDENTIALS_NEEDED. 284 If the verification of a certificate fails, a verifier MAY signal 285 this to the provider of the certificate by sending a HIP NOTIFY 286 message with NOTIFICATION parameter error type INVALID_CERTIFICATE. 288 NOTIFICATION PARAMETER - ERROR TYPES Value 289 ------------------------------------ ----- 291 CREDENTIALS_REQUIRED 48 293 The Responder is unwilling to set up an association 294 as the Initiator did not send the needed credentials. 296 INVALID_CERTIFICATE 50 298 Sent in response to a failed verification of a certificate. 299 Notification Data MAY contain n groups of 2 octets (n calculated 300 from the NOTIFICATION parameter length), in order Cert group and 301 Cert ID of the certificate parameter that caused the failure. 303 7. IANA Considerations 305 This document defines the CERT parameter for the Host Identity 306 Protocol [RFC5201]. This parameter is defined in Section 2 with type 307 768. The parameter type number is also defined in [RFC5201]. 309 The CERT parameter has 8-bit unsigned integer field for different 310 certificate types, for which IANA is to create and maintain a new 311 sub-registry entitled "HIP certificate types" under the "Host 312 Identity Protocol (HIP) Parameters". Initial values for the 313 Certificate type registry are given in Section 2. 315 In Section 6 this document defines two new types for "NOTIFY message 316 types" sub-registry under "Host Identity Protocol (HIP) Parameters". 318 8. Security Considerations 320 Certificate grouping allows the certificates to be sent in multiple 321 consecutive packets. This might allow similar attacks as IP-layer 322 fragmentation allows, for example sending of fragments in wrong order 323 and skipping some fragments to delay or stall packet processing by 324 the victim in order to use resources (e.g. CPU or memory). 326 It is NOT RECOMMENDED to use grouping or hash and URL encodings when 327 HIP aware middleboxes are anticipated to be present on the 328 communication path between peers because fetching remote certificates 329 require the middlebox to buffer the packets and to request remote 330 data. This makes these devices prone to denial of service (DoS) 331 attacks. Moreover, middleboxes and responders that request remote 332 certificates can be used as deflectors for distributed denial of 333 service attacks. 335 9. Acknowledgements 337 The authors would like to thank A. Keranen, D. Mattes, M. Komu and T. 338 Henderson for the fruitful conversations on the subject. D. Mattes 339 most notably contributed the non-HIP aware use case in Section 3. 341 10. References 343 10.1. Normative References 345 [RFC1779] Kille, S., "A String Representation of Distinguished 346 Names", RFC 1779, March 1995. 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, 352 December 1997. 354 [RFC2459] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet 355 X.509 Public Key Infrastructure Certificate and CRL 356 Profile", RFC 2459, January 1999. 358 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 359 B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 360 September 1999. 362 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 363 X.509 Public Key Infrastructure Certificate and 364 Certificate Revocation List (CRL) Profile", RFC 3280, 365 April 2002. 367 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 368 RFC 4306, December 2005. 370 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 371 "Host Identity Protocol", RFC 5201, April 2008. 373 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 374 Address Text Representation", RFC 5952, August 2010. 376 10.2. Informative References 378 [X.690] ITU-T, "Recommendation X.690 Information Technology - 379 ASN.1 encoding rules: Specification of Basic Encoding 380 Rules (BER), Canonical Encoding Rules (CER) and 381 Distinguished Encoding Rules (DER)", July 2002, . 385 Appendix A. SPKI certificate example 387 This section shows a SPKI certificate with encoded HITs. The example 388 has been indented for readability. 390 (sequence 391 (public_key 392 (rsa-pkcs1-sha1 393 (e #010001#) 394 (n |uV7M1dl7OcJCPnlJrX8MvQ8SmE6wne5idnp7VfDMolestu 395 JqvB69z3UwlVuSr3VVaQvDSA+15BUweYkis/1+UVnSDdcS 396 XUTz6AUTH1tPifoebYPp4s+9XG/vAh7I25pImjW4uL6Jvq 397 vI3WBE36wBt3Zmq12hpdA8jSIE1CRZYA8=| 398 ) 399 ) 400 ) 401 (cert 402 (issuer 403 (hash hit 2001:001e:d709:1980:5c6a:bb0c:7650:a027) 404 ) 405 (subject 406 (hash hit 2001:001c:5a14:26de:a07c:385b:de35:60e3) 407 ) 408 (not-before "2010-06-22_16:40:47") 409 (not-after "2010-07-02_16:40:47") 410 ) 411 (signature 412 (hash sha1 |+UzjNn5+bXo3aMZQNGGtapKdlFAA|) 413 |Fhioyxi0mpHa2aq2ofhotsauYyDuCa45mMAQ+yTEGOzcc1K+Prx 414 +O6kFecKxl+Cwz9qXEI6a/zfAnZqLj18yvszM1D/tH+W3RKl2LW 415 +lASsCDKXOi9ObNx+Dwzj3YlHABPxt4gGk0XVadEMXfCPDqiLF+ 416 zMR9fW5/OaJ+vRwhKs=| 417 ) 418 ) 420 Appendix B. X.509.v3 certificate example 422 This section shows a X.509.v3 certificate with encoded HITs. 424 Certificate: 425 Data: 426 Version: 3 (0x2) 427 Serial Number: 0 (0x0) 428 Signature Algorithm: sha1WithRSAEncryption 429 Issuer: CN=2001:1e:d709:1980:5c6a:bb0c:7650:a027 430 Validity 431 Not Before: Jun 22 13:39:32 2010 GMT 432 Not After : Jul 2 13:39:32 2010 GMT 433 Subject: CN=2001:1c:5a14:26de:a07c:385b:de35:60e3 434 Subject Public Key Info: 435 Public Key Algorithm: rsaEncryption 436 RSA Public Key: (1024 bit) 437 Modulus (1024 bit): 438 00:b9:5e:cc:d5:d9:7b:39:c2:42:3e:79:49:ad:7f: 439 0c:bd:0f:12:98:4e:b0:9d:ee:62:76:7a:7b:55:f0: 440 cc:a2:57:ac:b6:e2:6a:bc:1e:bd:cf:75:30:95:5b: 441 92:af:75:55:69:0b:c3:48:0f:b5:e4:15:30:79:89: 442 22:b3:fd:7e:51:59:d2:0d:d7:12:5d:44:f3:e8:05: 443 13:1f:5b:4f:89:fa:1e:6d:83:e9:e2:cf:bd:5c:6f: 444 ef:02:1e:c8:db:9a:48:9a:35:b8:b8:be:89:be:ab: 445 c8:dd:60:44:df:ac:01:b7:76:66:ab:5d:a1:a5:d0: 446 3c:8d:22:04:d4:24:59:60:0f 447 Exponent: 65537 (0x10001) 448 X509v3 extensions: 449 X509v3 Issuer Alternative Name: 450 IP Address:2001:1E:D709:1980:5C6A:BB0C:7650:A027 451 X509v3 Subject Alternative Name: 452 IP Address:2001:1C:5A14:26DE:A07C:385B:DE35:60E3 453 Signature Algorithm: sha1WithRSAEncryption 454 48:a1:25:fb:01:31:d9:80:76:1b:1a:2d:00:f1:26:22:3c:3b: 455 20:a0:cb:b2:28:d2:0c:21:d3:9e:3b:4a:ab:3d:f6:ea:ad:46: 456 f6:f5:c4:4f:71:ce:3e:7b:65:8d:58:75:2e:99:25:82:5f:73: 457 10:c6:c2:f0:4b:35:ff:5c:65:ac:fc:a4:a7:76:50:ab:62:50: 458 b8:86:21:e6:83:e1:c1:3d:20:c9:8e:13:ab:d7:4b:d4:ab:2d: 459 72:9d:f0:9f:5f:e0:6f:95:fa:a1:95:64:3f:74:63:e5:a8:1d: 460 f7:e6:48:98:33:53:7b:91:6d:b0:cb:af:32:15:8c:e0:01:a0: 461 a0:b8 463 Appendix C. Change log 465 Changes from version 00 to 01: 467 o Revised text about DN usage. 469 o Revised text about Cert group usage. 471 Changes from version 01 to 02: 473 o Revised the type numbers. 475 o Added a section about signaling. 477 Changes from version 02 to 03: 479 o Revised text about CERT use in control packets. 481 Changes from version 03 to 04: 483 o Added the non-HIP aware use case to the Section 3. 485 o Clarified that the HITs are not always required in the 486 certificates. 488 o Rewrote the signaling section. 490 o LDAP URL to LDAP DN in Section 2 last paragraph. 492 o CERT is always covered by a signature as it's type number requires 494 o New example certificates 496 o Style and language clean-ups 498 o Changed IANA considerations 500 o Revised the type numbers 502 o RFC 2119 keywords 504 o Updated the IANA considerations section 506 o Rewrote the abstract 508 Changes from version 04 to 05: 510 o Clarified the examples in Section 3. 512 o Clarifications to Section Section 3. 514 o Modified the explanation of INVALID_CERTIFICATE to allow multiple 515 certs. 517 o Added reference to the IPv6 colon delimited presentation format. 519 o Small editorial changes. 521 Authors' Addresses 523 Tobias Heer 524 Distributed Systems Group, RWTH Aachen University 525 Ahornstrasse 55 526 Aachen 527 Germany 529 Phone: +49 241 80 214 36 530 Email: heer@cs.rwth-aachen.de 531 URI: http://ds.cs.rwth-aachen.de/members/heer 533 Samu Varjonen 534 Helsinki Institute for Information Technology 535 Gustaf Haellstroemin katu 2b 536 Helsinki 537 Finland 539 Email: samu.varjonen@hiit.fi 540 URI: http://www.hiit.fi