idnits 2.17.1 draft-ietf-hip-cert-08.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 18, 2011) is 4840 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: 3 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 22, 2011 Varjonen 6 Helsinki Institute for Information 7 Technology 8 January 18, 2011 10 Host Identity Protocol Certificates 11 draft-ietf-hip-cert-08 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 22, 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 [RFC5280]. 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 [RFC5996] 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 [RFC4516]. 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 [RFC4514]. 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 [RFC5280]. 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 [RFC5280]. 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, March 1997. 352 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 353 B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 354 September 1999. 356 [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol 357 (LDAP): String Representation of Distinguished Names", 358 RFC 4514, June 2006. 360 [RFC4516] Smith, M. and T. Howes, "Lightweight Directory Access 361 Protocol (LDAP): Uniform Resource Locator", RFC 4516, 362 June 2006. 364 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 365 "Host Identity Protocol", RFC 5201, April 2008. 367 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 368 Housley, R., and W. Polk, "Internet X.509 Public Key 369 Infrastructure Certificate and Certificate Revocation List 370 (CRL) Profile", RFC 5280, May 2008. 372 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 373 Address Text Representation", RFC 5952, August 2010. 375 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 376 "Internet Key Exchange Protocol Version 2 (IKEv2)", 377 RFC 5996, September 2010. 379 10.2. Informative References 381 [X.690] ITU-T, "Recommendation X.690 Information Technology - 382 ASN.1 encoding rules: Specification of Basic Encoding 383 Rules (BER), Canonical Encoding Rules (CER) and 384 Distinguished Encoding Rules (DER)", July 2002, . 388 Appendix A. SPKI certificate example 390 This section shows a SPKI certificate with encoded HITs. The example 391 has been indented for readability. 393 (sequence 394 (public_key 395 (rsa-pkcs1-sha1 396 (e #010001#) 397 (n |yDwznOwX0w+zvQbpWoTnfWrUPLKW2NFrpXbsIcH/QBSLb 398 k1RKTZhLasFwvtSHAjqh220W8gRiQAGIqKplyrDEqSrJp 399 OdIsHIQ8BQhJAyILWA1Sa6f5wAnWozDfgdXoKLNdT8ZNB 400 mzluPiw4ozc78p6MHElH75Hm3yHaWxT+s83M=| 401 ) 402 ) 403 ) 404 (cert 405 (issuer 406 (hash hit 2001:15:2453:698a:9aa:253a:dcb5:981e) 407 ) 408 (subject 409 (hash hit 2001:12:ccd6:4715:72a3:2ab1:77e4:4acc) 410 ) 411 (not-before "2011-01-12_13:43:09") 412 (not-after "2011-01-22_13:43:09") 413 ) 414 (signature 415 (hash sha1 |h5fC8HUMATTtK0cjYqIgeN3HCIMA|) 416 |u8NTRutINI/AeeZgN6bngjvjYPtVahvY7MhGfenTpT7MCgBy 417 NoZglqH5Cy2vH6LrQFYWx0MjWoYwHKimEuBKCNd4TK6hrCyAI 418 CIDJAZ70TyKXgONwDNWPOmcc3lFmsih8ezkoBseFWHqRGISIm 419 MLdeaMciP4lVfxPY2AQKdMrBc=| 420 ) 421 ) 423 Appendix B. X.509.v3 certificate example 425 This section shows a X.509.v3 certificate with encoded HITs. 427 Certificate: 428 Data: 429 Version: 3 (0x2) 430 Serial Number: 0 (0x0) 431 Signature Algorithm: sha1WithRSAEncryption 432 Issuer: CN=2001:1e:d709:1980:5c6a:bb0c:7650:a027 433 Validity 434 Not Before: Jun 22 13:39:32 2010 GMT 435 Not After : Jul 2 13:39:32 2010 GMT 436 Subject: CN=2001:1c:5a14:26de:a07c:385b:de35:60e3 437 Subject Public Key Info: 438 Public Key Algorithm: rsaEncryption 439 RSA Public Key: (1024 bit) 440 Modulus (1024 bit): 441 00:b9:5e:cc:d5:d9:7b:39:c2:42:3e:79:49:ad:7f: 442 0c:bd:0f:12:98:4e:b0:9d:ee:62:76:7a:7b:55:f0: 443 cc:a2:57:ac:b6:e2:6a:bc:1e:bd:cf:75:30:95:5b: 444 92:af:75:55:69:0b:c3:48:0f:b5:e4:15:30:79:89: 445 22:b3:fd:7e:51:59:d2:0d:d7:12:5d:44:f3:e8:05: 446 13:1f:5b:4f:89:fa:1e:6d:83:e9:e2:cf:bd:5c:6f: 447 ef:02:1e:c8:db:9a:48:9a:35:b8:b8:be:89:be:ab: 448 c8:dd:60:44:df:ac:01:b7:76:66:ab:5d:a1:a5:d0: 449 3c:8d:22:04:d4:24:59:60:0f 450 Exponent: 65537 (0x10001) 451 X509v3 extensions: 452 X509v3 Issuer Alternative Name: 453 IP Address:2001:1e:d709:1980:5c6a:bb0C:7650:a027 454 X509v3 Subject Alternative Name: 455 IP Address:2001:1c:5a14:26de:a07c:385b:de35:60e3 456 Signature Algorithm: sha1WithRSAEncryption 457 48:a1:25:fb:01:31:d9:80:76:1b:1a:2d:00:f1:26:22:3c:3b: 458 20:a0:cb:b2:28:d2:0c:21:d3:9e:3b:4a:ab:3d:f6:ea:ad:46: 459 f6:f5:c4:4f:71:ce:3e:7b:65:8d:58:75:2e:99:25:82:5f:73: 460 10:c6:c2:f0:4b:35:ff:5c:65:ac:fc:a4:a7:76:50:ab:62:50: 461 b8:86:21:e6:83:e1:c1:3d:20:c9:8e:13:ab:d7:4b:d4:ab:2d: 462 72:9d:f0:9f:5f:e0:6f:95:fa:a1:95:64:3f:74:63:e5:a8:1d: 463 f7:e6:48:98:33:53:7b:91:6d:b0:cb:af:32:15:8c:e0:01:a0: 464 a0:b8 466 Appendix C. Change log 468 Changes from version 00 to 01: 470 o Revised text on DN usage. 472 o Revised text on Cert group usage. 474 Changes from version 01 to 02: 476 o Revised the type numbers. 478 o Added a section on signaling. 480 Changes from version 02 to 03: 482 o Revised text on CERT usage in control packets. 484 Changes from version 03 to 04: 486 o Added the non-HIP aware use case to the Section 3. 488 o Clarified that the HITs are not always required in the 489 certificates. 491 o Rewrote the signaling section. 493 o LDAP URL to LDAP DN in Section 2 last paragraph. 495 o CERT is always covered by a signature as it's type number requires 497 o New example certificates 499 o Style and language clean-ups 501 o Changed IANA considerations 503 o Revised the type numbers 505 o RFC 2119 keywords 507 o Updated the IANA considerations section 509 o Rewrote the abstract 511 Changes from version 04 to 05: 513 o Clarified the examples in Section 3. 515 o Clarifications to Section Section 3. 517 o Modified the explanation of INVALID_CERTIFICATE to allow multiple 518 certs. 520 o Added reference to the IPv6 colon delimited presentation format. 522 o Small editorial changes. 524 Changes from version 05 to 06: 526 o Editorial changes. 528 o Unified the example in Section 3. 530 Changes from version 06 to 07: 532 o Editorial changes. 534 o Removed a the second paragraph in section 8. 536 o Changed the example in Appendix A (Cert created without the 537 leading zeroes in HITs). 539 Changes from version 07 to 08: 541 o Updated and checked the references. 543 Authors' Addresses 545 Tobias Heer 546 Distributed Systems Group, RWTH Aachen University 547 Ahornstrasse 55 548 Aachen 549 Germany 551 Phone: +49 241 80 214 36 552 Email: heer@cs.rwth-aachen.de 553 URI: http://ds.cs.rwth-aachen.de/members/heer 555 Samu Varjonen 556 Helsinki Institute for Information Technology 557 Gustaf Haellstroemin katu 2b 558 Helsinki 559 Finland 561 Email: samu.varjonen@hiit.fi 562 URI: http://www.hiit.fi