idnits 2.17.1 draft-hajjeh-tls-sign-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 480. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 487. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 493. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([TLSSign]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 103: '...ents and servers MAY include an extens...' RFC 2119 keyword, line 155: '...signature method MAY be added in futur...' RFC 2119 keyword, line 158: '... The server MAY reject the connectio...' RFC 2119 keyword, line 161: '...t and the server MAY or MAY NOT use th...' RFC 2119 keyword, line 166: '...ith signature ability, the server MUST...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The client and the server MAY or MAY NOT use the same certificates used by the Handshake protocol. Several cases are possible: -- 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 (June 2007) is 6131 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '2' on line 122 == Missing Reference: 'ChangeCipherSpec' is mentioned on line 224, but not defined == Missing Reference: 'TLSEXT' is mentioned on line 381, but not defined ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3546 (ref. 'TLSExt') (Obsoleted by RFC 4366) -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS7' -- Possible downref: Non-RFC (?) normative reference: ref. 'TLSSign' ** Obsolete normative reference: RFC 2828 (Obsoleted by RFC 4949) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force I. Hajjeh 3 INTERNET DRAFT ESRGroups 4 M. Badra 5 LIMOS Laboratory 7 Expires: November 2007 June 2007 9 TLS Sign 10 12 Status 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on November 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 TLS protocol provides authentication and data protection for 44 communication between two entities. However, missing from the 45 protocol is a way to perform non-repudiation service. 47 This document defines extensions to the TLS protocol to allow it to 48 perform non-repudiation service. It is based on [TLSSign] and it 49 provides the client and the server the ability to sign by TLS, 50 handshake and applications data using certificates such as X.509. 52 1 Introduction 54 Actually, TLS is the most deployed security protocol for securing 55 exchanges. It provides end-to-end secure communications between two 56 entities with authentication and data protection. However, what is 57 missing from the protocol is a way to provide the non-repudiation 58 service. 60 This document describes how the non-repudiation service may be 61 integrated as an optional module in TLS. This is in order to provide 62 both parties with evidence that the transaction has taken place and 63 to offer a clear separation with application design and development. 65 TLS-Sign's design motivations included: 67 o TLS is application protocol-independent. Higher-level protocol 68 can operate on top of the TLS protocol transparently. 70 o TLS is a modular nature protocol. Since TLS is developed in four 71 independent protocols, the approach defined in this document can 72 be added by extending the TLS protocol and with a total 73 reuse of pre-existing TLS infrastructures and implementations. 75 o Several applications like E-Business require non-repudiation 76 proof of transactions. It is critical in these applications to 77 have the non-repudiation service that generates, distributes, 78 validates and maintains the evidence of an electronic 79 transaction. Since TLS is widely used to secure these 80 applications exchanges, the non-repudiation should be offered by 81 TLS. 83 o Generic non-repudiation with TLS. TLS Sign provides a generic 84 non-repudiation service that can be easily used with protocols. 85 TLS Sign minimizes both design and implementation of the 86 signature service and that of the designers and implementators 87 who wish to use this module. 89 1.2 Requirements language 91 The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document 92 are to be interpreted as described in RFC-2119. 94 2 TLS Sign overview 96 TLS Sign is integrated as a higher-level module of the TLS Record 97 protocol. It is optionally used if the two entities agree. This is 98 negotiated by extending Client and Server Hello messages in the same 99 way defined in [TLSExt]. 101 In order to allow a TLS client to negotiate the TLS Sign, a new 102 extension type should be added to the Extended Client and Server 103 Hellos messages. TLS clients and servers MAY include an extension of 104 type 'signature' in the Extended Client and Server Hellos messages. 105 The 'extension_data' field of this extension contains a 106 'signature_request' where: 108 enum { 109 pkcs7(0), smime(1), xmldsig(2), (255); 110 } ContentFormat; 112 struct { 113 ContentFormat content_format; 114 SignMethod sign_meth; 115 SignType sign_type<2..2^16-1>; 116 } SignatureRequest; 118 enum { 119 ssl_client_auth_cert(0), ssl_client_auth_cert_url(1), (255); 120 } SignMethod; 122 uint8 SignType[2]; 124 The client initiates the TLS Sign module by sending the 125 ExtendedClientHello including the 'signature' extension. This 126 extension contains: 128 - the SignType carrying the type of the non repudiation proof. It 129 can have one of these two values: 131 SignType non_repudiation_with_proof_of_origin = { 0x00, 0x01 }; 132 SignType non_repudiation_without_proof_of_origin = { 0x00, 0x02 }; 134 - the ContentFormat carrying the format of signed data. It can be 135 PKCS7 [PKCS7], S/MIME [S/MIME] or XMLDSIG [XMLDSIG] 137 ContentFormat PKCS7 = { 0x00, 0xA1 }; 138 ContentFormat SMIME = { 0x00, 0xA2 }; 139 ContentFormat XMLDSIG = { 0x00, 0xA3 }; 141 o if the value of the ContentFormat is PKCS7, then the PKCS7 142 Content_type is of type signed-data. 144 o if the value of the ContentFormat is S/MIME, then S/MIME 145 Content_type is of type SignedData 147 o if the value of the ContentFormat is XMLDSIG, then XMLDSIG 148 signatureMethod algorithms. 150 - the SignMethod carrying the signature method that is used to sign 151 the application data (e.g. X509 authentication certificate). 153 SignMethod X509 = { 0x00, 0xB1 }; 154 Actually, this document uses the same certificate used in client 155 authentication. Any new signature method MAY be added in future 156 versions (e.g. delegated attributes certificates). 158 The server MAY reject the connection by sending the error alert 159 "unsupported_extension" [TLSExt] and closing the connection. 161 The client and the server MAY or MAY NOT use the same certificates 162 used by the Handshake protocol. Several cases are possible: 164 - If the server has an interest in getting non-repudiation data from 165 the client and that the cipher_suites list sent by the client does 166 not include any cipher_suite with signature ability, the server MUST 167 (upon reception of tls_sign_on_off protocol message not followed by 168 a certificate with a type equals to ExtendedServerHello.sign_method) 169 close the connection by sending a fatal error. 171 - If the server has an interest in getting non-repudiation data from 172 the client and that the cipher_suites list sent by the client 173 includes at least a cipher_suite with signature ability, the server 174 SHOULD select a cipher_suite with signature ability and MUST provide 175 a certificate (e.g., RSA) that MAY be used for key exchange. 176 Further, the server MUST request a certificate from the client using 177 the TLS certificate request message (e.g., an RSA or a DSS 178 signature-capable certificate). If the client does not send a 179 certificate during the TLS Handshake, the server MUST close the TLS 180 session by sending a fatal error in the case where the client sends 181 a tls_sign_on_off protocol message not followed by a certificate 182 with a type equals to ExtendedServerHello.sign_method. 184 - The client or the server MAY use a certificate different to these 185 being used by TLS Handshake. This MAY happen when the server agrees 186 in getting non-repudiation data from the client and that the type of 187 the client certificate used by TLS Handshake and the type selected 188 by the server from the list in ExtendedClientHello.sign_method are 189 different, or when the ExtendedServerHello.cipher_suite does not 190 require client and/or server certificates. In these cases, the 191 client or the server sends a new message called certificate_sign, 192 right after sending the tls_sign_on_off protocol messages. The new 193 message contains the sender's certificate in which the type is the 194 same type selected by the server from the list in 195 ExtendedClientHello.sign_method. The certificate_sign is therefore 196 used to generate signed data. It is defined as follows: 198 opaque ASN.1Cert<2^24-1>; 200 struct { 201 ASN.1Cert certificate_list<1..2^24-1>; 202 } CertificateSign; 203 The certificate_list, as defined in [TLS], is a sequence (chain) of 204 certificates. The sender's certificate MUST come first in the list. 206 If the server has no interest in getting non-repudiation data from 207 the client, it replays with an ordinary TLS ServerHello or return a 208 handshake failure alert and close the connection [TLS]. 210 Client Server 211 ------ ------ 213 ClientHello --------> 214 ServerHello 215 Certificate* 216 ServerKeyExchange* 217 CertificateRequest* 218 <-------- ServerHelloDone 219 Certificate* 220 ClientKeyExchange 221 CertificateVerify* 222 [ChangeCipherSpec] 223 Finished --------> 224 [ChangeCipherSpec] 225 <-------- Finished 227 TLSSignOnOff <--------------------------> TLSSignOnOff 229 CertificateSign* <-----------------------> CertificateSign* 231 (Signed) Application Data <----> (Signed) Application Data 233 * Indicates optional or situation-dependent messages that are not 234 always sent. 236 2.1 tls sign on off protocol 238 To manage the generation of evidence, new sub-protocol is added by 239 this document, called tls_sign_on_off. This protocol consists of a 240 single message that is encrypted and compressed under the 241 established connection state. This message can be sent at any time 242 after the TLS session has been established. Thus, no man in the 243 middle can replay or inject this message. It consists of a single 244 byte of value 1 (tls_sign_on) or 0 (tls_sign_off). 246 enum { 247 change_cipher_spec(20), alert(21), handshake(22), 248 application_data(23), tls_sign(TBC), (255) 249 } ContentType; 251 struct { 252 enum { tls_sign_off(0), tls_sign_on(1), (255) } type; 253 } TLSSignOnOff; 254 The tls_sign_on_off message is sent by the client and/or server to 255 notify the receiving party that subsequent records will carry data 256 signed under the negotiated parameters. 258 Note: TLSSignOnOff is an independent TLS Protocol content type, and 259 is not actually a TLS handshake message. 261 2.1.1 TLS sign packet format 263 This document defines a new packet format that encapsulates signed 264 data, the TLSSigntext. The packet format is shown below. The fields 265 are transmitted from left to right. 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Content-Type | Flag | Version | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Length | Signed Data ... 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Content-Type 277 Same as TLSPlaintext.type. 279 Flag 281 0 1 2 3 4 5 6 7 8 282 +-+-+-+-+-+-+-+-+ 283 |A R R R R R R R| 284 +-+-+-+-+-+-+-+-+ 286 A = acknowledgement of receipt 287 R = Reserved 289 When the whole signed data is delivered to the receiver, the TLS 290 Sign will check the signature. If the signature is valid and that 291 the sender requires a proof of receipt, the receiver MUST generate a 292 TLSSigntext packet with the bit A set to 1 (acknowledgement of 293 receipt). This helps the receiver of the acknowledgment of receipt 294 in storing the data-field for later use (see section 2.2). The data- 295 field of that message contains the digest of the whole data receiver 296 by the generator of the acknowledgement of receipt. The digest is 297 signed before sending the result to the other side. 299 2.1.3 bad_sign alert 301 This alert is returned if a record is received with an incorrect 302 signature. This message is always fatal. 304 2.2 Storing signed data 306 The objective of TLS Sign is to provide both parties with evidence 307 that can be stored and later presented to a third party to resolve 308 disputes that arise if and when a communication is repudiated by one 309 of the entities involved. This document provides the two basic types 310 of non-repudiation service: 312 o Non-repudiation with proof of origin: provides the TLS server 313 with evidence proving that the TLS client has sent it the signed 314 data at a certain time. 316 o Non-repudiation with proof of delivery: provides the TLS client 317 with evidence that the server has received the client's signed 318 data at a specific time. 320 TLS Handshake exchanges the current time and date according to the 321 entities internal clock. Thus, the time and date can be stored with 322 the signed data as a proof of communication. For B2C or B2B 323 transactions, non-repudiation with proof of origin and non- 324 repudiation with proof of receipt are both important. If the TLS 325 client requests a non-repudiation service with proof of receipt, the 326 server SHOULD verify and send back to client a signature on the hash 327 of signed data. 329 The following figure explains the different events for proving and 330 storing signed data [RFC2828]. RFC 2828 uses the term "critical 331 action" to refer to the act of communication between the two 332 entities. For a complete non-repudiation deployment, 6 phases should 333 be respected: 335 -------- -------- -------- -------- -------- -------- 336 Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: Phase 6: 337 Request Generate Transfer Verify Retain Resolve 338 Service Evidence Evidence Evidence Evidence Dispute 339 -------- -------- -------- -------- -------- -------- 340 Service Critical Evidence Evidence Archive Evidence 341 Request => Action => Stored => Is => Evidence Is 342 Is Made Occurs For Later Tested In Case Verified 343 and Use | ^ Critical ^ 344 Evidence v | Action Is | 345 Is +-------------------+ Repudiated | 346 Generated |Verifiable Evidence|------> ----+ 347 +-------------------+ 349 1- Requesting explicit transaction evidence before sending data. 350 Normally, this action is taken by the SSL/TLS client 352 2- If the server accepts, the client will generate evidence by 353 signing data using his X.509 authentication certificate. Server will 354 go through the same process if the evidence of receipt is requested. 356 3 - The signed data is then sent by the initiator (client or server) 357 and stored it locally, or by a third party, for a later use if 358 needed. 360 4 - The entity that receive the evidence process to verify the 361 signed data. 363 5- The evidence is then stored by the receiver entity for a later 364 use if needed. 366 6- In this phase, which occurs only if the critical action is 367 repudiated, the evidence is retrieved from storage, presented, and 368 verified to resolve the dispute. 370 With this method, the stored signed data (or evidence) can be 371 retrieved by both parties, presented and verified if the critical 372 action is repudiated. 374 Security Considerations 376 Security issues are discussed throughout this memo. 378 IANA Considerations 380 This document defines a new TLS extension "signature", assigned the 381 value TBD from the TLS ExtensionType registry defined in [TLSEXT]. 383 This document defines one TLS ContentType: tls_sign(TBD). This 384 ContentType value is assigned from the TLS ContentType registry 385 defined in [TLS]. 387 This document defines a new handshake message, certificate_sign, 388 whose value is to be allocated from the TLS HandshakeType registry 389 defined in [TLS]. 391 The bad_sign alert that is defined in this document is assigned to 392 the TLS Alert registry defined in [TLS]. 394 References 396 [TLS] Dierks, T., et. al., "The TLS Protocol Version 1.0", 397 RFC 2246, January 1999. 399 [TLSExt] Blake-Wilson, S., et. al., "Transport Layer Security TLS) 400 Extensions", RFC 3546, June 2003. 402 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message 403 Syntax Standard," version 1.5, November 1993. 405 [S/MIME] Ramsdell, B., "S/MIME Version 3 Message Specification", 406 RFC 2633, June 1999. 408 [XMLDSIG] Eastlake, D., et. al, "(Extensible Markup Language) XML 409 Signature Syntax and Processing", RFC 3275, March 2002. 411 [TLSSign] Hajjeh, I., Serhrouchni, A., "Integrating a signature 412 module in SSL/TLS, ICETE2004., ACM/IEEE, First 413 International Conference on E-Business and 414 Telecommunication Networks, Portugal, August 2004. 416 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May 417 2000. 419 Author's Addresses 421 Ibrahim Hajjeh 422 Engineering and Scientific Research Groups (ESRGroups) 423 82 rue Baudricourt 424 75013 Paris Phone: NA 425 France Email: Ibrahim.Hajjeh@esrgroups.org 427 Mohamad Badra 428 LIMOS Laboratory - UMR 6158, CNRS 429 France Email: badra@isima.fr 431 Acknowledgements 433 The authors would like to thank Eric Rescorla for discussions and 434 comments on the design of TLS Sign. 436 Appendix Changelog 438 Changes from -01 to -02: 440 o Add an IANA section. 442 o Small clarifications to section 2. 444 o Add the bad_sign alert and the certificate_sign message. 446 Changes from -00 to -01: 448 o Clarifications to the format of the signed data in Section 2. 450 o Small clarifications to TLS SIGN negotiation in Section 2. 452 o Added Jacques Demerjian and Mohammed Achemlal as 453 contributors/authors. 455 Full Copyright Statement 456 Copyright (C) The IETF Trust (2007). 458 This document is subject to the rights, licenses and restrictions 459 contained in BCP 78, and except as set forth therein, the authors 460 retain all their rights. 462 This document and the information contained herein are provided on 463 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 464 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 465 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 466 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 467 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 468 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 469 FOR A PARTICULAR PURPOSE. 471 Intellectual Property 473 The IETF takes no position regarding the validity or scope of any 474 Intellectual Property Rights or other rights that might be claimed 475 to pertain to the implementation or use of the technology described 476 in this document or the extent to which any license under such 477 rights might or might not be available; nor does it represent that 478 it has made any independent effort to identify any such rights. 479 Information on the procedures with respect to rights in RFC 480 documents can be found in BCP 78 and BCP 79. 482 Copies of IPR disclosures made to the IETF Secretariat and any 483 assurances of licenses to be made available, or the result of an 484 attempt made to obtain a general license or permission for the use 485 of such proprietary rights by implementers or users of this 486 specification can be obtained from the IETF on-line IPR repository 487 at http://www.ietf.org/ipr. 489 The IETF invites any interested party to bring to its attention any 490 copyrights, patents or patent applications, or other proprietary 491 rights that may cover technology that may be required to implement 492 this standard. Please address the information to the IETF at ietf- 493 ipr@ietf.org. 495 Acknowledgement 497 Funding for the RFC Editor function is provided by the IETF 498 Administrative Support Activity (IASA).