idnits 2.17.1 draft-liao-smimeheaderprotect-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (June 30, 2009) is 5413 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3850 (Obsoleted by RFC 5750) ** Obsolete normative reference: RFC 3851 (Obsoleted by RFC 5751) ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4871 (Obsoleted by RFC 6376) Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Lijun Liao, Joerg Schwenk 3 Internet-Draft HGI, Ruhr-University Bochum 4 Intended status: Standards Track June 30, 2009 5 Expires: December 31, 2009 7 Header Protection for S/MIME 8 draft-liao-smimeheaderprotect-05 10 Status of This Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 31, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 In the current S/MIME Version 3.1 specification, the header 47 protection is achieved by encoding the whole message as a 48 message/rfc822 MIME media. Since this approach poses some practical 49 problems, we propose to use signed attributes to implement a fully 50 backward compatible S/MIME header protection scheme. 52 Table of Contents 54 1. Introduction ............................................. 2 55 1.1. Terminology .......................................... 3 56 1.2. Syntactic Notation ................................... 3 57 1.3 Object Identifiers ................................... 3 58 1.4. Security Goals of Header Protection .................. 3 59 1.5. Header Protection in S/MIME Version 3.1 .............. 4 60 1.6. Prototype Implementation ............................. 4 61 2. S/MIME Header Protection Entity .......................... 4 62 2.1. Fieldname List ....................................... 5 63 2.2. Canonicalization of Headers .......................... 6 64 3. CMS Fields ............................................... 6 65 3.1. CanonAlgorithmIdentifier ............................. 6 66 3.2. SMIME Header Protection .............................. 7 67 4. Creating Signed S/MIME Messages with Header Protection ... 8 68 4.1. Preparing an SMIME-Header-Protection Attribute ....... 8 69 5. Verifying Signed S/MIME Message with Header Protection ... 8 70 5.1. Verifying an SMIME-Header-Protection Attribute ....... 9 71 6. Security Considerations .................................. 9 72 7. References ............................................... 9 73 7.1 Normative References .................................. 9 74 7.2 Informative References ................................ 10 75 A. ASN.1 Module ............................................. 10 76 B. Examples ................................................. 11 77 B.1. SMIME-Header-Protection Attribute with "simple" 78 and "SHA256" ........................................... 11 79 B.2. SMIME-Header-Protection Attribute with "relaxed" 80 and "SHA1" ............................................. 12 81 C. Authors' Addresses ....................................... 13 83 1. Introduction 85 Mail message header fields as defined in [RFC5322] contain security 86 critical information that is not protected cryptographically. The 87 only exception is the address portion of the header fields From or 88 Sender. Receiving agents MUST check that the message originator of 89 a mail message matches an Internet mail address, if present, in the 90 signer's certificate. Since there are no standards that cover this 91 issue in S/MIME, each MUA behaves differently. For example, message 92 originator is retrieved always from the "From" field in Outlook 93 Express. Outlook does not check it at all. While in Thunderbird, 94 message originator is retrieved from the "Sender" field if it 95 exists; otherwise from the "From" field. A receiving agent SHOULD 96 provide some explicit alternate processing of the message if the 97 message originator does not match the signer's address, which may be 98 to display a message that shows the recipient the addresses in the 99 certificate or other certificate details [RFC3850]. Other header 100 fields like "To", "Date", "Reply-To" and "Subject" remain totally 101 unprotected. 103 In the solution described in this specification, a digest value is 104 computed over the canonicalized version of some selected header 105 fields. This technique resembles header protection in [RFC4871]. 106 Then the digest value is included in a signed attribute field of a 107 CMS signature. 109 This solution allows conforming clients to check if the 110 selected header fields have been altered by simply re-computing the 111 digest value. Non-conforming legacy clients will simply ignore that 112 the signed attribute contains a digest value, and will only check the 113 digest value computed over the message body according to S/MIME. 115 1.1. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 1.2. Syntactic Notation 123 The following tokens are imported from other RFCs as noted. Those 124 RFCs should be considered definitive. 126 The following tokens are imported from [RFC5322]: 128 o "field-name" (name of a header field) 130 Other tokens not defined herein are imported from [RFC4234]. These 131 are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, 132 etc. 134 1.3. Object Identifiers 136 The object identifiers defined in this specification is only for the 137 experiment. When this memo moves to standards track within the IETF, 138 it is intended that the IANA will maintain this registry. 140 1.4. Security Goals of Header Protection 142 The main security goal of mail message header protection is not to 143 protect the whole RFC 822 header against manipulation, but to make 144 it possible for the receiving client to detect whether the protected 145 header fields have been changed. 147 1.5. Header Protection in S/MIME Version 3.1 149 S/MIME Version 3.1 [RFC3851] addresses the header protection by 150 including all header fields as generated by the sending mail client, 151 together with the body of the message, in a message/rfc822 MIME 152 media, which can then be protected by S/MIME. It is up to the 153 receiving client to decide how to present this message to the user. 155 This approach has, however, some limitations: If some of the message 156 headers are changed during transport (e.g. when sent to a mailing 157 list), this will either invalidate the whole message, or not be 158 detected at all, depending on the receiving mail client's behavior. 160 This approach has the following disadvantages: 162 o All inner header fields must also appear in the outer header 163 (i.e., those headers must be presented doubly) so that the mail 164 message is conform to [RFC5322] and the mail server and relay 165 systems know how to send the mail message. 167 o Only the inner header fields are protected, but not the outer 168 header fields. As stated in [RFC3851], it is up to the receiving 169 client to decide how to present the inner header along with the 170 unprotected outer header. Usually the following header fields, 171 if present, are shown in most clients: "From", "Sender", "To", 172 "Cc", "Date", and "Subject". If the same header field is present 173 in both inner and outer header, only the one in the inner header 174 is presented. If a header field is only presented in the outer 175 header, it will be also shown. Most mail messages do not contain 176 the headers "Sender" and "Cc", hence one can add these header 177 fields in the outer header to confuse the receivers. 179 o It complicates the receiver to show the mail message. It is 180 difficult to determine whether the message within the 181 message/rfc822 wrapper is the top-level message or the complete 182 message/rfc822 MIME entity is another encapsulated mail message. 184 1.6. Prototype Implementation 186 A prototype implementation of this memo is available in [FeLi08]. When 187 this memo moves to standards track within the IETF, this section will 188 be removed. 190 2. S/MIME Header Protection Entity 192 A S/MIME header protection entity contains names of header fields to 193 be protected, the canonicalization algorithm, the digest algorithm 194 and the corresponding digest value. 196 2.1. Fieldname List 198 The fieldname-list is a colon-separated list of header field names 199 that identify the header fields presented to the digest algorithm; it 200 is defined as follows: 202 fieldname-list = lowercase-field-name *(":" lowercase-field-name) 203 lowercase-field-name = field-name in lowercase 205 The fieldname-list contains the complete list of header fields input to 206 the hash algorithm. The order of the names in the list does not 207 matter. The header fields specified by the list are presented to the 208 hash algorithm in order of their appearance in the header block, from 209 the top to the bottom. The field name is lowercase. The field may 210 contain names of header fields that do not exist when digested. This 211 is useful to prevent adding of undesired header fields. The 212 fieldname-list is compared against the actual header field names in a 213 case insensitive manner. 215 INFORMATIVE EXAMPLE: 217 Given a mail message as follows: 218 Received: A 219 Message-ID: B 220 Date: C 221 From: D 222 To: E 223 Cc: F 224 Subject: G 225 Comments: H 227 Body 229 If the signer wishes to sign the header fields "From", "To", "Cc" 230 and "Subject", then the fieldname-list may be: 232 from:to:cc:subject 234 and the following header fields will be digested in the order: 236 From: D 237 To: E 238 Cc: F 239 Subject: G 241 If the signer wishes to protect additional header fields "Date", 242 "Comments" and "Message-ID" then the fieldname-list may be: 244 from:to:cc:subject:date:comments:message-id 246 and the following header fields will be digested in the order: 248 Message-ID: B 249 Date: C 250 From: D 251 To: E 252 Cc: F 253 Subject: G 254 Comments: H 256 Signers MUST NOT digest header fields that might have 257 additional instances added later in the delivery process, since such 258 header fields will change the input of the digest algorithm. 260 To prevent modifying header fields as far as possible, headers fields 261 which are added before the signature creation and will not be 262 modified after that SHOULD be included in the fieldname-list. Thus, a 263 reasonable fieldname-list SHOULD contain at least the following 264 content: 265 date:from:sender:reply-to:to:cc:message-id:in-reply-to:references: 266 subject:comments:keywords. 268 2.2. Canonicalization of Headers 270 Mail message, specially the mail message header, may be modified by 271 some mail servers and relay systems. Some signers may demand that any 272 modification of the mail message header result in a signature 273 failure, while some other signers may accept modification of the 274 header within the bounds of mail message standards such as [RFC5322]. 276 To satisfy all requirements, two canonicalization algorithms are 277 defined for each of the header: a "simple" algorithm 278 stated in Section 3.4.1 of [RFC4871] that tolerates almost no 279 modification and a "relaxed" algorithm stated in Section 3.4.2 of 280 [RFC4871] that tolerates common modifications such as white-space 281 replacement and header field line re-wrapping. 283 3. CMS Fields 285 3.1. CanonAlgorithmIdentifier 287 The CanonAlgorithmIdentifier type identifies a canonicalization 288 algorithm. Examples include "simple" header canonicalization, and 289 "relaxed" header canonicalization. 291 CanonAlgorithmIdentifier ::= AlgorithmIdentifier 293 AlgorithmIdentifier is defined in [RFC5280] as follows: 295 AlgorithmIdentifier ::= SEQUENCE { 296 algorithm OBJECT IDENTIFIER, 297 parameters ANY DEFINED BY algorithm OPTIONAL } 299 The algorithm identifier is used to identify a canonicalization 300 algorithm. 302 The "simple" canonicalization algorithm is identified by the 303 following object: 305 id-alg-simpleHeaderCanon OBJECT IDENTIFIER ::= {iso(1) 306 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 307 smime(16) alg(3) 101} 309 The "relaxed" canonicalization algorithm is identified by the 310 following object: 312 id-alg-relaxedHeaderCanon OBJECT IDENTIFIER ::= {iso(1) 313 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 314 smime(16) alg(3) 102} 316 For the canonicalization algorithms "simple" and "relaxed" the 317 parameters field is NULL. 319 3.2. SMIME Header Protection 321 The smime-header-protection attribute type specifies the S/MIME 322 header protection entity. It MUST be a signed attribute or an 323 authenticated attribute; it MUST NOT be an unsigned attribute, 324 unauthenticated attribute, or unprotected attribute in CMS signature. 326 The following object identifier identifies the 327 smime-header-protection attribute: 329 id-smimeHeaderProtection OBJECT IDENTIFIER :: = {iso(1) 330 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 331 smime(16) aa(2) 101} 333 The attrValues of the smime-header-protection attribute contains 334 only one value that has ASN.1 type SMIMEHeaderProtectionEntity: 336 SMIMEHeaderProtectionEntity ::= SEQUENCE { 337 canonAlgorithm CanonAlgorithmIdentifier, 338 digestAlgorithm DigestAlgorithmIdentifier, 339 headerfieldNames PrintableString, 340 digest Digest 341 } 342 The canonAlgorithm field specifies the canonicalization algorithm. 343 The digestAlgorithm field specifies the digest algorithm. The format 344 of an headerfieldNames is a "headername-list" field specified in 345 Section 2.1, which specifies the list of 346 header field names. The digest field carries the the digest value. 348 4. Creating Signed S/MIME Messages with Header Protection 350 The signed S/MIME messages with header protection are created in the 351 same way as in [RFC3851] except the followings: 353 o Before computing the digest value over the signedAttrs field, the 354 smime-header-protection attribute MUST be prepared (see Section 355 4.1) and added to the signedAttrs field. 357 o All header fields that are protected MUST be prepared before the 358 preparing the smime-header-protection. 360 4.1. Preparing an SMIME-Header-Protection Attribute 362 An smime-header-protection attribute is prepared as follows: 364 Step 1. Choose the canonicalization algorithm, the digest algorithm, 365 and the list of names of message header fields to be digested. The 366 digest algorithm SHOULD be the same as the digest algorithm in the 367 SignerInfo to which the smime-header-protection attribute should be 368 added. 370 Step 2. Retrieve the message header fields from the message according 371 to the protected header fields from Step 1. 373 Step 3. Canonicalize the retrieved header fields from Step 2 374 according to the canonicalization algorithm. 376 Step 4. Compute the digest value over the canonicalization result in 377 Step 3 according to the digest algorithm. 379 Step 5. Create an smime-header-protection attribute. Store the chosen 380 canonicalization algorithm, the digest algorithm, and the list of 381 names from Step 1 in the fields canonAlgorithm, digestAlgorithm, 382 and headerfieldNames, respectively. Store the digest value from Step 383 4 in the the field digest. 385 5. Verifying Signed S/MIME Message with Header Protection 387 The signed S/MIME message with header protection are first verified in 388 the same way as in [RFC3851], then the smime-header-protection 389 attribute is verified as stated in Section 5.1. 391 5.1. Verifying an SMIME-Header-Protection Attribute 393 An smime-header-protection attribute is verified as follows: 395 Step 1. Retrieve the canonicalization algorithm, the digest 396 algorithm, and the list of names of message header fields, and the 397 digest value from the smime-header-protection attribute. 399 Step 2. Retrieve the message header fields from the message according 400 to the list of protected header fields from Step 1. 402 Step 3. Canonicalize the retrieved header fields from Step 2 403 according to the canonicalization algorithm. 405 Step 4. Compute the digest value over the canonicalization result in 406 Step 3 according to the digest algorithm. 408 Step 5. Compares the computed digest value from Step 4 and the stored 409 one from Step 1. If both digest values are different, then the 410 verification fails; otherwise the verification successes. 412 6. Security Considerations 414 All security considerations from [RFC3851] and [RFC3852] apply to 415 applications that use procedures described in this document. 417 7. References 419 7.1 Normative References 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, March 1997. 424 [RFC3850] Ramsdell, B. (Editor), "Secure/Multipurpose Internet Mail 425 Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 426 3850, July 2004. 428 [RFC3851] Ramsdell, B. (Editor), " Secure/Multipurpose Internet Mail 429 Extensions (S/MIME) Version 3.1 Message Specification", 430 RFC 3851, July 2004. 432 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS), RFC 433 3852, July 2004. 435 [RFC4234] Crocker, D. (Editor), Overell, P., "Augmented BNF for 436 Syntax Specifications: ABNF", RFC 4234, October 2005 438 [RFC4871] Allman, E. et. al., "DomainKeys Identified Mail (DKIM) 439 Signatures", RFC 4871, May 2007 441 [RFC5280] Cooper, D., Santesson S., Farrell S., Boeyen S., Housley 442 R., Polk W., "Internet X.509 Public Key Infrastructure, 443 Certificate and Certificate Revocation List (CRL) 444 Profile", RFC 5280, April 2002. 446 [RFC5322] Resnick, P. (Editor), "Internet Message Format", RFC 5322, 447 October 2008.7.2 Informative References 449 7.2 Informative References 451 [FeLi08] Feldmann, F., Liao, L., Prototype Implementation of Header 452 Protection for S/MIME (this draft). URL: 453 http://nds.hgi.rub.de/liao/works/headerprotect/index.html 455 A. ASN.1 Module 457 SMIMEHeaderProtectionService 458 { iso(1) member-body(2) us(840) rsadsi(113549) 459 pkcs(1) pkcs-9(9) smime(16) modules(0) shps(101) } 461 DEFINITIONS IMPLICIT TAGS ::= 462 BEGIN 464 IMPORTS 465 -- Imports from RFC 5280 466 AlgorithmIdentifier 467 FROM PKIX1Explicit88 468 { iso(1) identified-organization(3) dod(6) 469 internet(1) security(5) mechanisms(5) pkix(7) 470 mod(0) pkix1-explicit(18) } 472 -- Imports from RFC 3852 473 DigestAlgorithmIdentifier, Digest 474 FROM CryptographicMessageSyntax2004 475 { iso(1) member-body(2) us(840) rsadsi(113549) 476 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24)} 478 CanonAlgorithmIdentifier ::= AlgorithmIdentifier 480 id-alg-simpleHeaderCanon OBJECT IDENTIFIER ::= {iso(1) 481 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 482 smime(16) alg(3) 101} 484 id-alg-relaxedHeaderCanon OBJECT IDENTIFIER ::= {iso(1) 485 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 486 smime(16) alg(3) 102} 488 id-smimeHeaderProtection OBJECT IDENTIFIER :: = {iso(1) 489 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 490 smime(16) aa(2) 101} 492 SMIMEHeaderProtectionEntity ::= SEQUENCE { 493 canonAlgorithm CanonAlgorithmIdentifier, 494 digestAlgorithm DigestAlgorithmIdentifier, 495 headerfieldNames PrintableString, 496 -- The format of a headerfieldNames 497 -- is a "fieldname-list" field 498 -- specified in Section 2.1. 499 digest Digest 500 } 502 END 504 B. Examples 506 B.1. SMIME-Header-Protection Attribute with "simple" and "SHA256" 508 This section contains an annotated hex dump of a 178 byte 509 smime-header-protection attribute which is contained in the 510 signedAttrs of a signature. The attribute contains the following 511 information: 513 (a) the canocalization algorithm is "simple" header canonicalization; 514 (b) the digest algorithm is "SHA256"; 515 (c) the list of header field names is 516 "date:from:sender:reply-to:to:cc:message-id:in-reply-to: 517 references:subject:comments:keywords"; 518 (d) the digest value (32 hex). 520 0 30 178: SEQUENCE { 521 2 06 11: OBJECT IDENTIFIER 522 : smime-header-protection {1 2 840 113549 1 9 16 2 523 : 101} 524 15 31 163: SET { 525 17 30 161: SEQUENCE { 526 19 30 15: SEQUENCE { 527 21 06 11: OBJECT IDENTIFIER 528 : simple { 1 2 840 113549 1 9 16 3 101 } 529 34 05 0: NULL 530 : } 531 36 30 13: SEQUENCE { 532 38 06 9: OBJECT IDENTIFIER 533 : SHA256 { 2 16 840 1 101 3 4 2 1 } 534 49 05 0: NULL 535 : } 537 51 16 93: PrintableString "date:from:sender:reply-to:to:cc: 538 message-id:in-reply-to:references: 539 subject:comments:keywords" 541 146 04 32: OCTET STRING 542 : BA F1 D4 FD 95 EB 8B FA 55 F6 31 52 E7 86 50 53 AB 543 : 6B 79 C7 93 F1 87 89 A1 11 66 A8 10 83 42 24 544 : } 545 : } 546 : } 548 B.2. SMIME-Header-Protection Attribute with "relaxed" and "SHA1" 550 This section contains an annotated hex dump of a 163 byte 551 smime-header-protection attribute which is contained in the 552 signedAttrs of a signature. The attribute contains the following 553 information: 555 (a) the canocalization algorithm is "relaxed" header 556 canonicalization; 557 (b) the digest algorithm is "SHA1"; 558 (c) the list of header field names is 559 "date:from:sender:reply-to:to:cc:message-id:in-reply-to: 560 references:subject:comments:keywords"; 561 (d) the digest value (20 hex) 563 0 30 163: SEQUENCE { 564 2 06 11: OBJECT IDENTIFIER 565 : smime-header-protection {1 2 840 113549 1 9 16 2 566 : 101} 567 15 31 147: SET { 568 17 30 145: SEQUENCE { 569 19 30 15: SEQUENCE { 570 21 06 11: OBJECT IDENTIFIER 571 : relaxed { 1 2 840 113549 1 9 16 3 102 } 572 34 05 0: NULL 573 : } 574 36 30 9: SEQUENCE { 575 38 06 5: OBJECT IDENTIFIER 576 : SHA1 { 1 3 14 3 2 26 } 577 45 05 0: NULL 578 : } 579 47 16 93: PrintableString "date:from:sender:reply-to:to:cc: 580 message-id:in-reply-to:references: 581 subject:comments:keywords" 583 142 04 20: OCTET STRING 584 : 61 8D A3 CA 54 E2 F7 71 38 CD 76 A2 AA 2A 3D ED 585 79 EC 3A 86 586 : 587 : } 588 : } 589 : } 591 C. Authors' Addresses 593 Lijun Liao 594 Chair for Network and Data Security 595 Ruhr-University Bochum 596 44780 Bochum 597 Germany 598 Mail message: lijun.liao@nds.rub.de 600 Joerg Schwenk 601 Chair for Network and Data Security 602 Ruhr-University Bochum 603 44780 Bochum 604 Germany 605 Mail message: joerg.schwenk@nds.rub.de