idnits 2.17.1 draft-ietf-hip-cert-09.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 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 18, 2011) is 4839 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 2 errors (**), 0 flaws (~~), 2 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 22, 2011 Varjonen 6 Helsinki Institute for Information 7 Technology 8 January 18, 2011 10 Host Identity Protocol Certificates 11 draft-ietf-hip-cert-09 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 in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 22, 2011. 47 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 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 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 1. Introduction 75 Digital certificates bind a piece of information to a public key by 76 means of a digital signature, and thus, enable the holder of a 77 private key to generate cryptographically verifiable statements. The 78 Host Identity Protocol (HIP) [RFC5201] defines a new cryptographic 79 namespace based on asymmetric cryptography. The identity of each 80 host is derived from a public key, allowing hosts to digitally sign 81 data and issue certificates with their private key. This document 82 specifies the CERT parameter, which is used to transmit digital 83 certificates in HIP. It fills the placeholder specified in Section 84 5.2 of [RFC5201]. 86 1.1. Requirements Language 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 2. CERT Parameter 94 The CERT parameter is a container for certain types of digital 95 certificates. It MAY either carry SPKI certificates or X.509.v3 96 certificates. It does not specify any certificate semantics. 97 However, it defines supplementary parameters that help HIP hosts to 98 transmit semantically grouped CERT parameters in a more systematic 99 way. The specific use of the CERT parameter for different use cases 100 is intentionally not discussed in this document because it is 101 specific to a concrete use case. Hence, the use of the CERT 102 parameter will be defined in the documents that use the CERT 103 parameter. 105 The CERT parameter is covered, when present, by the HIP SIGNATURE 106 field and is a non-critical parameter. 108 The CERT parameter can be used in all HIP packets. However, using it 109 in the I1 packet is not recommended because it can increase the 110 processing times of I1s, which can be problematic when processing 111 storms of I1s. Each HIP control packet MAY contain multiple CERT 112 parameters. These parameters MAY be related or unrelated. Related 113 certificates are managed in Cert groups. A Cert group specifies a 114 group of related CERT parameters that SHOULD be interpreted in a 115 certain order (e.g., for expressing certificate chains). For 116 grouping CERT parameters, the Cert group and the Cert count field 117 MUST be set. Ungrouped certificates exhibit a unique Cert group 118 field and set the Cert count to 1. CERT parameters with the same 119 Cert group number in the group field indicate a logical grouping. 120 The Cert count field indicates the number of CERT parameters in the 121 group. 123 CERT parameters that belong to the same Cert group MAY be contained 124 in multiple sequential HIP control packets. This is indicated by a 125 higher Cert count than the amount of CERT parameters with matching 126 Cert group fields in a HIP control packet. The CERT parameters MUST 127 be placed in ascending order, within a HIP control packet, according 128 to their Cert group field. Cert groups MAY only span multiple 129 packets if the Cert group does not fit the packet. A HIP packet MUST 130 NOT contain more than one incomplete Cert group that continues in the 131 next HIP control packet. 133 The Cert ID acts as a sequence number to identify the certificates in 134 a Cert group. The numbers in the Cert ID field MUST start from 1 up 135 to Cert count. 137 The Cert Group and Cert ID namespaces are managed locally by each 138 host that sends CERT parameters in HIP control packets. 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Type | Length | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Cert group | Cert count | Cert ID | Cert type | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Certificate / 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 / | Padding | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 Type 768 153 Length Length in octets, excluding Type, Length, and Padding 154 Cert group Group ID grouping multiple related CERT parameters 155 Cert count Total count of certificates that are sent, possibly 156 in several consecutive HIP control packets. 157 Cert ID The sequence number for this certificate 158 Cert Type Indicates the type of the certificate 159 Padding Any Padding, if necessary, to make the TLV a multiple 160 of 8 bytes. 162 The following certificate types are defined: 164 +--------------------------------+-------------+ 165 | Cert format | Type number | 166 +--------------------------------+-------------+ 167 | X.509.v3 | 1 | 168 | SPKI | 2 | 169 | Hash and URL of X.509.v3 | 3 | 170 | Hash and URL of SPKI | 4 | 171 | LDAP URL of X.509.v3 | 5 | 172 | LDAP URL of SPKI | 6 | 173 | Distinguished Name of X.509.v3 | 7 | 174 | Distinguished Name of SPKI | 8 | 175 +--------------------------------+-------------+ 177 The next sections outline the use of HITs in X.509.v3 and in SPKI 178 certificates. X.509.v3 certificates are defined in [RFC5280]. The 179 wire format for X.509.v3 is Distinguished Encoding Rules format as 180 defined in [X.690]. The SPKI and its formats are defined in 181 [RFC2693]. 183 Hash and URL encodings (3 and 4) are used as defined in [RFC5996] 184 Section 3.6. Using hash and URL encodings results in smaller HIP 185 control packets, but requires the receiver to resolve the URL or 186 check a local cache against the hash. 188 LDAP URL encodings (5 and 6) are used as defined in [RFC4516]. Using 189 LDAP URL encoding results in smaller HIP control packets but requires 190 the receiver to retrieve the certificate or check a local cache 191 against the URL. 193 Distinguished name (DN) encodings (7 and 8) are used as defined in 194 [RFC4514]. Using the DN encoding results in smaller HIP control 195 packets, but requires the receiver to retrieve the certificate or 196 check a local cache against the DN. 198 3. X.509.v3 Certificate Object and Host Identities 200 When using X.509.v3 certificates to transmit information related to 201 HIP hosts, HITs MAY be enclosed within the certificates. HITs can 202 represent an issuer, a subject, or both. In X.509.v3 HITs are 203 represented as issuer or subject alternative name extensions as 204 defined in [RFC5280]. If only the HIT of the host is presented as 205 either the issuer or the subject the respective HIT MUST be placed 206 into the respective entity's DN's Common Name (CN) section in a colon 207 delimited presentation format defined in [RFC5952]. Inclusion of CN 208 is not necessary if DN contains any other naming information. It is 209 RECOMMENDED to use the FQDN/NAI from the hosts HOST_ID parameter in 210 the DN if one exists. The full HIs are presented in the public key 211 entries of X.509.v3 certificates. 213 The following examples illustrate how HITs are presented as issuer 214 and subject in the DN and in the X.509.v3 extension alternative 215 names. 217 Format of DN: 218 Issuer: CN=hit-of-issuer 219 Subject: CN=hit-of-subject 221 Example DN: 222 Issuer: CN=2001:14:6cf:fae7:bb79:bf78:7d64:c056 223 Subject: CN=2001:1c:5a14:26de:a07c:385b:de35:60e3 225 Format of X509v3 extensions: 226 X509v3 Issuer Alternative Name: 227 IP Address:hit-of-issuer 228 X509v3 Subject Alternative Name: 229 IP Address:hit-of-subject 231 Example X509v3 extensions: 232 X509v3 Issuer Alternative Name: 233 IP Address:2001:14:6cf:fae7:bb79:bf78:7d64:c056 234 X509v3 Subject Alternative Name: 235 IP Address:2001:1C:5a14:26de:a07C:385b:de35:60e3 237 Appendix B shows a full example X.509.v3 certificate with HIP 238 content. 240 As another example, consider a managed PKI environment in which the 241 peers have certificates that are anchored in (potentially different) 242 managed trust chains. In this scenario, the certificates issued to 243 HIP hosts are signed by intermediate Certificate Authorities (CAs) up 244 to a root CA. In this example, the managed PKI environment is 245 neither HIP aware, nor can it be configured to compute HITs and 246 include them in the certificates. 248 In this scenario, it is RECOMMENDED that the HIP peers have and use 249 some mechanism of defining trusted root CAs for the purpose of 250 establishing HIP communications. Furthermore it is recommended that 251 the HIP peers have and use some mechanism of checking peer 252 certificate validity for revocation, signature, minimum cryptographic 253 strength, etc., up to the trusted root CA. 255 When HIP communications are established, the HIP hosts not only need 256 to send their identity certificates (or pointers to their 257 certificates), but also the chain of intermediate CAs (or pointers to 258 the CAs) up to the root CA, or to a CA that is trusted by the remote 259 peer. This chain of certificates MUST be sent in a Cert group as 260 specified in Section 2. The HIP peers validate each other's 261 certificates and compute peer HITs based on the certificate public 262 keys. 264 4. SPKI Cert Object and Host Identities 266 When using SPKI certificates to transmit information related to HIP 267 hosts, HITs need to be enclosed within the certificates. HITs can 268 represent an issuer, a subject, or both. In the following we define 269 the representation of those identifiers for SPKI given as 270 S-expressions. Note that the S-expressions are only the human- 271 readable representation of SPKI certificates. Full HIs are presented 272 in the public key sequences of SPKI certificates. 274 As an example the Host Identity Tag of a host is expressed as 275 follows: 277 Format: (hash hit hit-of-host) 278 Example: (hash hit 2001:13:724d:f3c0:6ff0:33c2:15d8:5f50) 280 Appendix A shows a full example SPKI certificate with HIP content. 282 5. Revocation of Certificates 284 Revocation of X.509.v3 certificates is handled as defined in Section 285 5 of [RFC5280]. Revocation of SPKI certificates is handled as 286 defined in Section 5 of [RFC2693]. 288 6. Error signaling 290 If the Initiator does not send the certificate that the Responder 291 requires the Responder may take actions (e.g. reject the connection). 292 The Responder MAY signal this to the Initiator by sending a HIP 293 NOTIFY message with NOTIFICATION parameter error type 294 CREDENTIALS_NEEDED. 296 If the verification of a certificate fails, a verifier MAY signal 297 this to the provider of the certificate by sending a HIP NOTIFY 298 message with NOTIFICATION parameter error type INVALID_CERTIFICATE. 300 NOTIFICATION PARAMETER - ERROR TYPES Value 301 ------------------------------------ ----- 303 CREDENTIALS_REQUIRED 48 305 The Responder is unwilling to set up an association 306 as the Initiator did not send the needed credentials. 308 INVALID_CERTIFICATE 50 310 Sent in response to a failed verification of a certificate. 311 Notification Data MAY contain n groups of 2 octets (n calculated 312 from the NOTIFICATION parameter length), in order Cert group and 313 Cert ID of the certificate parameter that caused the failure. 315 7. IANA Considerations 317 This document defines the CERT parameter for the Host Identity 318 Protocol [RFC5201]. This parameter is defined in Section 2 with type 319 768. The parameter type number is also defined in [RFC5201]. 321 The CERT parameter has 8-bit unsigned integer field for different 322 certificate types, for which IANA is to create and maintain a new 323 sub-registry entitled "HIP certificate types" under the "Host 324 Identity Protocol (HIP) Parameters". Initial values for the 325 Certificate type registry are given in Section 2. 327 In Section 6 this document defines two new types for "NOTIFY message 328 types" sub-registry under "Host Identity Protocol (HIP) Parameters". 330 8. Security Considerations 332 Certificate grouping allows the certificates to be sent in multiple 333 consecutive packets. This might allow similar attacks as IP-layer 334 fragmentation allows, for example sending of fragments in wrong order 335 and skipping some fragments to delay or stall packet processing by 336 the victim in order to use resources (e.g. CPU or memory). Hence, 337 hosts SHOULD implement mechanisms to discard certificate groups with 338 outstanding certificates if state space is scarce. 340 9. Acknowledgements 342 The authors would like to thank A. Keranen, D. Mattes, M. Komu and T. 343 Henderson for the fruitful conversations on the subject. D. Mattes 344 most notably contributed the non-HIP aware use case in Section 3. 346 10. References 348 10.1. Normative References 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, March 1997. 353 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 354 B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 355 September 1999. 357 [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol 358 (LDAP): String Representation of Distinguished Names", 359 RFC 4514, June 2006. 361 [RFC4516] Smith, M. and T. Howes, "Lightweight Directory Access 362 Protocol (LDAP): Uniform Resource Locator", RFC 4516, 363 June 2006. 365 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 366 "Host Identity Protocol", RFC 5201, April 2008. 368 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 369 Housley, R., and W. Polk, "Internet X.509 Public Key 370 Infrastructure Certificate and Certificate Revocation List 371 (CRL) Profile", RFC 5280, May 2008. 373 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 374 Address Text Representation", RFC 5952, August 2010. 376 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 377 "Internet Key Exchange Protocol Version 2 (IKEv2)", 378 RFC 5996, September 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 Changes from version 07 to 08: 542 o Updated and checked the references. 544 Changes from version 08 to 09: 546 o Fixing boilerplate. 548 Authors' Addresses 550 Tobias Heer 551 Distributed Systems Group, RWTH Aachen University 552 Ahornstrasse 55 553 Aachen 554 Germany 556 Phone: +49 241 80 214 36 557 Email: heer@cs.rwth-aachen.de 558 URI: http://ds.cs.rwth-aachen.de/members/heer 560 Samu Varjonen 561 Helsinki Institute for Information Technology 562 Gustaf Haellstroemin katu 2b 563 Helsinki 564 Finland 566 Email: samu.varjonen@hiit.fi 567 URI: http://www.hiit.fi