| blob | 3dc77cbcee43c893a36f9a0ed5bf1fbe90ad8a2a |
1 TLS Working Group I. Hajjeh
2 Internet Draft INEOVATION
3 M. Badra
4 LIMOS Laboratory
5 Intended status: Experimental December 15, 2007
6 Expires: June 2008
10 TLS Sign
11 draft-hajjeh-tls-sign-04.txt
14 Status of this Memo
16 By submitting this Internet-Draft, each author represents that any
17 applicable patent or other IPR claims of which he or she is aware
18 have been or will be disclosed, and any of which he or she becomes
19 aware will be disclosed, in accordance with Section 6 of BCP 79.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF), its areas, and its working groups. Note that
23 other groups may also distribute working documents as Internet-
24 Drafts.
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than as "work in progress."
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html
37 This Internet-Draft will expire on June 15, 2007.
39 Copyright Notice
41 Copyright (C) The IETF Trust (2007).
43 Abstract
45 TLS protocol provides authentication and data protection for
46 communication between two entities. However, missing from the
47 protocol is a way to perform non-repudiation service.
52 Hajjeh & Badra Expires June 2008 [Page 1]
53 \f
54 Internet-Draft TLS Sign December 2007
57 This document defines extensions to the TLS protocol to allow it to
58 perform non-repudiation service. It is based on [TLSSIGN] and it
59 provides the client and the server the ability to sign by TLS,
60 handshake and applications data using certificates such as X.509.
62 Table of Contents
65 1. Introduction...................................................2
66 1.1. Conventions used in this document.........................3
67 2. TLS Sign overview..............................................3
68 2.1. tls sign on off protocol..................................6
69 2.1.1. bad_sign alert.......................................7
70 2.2. Storing signed data.......................................7
71 3. Security Considerations........................................9
72 4. IANA Considerations............................................9
73 5. References.....................................................9
74 5.1. Normative References......................................9
75 5.2. Informative References...................................10
76 Author's Addresses...............................................10
77 Appendix Changelog...............................................10
78 Intellectual Property Statement..................................11
79 Disclaimer of Validity...........................................11
81 1. Introduction
83 Actually, TLS is the most deployed security protocol for securing
84 exchanges. It provides end-to-end secure communications between two
85 entities with authentication and data protection. However, what is
86 missing from the protocol is a way to provide the non-repudiation
87 service.
89 This document describes how the non-repudiation service may be
90 integrated as an optional module in TLS. This is in order to provide
91 both parties with evidence that the transaction has taken place and
92 to offer a clear separation with application design and development.
94 TLS-Sign's design motivations included:
96 O TLS is application protocol-independent. Higher-level protocol can
97 operate on top of the TLS protocol transparently.
99 O TLS is a modular nature protocol. Since TLS is developed in four
100 independent protocols, the approach defined in this document can
101 be added by extending the TLS protocol and with a total reuse of
102 pre-existing TLS infrastructures and implementations.
106 Hajjeh & Badra Expires June 2008 [Page 2]
107 \f
108 Internet-Draft TLS Sign December 2007
111 O Several applications like E-Business require non-repudiation proof
112 of transactions. It is critical in these applications to have the
113 non-repudiation service that generates, distributes, validates and
114 maintains the evidence of an electronic transaction. Since TLS is
115 widely used to secure these applications exchanges, the non-
116 repudiation should be offered by TLS.
118 O Generic non-repudiation with TLS. TLS Sign provides a generic non-
119 repudiation service that can be easily used with protocols. TLS
120 Sign minimizes both design and implementation of the signature
121 service and that of the designers and implementators who wish to
122 use this module.
124 1.1. Conventions used in this document
126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
128 document are to be interpreted as described in RFC-2119 [RFC2119].
130 2. TLS Sign overview
132 TLS Sign is integrated as a higher-level module of the TLS Record
133 protocol. It is optionally used if the two entities agree. This is
134 negotiated by extending Client and Server Hello messages in the same
135 way defined in [TLSEXT].
137 In order to allow a TLS client to negotiate the TLS Sign, a new
138 extension type should be added to the Extended Client and Server
139 Hellos messages. TLS clients and servers MAY include an extension of
140 type 'signature' in the Extended Client and Server Hellos messages.
141 The 'extension_data' field of this extension contains a
142 'signature_request' where:
144 enum {
145 pkcs7(0), smime(1), xmldsig(2), (255);
146 } ContentFormat;
148 struct {
149 ContentFormat content_format;
150 SignMethod sign_meth;
151 SignType sign_type<2..2^16-1>;
152 } SignatureRequest;
154 enum {
155 ssl_client_auth_cert(0), ssl_client_auth_cert_url(1), (255);
156 } SignMethod;
160 Hajjeh & Badra Expires June 2008 [Page 3]
161 \f
162 Internet-Draft TLS Sign December 2007
165 uint8 SignType[2];
167 The client initiates the TLS Sign module by sending the
168 ExtendedClientHello including the 'signature' extension. This
169 extension contains:
171 - the SignType carrying the type of the non repudiation proof. It can
172 have one of these two values:
174 SignType non_repudiation_with_proof_of_origin = { 0x00, 0x01 };
175 SignType non_repudiation_without_proof_of_origin = { 0x00, 0x02 };
177 - the ContentFormat carrying the format of signed data. It can be
178 PKCS7 [PKCS7], S/MIME [SMIME] or XMLDSIG [XMLDSIG]
180 ContentFormat PKCS7 = { 0x00, 0xA1 };
181 ContentFormat SMIME = { 0x00, 0xA2 };
182 ContentFormat XMLDSIG = { 0x00, 0xA3 };
184 o if the value of the ContentFormat is PKCS7, then the PKCS7
185 Content_type is of type signed-data.
187 o if the value of the ContentFormat is S/MIME, then S/MIME
188 Content_type is of type SignedData
190 o if the value of the ContentFormat is XMLDSIG, then XMLDSIG
191 signatureMethod algorithms.
193 - the SignMethod carrying the signature method that is used to sign
194 the application data (e.g. X509 authentication certificate).
196 SignMethod X509 = { 0x00, 0xB1 };
198 Actually, this document uses the same certificate used in client
199 authentication. Any new signature method MAY be added in future
200 versions (e.g. delegated attributes certificates).
202 The server MAY reject the connection by sending the error alert
203 "unsupported_extension" [TLSEXT] and closing the connection.
205 The client and the server MAY use the same certificates used by the
206 Handshake protocol. Several cases are possible:
208 - If the server has an interest in getting non-repudiation data from
209 the client and that the cipher_suites list sent by the client does
210 not include any cipher_suite with signature ability, the server MUST
211 (upon reception of tls_sign_on_off protocol message not followed by a
214 Hajjeh & Badra Expires June 2008 [Page 4]
215 \f
216 Internet-Draft TLS Sign December 2007
219 certificate with a type equals to ExtendedServerHello.sign_method)
220 close the connection by sending a fatal error.
222 - If the server has an interest in getting non-repudiation data from
223 the client and that the cipher_suites list sent by the client
224 includes at least a cipher_suite with signature ability, the server
225 SHOULD select a cipher_suite with signature ability and MUST provide
226 a certificate (e.g., RSA) that MAY be used for key exchange. Further,
227 the server MUST request a certificate from the client using the TLS
228 certificate request message (e.g., an RSA or a DSS signature-capable
229 certificate). If the client does not send a certificate during the
230 TLS Handshake, the server MUST close the TLS session by sending a
231 fatal error in the case where the client sends a tls_sign_on_off
232 protocol message not followed by a certificate with a type equals to
233 ExtendedServerHello.sign_method.
235 - The client or the server MAY use a certificate different to these
236 being used by TLS Handshake. This MAY happen when the server agrees
237 in getting non-repudiation data from the client and that the type of
238 the client certificate used by TLS Handshake and the type selected by
239 the server from the list in ExtendedClientHello.sign_method are
240 different, or when the ExtendedServerHello.cipher_suite does not
241 require client and/or server certificates. In these cases, the client
242 or the server sends a new message called certificate_sign, right
243 after sending the tls_sign_on_off protocol messages. The new message
244 contains the sender's certificate in which the type is the same type
245 selected by the server from the list in
246 ExtendedClientHello.sign_method. The certificate_sign is therefore
247 used to generate signed data. It is defined as follows:
249 opaque ASN.1Cert<2^24-1>;
251 struct {
252 ASN.1Cert certificate_list<1..2^24-1>;
253 } CertificateSign;
255 The certificate_list, as defined in [TLS], is a sequence (chain) of
256 certificates. The sender's certificate MUST come first in the list.
257 If the server has no interest in getting non-repudiation data from
258 the client, it replays with an ordinary TLS ServerHello or return a
259 handshake failure alert and close the connection [TLS].
261 Client Server
263 ClientHello -------->
264 ServerHello
265 Certificate*
268 Hajjeh & Badra Expires June 2008 [Page 5]
269 \f
270 Internet-Draft TLS Sign December 2007
273 ServerKeyExchange*
274 CertificateRequest*
275 <-------- ServerHelloDone
276 Certificate*
277 ClientKeyExchange
278 CertificateVerify*
279 ChangeCipherSpec
280 Finished -------->
281 ChangeCipherSpec
282 <-------- Finished
283 TLSSignOnOff <-------------------------> TLSSignOnOff
284 CertificateSign* <----------------------> CertificateSign*
285 (Signed) Application Data <-----> (Signed) Application Data
287 * Indicates optional or situation-dependent messages that are not
288 always sent.
290 2.1. tls sign on off protocol
292 To manage the generation of evidence, new sub-protocol is added by
293 this document, called tls_sign_on_off. This protocol consists of a
294 single message that is encrypted and compressed under the established
295 connection state. This message can be sent at any time after the TLS
296 session has been established. Thus, no man in the middle can replay
297 or inject this message. It consists of a single byte of value 1
298 (tls_sign_on) or 0 (tls_sign_off).
300 enum {
301 change_cipher_spec(20), alert(21), handshake(22),
302 application_data(23), tls_sign(TBC), (255)
303 } ContentType;
305 struct {
306 enum { tls_sign_off(0), tls_sign_on(1), (255) } type;
307 } TLSSignOnOff;
309 The tls_sign_on_off message is sent by the client and/or server to
310 notify the receiving party that subsequent records will carry data
311 signed under the negotiated parameters.
313 Note: TLSSignOnOff is an independent TLS Protocol content type, and
314 is not actually a TLS handshake message.
316 2.1.1 TLS sign packet format
322 Hajjeh & Badra Expires June 2008 [Page 6]
323 \f
324 Internet-Draft TLS Sign December 2007
327 This document defines a new packet format that encapsulates signed
328 data, the TLSSigntext. The packet format is shown below. The fields
329 are transmitted from left to right.
331 0 1 2 3
332 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
333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
334 | Content-Type | Flag | Version |
335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
336 | Length | Signed Data ...
337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
339 Content-Type
341 Same as TLSPlaintext.type.
343 Flag
345 0 1 2 3 4 5 6 7 8
346 +-+-+-+-+-+-+-+-+
347 |A R R R R R R R|
348 +-+-+-+-+-+-+-+-+
350 A = acknowledgement of receipt
351 R = Reserved.
353 When the whole signed data is delivered to the receiver, the TLS Sign
354 will check the signature. If the signature is valid and that the
355 sender requires a proof of receipt, the receiver MUST generate a
356 TLSSigntext packet with the bit A set to 1 (acknowledgement of
357 receipt). This helps the receiver of the acknowledgment of receipt in
358 storing the data-field for later use (see section 2.2). The data
359 field of that message contains the digest of the whole data receiver
360 by the generator of the acknowledgement of receipt. The digest is
361 signed before sending the result to the other side.
363 2.1.1. bad_sign alert
365 This alert is returned if a record is received with an incorrect
366 signature. This message is always fatal.
368 2.2. Storing signed data
370 The objective of TLS Sign is to provide both parties with evidence
371 that can be stored and later presented to a third party to resolve
372 disputes that arise if and when a communication is repudiated by one
376 Hajjeh & Badra Expires June 2008 [Page 7]
377 \f
378 Internet-Draft TLS Sign December 2007
381 of the entities involved. This document provides the two basic types
382 of non-repudiation service:
384 O Non-repudiation with proof of origin: provides the TLS server with
385 evidence proving that the TLS client has sent it the signed data
386 at a certain time.
388 O Non-repudiation with proof of delivery: provides the TLS client
389 with evidence that the server has received the client's signed
390 data at a specific time.
392 TLS Handshake exchanges the current time and date according to the
393 entities internal clock. Thus, the time and date can be stored with
394 the signed data as a proof of communication. For B2C or B2B
395 transactions, non-repudiation with proof of origin and non-
396 repudiation with proof of receipt are both important. If the TLS
397 client requests a non-repudiation service with proof of receipt, the
398 server SHOULD verify and send back to client a signature on the hash
399 of signed data.
401 The following figure explains the different events for proving and
402 storing signed data [RFC4949]. RFC 4949 uses the term "critical
403 action" to refer to the act of communication between the two
404 entities. For a complete non-repudiation deployment, 6 phases should
405 be respected:
407 -------- -------- -------- -------- -------- . --------
408 Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: . Phase 6:
409 Request Generate Transfer Verify Retain . Resolve
410 Service Evidence Evidence Evidence Evidence . Dispute
411 -------- -------- -------- -------- -------- . --------
413 Service Critical Evidence Evidence Archive . Evidence
414 Request => Action => Stored => Is => Evidence . Is
415 Is Made Occurs For Later Tested In Case . Verified
416 and Use | ^ Critical . ^
417 Evidence v | Action Is . |
418 Is +-------------------+ Repudiated . |
419 Generated |Verifiable Evidence|------> ... . ----+
420 +-------------------+
422 1- Requesting explicit transaction evidence before sending data.
423 Normally, this action is taken by the SSL/TLS client
425 2- If the server accepts, the client will generate evidence by
426 signing data using his X.509 authentication certificate. Server will
427 go through the same process if the evidence of receipt is requested.
430 Hajjeh & Badra Expires June 2008 [Page 8]
431 \f
432 Internet-Draft TLS Sign December 2007
435 3 - The signed data is then sent by the initiator (client or server)
436 and stored it locally, or by a third party, for a later use if
437 needed.
439 4 - The entity that receive the evidence process to verify the signed
440 data.
442 5- The evidence is then stored by the receiver entity for a later use
443 if needed.
445 6- In this phase, which occurs only if the critical action is
446 repudiated, the evidence is retrieved from storage, presented, and
447 verified to resolve the dispute.
449 With this method, the stored signed data (or evidence) can be
450 retrieved by both parties, presented and verified if the critical
451 action is repudiated.
453 3. Security Considerations
455 Security issues are discussed throughout this memo.
457 4. IANA Considerations
459 This document defines a new TLS extension "signature", assigned the
460 value TBD from the TLS ExtensionType registry defined in [TLSEXT].
462 This document defines one TLS ContentType: tls_sign(TBD). This
463 ContentType value is assigned from the TLS ContentType registry
464 defined in [TLS].
466 This document defines a new handshake message, certificate_sign,
467 whose value is to be allocated from the TLS HandshakeType registry
468 defined in [TLS].
470 The bad_sign alert that is defined in this document is assigned to
471 the TLS Alert registry defined in [TLS].
473 5. References
475 5.1. Normative References
477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
478 Requirement Levels", BCP 14, RFC 2119, March 1997.
480 [TLS] Dierks, T. and E. Rescorla, "The TLS Protocol Version
481 1.1", RFC 4346, April 2005.
484 Hajjeh & Badra Expires June 2008 [Page 9]
485 \f
486 Internet-Draft TLS Sign December 2007
489 [TLSEXT] Blake-Wilson, S., et. al., "Transport Layer Security TLS)
490 Extensions", RFC 4366, April 2006.
492 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message
493 Syntax Standard," version 1.5, November 1993.
495 [SMIME] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
496 3851, July 2004.
498 [XMLDSIG] Eastlake, D., et. al, "(Extensible Markup Language) XML
499 Signature Syntax and Processing", RFC 3275, March 2002.
501 5.2. Informative References
503 [RFC4949] Shirey, R., "Internet Security Glossary", RFC 4949, August
504 2007.
506 [TLSSIGN] Hajjeh, I., Serhrouchni, A., "Integrating a signature
507 module in SSL/TLS, ICETE2004., ACM/IEEE, First
508 International Conference on E-Business and
509 Telecommunication Networks, Portugal, August 2004.
511 Author's Addresses
513 Ibrahim Hajjeh
514 INEOVATION
515 France
517 Email: hajjeh@ineovation.com
520 Mohamad Badra
521 LIMOS Laboratory - UMR6158, CNRS
522 France
524 Email: badra@isima.fr
527 Appendix Changelog
529 Changes from -01 to -02:
531 o Add an IANA section.
533 o Small clarifications to section 2.
535 o Add the bad_sign alert and the certificate_sign message.
538 Hajjeh & Badra Expires June 2008 [Page 10]
539 \f
540 Internet-Draft TLS Sign December 2007
543 Changes from -00 to -01:
545 o Clarifications to the format of the signed data in Section 2.
547 o Small clarifications to TLS SIGN negotiation in Section 2.
549 o Added Jacques Demerjian and Mohammed Achemlal as
550 contributors/authors.
552 Intellectual Property Statement
554 The IETF takes no position regarding the validity or scope of any
555 Intellectual Property Rights or other rights that might be claimed to
556 pertain to the implementation or use of the technology described in
557 this document or the extent to which any license under such rights
558 might or might not be available; nor does it represent that it has
559 made any independent effort to identify any such rights. Information
560 on the procedures with respect to rights in RFC documents can be
561 found in BCP 78 and BCP 79.
563 Copies of IPR disclosures made to the IETF Secretariat and any
564 assurances of licenses to be made available, or the result of an
565 attempt made to obtain a general license or permission for the use of
566 such proprietary rights by implementers or users of this
567 specification can be obtained from the IETF on-line IPR repository at
568 http://www.ietf.org/ipr.
570 The IETF invites any interested party to bring to its attention any
571 copyrights, patents or patent applications, or other proprietary
572 rights that may cover technology that may be required to implement
573 this standard. Please address the information to the IETF at
574 ietf-ipr@ietf.org.
576 Disclaimer of Validity
578 This document and the information contained herein are provided on an
579 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
580 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
581 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
582 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
583 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
584 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
586 Copyright Statement
588 Copyright (C) The IETF Trust (2007).
592 Hajjeh & Badra Expires June 2008 [Page 11]
593 \f
594 Internet-Draft TLS Sign December 2007
597 This document is subject to the rights, licenses and restrictions
598 contained in BCP 78, and except as set forth therein, the authors
599 retain all their rights.
601 Acknowledgment
603 Funding for the RFC Editor function is currently provided by the
604 Internet Society.
646 Hajjeh & Badra Expires June 2008 [Page 12]
647 \f