idnits 2.17.00 (12 Aug 2021) /tmp/idnits37458/draft-zhang-trans-ct-dnssec-02.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 too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 64 has weird spacing: '...ponents of Ce...' -- The document date (May 5, 2015) is 2573 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '32' on line 299 == Outdated reference: draft-ietf-trans-rfc6962-bis has been published as RFC 9162 ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) ** Obsolete normative reference: RFC 4305 (Obsoleted by RFC 4835) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Zhang 3 Internet-Draft 4 Intended status: Experimental D. Gillmor 5 Expires: November 6, 2015 CMRG 6 D. He 7 Huawei 8 B. Sarikaya 9 Huawei USA 10 May 5, 2015 12 Certificate Transparency for Domain Name System Security Extensions 13 draft-zhang-trans-ct-dnssec-02 15 Abstract 17 In draft-ietf-trans-rfc6962-bis, a solution is proposed for publicly 18 logging the existence of Transport Layer Security (TLS) certificates 19 using Merkle Hash Trees. This document tries to use this idea in 20 DNSSEC and publicly logging the DS RRs in order to notice the 21 issuance of suspect key signing keys. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on November 6, 2015. 46 Copyright Notice 48 Copyright (c) 2015 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 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Cryptographic Components of Certificate Transparency . . . . 4 65 3. Motivation Scenario . . . . . . . . . . . . . . . . . . . . . 4 66 4. Log Format and Operation . . . . . . . . . . . . . . . . . . 5 67 4.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.2. Structure of the Signed Certificate Timestamp . . . . . . 7 69 4.3. Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . 8 70 5. Including the Signed Certificate Timestamp into DNS Security 71 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 5.1. SCT RR . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 5.1.1. The Key Tag Field . . . . . . . . . . . . . . . . . . 10 74 5.1.2. The Algorithm Field . . . . . . . . . . . . . . . . . 10 75 5.1.3. The Digest Type Field . . . . . . . . . . . . . . . . 10 76 5.1.4. The Digest Field . . . . . . . . . . . . . . . . . . 10 77 5.1.5. The SCT Field . . . . . . . . . . . . . . . . . . . . 10 78 5.1.6. The Signature Field . . . . . . . . . . . . . . . . . 11 79 5.2. Operations . . . . . . . . . . . . . . . . . . . . . . . 11 80 6. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 11 81 6.1. Add DNSSEC RR Chain to Log . . . . . . . . . . . . . . . 11 82 6.2. Retrieve Accepted Root DNSKEY RRs . . . . . . . . . . . . 12 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 8.1. Logging other types of RRs . . . . . . . . . . . . . . . 12 86 8.2. Scalability Concerns . . . . . . . . . . . . . . . . . . 13 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 88 10. Normative References . . . . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 [I-D.ietf-trans-rfc6962-bis] specifies a Certificate Transparency 94 (CT) mechanism to disclosing TLS certificates into public logs so as 95 to benefit the public to monitor the operations in issuing 96 certificates to improper subscribers. The logs do not prevent mis- 97 issuing behavior directly, but the provided public audibility can 98 increase the possibility in detecting the improper behaviors of 99 issuers. The logs are constructed with Merkle Hash Trees to ensure 100 the append-only property, and thus enable anyone to verify the 101 correctness of each log. Note that CT is a common mechanism although 102 [I-D.ietf-trans-rfc6962-bis] only specify how to use it to publish 103 TLS server certificates issued by public certificate authorities 104 (CAs). 106 This document discusses the application of CT in addressing the 107 improper issuance issues in DNSSEC. DNSSEC establishes chains of 108 public keys for clients to assess the validity of DNS resource 109 records. In order to prove the validity of keys used for signing DNS 110 data, DNSSEC uses DNS public key (DNSKEY) RRsets and Delegation 111 Signer (DS) RRsets to form authentication chains for the signed data, 112 with each link in the chains vouching for the next by signing the 113 next. If an authentication chain can be eventually connected to the 114 a trusted DNS key or DS RR, the client can then ensure the key for 115 signing the data is legitimate. Unlike PKIX, SDNSEC inherently has 116 strong naming constraints. The owner of a zone can only be allowed 117 to sign the RRs in his zone. Any attempt in signing the RRs in other 118 zones will be easily detected by clients. However, the owner of a 119 zone is dependent on its parent delegation via the DS record to vouch 120 for its DNSKEY. The zone itself is responsible for publishing DS 121 records for the child zones that dependant on it. Misbehavior or 122 compromise of the parent zone directly affects the core DNS security 123 of the child zone. A detailed example is provided in Section 3. 125 In order to benefit the detection of improper issuance/delegation of 126 DNSSEC keys, this document describes an extension to CT to support 127 logging DSs . The CT logs are publicly auditable, making it possible 128 for anyone to verify the correctness of the log entries and monitor 129 the new DS RR's appended to the log. The logs do not prevent the 130 parent from issuing DS records that the child disagrees with, but 131 they ensure that interested parties can detect such operations. For 132 instance, For example, a zone owner that has been compromised or 133 compelled by a third party can hijack a child zone to return 134 different DNS data that is indistinguishable from DNSSEC validated 135 data from the child zone by using its own DNSKEY to sign DNS data on 136 behalf of the child zone. It could deliver this modified DNS data to 137 only selected regions or individuals, making this attack very 138 difficult to detect by the legitimate child zone. 140 In DNSSEC, it is assumed that the keys used for signing RRs or other 141 keys will be properly maintained. This work follows this assumption 142 and the compromise of key signing keys are out of scope of this work. 143 This work assumes the existence of inside attacker. That is, a legal 144 owner of a zone may try to attack or circumvent other zones. 145 However, because the naming constraint feature of DNSSEC, a zone 146 owner in principle can only use its keys to perform attacks on its 147 child zones. 149 This work reuses most of the messages and data structures specified 150 in [I-D.ietf-trans-rfc6962-bis] and makes necessary extensions for 151 supporting DS RRs. Only the extensions to 152 [I-D.ietf-trans-rfc6962-bis] are presented in this document. 154 2. Cryptographic Components of Certificate Transparency 156 The introduce of cryptographic components of CT is in Section 2 of 157 [I-D.ietf-trans-rfc6962-bis]. When applying CT for NDSSEC, a log is 158 a single, ever-growing, append-only Merkle Tree of DS RRs. 160 3. Motivation Scenario 162 Assume a zone (foo.bar.example) and its parent zone (bar.example) are 163 owned by different organizations. Follows are the steps of an 164 example attack that the owner of the parent zone could perform on the 165 child zone. 167 1. Set up a fake foo.bar.example DNS server 169 2. It generates a new key signing key X1 and zone signing key X2. 170 It uses the KSK to sign the ZSK. It uses the ZSK to sign its 171 resource records. 173 3. It generates a DS record for the KSK record it generated in step 174 2. 176 4. The owner of bar.example sign the DS RR with its zone signing key 177 and publishes it 179 5. Change the IP address of the DNS server of foo.bar.example in the 180 associated RRs to the IP address of the fake DNS server 182 The owner of foo.bar.example may try to periodically access the DNS 183 server of bar.example and monitor the RRs on it . However, there is 184 still a time window between two assessments which can be taken 185 advantage of by the owner of bar.example to perform a hijacking 186 attack and remove the bogus RRs before the owner of foo.bar.example 187 detects the attack. 189 In some cases, the parent can even achieve its objectives without 190 publishing the DS RR, which makes the attacks more difficult to 191 detect. 193 If the owner of bar.example is forced to publish his operations on 194 the public CT logs, any improper behaviors will be detected 195 eventually. Through checking the log, it is easy detect the improper 196 issuance of RRs of his parent zone. 198 4. Log Format and Operation 200 As illustrated in Section 3, a zone owner may need to publish 201 multiple RRs in order to hijack the queries to its child zone and re- 202 direct them to another illegal DNS server. However, it is not 203 necessary to publish all those associated RRs to the log. In fact, 204 by publishing the DS RR which is critical in constructing the 205 authentication chain across two zones will be sufficient for helping 206 the public to detect the improper issuance behavior. In this 207 solution, when a zone owner generates a DS RR and delegates a new 208 public key to a child zone, it MUST publish the DS RR at least one CT 209 log in order to allow the public to monitor its behavior. Identical 210 to what is specified in [I-D.ietf-trans-rfc6962-bis], each CT log 211 needs to return a SCT to the zone owner immediately. The SCT will be 212 encapsulated in a SCT RR and published within a DS RR. 214 The SCT is the log's promise to incorporate the RR in the Merkle Tree 215 within a fixed amount of time known as the Maximum Merge Delay (MMD). 216 If the log has previously seen the certificate, it MAY return the 217 same SCT as it returned before. DNS servers MUST provide an SCT 218 within a SCT RR. DNSSEC clients will not honor a DS RR that does not 219 have a valid SCT. Therefore it is expected that a zone owner will 220 usually deliver the DS RRs for audit purposes. 222 4.1. Log Entries 224 A zone owner can submit a DS RR to any preferred logs before 225 publishing the RR. In order to enable attribution of each logged RR 226 to its issuer, the log SHALL publish a list of acceptable public keys 227 (or hashes of public keys) of root zone or islands of security. Each 228 submitted DS RR MUST be accompanied by all additional RRs (DNSKEY 229 RRs, DS RRs, and RRSIG RRs) which construct an authentication chain 230 to an accepted root public key. 232 Logs MUST verify that the authentication chain and make sure it leads 233 back to a trusted public key, using the chain of intermediate DNSKEY 234 RRs and DS RRs provided by the submitter. Logs MUST refuse to 235 publish a DS RR without a valid chain to a trusted key. If a DS RR 236 is accepted and an SCT issued, the accepting log MUST store the 237 entire chain used for verification, including the DS RR itself and 238 including the trusted key used to verify the chain, and MUST present 239 this chain for auditing upon request. 241 To comply with the certificate entries specified in 242 [I-D.ietf-trans-rfc6962-bis],Each DS RR entry in a log MUST include 243 the following components: 245 enum { x509_entry(0), precert_entry(1), DSRR_entry(TBD1),(65535) } LogEntryType; 247 struct { 248 LogEntryType entry_type; 249 select (entry_type) { 250 case x509_entry: X509ChainEntry; 251 case precert_entry: PrecertChainEntry; 252 case DSRR_entry:DSRR_Chain_Entry 253 } entry; 254 } LogEntry; 256 opaque DNSSECRR<1..2^24-1>; 258 struct { 259 DNSSECRR DSRR; 260 DNSSECRR DNSSEC_key_chain<0..2^24-1> 261 } DSRR_Chain_Entry; 263 "entry_type" is the type of this entry. the type value of a DSRR 264 LogEntry is TBD. 266 "DSRR" is the DS RR submitted for auditing. 268 "DNSSEC_key_chain" is a chain of additional DNSSEC RRs required to 269 verify the DS RR.A typical authentication chain is as follow: Trusted 270 DNSSKEY ->[DS->(DNSKEY)*->DNSKEY]*-> Submitted DS RR, where "*" 271 denotes zero or more sub-chains. (DNSKEY)* indicates that DNSSEC 272 permits additional layers of DNSKEY RRs including the keys for 273 signing other keys within a zone. Each DNSKEY/DS RR in the chain is 274 authenticated by a RRSIG RR. In practice, a RRSIG RR is normally 275 used to sign a DS/DNSKEY RRset. Therefore, not only the DS/DNSKEY RR 276 on the authentication chain but also other records in the RRset 277 SHOULD be provided to the log the verification purpose. Otherwise, 278 the log may have to consult DNS again in order to verify the 279 authentication chains. Logs SHOULD limit the length of chain they 280 will accept. 282 4.2. Structure of the Signed Certificate Timestamp 284 This work reuses the structure of Signed Certificate Timestamp 285 specified in Section 3.3 of [I-D.ietf-trans-rfc6962-bis] but make 286 necessary extensions. 288 enum { certificate_timestamp(0), tree_hash(1),DSRR_timestamp(TBD2), (255) } 289 SignatureType; 291 enum { v1(0), (255) } 292 Version; 294 struct { 295 opaque key_id[32]; 296 } LogID; 298 struct { 299 opaque issuer_key_hash[32]; 300 C14N_DSRR dsrr; 301 } DSRR; 303 opaque CtExtensions<0..2^16-1>; 305 "key_id" and "issuer_key_hash" are defined in Section 3.3 of 306 [I-D.ietf-trans-rfc6962-bis]. 308 dsrr is the submitted DS RR in a canonical form. The 309 canconicalization of a DS RR is described in Section 6.2 of 310 [RFC4304]. 312 struct { 313 Version sct_version; 314 LogID id; 315 uint64 timestamp; 316 CtExtensions extensions; 317 digitally-signed struct { 318 Version sct_version; 319 SignatureType signature_type = DSRR_timestamp; 320 uint64 timestamp; 321 LogEntryType entry_type; 322 select(entry_type) { 323 case x509_entry: ASN.1Cert; 324 case precert_entry: PreCert; 325 case BIN_entry: BinaryDigest; 326 case BINDI_entry: BinaryDigest 327 } signed_entry; 328 CtExtensions extensions; 329 }; 330 } SignedCertificateTimestamp; 332 The encoding of the digitally-signed element is defined in [RFC5246]. 334 "sct_version", "timestamp", "entry_type and extensions" are are 335 identical to what is defined in Section 3.3 of 336 [I-D.ietf-trans-rfc6962-bis].. 338 "signed_entry" is the is DSRR (in the case of a DSRR_entry), as 339 described above. 341 "extensions" are future extensions to this protocol version (v1). 342 Currently, no extensions are specified. 344 4.3. Merkle Tree 346 This specification extends teh structure of the Merkle Tree input in 347 Section 3.5 of [I-D.ietf-trans-rfc6962-bis] and enable it to 348 encapsulate DS RR: 350 enum { v1(0), v2(1), (255) } 351 LeafVersion; 353 struct { 354 uint64 timestamp; 355 LogEntryType entry_type; 356 select(entry_type) { 357 case x509_entry: ASN.1Cert; 358 case precert_entry: PreCert; 359 case DSRR_entry: DSRR; 360 } signed_entry; 361 CtExtensions extensions; 362 } TimestampedEntry; 364 struct { 365 LeafVersion version; 366 TimestampedEntry timestamped_entry; 367 } MerkleTreeLeaf; 369 The fields in the input are introduced in Section 3.5 of 370 [I-D.ietf-trans-rfc6962-bis]. 372 Open question[dacheng]: We should include the RRs constucting the 373 authenticaiton chain in the input, right? 375 5. Including the Signed Certificate Timestamp into DNS Security 376 Extensions 378 In section 3.5 of [I-D.ietf-trans-rfc6962-bis] 380 5.1. SCT RR 382 The SCT associated with a DS RR is stored within a STC RR. A DNS 383 server MAY provide multiple SCT RRs for one DS RR. 385 The type number for the SCT record is TBD3. 387 The SCT resource record is class independent. 389 The life period of SCT RR should not be set in a way that the RR will 390 not be expired before the associated DS RR. 392 The RDATA portion of an SCT RR is as shown below. 394 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Key Tag | Algorithm | Digest Type | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 / / 400 / Digest / 401 / / 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 / / 404 / STC / 405 / / 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 / / 408 / Signature / 409 / / 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 5.1.1. The Key Tag Field 414 The Key Tag field lists the key tag of the DNSKEY RR referred to by 415 the SCT record, in network byte order. Appendix B of [RFC4034] 416 describes how to compute a Key Tag. 418 5.1.2. The Algorithm Field 420 The Algorithm field lists the algorithm number of the DNSKEY RR 421 referred to by the SCT record. Appendix A.1 of [RFC4034] lists the 422 algorithm number types. 424 5.1.3. The Digest Type Field 426 The Digest Type field identifies the algorithm used to construct the 427 digest used to identify the DS RR that the SCT RR refers to. 428 Appendix A.2 of [RFC4034] lists the possible digest algorithm types. 430 5.1.4. The Digest Field 432 The method of calculating digest is identical to what is specified in 433 Section 5.1.4 of [RFC2065].[RFC4034] 435 5.1.5. The SCT Field 437 This field contains the SCT got from the log, encoded in BASE64. 439 5.1.6. The Signature Field 441 This field contains the SCT signature associated with the SCT. The 442 Signature field is represented as a Base64 encoding of the signature. 444 5.2. Operations 446 After introducing the SCT RR, the verification procedures of DNS data 447 specified in DNSSEC[RFC4305] do not change a lot. However, the 448 correctness of CTS needs to be assessed during checking the validity 449 of a DS RR. 451 A DS RR needs to be associated with a CTS RR which contains a valid 452 CTS and signed with a proper public key. Otherwise, the DS RR will 453 not be used to construct the authentication chain. The signatures of 454 DS RR and its CTS RR should be stored in different RRSIG RR 455 respectively. In addition, a DNS server will sends CTS RRs and the 456 associated RRSIG RRs to a resolver only when it indicates the support 457 of CT in the request. 459 6. Log Client Messages 461 In Section 4 of [I-D.ietf-trans-rfc6962-bis], a set of messages is 462 defined for clients to query and verfiy the correctness of the log 463 entries they are interested in. In this memo, two new messages are 464 defined for CT to support DNSSEC. 466 6.1. Add DNSSEC RR Chain to Log 468 POST https:///ct/v1/add-RR-chain 470 Inputs: 472 chain: An array of base64-encoded DNS RR. The first element is 473 the submited DS RR; the second chains to the first and so on to 474 the last, which is a trurst DNSKey RR. 476 Outputs: 478 sct_version: The version of the SignedCertificateTimestamp 479 structure, in decimal. A compliant v1 implementation MUST NOT 480 expect this to be 0 (i.e., v1). 482 id: The log ID, base64 encoded. 484 timestamp: The SCT timestamp, in decimal. 486 extensions: An opaque type for future expansion. It is likely 487 that not all participants will need to understand data in this 488 field. Logs should set this to the empty string. Clients 489 should decode the base64-encoded data and include it in the 490 SCT. 492 signature: The SCT signature, base64 encoded. 494 6.2. Retrieve Accepted Root DNSKEY RRs 496 GET https:///ct/v1/get-root-RRs 498 No inputs. 500 Outputs: 502 RRs: An array of base64-encoded DNSKEY RRs that are acceptable to 503 the log. 505 7. IANA Considerations 507 8. Security Considerations 509 8.1. Logging other types of RRs 511 This solution only tries to describes a solution to disclose keys for 512 DNSSEC in logs for the public to audit. However, it may be valuable 513 to also log the RRs specified in [RFC1035]. For instance, assume 514 there is an attacker which has compromised the zone authentication 515 key and is able to perform the MITM attack between a resolver and the 516 DNS server of the zone. It is possible for an attacker to transfer a 517 forged RR which is signed with the compromised key. The current 518 solution cannot benefit the detection of this attack in this 519 scenario. However, if the RR is also required to be uploaded to 520 public logs, the condition is changed. If the attacker does not 521 publish the RR to a log, it cannot get the SCT. When the attacker 522 tries to publish the RR to the log, the owner of the zone may detect 523 the problem even if the attacker can provide keys to convince the log 524 to accept the RR. 526 8.2. Scalability Concerns 528 The log MAY limit accepting entries where the TTL is too short or the 529 RRSIG times are too far in the future or the past, to avoid spamming 530 the log. It should probably also put a maximum on the number of 531 child zones to avoid getting spammed. 533 9. Acknowledgements 535 10. Normative References 537 [I-D.ietf-trans-rfc6962-bis] 538 Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. 539 Stradling, "Certificate Transparency", draft-ietf-trans- 540 rfc6962-bis-07 (work in progress), March 2015. 542 [RFC1035] Mockapetris, P., "Domain names - implementation and 543 specification", STD 13, RFC 1035, November 1987. 545 [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security 546 Extensions", RFC 2065, January 1997. 548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels", BCP 14, RFC 2119, March 1997. 551 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 552 Rose, "Resource Records for the DNS Security Extensions", 553 RFC 4034, March 2005. 555 [RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to 556 IPsec Domain of Interpretation (DOI) for Internet Security 557 Association and Key Management Protocol (ISAKMP)", RFC 558 4304, December 2005. 560 [RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation 561 Requirements for Encapsulating Security Payload (ESP) and 562 Authentication Header (AH)", RFC 4305, December 2005. 564 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 565 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 567 Authors' Addresses 569 Dacheng Zhang 571 Email: dacheng.zhang@gmail.com 572 Daniel Kahn Gillmor 573 CMRG 575 Email: dkg@fifthhorseman.net 577 Danping He 578 Huawei 580 Email: ana.hedanping@huawei.com 582 Behcet Sarikaya 583 Huawei USA 584 5340 Legacy Dr. Building 3 585 Plano, TX 75024 587 Email: sarikaya@ieee.org