idnits 2.17.1 draft-housley-evidence-extns-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 898. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 875), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Either party may initiate the closure of an evidence-creating interval and the exchange of evidence messages by sending the evidence_end1 alert. Upon sending evidence_end1, the sender MUST not send any more application data on this connection until the Evidence Protocol messages are exchanged. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '2' on line 223 == Missing Reference: 'TLSAUTHZ' is mentioned on line 530, but not defined == Missing Reference: 'RANDOM' is mentioned on line 707, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' ** Obsolete normative reference: RFC 2313 (ref. 'PKCS1') (Obsoleted by RFC 2437) ** Obsolete normative reference: RFC 3280 (ref. 'PKIX1') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4366 (ref. 'TLSEXT') (Obsoleted by RFC 5246, RFC 6066) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' -- Obsolete informational reference (is this intentional?): RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft M. Brown 3 November 2006 RedPhone Security 4 Expires: May 2007 R. Housley 5 Vigil Security 7 Transport Layer Security (TLS) Evidence Extensions 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). All Rights Reserved. 37 Abstract 39 This document specifies evidence creation extensions to the Transport 40 Layer Security (TLS) Protocol. Extension types are carried in the 41 client and server hello message extensions to confirm that both 42 parties support the protocol features needed to perform evidence 43 creation. The syntax and semantics of the evidence creation alerts 44 and messages are described in detail. 46 1. Introduction 48 Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1] is being 49 used in an increasing variety of operational environments, including 50 ones that were not envisioned when the original design criteria for 51 TLS were determined. The extensions specified in this document 52 support evidence creation in environments where the peers in the TLS 53 session cooperate to create persistent evidence of the TLS-protected 54 application data. Such evidence may be necessary to meet business 55 requirements, including regulatory requirements. Also, evidence may 56 be used in tandem with authorization information to make high 57 assurance access control and routing decisions in military and 58 government environments. Evidence created using this extension may 59 also be used to audit various aspects of the TLS handshake, including 60 the cipher suite negotiation and the use of other TLS extensions. In 61 many cases, the evidence does not need to be validated by third 62 parties; however, in other cases, the evidence might be validated by 63 third parties. To accommodate all of these situations, the evidence 64 is generated using a digital signature. Since validation of a 65 digital signature requires only public information, evidence 66 generated with this mechanism is suitable for sharing with third 67 parties. 69 When digital certificates are to be employed in evidence creations, 70 the client must obtain the public key certificate (PKC) for the 71 server, and the server must obtain the PKC for the client. This is 72 most easily accomplished by using the PKCs provided in the Handshake 73 Protocol Certificate messages. Further, both parties SHOULD have an 74 opportunity to validate the PKC that will be used by the other party 75 before evidence creation. Again, this is naturally accomplished 76 using the Handshake Protocol, where the TLS session can be rejected 77 if the PKC cannot be validated. 79 This document describes evidence creation TLS extensions supporting 80 both TLS 1.0 and TLS 1.1. These extensions observe the conventions 81 defined for TLS Extensions [TLSEXT]. The extensions are designed to 82 be backwards compatible, meaning that the protocol alerts and 83 messages associated with the evidence creation extensions will be 84 exchanged only if the client indicates support for them in the client 85 hello message and the server indicates support for them in the server 86 hello message. 88 Clients typically know the context of the TLS session before it is 89 established. As a result, the client can request the use of the 90 evidence creation extensions in sessions where they might be needed. 91 Servers accept extended client hello messages, even if the server 92 does not support the all of the listed extensions. However, the 93 server will not indicate support for any extensions that are not 94 "understood" by the implementation. At the end of the hello message 95 exchange, the client may reject communications with servers that do 96 not support the evidence creation extensions, or the client may 97 accept the situation and proceed, whichever is appropriate. 99 1.1. Conventions 101 The syntax for the evidence creation messages is defined using the 102 TLS Presentation Language, which is specified in Section 4 of 103 [TLS1.0]. 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [STDWORDS]. 109 1.2. Overview 111 Figure 1 illustrates the placement of the evidence creation alerts 112 and messages in the TLS session. The first pair of evidence creation 113 alerts indicates the beginning of the protected content that will be 114 covered by the evidence. The first pair of alerts can appear any 115 place after the TLS Handshake Protocol Finished messages, which 116 ensures that they are integrity protected. The second pair of 117 evidence creation alerts indicates the ending of the protected 118 content that will be covered by the evidence. Immediately after the 119 reception of the final alert, a pair of Evidence Protocol messages is 120 exchanged to create the persistent evidence. 122 Generating evidence is not compatible with Diffie-Hellman Ephemeral 123 (DHE) key exchanges. DHE does not permit the same keying material to 124 be generated for validation of the evidence after the TLS session is 125 over. Persistent evidence requires the use of a digital signature so 126 that it can be validated well after the TLS session is over. 128 The ClientHello message includes an indication that the evidence 129 creation messages are supported. The ServerHello message also 130 includes an indication that the evidence creation messages are 131 supported. Both the client and the server MUST indicate support for 132 the evidence protocol alerts and messages; otherwise they MUST NOT be 133 employed by either the client or the server. 135 Client Server 137 ClientHello --------> 138 ServerHello 139 Certificate+ 140 ServerKeyExchange* 141 CertificateRequest+ 142 <-------- ServerHelloDone 143 Certificate+ 144 ClientKeyExchange 145 CertificateVerify+ 146 ChangeCipherSpec 147 Finished --------> 148 ChangeCipherSpec 149 <-------- Finished 150 Application Data <-------> Application Data 151 Alert(evidence_start1) --------> 152 Application Data 153 <-------- Alert(evidence_start2) 155 Application Data <-------> Application Data 156 Alert(evidence_end1) --------> 157 Application Data 158 <-------- Alert(evidence_end2) 159 EvidenceRequest --------> 160 <-------- EvidenceResponse 161 Application Data <-------> Application Data 163 * Indicates optional or situation-dependent messages that 164 are not always sent. 165 + Indicates messages optional to the TLS handshake that 166 MUST be sent when using TLS evidence. 168 Figure 1. Example TLS Session with Evidence Creation. 170 2. Evidence Extension Types 172 The general extension mechanisms enable clients and servers to 173 negotiate whether to use specific extensions, and how to use specific 174 extensions. As specified in [TLSEXT], the extension format used in 175 the extended client hello message and extended server hello message 176 within the TLS Handshake Protocol is: 178 struct { 179 ExtensionType extension_type; 180 opaque extension_data<0..2^16-1>; 181 } Extension; 183 The extension_type identifies a particular extension type, and the 184 extension_data contains information specific to the particular 185 extension type. 187 As specified in [TLSEXT], for all extension types, the extension type 188 MUST NOT appear in the extended server hello message unless the same 189 extension type appeared in the preceding client hello message. 190 Clients MUST abort the handshake if they receive an extension type in 191 the extended server hello message that they did not request in the 192 preceding extended client hello message. 194 When multiple extensions of different types are present in the 195 extended client hello message or the extended server hello message, 196 the extensions can appear in any order, but there MUST NOT be more 197 than one extension of the same type. 199 This document specifies the use of the evidence_creation extension 200 type. This specification adds one new type to ExtensionType: 202 enum { 203 evidence_creation(TBD), (65535) 204 } ExtensionType; 206 The evidence_creation extension is relevant when a session is 207 initiated and also for any subsequent session resumption. However, a 208 client that requests resumption of a session does not know whether 209 the server has maintained all of the context necessary to accept this 210 request, and therefore the client SHOULD send an extended client 211 hello message that includes the evidence_creation extension type. 212 This indicates that the client requests the server's continued 213 cooperation in creating evidence. If the server denies the 214 resumption request, then the evidence_creation extension will be 215 negotiated normally using the full Handshake protocol. 217 Clients MUST include the evidence_creation extension in the extended 218 client hello message to indicate their desire to send and receive 219 evidence creation alerts and messages. The extension_data field 220 indicates the evidence creation algorithms that are supported. The 221 format is indicated with the EvidenceCreateList type: 223 uint16 EvidenceCreateSuite[2]; 225 struct { 226 EvidenceCreateSuite evidence_suites<2..2^16-1>; 227 } EvidenceCreateList; 229 The EvidenceCreateList enumerates the evidence creation algorithms 230 that are supported by the client. The client MUST order the entries 231 from most preferred to least preferred, but all of the entries MUST 232 be acceptable to the client. Values are defined in Appendix A, and 233 others can be registered in the future. 235 Servers that receive an extended client hello message containing the 236 evidence_creation extension MUST respond with the evidence_creation 237 extension in the extended server hello message if the server is 238 willing to send and receive evidence creation alerts and messages. 239 The evidence_creation extension MUST be omitted from the extended 240 server hello message if the server is unwilling to send and receive 241 using one of the evidence creation algorithm suites identified by the 242 client. The extension_data field indicates the evidence creation 243 algorithm suite that the server selected from the list provided by 244 the client. The format is indicated with the EvidenceCreateSuite 245 type defined above. 247 3. Alert Messages 249 This document specifies the use of four new alert message 250 descriptions: the evidence_start1, evidence_start2, evidence_end1, 251 and evidence_end2. These descriptions are specified in Sections 3.1, 252 3.2, 3.3, and 3.4, respectively. The alert descriptions are 253 presented below in the order they MUST be sent; sending alerts in an 254 unexpected order results in a fatal error. These descriptions are 255 always used with the warning alert level. This specification adds 256 four new types to AlertDescription: 258 enum { 259 evidence_start1(TBD), 260 evidence_start2(TBD), 261 evidence_end1(TBD), 262 evidence_end2(TBD), 263 evidence_failure(TBD), 264 (255) 265 } AlertDescription; 267 3.1. The evidence_start1 Description 269 The client and the server need to synchronize evidence creation. 270 Either party may indicate the desire to start creating evidence by 271 sending the evidence_start1 alert. If the other party is ready to 272 begin creating evidence, then the other party MUST send an 273 evidence_start2 alert in response to the evidence_start1 alert that 274 was sent. If the other party is unwilling to begin creating 275 evidence, the other party MUST respond with fatal 276 evidence_failure(TBD) alert and terminate the TLS session. 278 Evidence may be collected more than once during a TLS session; 279 however, evidence gathering MUST NOT be nested. That is, a party 280 sending the a second evidence_start1 alert before evidence_end2 alert 281 has occurred and the evidence protocol has completed is a protocol 282 violation. Reception of an evidence_start1 alert that would result 283 in evidence nesting MUST be responded to with a fatal 284 evidence_failure(TBD) alert and terminating the TLS session. 286 Digital signatures are used in evidence creation. If an 287 evidence_start1 alert is received before the other party has provided 288 a valid PKC, then the evidence_start1 alert recipient MUST terminate 289 the TLS session using a fatal certificate_unknown alert. 291 3.2. The evidence_start2 Description 293 The evidence_start2 alert is sent in response to the evidence_start1 294 alert. By sending the evidence_start2 alert, the sending party 295 indicates that they are also ready to begin creating evidence. After 296 this pair of alerts is exchanged, both the client and the server use 297 the hash function indicated in the extended server hello message to 298 start computing the evidence. Each party computes two independent 299 hash values: one for each octet that is written, and one for each 300 octet that is read. 302 Digital signatures are used in evidence creation. If an 303 evidence_start2 alert is received before the other party has provided 304 a valid PKC, then the evidence_start2 alert recipient MUST terminate 305 the TLS session using a fatal certificate_unknown alert. 307 3.3. The evidence_end1 Description 309 Either party may initiate the closure of an evidence-creating 310 interval and the exchange of evidence messages by sending the 311 evidence_end1 alert. Upon sending evidence_end1, the sender MUST not 312 send any more application data on this connection until the Evidence 313 Protocol messages are exchanged. 315 The evidence_end1 alert sender MAY initiate the Evidence Protocol as 316 described in Section 4 at any time following this alert. The 317 evidence_end1 alert sender SHOULD ensure that it has received all 318 pending application data writes from the other party before 319 initiating the Evidence Protocol. One way to ensure that all of the 320 application data has been received it to wait for the receipt of an 321 evidence_end2 alert. If the Evidence Protocol begins before all of 322 the application data is available, the result will be a fatal 323 evidence_failure(TBD) alert when signature verification fails. 325 3.4. The evidence_end2 Description 327 The evidence_end2 alert is sent in response to the evidence_end1 328 alert. The evidence_end1 alert receiver SHOULD complete any pending 329 writes. The intent is to include any application data that would be 330 sent in response to application data that was received before the 331 evidence_end1 alert as part of evidence creation. Once the pending 332 writes are complete, the evidence_end1 alert receiver sends the 333 evidence_end2 alert. 335 At this point, each party completes the hash value computations. 337 The evidence_end2 alert receiver MUST respond by initiating the 338 Evidence Protocol as described in Section 4, if it has not already 339 done so. 341 3.5. The evidence_failure Description 343 The evidence_failure fatal alert is sent to indicate a failure in 344 evidence creation. During evidence synchronization, this alert 345 indicates that the sending party is unwilling to begin evidence 346 creation. During the Evidence Protocol, this alert indicates that 347 the evidence provided by the other party is not acceptable or cannot 348 be validated. 350 4. Evidence Protocol 352 This document specifies an additional TLS Protocol: the Evidence 353 Protocol. It is used to create persistent evidence of the TLS 354 session content. This specification adds one new Record layer 355 ContentType: 357 enum { 358 evidence(TBD), 359 (255) 360 } ContentType; 362 Persistence evidence of the TLS session content is produced by the 363 TLS Evidence Protocol. Evidence messages are supplied to the TLS 364 Record Layer, where they are encapsulated within one or more 365 TLSPlaintext structures, which are processed and transmitted as 366 specified by the current active session state. 368 The Evidence Protocol structure follows: 370 enum { 371 request(1), response(2), (255) 372 } EvidenceMsgType; 374 struct { 375 EvidenceMsgType evidence_msg_type; 376 uint24 length; /* number of octets in message */ 377 select (EvidenceMsgType) { 378 case request: EvidenceRequest; 379 case response: EvidenceResponse; 380 } body; 381 } EvidenceProtocol; 383 The Evidence Protocol messages are presented below in the order they 384 MUST be sent; sending evidence messages in an unexpected order 385 results in a fatal unexpected_message(10) alert. The EvidenceRequest 386 message and the EvidenceResponse message are specified in Section 4.2 387 and Section 4.3, respectively. Section 4.1 describes structures that 388 are used in the EvidenceRequest and EvidenceResponse messages. 390 4.1. Certificates and Digital Signatures 392 The evidence Protocol makes use of the ASN.1Cert definition used 393 elsewhere in TLS. It is repeated here for convenience. 395 opaque ASN.1Cert<1..2^24-1>; 397 The EvidenceSignature definition is very similar to the Signature 398 definition used elsewhere in TLS. The EvidenceSignature definition 399 signs hash[hash_size], but the Signature definition used elsewhere in 400 TLS signs a combination of an md5_hash and a sha_hash. Also, the 401 EvidenceSignature definition excludes the anonymous case. 403 enum { rsa, dsa, ecdsa } EvidenceSignatureAlgorithm; 405 select (EvidenceSignatureAlgorithm) 406 { case rsa: 407 digitally-signed struct { 408 opaque hash[hash_size]; 409 }; 410 case dsa: 411 digitally-signed struct { 412 opaque hash[hash_size]; 413 }; 414 case ecdsa: 415 digitally-signed struct { 416 opaque hash[hash_size]; 417 }; 418 } EvidenceSignature; 420 The hash algorithm and the hash_size depend on evidence create 421 algorithm suite selected by the server in the evidence_creation 422 extension. 424 4.2. EvidenceRequest Message 426 The EvidenceRequest message contains the evidence_end1 alert sender's 427 contribution to the persistent evidence. It employs the evidence 428 create algorithm suite selected by the server in the 429 evidence_creation extension in the extended server hello message. 431 struct { 432 Evidence evidence<1..2^16-1>; 433 ASN.1Cert party1_certificate; 434 EvidenceSignature party1_signature; 435 } EvidenceRequest; 436 struct { 437 EvidenceCreateSuite evidence_suite; 438 uint64 gmt_unix_time; 439 uint64 app_data_sent_offset; 440 uint64 app_data_received_offset; 441 opaque handshake_protocol_hash<1..512>; 442 opaque app_data_sent_hash<1..512>; 443 opaque app_data_received_hash<1..512>; 444 } Evidence; 446 The elements of the EvidenceRequest structure are described below: 448 evidence 449 Contains an evidence create algorithm identifier, a timestamp, 450 and three hash values in the Evidence structure as described 451 below. 453 party1_certificate 454 Contains the X.509 certificate of the signer. While this 455 certificate was probably exchanged and validated in the 456 Handshake Protocol, inclusion here makes it clear which 457 certificate was employed by the signer when the evidence is 458 validated in the future, possibly by a third party. 460 party1_signature 461 Contains the digital signature computed by the sender of the 462 evidence_end1 alert using the evidence creation algorithm suite 463 identified in evidence_create_suite. The hash value is 464 computed as: 466 Hash(evidence) 468 The elements of the Evidence structure are described below: 470 evidence_suite 471 Indicates the evidence creation algorithm suite selected by the 472 server in the evidence_creation extension in the Handshake 473 Protocol. This value determines the structure of the hash 474 values and digital signatures. 476 gmt_unix_time 477 Indicates the current date and time according to the local 478 system clock used by the sender of the evidence_end1 alert. 479 This time value is intended to represent the moment in time 480 that evidence_end1 was sent. Unlike other places in the TLS 481 protocol, a 64-bit value is used to ensure that time values do 482 not wrap in 2038. 484 app_data_sent_offset 485 Indicates the number of octets that were sent as part of this 486 TLS session before evidence collection began. 488 app_data_received_offset 489 Indicates the number of octets that were received as part of 490 this TLS session before evidence collection began. 492 handshake_protocol_hash 493 Compute as: 495 Hash(handshake_messages), 497 where handshake_messages refers to all Handshake Protocol 498 messages sent or received, beginning with the most recent 499 client hello message. If the double handshake mechanism 500 described in the security considerations of [TLSAUTHZ] is used 501 to encrypt the Handshake Protocol, the plaintext form of these 502 messages is used in calculating this hash value. 504 Verification of the handshake_protocol_hash is performed using 505 the plaintext form of the Handshake protocol messages. For 506 this hash value to be validated at a later time, this 507 information must be saved as part of the overall evidence. Any 508 attempt to save this data must ensure that it is not 509 inappropriately disclosed by employing suitable physical 510 protection or cryptographic mechanisms that are at least as 511 strong as the selected TLS ciphersuite. Suitable controls are 512 discussed further in the Security Considerations; see Section 513 6. 515 In the case of successful TLS session resumption, the most 516 recent client hello message will contain a valid 517 ClientHello.session_id value as well as extensions, and these 518 extensions may include sensitive data. The TLS Authorization 519 Extension [AUTHZ] is one example where an extension might 520 contain sensitive information. Thus, even when session 521 resumption is employed, the content of the Handshake protocol 522 messages ought to be protected. 524 TLS users should ensure that the content of the Handshake 525 protocol messages contain sufficient evidence to determine the 526 intent of the signers, where "signers" are defined as the 527 subject identities in the exchanged X.509 certificates. 528 Clients and servers MAY record the protocol messages containing 529 an expression of the intent of the signers using a suitable TLS 530 extension [TLSEXT], such as [TLSAUTHZ]. For example, a client 531 may request access to a resource provided by the server, 532 provide sufficient authentication and authorization information 533 grounds to convince the server to grant the requested access, 534 and receive an affirmative response from the server. A record 535 of TLS Handshake protocol messages representing this example 536 may provide a sufficient record of the intent of both the 537 client and the server. 539 app_data_sent_hash 540 Compute as: 542 Hash(sent_application_data), 544 where sent_application_data refers to all of the Application 545 Data messages sent since the most recent evidence_start1 or 546 evidence start2 alert was sent, and ending with the sending of 547 the evidence_end1 alert. The alerts are not application data, 548 and they are not included in the hash computation. 550 app_data_received_hash 551 Compute as: 553 Hash(received_application_data), 555 where received_application_data refers to all of the 556 Application Data messages received since the most recent 557 evidence_start1 or evidence start2 alert was received, and 558 ending with the receipt of the evidence_end2 alert. The alerts 559 are not application data, and they are not included in the hash 560 computation. 562 4.3. EvidenceResponse Message 564 The EvidenceResponse message contains the complete persistent 565 evidence. The value is saved by one or both parties as evidence of 566 the TLS session content identified by the evidence_start1, 567 evidence_start2, evidence_end1, and evidence_end2 alerts. 569 struct { 570 Evidence evidence<1..2^16-1>; 571 ASN.1Cert party1_certificate; 572 EvidenceSignature party1_signature; 573 ASN.1Cert party2_certificate; 574 EvidenceSignature party2_signature; 575 } EvidenceResponse; 577 The elements of the EvidenceResponse structure are described below: 579 evidence 580 Contains an evidence create algorithm identifier, a timestamp, 581 and three hash values in the Evidence structure as described in 582 section 4.2. The evidence creation algorithm MUST match the 583 evidence create algorithm suite selected by the server in the 584 evidence_creation extension in the extended server hello 585 message. The timestamp MUST be acceptable to the 586 EvidenceRequest recipient as the same value is provided in the 587 EvidenceResponse message. The three hash values received in 588 the EvidenceRequest message MUST match locally computed values 589 over the same data. Note that the app_data_sent_hash and the 590 app_data_received_hash values represent the session from the 591 perspective of the EvidenceRequest originator, and the values 592 are not swapped to represent the EvidenceRequest recipient 593 perspective. If any of these conditions is not met, then the 594 EvidenceResponse message MUST NOT be sent, and the TLS session 595 MUST be closed immediately after sending a fatal 596 evidence_failure(TBD) alert. 598 party1_certificate 599 Contains the X.509 certificate of the sender of the 600 evidence_end1 alert. If this certificate cannot be validated, 601 then TLS session must be closed immediately after sending one 602 of the following fatal alerts: bad_certificate(42), 603 unsupported_certificate(43), certificate_revoked(44), or 604 certificate_expired(45). These alerts are described in Section 605 7.2.2 of [TLS1.1]. 607 party1_signature 608 Contains the digital signature computed by the sender of the 609 evidence_end1 alert. If this signature cannot be validated, 610 then TLS session must be closed immediately after sending a 611 fatal evidence_failure(TBD) alert. 613 party2_certificate 614 Contains the X.509 certificate of the sender of the 615 evidence_end2 alert. While this certificate was probably 616 exchanged and validated in the Handshake Protocol, inclusion 617 here make it clear which certificate was employed by the signer 618 when the evidence is validated in the future, possibly by a 619 third party. 621 Party2_signature 622 Contains the digital signature computed by the sender of the 623 evidence_end2 alert using the evidence creation algorithm suite 624 identified in evidence_suite. The hash value is computed as: 626 Hash(evidence) 628 5. IANA Considerations 630 This document defines one TLS extension: evidence_creation(TBD). 631 This extension type value is assigned from the TLS Extension Type 632 registry defined in [TLSEXT]. 634 This document defines five TLS alert descriptions: the 635 evidence_start1(TBD), evidence_start2(TBD), evidence_end1(TBD), 636 evidence_end2(TBD), and evidence_failure(TBD). These alert 637 descriptions are assigned from the TLS Alert registry defined in 638 [TLS1.1]. 640 This document defines one TLS ContentType: evidence(TBD). This 641 ContentType value is assigned from the TLS ContentType registry 642 defined in [TLS1.1]. 644 This document establishes a registry for TLS Evidence Protocol 645 EvidenceMsgType. The first two entries in the registry are 646 request(1) and response(2). All additional TLS Evidence Protocol 647 EvidenceMsgType values are assigned by Standards Action as described 648 in [IANA]. 650 This document establishes a registry for Evidence Create Algorithm 651 suite identifiers. Appendix A lists the initial values for this 652 registry. Evidence Create Algorithm suite identifier values with the 653 first byte in the range 0-191 (decimal) inclusive are assigned by 654 Standards Action as described in [IANA]. Values with the first byte 655 in the range 192-254 (decimal) are assigned by Specification Required 656 as described in [IANA]. Values with the first byte 255 (decimal) are 657 reserved for Private Use as described in [IANA]. 659 6. Security Considerations 661 This document describes an extension to the TLS protocol, and the 662 security considerations in [TLS1.1] and [TLSEXT] apply. 663 Additionally, temporal and storage security considerations are 664 discussed below. 666 6.1. Temporal Considerations 668 Generating evidence that covers Application Data values that do not 669 explicitly or implicitly indicate the point in time at which the 670 Application Data was transferred over the TLS session might give rise 671 to replay attacks, post-dating, pre-dating, or other temporal 672 disputes. To avoid these concerns, the evidence includes an 673 indication of the date and time. The TLS implementation MUST NOT 674 attempt to extract date and time values from the Application Data; 675 doing so is likely to be error prone. Instead, the date and time 676 SHOULD come from a local clock or a trustworthy time server. Date 677 and time are provided by one of the parties, and the other party 678 determines that the date and time value is sufficiently accurate. 680 When a more highly trusted time source is needed, the Time-Stamp 681 Protocol [TSP] can be used to obtain a time-stamp on the evidence 682 from a trusted third party. 684 6.2. Storage Considerations 686 Parties that choose to preserve a plaintext record of Application 687 Data or Handshake Protocol messages for evidence verification at a 688 later time must ensure must ensure that this data is not 689 inappropriately disclosed by employing suitable physical protection 690 or cryptographic mechanisms that are at least as strong as the 691 selected TLS ciphersuite. 693 Suitable physical controls for the protection of Application Data or 694 Handshake Protocol messages containing keying material or sensitive 695 data should use removable storage media in conjunction with durable, 696 locking storage containers. If the removable media is transferred 697 from one location to another or backup copies are made, secure 698 handling protections ought to be employed, which might include the 699 use of insured or bonded couriers. 701 A suitable cryptographic mechanism provides confidentiality 702 protection, since the hash value in the evidence itself provides 703 integrity protection. One reasonable solution is to encrypt the 704 Handshake Protocol messages and Application Data messages with a 705 fresh symmetric encryption key using the same algorithm that was 706 negotiated for the selected TLS ciphersuite. The key generation 707 should follow the recommendations in [RANDOM]. Then, the symmetric 708 key is encrypted for storage with the party's RSA public key or long- 709 lived key-encryption key. The Cryptographic Message Syntax (CMS) 710 [CMS] offers a convenient way to keep all of this information 711 together. 713 An alternative cryptographic mechanism is to save the TLS session 714 itself. The negotiated TLS ciphersuite was already used to protect 715 the Application Data messages, and the Handshake Protocol messages 716 contain the keying material necessary to decrypt them if the party 717 retains the private keys and/or pre-shared secrets. 719 7. References 721 7.1. Normative References 723 [IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing 724 an IANA Considerations Section in RFCs", RFC 3434, 725 October 1998. 727 [DSS] Federal Information Processing Standards Publication 728 (FIPS PUB) 186, Digital Signature Standard, 2000. 730 [PKCS1] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", 731 RFC 2313, March 1998. 733 [PKIX1] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 734 Public Key Infrastructure - Certificate and 735 Certificate Revocation List (CRL) Profile", RFC 3280, 736 April 2002. 738 [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0", 739 RFC 2246, January 1999. 741 [TLS1.1] Dierks, T., and E. Rescorla, "The Transport Layer Security 742 (TLS) Protocol, Version 1.1", RFC 4346, April 2006. 744 [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 745 and T. Wright, "Transport Layer Security (TLS) Extensions", 746 RFC 4366, April 2006. 748 [SHA] Federal Information Processing Standards Publication 749 (FIPS PUB) 180-2, Secure Hash Algorithm, 2002. 751 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 752 Requirement Levels", BCP 14, RFC 2119, March 1997. 754 [X9.62] X9.62-1998, "Public Key Cryptography For The Financial 755 Services Industry: The Elliptic Curve Digital 756 Signature Algorithm (ECDSA)", January 7, 1999. 758 7.2. Informative References 760 [AUTHZ] Brown, M., and R. Housley, "Transport Layer Security 761 (TLS) Authorization Extensions", work in progress, 762 draft-housley-tls-authz-extns. 764 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 765 RFC 3852, July 2004. 767 [TSP] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 768 "Internet X.509 Public Key Infrastructure: Time-Stamp 769 Protocol (TSP)", RFC 3161,August 2001. 771 8. Acknowledgements 773 Thanks to C. Robert Beattie, J.D. and Randy V. Sabett, J.D., CISSP 774 for their observations and comparisons between the Uniform Electronic 775 Transactions Act (1999) prepared by the National Conference of 776 Commissioners on Uniform State Laws versus the American Bar 777 Association's Digital Signature Guidelines (1996), their observations 778 regarding the strengths and weaknesses of these two approaches, and 779 their desire to promote trust and reduce potential for litigation in 780 online transactions. Their pro bono contribution of time and 781 expertise deserves recognition. 783 This material is based, in part, upon work supported by the United 784 States Navy Space and Naval Warfare Systems Command under Contract 785 No. N00039-06-C-0097. 787 Appendix A. Evidence Create Algorithms 789 The following values define the EvidenceCreateSuite identifiers used 790 in the TLS Evidence Extensions. 792 An EvidenceCreateSuite defines a cipher specification supported by 793 TLS Evidence Extensions. A suite identifier names a public key 794 signature algorithm and an associated one-way hash function. A 795 registration is named as follows: 797 _WITH_ 799 These components have the following meaning: 801 802 Specifies the digital signature algorithm and key length 803 associated with the algorithm. It is used to digitally sign 804 the evidence. The "RSA_1024" value indicates the use of the 805 PKCS#1 v1.5 [PKCS1] digital signature algorithm using a 806 1024-bit public key. The "DSS_1024" value indicates the use of 807 the DSS digital signature algorithm [DSS] with a 1024-bit 808 public key. The "ECDSA_P384" value indicates the use of the 809 ECDSA digital signature algorithm [X9.62] using the P-384 named 810 elliptic curve. 812 813 Specifies the one-way hash function used as part of the digital 814 signature. The "SHA_1", "SHA_224", "SHA_256", "SHA_384", and 815 "SHA_512" values identify members of the Secure Hash Algorithm 816 family of one-way- hash functions [SHA]. 818 In most cases it will be appropriate to use the same algorithms and 819 certified public keys that were negotiated in the TLS Handshake 820 Protocol. The following additional steps are required in order to 821 employ the digital signature aspects of a TLS CipherSuite to a valid 822 EvidenceCreateSuite: 824 1) CipherSuites that do not include signature-capable certificates 825 cannot be used as EvidenceCreateSuite. 827 2) CipherSuites that specify the use of MD5 one-way hash function 828 should not be used as EvidenceCreateSuite. 830 Of course, any aspect of a CipherSuite that deals with symmetric 831 ciphers and symmetric cipher key lengths is not relevant to the 832 EvidenceCreateSuite. 834 All public key certificate profiles used in TLS are defined by the 835 IETF PKIX working group in [PKIX1]. When a key usage extension is 836 present, then either the digitalSignature bit or the nonRepudiation 837 bit MUST be set for the public key to be eligible for signing 838 evidence. If both bits are set, then this requirement is satisfied. 840 The following EvidenceCreateSuite definitions are made at this time. 841 Section 5 specifies the procedures for registering additional 842 EvidenceCreateSuite definitions. 844 EvidenceCreateSuite RSA_1024_WITH_SHA_1 = { 0x00, 0x01 }; 845 EvidenceCreateSuite RSA_1024_WITH_SHA_256 = { 0x00, 0x02 }; 846 EvidenceCreateSuite RSA_2048_WITH_SHA_256 = { 0x00, 0x03 }; 848 EvidenceCreateSuite DSS_1024_WITH_SHA_1 = { 0x00, 0x11 }; 849 EvidenceCreateSuite DSS_2048_WITH_SHA_256 = { 0x00, 0x12 }; 851 EvidenceCreateSuite ECDSA_P256_WITH_SHA_256 = { 0x00, 0x21 }; 852 EvidenceCreateSuite ECDSA_P384_WITH_SHA_384 = { 0x00, 0x22 }; 853 EvidenceCreateSuite ECDSA_P521_WITH_SHA_512 = { 0x00, 0x23 }; 855 Author's Address 857 Mark Brown 858 RedPhone Security 859 2019 Palace Avenue 860 Saint Paul, MN 55105 861 USA 862 mark redphonesecurity com 864 Russell Housley 865 Vigil Security, LLC 866 918 Spring Knoll Drive 867 Herndon, VA 20170 868 USA 869 housley vigilsec com 871 Full Copyright Statement 873 Copyright (C) The Internet Society (2006). This document is subject 874 to the rights, licenses and restrictions contained in BCP 78, and 875 except as set forth therein, the authors retain all their rights. 877 This document and translations of it may be copied and furnished to 878 others, and derivative works that comment on or otherwise explain it 879 or assist in its implementation may be prepared, copied, published 880 and distributed, in whole or in part, without restriction of any 881 kind, provided that the above copyright notice and this paragraph are 882 included on all such copies and derivative works. However, this 884 document itself may not be modified in any way, such as by removing 885 the copyright notice or references to the Internet Society or other 886 Internet organizations, except as needed for the purpose of 887 developing Internet standards in which case the procedures for 888 copyrights defined in the Internet Standards process must be 889 followed, or as required to translate it into languages other than 890 English. 892 This document and the information contained herein are provided on an 893 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 894 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 895 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 896 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 897 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 898 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.