TLS Working Group I. Hajjeh
Internet Draft INEOVATION
M. Badra
LIMOS Laboratory
Intended status: Experimental December 15, 2007
Expires: June 2008
TLS Sign
draft-hajjeh-tls-sign-04.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
This Internet-Draft will expire on June 15, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
TLS protocol provides authentication and data protection for
communication between two entities. However, missing from the
protocol is a way to perform non-repudiation service.
Hajjeh & Badra Expires June 2008 [Page 1]
Internet-Draft TLS Sign December 2007
This document defines extensions to the TLS protocol to allow it to
perform non-repudiation service. It is based on [TLSSIGN] and it
provides the client and the server the ability to sign by TLS,
handshake and applications data using certificates such as X.509.
Table of Contents
1. Introduction...................................................2
1.1. Conventions used in this document.........................3
2. TLS Sign overview..............................................3
2.1. tls sign on off protocol..................................6
2.1.1. bad_sign alert.......................................7
2.2. Storing signed data.......................................7
3. Security Considerations........................................9
4. IANA Considerations............................................9
5. References.....................................................9
5.1. Normative References......................................9
5.2. Informative References...................................10
Author's Addresses...............................................10
Appendix Changelog...............................................10
Intellectual Property Statement..................................11
Disclaimer of Validity...........................................11
1. Introduction
Actually, TLS is the most deployed security protocol for securing
exchanges. It provides end-to-end secure communications between two
entities with authentication and data protection. However, what is
missing from the protocol is a way to provide the non-repudiation
service.
This document describes how the non-repudiation service may be
integrated as an optional module in TLS. This is in order to provide
both parties with evidence that the transaction has taken place and
to offer a clear separation with application design and development.
TLS-Sign's design motivations included:
O TLS is application protocol-independent. Higher-level protocol can
operate on top of the TLS protocol transparently.
O TLS is a modular nature protocol. Since TLS is developed in four
independent protocols, the approach defined in this document can
be added by extending the TLS protocol and with a total reuse of
pre-existing TLS infrastructures and implementations.
Hajjeh & Badra Expires June 2008 [Page 2]
Internet-Draft TLS Sign December 2007
O Several applications like E-Business require non-repudiation proof
of transactions. It is critical in these applications to have the
non-repudiation service that generates, distributes, validates and
maintains the evidence of an electronic transaction. Since TLS is
widely used to secure these applications exchanges, the non-
repudiation should be offered by TLS.
O Generic non-repudiation with TLS. TLS Sign provides a generic non-
repudiation service that can be easily used with protocols. TLS
Sign minimizes both design and implementation of the signature
service and that of the designers and implementators who wish to
use this module.
1.1. Conventions used in this document
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 [RFC2119].
2. TLS Sign overview
TLS Sign is integrated as a higher-level module of the TLS Record
protocol. It is optionally used if the two entities agree. This is
negotiated by extending Client and Server Hello messages in the same
way defined in [TLSEXT].
In order to allow a TLS client to negotiate the TLS Sign, a new
extension type should be added to the Extended Client and Server
Hellos messages. TLS clients and servers MAY include an extension of
type 'signature' in the Extended Client and Server Hellos messages.
The 'extension_data' field of this extension contains a
'signature_request' where:
enum {
pkcs7(0), smime(1), xmldsig(2), (255);
} ContentFormat;
struct {
ContentFormat content_format;
SignMethod sign_meth;
SignType sign_type<2..2^16-1>;
} SignatureRequest;
enum {
ssl_client_auth_cert(0), ssl_client_auth_cert_url(1), (255);
} SignMethod;
Hajjeh & Badra Expires June 2008 [Page 3]
Internet-Draft TLS Sign December 2007
uint8 SignType[2];
The client initiates the TLS Sign module by sending the
ExtendedClientHello including the 'signature' extension. This
extension contains:
- the SignType carrying the type of the non repudiation proof. It can
have one of these two values:
SignType non_repudiation_with_proof_of_origin = { 0x00, 0x01 };
SignType non_repudiation_without_proof_of_origin = { 0x00, 0x02 };
- the ContentFormat carrying the format of signed data. It can be
PKCS7 [PKCS7], S/MIME [SMIME] or XMLDSIG [XMLDSIG]
ContentFormat PKCS7 = { 0x00, 0xA1 };
ContentFormat SMIME = { 0x00, 0xA2 };
ContentFormat XMLDSIG = { 0x00, 0xA3 };
o if the value of the ContentFormat is PKCS7, then the PKCS7
Content_type is of type signed-data.
o if the value of the ContentFormat is S/MIME, then S/MIME
Content_type is of type SignedData
o if the value of the ContentFormat is XMLDSIG, then XMLDSIG
signatureMethod algorithms.
- the SignMethod carrying the signature method that is used to sign
the application data (e.g. X509 authentication certificate).
SignMethod X509 = { 0x00, 0xB1 };
Actually, this document uses the same certificate used in client
authentication. Any new signature method MAY be added in future
versions (e.g. delegated attributes certificates).
The server MAY reject the connection by sending the error alert
"unsupported_extension" [TLSEXT] and closing the connection.
The client and the server MAY use the same certificates used by the
Handshake protocol. Several cases are possible:
- If the server has an interest in getting non-repudiation data from
the client and that the cipher_suites list sent by the client does
not include any cipher_suite with signature ability, the server MUST
(upon reception of tls_sign_on_off protocol message not followed by a
Hajjeh & Badra Expires June 2008 [Page 4]
Internet-Draft TLS Sign December 2007
certificate with a type equals to ExtendedServerHello.sign_method)
close the connection by sending a fatal error.
- If the server has an interest in getting non-repudiation data from
the client and that the cipher_suites list sent by the client
includes at least a cipher_suite with signature ability, the server
SHOULD select a cipher_suite with signature ability and MUST provide
a certificate (e.g., RSA) that MAY be used for key exchange. Further,
the server MUST request a certificate from the client using the TLS
certificate request message (e.g., an RSA or a DSS signature-capable
certificate). If the client does not send a certificate during the
TLS Handshake, the server MUST close the TLS session by sending a
fatal error in the case where the client sends a tls_sign_on_off
protocol message not followed by a certificate with a type equals to
ExtendedServerHello.sign_method.
- The client or the server MAY use a certificate different to these
being used by TLS Handshake. This MAY happen when the server agrees
in getting non-repudiation data from the client and that the type of
the client certificate used by TLS Handshake and the type selected by
the server from the list in ExtendedClientHello.sign_method are
different, or when the ExtendedServerHello.cipher_suite does not
require client and/or server certificates. In these cases, the client
or the server sends a new message called certificate_sign, right
after sending the tls_sign_on_off protocol messages. The new message
contains the sender's certificate in which the type is the same type
selected by the server from the list in
ExtendedClientHello.sign_method. The certificate_sign is therefore
used to generate signed data. It is defined as follows:
opaque ASN.1Cert<2^24-1>;
struct {
ASN.1Cert certificate_list<1..2^24-1>;
} CertificateSign;
The certificate_list, as defined in [TLS], is a sequence (chain) of
certificates. The sender's certificate MUST come first in the list.
If the server has no interest in getting non-repudiation data from
the client, it replays with an ordinary TLS ServerHello or return a
handshake failure alert and close the connection [TLS].
Client Server
ClientHello -------->
ServerHello
Certificate*
Hajjeh & Badra Expires June 2008 [Page 5]
Internet-Draft TLS Sign December 2007
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
ChangeCipherSpec
Finished -------->
ChangeCipherSpec
<-------- Finished
TLSSignOnOff <-------------------------> TLSSignOnOff
CertificateSign* <----------------------> CertificateSign*
(Signed) Application Data <-----> (Signed) Application Data
* Indicates optional or situation-dependent messages that are not
always sent.
2.1. tls sign on off protocol
To manage the generation of evidence, new sub-protocol is added by
this document, called tls_sign_on_off. This protocol consists of a
single message that is encrypted and compressed under the established
connection state. This message can be sent at any time after the TLS
session has been established. Thus, no man in the middle can replay
or inject this message. It consists of a single byte of value 1
(tls_sign_on) or 0 (tls_sign_off).
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), tls_sign(TBC), (255)
} ContentType;
struct {
enum { tls_sign_off(0), tls_sign_on(1), (255) } type;
} TLSSignOnOff;
The tls_sign_on_off message is sent by the client and/or server to
notify the receiving party that subsequent records will carry data
signed under the negotiated parameters.
Note: TLSSignOnOff is an independent TLS Protocol content type, and
is not actually a TLS handshake message.
2.1.1 TLS sign packet format
Hajjeh & Badra Expires June 2008 [Page 6]
Internet-Draft TLS Sign December 2007
This document defines a new packet format that encapsulates signed
data, the TLSSigntext. The packet format is shown below. The fields
are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Content-Type | Flag | Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Signed Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Content-Type
Same as TLSPlaintext.type.
Flag
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
|A R R R R R R R|
+-+-+-+-+-+-+-+-+
A = acknowledgement of receipt
R = Reserved.
When the whole signed data is delivered to the receiver, the TLS Sign
will check the signature. If the signature is valid and that the
sender requires a proof of receipt, the receiver MUST generate a
TLSSigntext packet with the bit A set to 1 (acknowledgement of
receipt). This helps the receiver of the acknowledgment of receipt in
storing the data-field for later use (see section 2.2). The data
field of that message contains the digest of the whole data receiver
by the generator of the acknowledgement of receipt. The digest is
signed before sending the result to the other side.
2.1.1. bad_sign alert
This alert is returned if a record is received with an incorrect
signature. This message is always fatal.
2.2. Storing signed data
The objective of TLS Sign is to provide both parties with evidence
that can be stored and later presented to a third party to resolve
disputes that arise if and when a communication is repudiated by one
Hajjeh & Badra Expires June 2008 [Page 7]
Internet-Draft TLS Sign December 2007
of the entities involved. This document provides the two basic types
of non-repudiation service:
O Non-repudiation with proof of origin: provides the TLS server with
evidence proving that the TLS client has sent it the signed data
at a certain time.
O Non-repudiation with proof of delivery: provides the TLS client
with evidence that the server has received the client's signed
data at a specific time.
TLS Handshake exchanges the current time and date according to the
entities internal clock. Thus, the time and date can be stored with
the signed data as a proof of communication. For B2C or B2B
transactions, non-repudiation with proof of origin and non-
repudiation with proof of receipt are both important. If the TLS
client requests a non-repudiation service with proof of receipt, the
server SHOULD verify and send back to client a signature on the hash
of signed data.
The following figure explains the different events for proving and
storing signed data [RFC4949]. RFC 4949 uses the term "critical
action" to refer to the act of communication between the two
entities. For a complete non-repudiation deployment, 6 phases should
be respected:
-------- -------- -------- -------- -------- . --------
Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: . Phase 6:
Request Generate Transfer Verify Retain . Resolve
Service Evidence Evidence Evidence Evidence . Dispute
-------- -------- -------- -------- -------- . --------
Service Critical Evidence Evidence Archive . Evidence
Request => Action => Stored => Is => Evidence . Is
Is Made Occurs For Later Tested In Case . Verified
and Use | ^ Critical . ^
Evidence v | Action Is . |
Is +-------------------+ Repudiated . |
Generated |Verifiable Evidence|------> ... . ----+
+-------------------+
1- Requesting explicit transaction evidence before sending data.
Normally, this action is taken by the SSL/TLS client
2- If the server accepts, the client will generate evidence by
signing data using his X.509 authentication certificate. Server will
go through the same process if the evidence of receipt is requested.
Hajjeh & Badra Expires June 2008 [Page 8]
Internet-Draft TLS Sign December 2007
3 - The signed data is then sent by the initiator (client or server)
and stored it locally, or by a third party, for a later use if
needed.
4 - The entity that receive the evidence process to verify the signed
data.
5- The evidence is then stored by the receiver entity for a later use
if needed.
6- In this phase, which occurs only if the critical action is
repudiated, the evidence is retrieved from storage, presented, and
verified to resolve the dispute.
With this method, the stored signed data (or evidence) can be
retrieved by both parties, presented and verified if the critical
action is repudiated.
3. Security Considerations
Security issues are discussed throughout this memo.
4. IANA Considerations
This document defines a new TLS extension "signature", assigned the
value TBD from the TLS ExtensionType registry defined in [TLSEXT].
This document defines one TLS ContentType: tls_sign(TBD). This
ContentType value is assigned from the TLS ContentType registry
defined in [TLS].
This document defines a new handshake message, certificate_sign,
whose value is to be allocated from the TLS HandshakeType registry
defined in [TLS].
The bad_sign alert that is defined in this document is assigned to
the TLS Alert registry defined in [TLS].
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[TLS] Dierks, T. and E. Rescorla, "The TLS Protocol Version
1.1", RFC 4346, April 2005.
Hajjeh & Badra Expires June 2008 [Page 9]
Internet-Draft TLS Sign December 2007
[TLSEXT] Blake-Wilson, S., et. al., "Transport Layer Security TLS)
Extensions", RFC 4366, April 2006.
[PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message
Syntax Standard," version 1.5, November 1993.
[SMIME] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
3851, July 2004.
[XMLDSIG] Eastlake, D., et. al, "(Extensible Markup Language) XML
Signature Syntax and Processing", RFC 3275, March 2002.
5.2. Informative References
[RFC4949] Shirey, R., "Internet Security Glossary", RFC 4949, August
2007.
[TLSSIGN] Hajjeh, I., Serhrouchni, A., "Integrating a signature
module in SSL/TLS, ICETE2004., ACM/IEEE, First
International Conference on E-Business and
Telecommunication Networks, Portugal, August 2004.
Author's Addresses
Ibrahim Hajjeh
INEOVATION
France
Email: hajjeh@ineovation.com
Mohamad Badra
LIMOS Laboratory - UMR6158, CNRS
France
Email: badra@isima.fr
Appendix Changelog
Changes from -01 to -02:
o Add an IANA section.
o Small clarifications to section 2.
o Add the bad_sign alert and the certificate_sign message.
Hajjeh & Badra Expires June 2008 [Page 10]
Internet-Draft TLS Sign December 2007
Changes from -00 to -01:
o Clarifications to the format of the signed data in Section 2.
o Small clarifications to TLS SIGN negotiation in Section 2.
o Added Jacques Demerjian and Mohammed Achemlal as
contributors/authors.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
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, THE IETF TRUST 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.
Copyright Statement
Copyright (C) The IETF Trust (2007).
Hajjeh & Badra Expires June 2008 [Page 11]
Internet-Draft TLS Sign December 2007
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hajjeh & Badra Expires June 2008 [Page 12]