diff options
Diffstat (limited to 'doc/protocol/draft-housley-evidence-extns-01.txt')
| -rw-r--r-- | doc/protocol/draft-housley-evidence-extns-01.txt | 1176 |
1 files changed, 0 insertions, 1176 deletions
diff --git a/doc/protocol/draft-housley-evidence-extns-01.txt b/doc/protocol/draft-housley-evidence-extns-01.txt deleted file mode 100644 index 639dd0b481..0000000000 --- a/doc/protocol/draft-housley-evidence-extns-01.txt +++ /dev/null @@ -1,1176 +0,0 @@ - - - - -Internet-Draft M. Brown -November 2006 RedPhone Security -Expires: May 2007 R. Housley - Vigil Security - - - Transport Layer Security (TLS) Evidence Extensions - <draft-housley-evidence-extns-01.txt> - - - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -Copyright Notice - - Copyright (C) The Internet Society (2006). All Rights Reserved. - -Abstract - - This document specifies evidence creation extensions to the Transport - Layer Security (TLS) Protocol. Extension types are carried in the - client and server hello message extensions to confirm that both - parties support the protocol features needed to perform evidence - creation. The syntax and semantics of the evidence creation alerts - and messages are described in detail. - - - - - -Brown & Housley [Page 1] - -Internet-Draft November 2006 - - -1. Introduction - - Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1] is being - used in an increasing variety of operational environments, including - ones that were not envisioned when the original design criteria for - TLS were determined. The extensions specified in this document - support evidence creation in environments where the peers in the TLS - session cooperate to create persistent evidence of the TLS-protected - application data. Such evidence may be necessary to meet business - requirements, including regulatory requirements. Also, evidence may - be used in tandem with authorization information to make high - assurance access control and routing decisions in military and - government environments. Evidence created using this extension may - also be used to audit various aspects of the TLS handshake, including - the cipher suite negotiation and the use of other TLS extensions. In - many cases, the evidence does not need to be validated by third - parties; however, in other cases, the evidence might be validated by - third parties. To accommodate all of these situations, the evidence - is generated using a digital signature. Since validation of a - digital signature requires only public information, evidence - generated with this mechanism is suitable for sharing with third - parties. - - When digital certificates are to be employed in evidence creations, - the client must obtain the public key certificate (PKC) for the - server, and the server must obtain the PKC for the client. This is - most easily accomplished by using the PKCs provided in the Handshake - Protocol Certificate messages. Further, both parties SHOULD have an - opportunity to validate the PKC that will be used by the other party - before evidence creation. Again, this is naturally accomplished - using the Handshake Protocol, where the TLS session can be rejected - if the PKC cannot be validated. - - This document describes evidence creation TLS extensions supporting - both TLS 1.0 and TLS 1.1. These extensions observe the conventions - defined for TLS Extensions [TLSEXT]. The extensions are designed to - be backwards compatible, meaning that the protocol alerts and - messages associated with the evidence creation extensions will be - exchanged only if the client indicates support for them in the client - hello message and the server indicates support for them in the server - hello message. - - Clients typically know the context of the TLS session before it is - established. As a result, the client can request the use of the - evidence creation extensions in sessions where they might be needed. - Servers accept extended client hello messages, even if the server - does not support the all of the listed extensions. However, the - server will not indicate support for any extensions that are not - - - -Brown & Housley [Page 2] - -Internet-Draft November 2006 - - - "understood" by the implementation. At the end of the hello message - exchange, the client may reject communications with servers that do - not support the evidence creation extensions, or the client may - accept the situation and proceed, whichever is appropriate. - -1.1. Conventions - - The syntax for the evidence creation messages is defined using the - TLS Presentation Language, which is specified in Section 4 of - [TLS1.0]. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [STDWORDS]. - -1.2. Overview - - Figure 1 illustrates the placement of the evidence creation alerts - and messages in the TLS session. The first pair of evidence creation - alerts indicates the beginning of the protected content that will be - covered by the evidence. The first pair of alerts can appear any - place after the TLS Handshake Protocol Finished messages, which - ensures that they are integrity protected. The second pair of - evidence creation alerts indicates the ending of the protected - content that will be covered by the evidence. Immediately after the - reception of the final alert, a pair of Evidence Protocol messages is - exchanged to create the persistent evidence. - - Generating evidence is not compatible with Diffie-Hellman Ephemeral - (DHE) key exchanges. DHE does not permit the same keying material to - be generated for validation of the evidence after the TLS session is - over. Persistent evidence requires the use of a digital signature so - that it can be validated well after the TLS session is over. - - The ClientHello message includes an indication that the evidence - creation messages are supported. The ServerHello message also - includes an indication that the evidence creation messages are - supported. Both the client and the server MUST indicate support for - the evidence protocol alerts and messages; otherwise they MUST NOT be - employed by either the client or the server. - - - - - - - - - - - -Brown & Housley [Page 3] - -Internet-Draft November 2006 - - - Client Server - - ClientHello --------> - ServerHello - Certificate+ - ServerKeyExchange* - CertificateRequest+ - <-------- ServerHelloDone - Certificate+ - ClientKeyExchange - CertificateVerify+ - ChangeCipherSpec - Finished --------> - ChangeCipherSpec - <-------- Finished - Application Data <-------> Application Data - Alert(evidence_start1) --------> - Application Data - <-------- Alert(evidence_start2) - - Application Data <-------> Application Data - Alert(evidence_end1) --------> - Application Data - <-------- Alert(evidence_end2) - EvidenceRequest --------> - <-------- EvidenceResponse - Application Data <-------> Application Data - - * Indicates optional or situation-dependent messages that - are not always sent. - + Indicates messages optional to the TLS handshake that - MUST be sent when using TLS evidence. - - - Figure 1. Example TLS Session with Evidence Creation. - - - - - - - - - - - - - - - - -Brown & Housley [Page 4] - -Internet-Draft November 2006 - - -2. Evidence Extension Types - - The general extension mechanisms enable clients and servers to - negotiate whether to use specific extensions, and how to use specific - extensions. As specified in [TLSEXT], the extension format used in - the extended client hello message and extended server hello message - within the TLS Handshake Protocol is: - - struct { - ExtensionType extension_type; - opaque extension_data<0..2^16-1>; - } Extension; - - The extension_type identifies a particular extension type, and the - extension_data contains information specific to the particular - extension type. - - As specified in [TLSEXT], for all extension types, the extension type - MUST NOT appear in the extended server hello message unless the same - extension type appeared in the preceding client hello message. - Clients MUST abort the handshake if they receive an extension type in - the extended server hello message that they did not request in the - preceding extended client hello message. - - When multiple extensions of different types are present in the - extended client hello message or the extended server hello message, - the extensions can appear in any order, but there MUST NOT be more - than one extension of the same type. - - This document specifies the use of the evidence_creation extension - type. This specification adds one new type to ExtensionType: - - enum { - evidence_creation(TBD), (65535) - } ExtensionType; - - The evidence_creation extension is relevant when a session is - initiated and also for any subsequent session resumption. However, a - client that requests resumption of a session does not know whether - the server has maintained all of the context necessary to accept this - request, and therefore the client SHOULD send an extended client - hello message that includes the evidence_creation extension type. - This indicates that the client requests the server's continued - cooperation in creating evidence. If the server denies the - resumption request, then the evidence_creation extension will be - negotiated normally using the full Handshake protocol. - - Clients MUST include the evidence_creation extension in the extended - - - -Brown & Housley [Page 5] - -Internet-Draft November 2006 - - - client hello message to indicate their desire to send and receive - evidence creation alerts and messages. The extension_data field - indicates the evidence creation algorithms that are supported. The - format is indicated with the EvidenceCreateList type: - - uint16 EvidenceCreateSuite[2]; - - struct { - EvidenceCreateSuite evidence_suites<2..2^16-1>; - } EvidenceCreateList; - - The EvidenceCreateList enumerates the evidence creation algorithms - that are supported by the client. The client MUST order the entries - from most preferred to least preferred, but all of the entries MUST - be acceptable to the client. Values are defined in Appendix A, and - others can be registered in the future. - - Servers that receive an extended client hello message containing the - evidence_creation extension MUST respond with the evidence_creation - extension in the extended server hello message if the server is - willing to send and receive evidence creation alerts and messages. - The evidence_creation extension MUST be omitted from the extended - server hello message if the server is unwilling to send and receive - using one of the evidence creation algorithm suites identified by the - client. The extension_data field indicates the evidence creation - algorithm suite that the server selected from the list provided by - the client. The format is indicated with the EvidenceCreateSuite - type defined above. - -3. Alert Messages - - This document specifies the use of four new alert message - descriptions: the evidence_start1, evidence_start2, evidence_end1, - and evidence_end2. These descriptions are specified in Sections 3.1, - 3.2, 3.3, and 3.4, respectively. The alert descriptions are - presented below in the order they MUST be sent; sending alerts in an - unexpected order results in a fatal error. These descriptions are - always used with the warning alert level. This specification adds - four new types to AlertDescription: - - enum { - evidence_start1(TBD), - evidence_start2(TBD), - evidence_end1(TBD), - evidence_end2(TBD), - evidence_failure(TBD), - (255) - } AlertDescription; - - - -Brown & Housley [Page 6] - -Internet-Draft November 2006 - - -3.1. The evidence_start1 Description - - The client and the server need to synchronize evidence creation. - Either party may indicate the desire to start creating evidence by - sending the evidence_start1 alert. If the other party is ready to - begin creating evidence, then the other party MUST send an - evidence_start2 alert in response to the evidence_start1 alert that - was sent. If the other party is unwilling to begin creating - evidence, the other party MUST respond with fatal - evidence_failure(TBD) alert and terminate the TLS session. - - Evidence may be collected more than once during a TLS session; - however, evidence gathering MUST NOT be nested. That is, a party - sending the a second evidence_start1 alert before evidence_end2 alert - has occurred and the evidence protocol has completed is a protocol - violation. Reception of an evidence_start1 alert that would result - in evidence nesting MUST be responded to with a fatal - evidence_failure(TBD) alert and terminating the TLS session. - - Digital signatures are used in evidence creation. If an - evidence_start1 alert is received before the other party has provided - a valid PKC, then the evidence_start1 alert recipient MUST terminate - the TLS session using a fatal certificate_unknown alert. - -3.2. The evidence_start2 Description - - The evidence_start2 alert is sent in response to the evidence_start1 - alert. By sending the evidence_start2 alert, the sending party - indicates that they are also ready to begin creating evidence. After - this pair of alerts is exchanged, both the client and the server use - the hash function indicated in the extended server hello message to - start computing the evidence. Each party computes two independent - hash values: one for each octet that is written, and one for each - octet that is read. - - Digital signatures are used in evidence creation. If an - evidence_start2 alert is received before the other party has provided - a valid PKC, then the evidence_start2 alert recipient MUST terminate - the TLS session using a fatal certificate_unknown alert. - -3.3. The evidence_end1 Description - - 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. - - - - -Brown & Housley [Page 7] - -Internet-Draft November 2006 - - - The evidence_end1 alert sender MAY initiate the Evidence Protocol as - described in Section 4 at any time following this alert. The - evidence_end1 alert sender SHOULD ensure that it has received all - pending application data writes from the other party before - initiating the Evidence Protocol. One way to ensure that all of the - application data has been received it to wait for the receipt of an - evidence_end2 alert. If the Evidence Protocol begins before all of - the application data is available, the result will be a fatal - evidence_failure(TBD) alert when signature verification fails. - -3.4. The evidence_end2 Description - - The evidence_end2 alert is sent in response to the evidence_end1 - alert. The evidence_end1 alert receiver SHOULD complete any pending - writes. The intent is to include any application data that would be - sent in response to application data that was received before the - evidence_end1 alert as part of evidence creation. Once the pending - writes are complete, the evidence_end1 alert receiver sends the - evidence_end2 alert. - - At this point, each party completes the hash value computations. - - The evidence_end2 alert receiver MUST respond by initiating the - Evidence Protocol as described in Section 4, if it has not already - done so. - -3.5. The evidence_failure Description - - The evidence_failure fatal alert is sent to indicate a failure in - evidence creation. During evidence synchronization, this alert - indicates that the sending party is unwilling to begin evidence - creation. During the Evidence Protocol, this alert indicates that - the evidence provided by the other party is not acceptable or cannot - be validated. - -4. Evidence Protocol - - This document specifies an additional TLS Protocol: the Evidence - Protocol. It is used to create persistent evidence of the TLS - session content. This specification adds one new Record layer - ContentType: - - enum { - evidence(TBD), - (255) - } ContentType; - - - - - -Brown & Housley [Page 8] - -Internet-Draft November 2006 - - - Persistence evidence of the TLS session content is produced by the - TLS Evidence Protocol. Evidence messages are supplied to the TLS - Record Layer, where they are encapsulated within one or more - TLSPlaintext structures, which are processed and transmitted as - specified by the current active session state. - - The Evidence Protocol structure follows: - - enum { - request(1), response(2), (255) - } EvidenceMsgType; - - struct { - EvidenceMsgType evidence_msg_type; - uint24 length; /* number of octets in message */ - select (EvidenceMsgType) { - case request: EvidenceRequest; - case response: EvidenceResponse; - } body; - } EvidenceProtocol; - - The Evidence Protocol messages are presented below in the order they - MUST be sent; sending evidence messages in an unexpected order - results in a fatal unexpected_message(10) alert. The EvidenceRequest - message and the EvidenceResponse message are specified in Section 4.2 - and Section 4.3, respectively. Section 4.1 describes structures that - are used in the EvidenceRequest and EvidenceResponse messages. - -4.1. Certificates and Digital Signatures - - The evidence Protocol makes use of the ASN.1Cert definition used - elsewhere in TLS. It is repeated here for convenience. - - opaque ASN.1Cert<1..2^24-1>; - - - - - - - - - - - - - - - - - -Brown & Housley [Page 9] - -Internet-Draft November 2006 - - - The EvidenceSignature definition is very similar to the Signature - definition used elsewhere in TLS. The EvidenceSignature definition - signs hash[hash_size], but the Signature definition used elsewhere in - TLS signs a combination of an md5_hash and a sha_hash. Also, the - EvidenceSignature definition excludes the anonymous case. - - enum { rsa, dsa, ecdsa } EvidenceSignatureAlgorithm; - - select (EvidenceSignatureAlgorithm) - { case rsa: - digitally-signed struct { - opaque hash[hash_size]; - }; - case dsa: - digitally-signed struct { - opaque hash[hash_size]; - }; - case ecdsa: - digitally-signed struct { - opaque hash[hash_size]; - }; - } EvidenceSignature; - - The hash algorithm and the hash_size depend on evidence create - algorithm suite selected by the server in the evidence_creation - extension. - -4.2. EvidenceRequest Message - - The EvidenceRequest message contains the evidence_end1 alert sender's - contribution to the persistent evidence. It employs the evidence - create algorithm suite selected by the server in the - evidence_creation extension in the extended server hello message. - - struct { - Evidence evidence<1..2^16-1>; - ASN.1Cert party1_certificate; - EvidenceSignature party1_signature; - } EvidenceRequest; - - - - - - - - - - - - -Brown & Housley [Page 10] - -Internet-Draft November 2006 - - - struct { - EvidenceCreateSuite evidence_suite; - uint64 gmt_unix_time; - uint64 app_data_sent_offset; - uint64 app_data_received_offset; - opaque handshake_protocol_hash<1..512>; - opaque app_data_sent_hash<1..512>; - opaque app_data_received_hash<1..512>; - } Evidence; - - The elements of the EvidenceRequest structure are described below: - - evidence - Contains an evidence create algorithm identifier, a timestamp, - and three hash values in the Evidence structure as described - below. - - party1_certificate - Contains the X.509 certificate of the signer. While this - certificate was probably exchanged and validated in the - Handshake Protocol, inclusion here makes it clear which - certificate was employed by the signer when the evidence is - validated in the future, possibly by a third party. - - party1_signature - Contains the digital signature computed by the sender of the - evidence_end1 alert using the evidence creation algorithm suite - identified in evidence_create_suite. The hash value is - computed as: - - Hash(evidence) - - The elements of the Evidence structure are described below: - - evidence_suite - Indicates the evidence creation algorithm suite selected by the - server in the evidence_creation extension in the Handshake - Protocol. This value determines the structure of the hash - values and digital signatures. - - gmt_unix_time - Indicates the current date and time according to the local - system clock used by the sender of the evidence_end1 alert. - This time value is intended to represent the moment in time - that evidence_end1 was sent. Unlike other places in the TLS - protocol, a 64-bit value is used to ensure that time values do - not wrap in 2038. - - - - -Brown & Housley [Page 11] - -Internet-Draft November 2006 - - - app_data_sent_offset - Indicates the number of octets that were sent as part of this - TLS session before evidence collection began. - - app_data_received_offset - Indicates the number of octets that were received as part of - this TLS session before evidence collection began. - - handshake_protocol_hash - Compute as: - - Hash(handshake_messages), - - where handshake_messages refers to all Handshake Protocol - messages sent or received, beginning with the most recent - client hello message. If the double handshake mechanism - described in the security considerations of [TLSAUTHZ] is used - to encrypt the Handshake Protocol, the plaintext form of these - messages is used in calculating this hash value. - - Verification of the handshake_protocol_hash is performed using - the plaintext form of the Handshake protocol messages. For - this hash value to be validated at a later time, this - information must be saved as part of the overall evidence. Any - attempt to save this data must ensure that it is not - inappropriately disclosed by employing suitable physical - protection or cryptographic mechanisms that are at least as - strong as the selected TLS ciphersuite. Suitable controls are - discussed further in the Security Considerations; see Section - 6. - - In the case of successful TLS session resumption, the most - recent client hello message will contain a valid - ClientHello.session_id value as well as extensions, and these - extensions may include sensitive data. The TLS Authorization - Extension [AUTHZ] is one example where an extension might - contain sensitive information. Thus, even when session - resumption is employed, the content of the Handshake protocol - messages ought to be protected. - - TLS users should ensure that the content of the Handshake - protocol messages contain sufficient evidence to determine the - intent of the signers, where "signers" are defined as the - subject identities in the exchanged X.509 certificates. - Clients and servers MAY record the protocol messages containing - an expression of the intent of the signers using a suitable TLS - extension [TLSEXT], such as [TLSAUTHZ]. For example, a client - may request access to a resource provided by the server, - - - -Brown & Housley [Page 12] - -Internet-Draft November 2006 - - - provide sufficient authentication and authorization information - grounds to convince the server to grant the requested access, - and receive an affirmative response from the server. A record - of TLS Handshake protocol messages representing this example - may provide a sufficient record of the intent of both the - client and the server. - - app_data_sent_hash - Compute as: - - Hash(sent_application_data), - - where sent_application_data refers to all of the Application - Data messages sent since the most recent evidence_start1 or - evidence start2 alert was sent, and ending with the sending of - the evidence_end1 alert. The alerts are not application data, - and they are not included in the hash computation. - - app_data_received_hash - Compute as: - - Hash(received_application_data), - - where received_application_data refers to all of the - Application Data messages received since the most recent - evidence_start1 or evidence start2 alert was received, and - ending with the receipt of the evidence_end2 alert. The alerts - are not application data, and they are not included in the hash - computation. - -4.3. EvidenceResponse Message - - The EvidenceResponse message contains the complete persistent - evidence. The value is saved by one or both parties as evidence of - the TLS session content identified by the evidence_start1, - evidence_start2, evidence_end1, and evidence_end2 alerts. - - struct { - Evidence evidence<1..2^16-1>; - ASN.1Cert party1_certificate; - EvidenceSignature party1_signature; - ASN.1Cert party2_certificate; - EvidenceSignature party2_signature; - } EvidenceResponse; - - - - - - - -Brown & Housley [Page 13] - -Internet-Draft November 2006 - - - The elements of the EvidenceResponse structure are described below: - - evidence - Contains an evidence create algorithm identifier, a timestamp, - and three hash values in the Evidence structure as described in - section 4.2. The evidence creation algorithm MUST match the - evidence create algorithm suite selected by the server in the - evidence_creation extension in the extended server hello - message. The timestamp MUST be acceptable to the - EvidenceRequest recipient as the same value is provided in the - EvidenceResponse message. The three hash values received in - the EvidenceRequest message MUST match locally computed values - over the same data. Note that the app_data_sent_hash and the - app_data_received_hash values represent the session from the - perspective of the EvidenceRequest originator, and the values - are not swapped to represent the EvidenceRequest recipient - perspective. If any of these conditions is not met, then the - EvidenceResponse message MUST NOT be sent, and the TLS session - MUST be closed immediately after sending a fatal - evidence_failure(TBD) alert. - - party1_certificate - Contains the X.509 certificate of the sender of the - evidence_end1 alert. If this certificate cannot be validated, - then TLS session must be closed immediately after sending one - of the following fatal alerts: bad_certificate(42), - unsupported_certificate(43), certificate_revoked(44), or - certificate_expired(45). These alerts are described in Section - 7.2.2 of [TLS1.1]. - - party1_signature - Contains the digital signature computed by the sender of the - evidence_end1 alert. If this signature cannot be validated, - then TLS session must be closed immediately after sending a - fatal evidence_failure(TBD) alert. - - party2_certificate - Contains the X.509 certificate of the sender of the - evidence_end2 alert. While this certificate was probably - exchanged and validated in the Handshake Protocol, inclusion - here make it clear which certificate was employed by the signer - when the evidence is validated in the future, possibly by a - third party. - - - - - - - - -Brown & Housley [Page 14] - -Internet-Draft November 2006 - - - Party2_signature - Contains the digital signature computed by the sender of the - evidence_end2 alert using the evidence creation algorithm suite - identified in evidence_suite. The hash value is computed as: - - Hash(evidence) - -5. IANA Considerations - - This document defines one TLS extension: evidence_creation(TBD). - This extension type value is assigned from the TLS Extension Type - registry defined in [TLSEXT]. - - This document defines five TLS alert descriptions: the - evidence_start1(TBD), evidence_start2(TBD), evidence_end1(TBD), - evidence_end2(TBD), and evidence_failure(TBD). These alert - descriptions are assigned from the TLS Alert registry defined in - [TLS1.1]. - - This document defines one TLS ContentType: evidence(TBD). This - ContentType value is assigned from the TLS ContentType registry - defined in [TLS1.1]. - - This document establishes a registry for TLS Evidence Protocol - EvidenceMsgType. The first two entries in the registry are - request(1) and response(2). All additional TLS Evidence Protocol - EvidenceMsgType values are assigned by Standards Action as described - in [IANA]. - - This document establishes a registry for Evidence Create Algorithm - suite identifiers. Appendix A lists the initial values for this - registry. Evidence Create Algorithm suite identifier values with the - first byte in the range 0-191 (decimal) inclusive are assigned by - Standards Action as described in [IANA]. Values with the first byte - in the range 192-254 (decimal) are assigned by Specification Required - as described in [IANA]. Values with the first byte 255 (decimal) are - reserved for Private Use as described in [IANA]. - -6. Security Considerations - - This document describes an extension to the TLS protocol, and the - security considerations in [TLS1.1] and [TLSEXT] apply. - Additionally, temporal and storage security considerations are - discussed below. - - - - - - - -Brown & Housley [Page 15] - -Internet-Draft November 2006 - - -6.1. Temporal Considerations - - Generating evidence that covers Application Data values that do not - explicitly or implicitly indicate the point in time at which the - Application Data was transferred over the TLS session might give rise - to replay attacks, post-dating, pre-dating, or other temporal - disputes. To avoid these concerns, the evidence includes an - indication of the date and time. The TLS implementation MUST NOT - attempt to extract date and time values from the Application Data; - doing so is likely to be error prone. Instead, the date and time - SHOULD come from a local clock or a trustworthy time server. Date - and time are provided by one of the parties, and the other party - determines that the date and time value is sufficiently accurate. - - When a more highly trusted time source is needed, the Time-Stamp - Protocol [TSP] can be used to obtain a time-stamp on the evidence - from a trusted third party. - -6.2. Storage Considerations - - Parties that choose to preserve a plaintext record of Application - Data or Handshake Protocol messages for evidence verification at a - later time must ensure must ensure that this data is not - inappropriately disclosed by employing suitable physical protection - or cryptographic mechanisms that are at least as strong as the - selected TLS ciphersuite. - - Suitable physical controls for the protection of Application Data or - Handshake Protocol messages containing keying material or sensitive - data should use removable storage media in conjunction with durable, - locking storage containers. If the removable media is transferred - from one location to another or backup copies are made, secure - handling protections ought to be employed, which might include the - use of insured or bonded couriers. - - A suitable cryptographic mechanism provides confidentiality - protection, since the hash value in the evidence itself provides - integrity protection. One reasonable solution is to encrypt the - Handshake Protocol messages and Application Data messages with a - fresh symmetric encryption key using the same algorithm that was - negotiated for the selected TLS ciphersuite. The key generation - should follow the recommendations in [RANDOM]. Then, the symmetric - key is encrypted for storage with the party's RSA public key or long- - lived key-encryption key. The Cryptographic Message Syntax (CMS) - [CMS] offers a convenient way to keep all of this information - together. - - - - - -Brown & Housley [Page 16] - -Internet-Draft November 2006 - - - An alternative cryptographic mechanism is to save the TLS session - itself. The negotiated TLS ciphersuite was already used to protect - the Application Data messages, and the Handshake Protocol messages - contain the keying material necessary to decrypt them if the party - retains the private keys and/or pre-shared secrets. - -7. References - -7.1. Normative References - - [IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing - an IANA Considerations Section in RFCs", RFC 3434, - October 1998. - - [DSS] Federal Information Processing Standards Publication - (FIPS PUB) 186, Digital Signature Standard, 2000. - - [PKCS1] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", - RFC 2313, March 1998. - - [PKIX1] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet - Public Key Infrastructure - Certificate and - Certificate Revocation List (CRL) Profile", RFC 3280, - April 2002. - - [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0", - RFC 2246, January 1999. - - [TLS1.1] Dierks, T., and E. Rescorla, "The Transport Layer Security - (TLS) Protocol, Version 1.1", RFC 4346, April 2006. - - [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., - and T. Wright, "Transport Layer Security (TLS) Extensions", - RFC 4366, April 2006. - - [SHA] Federal Information Processing Standards Publication - (FIPS PUB) 180-2, Secure Hash Algorithm, 2002. - - [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [X9.62] X9.62-1998, "Public Key Cryptography For The Financial - Services Industry: The Elliptic Curve Digital - Signature Algorithm (ECDSA)", January 7, 1999. - - - - - - - -Brown & Housley [Page 17] - -Internet-Draft November 2006 - - -7.2. Informative References - - [AUTHZ] Brown, M., and R. Housley, "Transport Layer Security - (TLS) Authorization Extensions", work in progress, - draft-housley-tls-authz-extns. - - [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", - RFC 3852, July 2004. - - [TSP] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, - "Internet X.509 Public Key Infrastructure: Time-Stamp - Protocol (TSP)", RFC 3161,August 2001. - -8. Acknowledgements - - Thanks to C. Robert Beattie, J.D. and Randy V. Sabett, J.D., CISSP - for their observations and comparisons between the Uniform Electronic - Transactions Act (1999) prepared by the National Conference of - Commissioners on Uniform State Laws versus the American Bar - Association's Digital Signature Guidelines (1996), their observations - regarding the strengths and weaknesses of these two approaches, and - their desire to promote trust and reduce potential for litigation in - online transactions. Their pro bono contribution of time and - expertise deserves recognition. - - This material is based, in part, upon work supported by the United - States Navy Space and Naval Warfare Systems Command under Contract - No. N00039-06-C-0097. - - - - - - - - - - - - - - - - - - - - - - - -Brown & Housley [Page 18] - -Internet-Draft November 2006 - - -Appendix A. Evidence Create Algorithms - - The following values define the EvidenceCreateSuite identifiers used - in the TLS Evidence Extensions. - - An EvidenceCreateSuite defines a cipher specification supported by - TLS Evidence Extensions. A suite identifier names a public key - signature algorithm and an associated one-way hash function. A - registration is named as follows: - - <SignatureAlgorithm>_WITH_<HashFunction> - - These components have the following meaning: - - <SignatureAlgorithm> - Specifies the digital signature algorithm and key length - associated with the algorithm. It is used to digitally sign - the evidence. The "RSA_1024" value indicates the use of the - PKCS#1 v1.5 [PKCS1] digital signature algorithm using a - 1024-bit public key. The "DSS_1024" value indicates the use of - the DSS digital signature algorithm [DSS] with a 1024-bit - public key. The "ECDSA_P384" value indicates the use of the - ECDSA digital signature algorithm [X9.62] using the P-384 named - elliptic curve. - - <HashFunction> - Specifies the one-way hash function used as part of the digital - signature. The "SHA_1", "SHA_224", "SHA_256", "SHA_384", and - "SHA_512" values identify members of the Secure Hash Algorithm - family of one-way- hash functions [SHA]. - - In most cases it will be appropriate to use the same algorithms and - certified public keys that were negotiated in the TLS Handshake - Protocol. The following additional steps are required in order to - employ the digital signature aspects of a TLS CipherSuite to a valid - EvidenceCreateSuite: - - 1) CipherSuites that do not include signature-capable certificates - cannot be used as EvidenceCreateSuite. - - 2) CipherSuites that specify the use of MD5 one-way hash function - should not be used as EvidenceCreateSuite. - - Of course, any aspect of a CipherSuite that deals with symmetric - ciphers and symmetric cipher key lengths is not relevant to the - EvidenceCreateSuite. - - - - - -Brown & Housley [Page 19] - -Internet-Draft November 2006 - - - All public key certificate profiles used in TLS are defined by the - IETF PKIX working group in [PKIX1]. When a key usage extension is - present, then either the digitalSignature bit or the nonRepudiation - bit MUST be set for the public key to be eligible for signing - evidence. If both bits are set, then this requirement is satisfied. - - The following EvidenceCreateSuite definitions are made at this time. - Section 5 specifies the procedures for registering additional - EvidenceCreateSuite definitions. - - EvidenceCreateSuite RSA_1024_WITH_SHA_1 = { 0x00, 0x01 }; - EvidenceCreateSuite RSA_1024_WITH_SHA_256 = { 0x00, 0x02 }; - EvidenceCreateSuite RSA_2048_WITH_SHA_256 = { 0x00, 0x03 }; - - EvidenceCreateSuite DSS_1024_WITH_SHA_1 = { 0x00, 0x11 }; - EvidenceCreateSuite DSS_2048_WITH_SHA_256 = { 0x00, 0x12 }; - - EvidenceCreateSuite ECDSA_P256_WITH_SHA_256 = { 0x00, 0x21 }; - EvidenceCreateSuite ECDSA_P384_WITH_SHA_384 = { 0x00, 0x22 }; - EvidenceCreateSuite ECDSA_P521_WITH_SHA_512 = { 0x00, 0x23 }; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Brown & Housley [Page 20] - -Internet-Draft November 2006 - - -Author's Address - - Mark Brown - RedPhone Security - 2019 Palace Avenue - Saint Paul, MN 55105 - USA - mark <at> redphonesecurity <dot> com - - Russell Housley - Vigil Security, LLC - 918 Spring Knoll Drive - Herndon, VA 20170 - USA - housley <at> vigilsec <dot> com - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - -Brown & Housley [Page 21] |