idnits 2.17.1 draft-hajjeh-tls-sign-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 484. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 491. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 497. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([TLSSIGN]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 15, 2007) is 5976 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2' on line 139 ** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4366 (ref. 'TLSEXT') (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 3851 (ref. 'SMIME') (Obsoleted by RFC 5751) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 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 8 TLS Sign 9 draft-hajjeh-tls-sign-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on June 15, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 TLS protocol provides authentication and data protection for 43 communication between two entities. However, missing from the 44 protocol is a way to perform non-repudiation service. 46 This document defines extensions to the TLS protocol to allow it to 47 perform non-repudiation service. It is based on [TLSSIGN] and it 48 provides the client and the server the ability to sign by TLS, 49 handshake and applications data using certificates such as X.509. 51 Table of Contents 53 1. Introduction...................................................2 54 1.1. Conventions used in this document.........................3 55 2. TLS Sign overview..............................................3 56 2.1. tls sign on off protocol..................................6 57 2.1.1. bad_sign alert.......................................7 58 2.2. Storing signed data.......................................7 59 3. Security Considerations........................................9 60 4. IANA Considerations............................................9 61 5. References.....................................................9 62 5.1. Normative References......................................9 63 5.2. Informative References...................................10 64 Author's Addresses...............................................10 65 Appendix Changelog...............................................10 66 Intellectual Property Statement..................................11 67 Disclaimer of Validity...........................................11 69 1. Introduction 71 Actually, TLS is the most deployed security protocol for securing 72 exchanges. It provides end-to-end secure communications between two 73 entities with authentication and data protection. However, what is 74 missing from the protocol is a way to provide the non-repudiation 75 service. 77 This document describes how the non-repudiation service may be 78 integrated as an optional module in TLS. This is in order to provide 79 both parties with evidence that the transaction has taken place and 80 to offer a clear separation with application design and development. 82 TLS-Sign's design motivations included: 84 O TLS is application protocol-independent. Higher-level protocol can 85 operate on top of the TLS protocol transparently. 87 O TLS is a modular nature protocol. Since TLS is developed in four 88 independent protocols, the approach defined in this document can 89 be added by extending the TLS protocol and with a total reuse of 90 pre-existing TLS infrastructures and implementations. 92 O Several applications like E-Business require non-repudiation proof 93 of transactions. It is critical in these applications to have the 94 non-repudiation service that generates, distributes, validates and 95 maintains the evidence of an electronic transaction. Since TLS is 96 widely used to secure these applications exchanges, the non- 97 repudiation should be offered by TLS. 99 O Generic non-repudiation with TLS. TLS Sign provides a generic non- 100 repudiation service that can be easily used with protocols. TLS 101 Sign minimizes both design and implementation of the signature 102 service and that of the designers and implementators who wish to 103 use this module. 105 1.1. Conventions used in this document 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC-2119 [RFC2119]. 111 2. TLS Sign overview 113 TLS Sign is integrated as a higher-level module of the TLS Record 114 protocol. It is optionally used if the two entities agree. This is 115 negotiated by extending Client and Server Hello messages in the same 116 way defined in [TLSEXT]. 118 In order to allow a TLS client to negotiate the TLS Sign, a new 119 extension type should be added to the Extended Client and Server 120 Hellos messages. TLS clients and servers MAY include an extension of 121 type 'signature' in the Extended Client and Server Hellos messages. 122 The 'extension_data' field of this extension contains a 123 'signature_request' where: 125 enum { 126 pkcs7(0), smime(1), xmldsig(2), (255); 127 } ContentFormat; 129 struct { 130 ContentFormat content_format; 131 SignMethod sign_meth; 132 SignType sign_type<2..2^16-1>; 133 } SignatureRequest; 135 enum { 136 ssl_client_auth_cert(0), ssl_client_auth_cert_url(1), (255); 137 } SignMethod; 139 uint8 SignType[2]; 141 The client initiates the TLS Sign module by sending the 142 ExtendedClientHello including the 'signature' extension. This 143 extension contains: 145 - the SignType carrying the type of the non repudiation proof. It can 146 have one of these two values: 148 SignType non_repudiation_with_proof_of_origin = { 0x00, 0x01 }; 149 SignType non_repudiation_without_proof_of_origin = { 0x00, 0x02 }; 151 - the ContentFormat carrying the format of signed data. It can be 152 PKCS7 [PKCS7], S/MIME [SMIME] or XMLDSIG [XMLDSIG] 154 ContentFormat PKCS7 = { 0x00, 0xA1 }; 155 ContentFormat SMIME = { 0x00, 0xA2 }; 156 ContentFormat XMLDSIG = { 0x00, 0xA3 }; 158 o if the value of the ContentFormat is PKCS7, then the PKCS7 159 Content_type is of type signed-data. 161 o if the value of the ContentFormat is S/MIME, then S/MIME 162 Content_type is of type SignedData 164 o if the value of the ContentFormat is XMLDSIG, then XMLDSIG 165 signatureMethod algorithms. 167 - the SignMethod carrying the signature method that is used to sign 168 the application data (e.g. X509 authentication certificate). 170 SignMethod X509 = { 0x00, 0xB1 }; 172 Actually, this document uses the same certificate used in client 173 authentication. Any new signature method MAY be added in future 174 versions (e.g. delegated attributes certificates). 176 The server MAY reject the connection by sending the error alert 177 "unsupported_extension" [TLSEXT] and closing the connection. 179 The client and the server MAY use the same certificates used by the 180 Handshake protocol. Several cases are possible: 182 - If the server has an interest in getting non-repudiation data from 183 the client and that the cipher_suites list sent by the client does 184 not include any cipher_suite with signature ability, the server MUST 185 (upon reception of tls_sign_on_off protocol message not followed by a 186 certificate with a type equals to ExtendedServerHello.sign_method) 187 close the connection by sending a fatal error. 189 - If the server has an interest in getting non-repudiation data from 190 the client and that the cipher_suites list sent by the client 191 includes at least a cipher_suite with signature ability, the server 192 SHOULD select a cipher_suite with signature ability and MUST provide 193 a certificate (e.g., RSA) that MAY be used for key exchange. Further, 194 the server MUST request a certificate from the client using the TLS 195 certificate request message (e.g., an RSA or a DSS signature-capable 196 certificate). If the client does not send a certificate during the 197 TLS Handshake, the server MUST close the TLS session by sending a 198 fatal error in the case where the client sends a tls_sign_on_off 199 protocol message not followed by a certificate with a type equals to 200 ExtendedServerHello.sign_method. 202 - The client or the server MAY use a certificate different to these 203 being used by TLS Handshake. This MAY happen when the server agrees 204 in getting non-repudiation data from the client and that the type of 205 the client certificate used by TLS Handshake and the type selected by 206 the server from the list in ExtendedClientHello.sign_method are 207 different, or when the ExtendedServerHello.cipher_suite does not 208 require client and/or server certificates. In these cases, the client 209 or the server sends a new message called certificate_sign, right 210 after sending the tls_sign_on_off protocol messages. The new message 211 contains the sender's certificate in which the type is the same type 212 selected by the server from the list in 213 ExtendedClientHello.sign_method. The certificate_sign is therefore 214 used to generate signed data. It is defined as follows: 216 opaque ASN.1Cert<2^24-1>; 218 struct { 219 ASN.1Cert certificate_list<1..2^24-1>; 220 } CertificateSign; 222 The certificate_list, as defined in [TLS], is a sequence (chain) of 223 certificates. The sender's certificate MUST come first in the list. 224 If the server has no interest in getting non-repudiation data from 225 the client, it replays with an ordinary TLS ServerHello or return a 226 handshake failure alert and close the connection [TLS]. 228 Client Server 230 ClientHello --------> 231 ServerHello 232 Certificate* 234 ServerKeyExchange* 235 CertificateRequest* 236 <-------- ServerHelloDone 237 Certificate* 238 ClientKeyExchange 239 CertificateVerify* 240 ChangeCipherSpec 241 Finished --------> 242 ChangeCipherSpec 243 <-------- Finished 244 TLSSignOnOff <-------------------------> TLSSignOnOff 245 CertificateSign* <----------------------> CertificateSign* 246 (Signed) Application Data <-----> (Signed) Application Data 248 * Indicates optional or situation-dependent messages that are not 249 always sent. 251 2.1. tls sign on off protocol 253 To manage the generation of evidence, new sub-protocol is added by 254 this document, called tls_sign_on_off. This protocol consists of a 255 single message that is encrypted and compressed under the established 256 connection state. This message can be sent at any time after the TLS 257 session has been established. Thus, no man in the middle can replay 258 or inject this message. It consists of a single byte of value 1 259 (tls_sign_on) or 0 (tls_sign_off). 261 enum { 262 change_cipher_spec(20), alert(21), handshake(22), 263 application_data(23), tls_sign(TBC), (255) 264 } ContentType; 266 struct { 267 enum { tls_sign_off(0), tls_sign_on(1), (255) } type; 268 } TLSSignOnOff; 270 The tls_sign_on_off message is sent by the client and/or server to 271 notify the receiving party that subsequent records will carry data 272 signed under the negotiated parameters. 274 Note: TLSSignOnOff is an independent TLS Protocol content type, and 275 is not actually a TLS handshake message. 277 2.1.1 TLS sign packet format 278 This document defines a new packet format that encapsulates signed 279 data, the TLSSigntext. The packet format is shown below. The fields 280 are transmitted from left to right. 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Content-Type | Flag | Version | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Length | Signed Data ... 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Content-Type 292 Same as TLSPlaintext.type. 294 Flag 296 0 1 2 3 4 5 6 7 8 297 +-+-+-+-+-+-+-+-+ 298 |A R R R R R R R| 299 +-+-+-+-+-+-+-+-+ 301 A = acknowledgement of receipt 302 R = Reserved. 304 When the whole signed data is delivered to the receiver, the TLS Sign 305 will check the signature. If the signature is valid and that the 306 sender requires a proof of receipt, the receiver MUST generate a 307 TLSSigntext packet with the bit A set to 1 (acknowledgement of 308 receipt). This helps the receiver of the acknowledgment of receipt in 309 storing the data-field for later use (see section 2.2). The data 310 field of that message contains the digest of the whole data receiver 311 by the generator of the acknowledgement of receipt. The digest is 312 signed before sending the result to the other side. 314 2.1.1. bad_sign alert 316 This alert is returned if a record is received with an incorrect 317 signature. This message is always fatal. 319 2.2. Storing signed data 321 The objective of TLS Sign is to provide both parties with evidence 322 that can be stored and later presented to a third party to resolve 323 disputes that arise if and when a communication is repudiated by one 324 of the entities involved. This document provides the two basic types 325 of non-repudiation service: 327 O Non-repudiation with proof of origin: provides the TLS server with 328 evidence proving that the TLS client has sent it the signed data 329 at a certain time. 331 O Non-repudiation with proof of delivery: provides the TLS client 332 with evidence that the server has received the client's signed 333 data at a specific time. 335 TLS Handshake exchanges the current time and date according to the 336 entities internal clock. Thus, the time and date can be stored with 337 the signed data as a proof of communication. For B2C or B2B 338 transactions, non-repudiation with proof of origin and non- 339 repudiation with proof of receipt are both important. If the TLS 340 client requests a non-repudiation service with proof of receipt, the 341 server SHOULD verify and send back to client a signature on the hash 342 of signed data. 344 The following figure explains the different events for proving and 345 storing signed data [RFC4949]. RFC 4949 uses the term "critical 346 action" to refer to the act of communication between the two 347 entities. For a complete non-repudiation deployment, 6 phases should 348 be respected: 350 -------- -------- -------- -------- -------- . -------- 351 Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: . Phase 6: 352 Request Generate Transfer Verify Retain . Resolve 353 Service Evidence Evidence Evidence Evidence . Dispute 354 -------- -------- -------- -------- -------- . -------- 356 Service Critical Evidence Evidence Archive . Evidence 357 Request => Action => Stored => Is => Evidence . Is 358 Is Made Occurs For Later Tested In Case . Verified 359 and Use | ^ Critical . ^ 360 Evidence v | Action Is . | 361 Is +-------------------+ Repudiated . | 362 Generated |Verifiable Evidence|------> ... . ----+ 363 +-------------------+ 365 1- Requesting explicit transaction evidence before sending data. 366 Normally, this action is taken by the SSL/TLS client 368 2- If the server accepts, the client will generate evidence by 369 signing data using his X.509 authentication certificate. Server will 370 go through the same process if the evidence of receipt is requested. 372 3 - The signed data is then sent by the initiator (client or server) 373 and stored it locally, or by a third party, for a later use if 374 needed. 376 4 - The entity that receive the evidence process to verify the signed 377 data. 379 5- The evidence is then stored by the receiver entity for a later use 380 if needed. 382 6- In this phase, which occurs only if the critical action is 383 repudiated, the evidence is retrieved from storage, presented, and 384 verified to resolve the dispute. 386 With this method, the stored signed data (or evidence) can be 387 retrieved by both parties, presented and verified if the critical 388 action is repudiated. 390 3. Security Considerations 392 Security issues are discussed throughout this memo. 394 4. IANA Considerations 396 This document defines a new TLS extension "signature", assigned the 397 value TBD from the TLS ExtensionType registry defined in [TLSEXT]. 399 This document defines one TLS ContentType: tls_sign(TBD). This 400 ContentType value is assigned from the TLS ContentType registry 401 defined in [TLS]. 403 This document defines a new handshake message, certificate_sign, 404 whose value is to be allocated from the TLS HandshakeType registry 405 defined in [TLS]. 407 The bad_sign alert that is defined in this document is assigned to 408 the TLS Alert registry defined in [TLS]. 410 5. References 412 5.1. Normative References 414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 415 Requirement Levels", BCP 14, RFC 2119, March 1997. 417 [TLS] Dierks, T. and E. Rescorla, "The TLS Protocol Version 418 1.1", RFC 4346, April 2005. 420 [TLSEXT] Blake-Wilson, S., et. al., "Transport Layer Security TLS) 421 Extensions", RFC 4366, April 2006. 423 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message 424 Syntax Standard," version 1.5, November 1993. 426 [SMIME] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 427 3851, July 2004. 429 [XMLDSIG] Eastlake, D., et. al, "(Extensible Markup Language) XML 430 Signature Syntax and Processing", RFC 3275, March 2002. 432 5.2. Informative References 434 [RFC4949] Shirey, R., "Internet Security Glossary", RFC 4949, August 435 2007. 437 [TLSSIGN] Hajjeh, I., Serhrouchni, A., "Integrating a signature 438 module in SSL/TLS, ICETE2004., ACM/IEEE, First 439 International Conference on E-Business and 440 Telecommunication Networks, Portugal, August 2004. 442 Author's Addresses 444 Ibrahim Hajjeh 445 INEOVATION 446 France 448 Email: hajjeh@ineovation.com 450 Mohamad Badra 451 LIMOS Laboratory - UMR6158, CNRS 452 France 454 Email: badra@isima.fr 456 Appendix Changelog 458 Changes from -01 to -02: 460 o Add an IANA section. 462 o Small clarifications to section 2. 464 o Add the bad_sign alert and the certificate_sign message. 466 Changes from -00 to -01: 468 o Clarifications to the format of the signed data in Section 2. 470 o Small clarifications to TLS SIGN negotiation in Section 2. 472 o Added Jacques Demerjian and Mohammed Achemlal as 473 contributors/authors. 475 Intellectual Property Statement 477 The IETF takes no position regarding the validity or scope of any 478 Intellectual Property Rights or other rights that might be claimed to 479 pertain to the implementation or use of the technology described in 480 this document or the extent to which any license under such rights 481 might or might not be available; nor does it represent that it has 482 made any independent effort to identify any such rights. Information 483 on the procedures with respect to rights in RFC documents can be 484 found in BCP 78 and BCP 79. 486 Copies of IPR disclosures made to the IETF Secretariat and any 487 assurances of licenses to be made available, or the result of an 488 attempt made to obtain a general license or permission for the use of 489 such proprietary rights by implementers or users of this 490 specification can be obtained from the IETF on-line IPR repository at 491 http://www.ietf.org/ipr. 493 The IETF invites any interested party to bring to its attention any 494 copyrights, patents or patent applications, or other proprietary 495 rights that may cover technology that may be required to implement 496 this standard. Please address the information to the IETF at 497 ietf-ipr@ietf.org. 499 Disclaimer of Validity 501 This document and the information contained herein are provided on an 502 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 503 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 504 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 505 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 506 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 507 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 509 Copyright Statement 511 Copyright (C) The IETF Trust (2007). 513 This document is subject to the rights, licenses and restrictions 514 contained in BCP 78, and except as set forth therein, the authors 515 retain all their rights. 517 Acknowledgment 519 Funding for the RFC Editor function is currently provided by the 520 Internet Society.