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]