idnits 2.17.1 draft-hajjeh-tls-sign-01.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 451. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 441. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 106: '...ents and servers MAY include an extens...' RFC 2119 keyword, line 159: '...signature method MAY be added in futur...' RFC 2119 keyword, line 162: '... The server MAY reject the connectio...' RFC 2119 keyword, line 167: '...ith signature ability, the server MUST...' RFC 2119 keyword, line 173: '... MUST select a cipher_suite with sig...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 20, 2005) is 6756 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) ** 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: 12 errors (**), 0 flaws (~~), 2 warnings (==), 8 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 A. Serhrouchni 6 ENST Paris 7 J. Demerjian 8 M. Achemlal 9 France Telecom R&D 10 Expires: April 2006 October 20, 2005 12 TLS Sign 13 15 Status 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on April 20, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 TLS protocol provides authentication and data protection for 47 communication between two entities. However, missing from the 48 protocol is a way to perform non-repudiation service. 50 This document defines extensions to the TLS protocol to allow it to 51 perform non-repudiation service. It is based on [TLSSign] and it 52 provides the client and the server the ability to sign by TLS, 53 handshake and applications data using certificates such as X.509. 55 1 Introduction 57 Actually, TLS is the most deployed security protocol for securing 58 exchanges. It provides end-to-end secure communications between two 59 entities with authentication and data protection. However, what is 60 missing from the protocol is a way to provide the non-repudiation 61 service. 63 This document describes how the non-repudiation service may be 64 integrated as an optional module in TLS. This is in order to provide 65 both parties with evidence that the transaction has taken place and 66 to offer a clear separation with application design and development. 68 TLS-Sign's design motivations included: 70 o TLS is application protocol-independent. Higher-level protocol 71 can operate on top of the TLS protocol transparently. 73 o TLS is a modular nature protocol. Since TLS is developed in four 74 independent protocols, the approach defined in this document can 75 be added by extending the TLS protocol and with a total 76 reuse of pre-existing TLS infrastructures and implementations. 78 o Several applications like E-Business require non-repudiation 79 proof of transactions. It is critical in these applications to 80 have the non-repudiation service that generates, distributes, 81 validates and maintains the evidence of an electronic 82 transaction. Since TLS is widely used to secure these 83 applications exchanges, the non-repudiation should be offered by 84 TLS. 86 o Generic Non repudiation with TLS. TLS SIGN provides a generic 87 non-repudiation service that can be easily used with protocols. 88 TLS SIGN minimizes both design and implementation of the 89 signature service and that of the designers and implementators 90 who wish to use this module. 92 1.2 Requirements language 94 The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document 95 are to be interpreted as described in RFC-2119. 97 2 TLS Sign overview 99 TLS Sign is integrated as a higher-level module of the TLS Record 100 protocol. It is optionally used if the two entities agree. This is 101 negotiated by extending Client and Server Hello messages in the same 102 way defined in [TLSExt]. 104 In order to allow a TLS client to negotiate the TLS Sign, a new 105 extension type should be added to the Extended Client and Server 106 Hellos messages. TLS clients and servers MAY include an extension of 107 type 'signature' in the Extended Client and Server Hellos messages. 108 The 'extension_data' field of this extension contains a 109 'signature_request' where: 111 enum { 112 pkcs7(0), smime(1), xmldsig(2), (255); 113 } ContentFormat; 115 struct { 116 ContentFormat content_format; 117 SignMethod sign_meth; 118 SignType_sign_type; 119 } signature_request; 121 enum { 122 ssl_client_auth_cert(0), ssl_client_auth_cert_url(1), (255); 123 } SignMethod; 125 opaque Signature_type<1..2^16-1>; 127 The client initiates the TLS Sign module by sending the 128 ExtendedClientHello including the 'signature' extension. This 129 extension contains: 131 - the SignType contains the type of the non repudiation proof. It 132 can have one of these two values: 134 SignType non_repudiation_with_proof_of_origin = { 0x00, 0x01 }; 135 SignType non_repudiation_without_proof_of_origin = { 0x00, 0x02 }; 137 - the ContentFormat contains the format of signed data. It can be 138 PKCS7 [PKCS7], S/MIME [S/MIME] or XMLDSIG [XMLDSIG] 140 ContentFormat PKCS7 = { 0x00, 0xA1 }; 141 ContentFormat SMIME = { 0x00, 0xA2 }; 142 ContentFormat XMLDSIG = { 0x00, 0xA3 }; 144 o if the value of the ContentFormat is PKCS7, then the PKCS7 145 Content_type is of type signed-data. 147 o if the value of the ContentFormat is S/MIME, then S/MIME 148 Content_type is of type SignedData 150 o if the value of the ContentFormat is XMLDSIG, then XMLDSIG 151 signatureMethod algorithms. 153 - the sign_method contains the signature method that is used to sign 154 the application data (e.g. X509 authentication certificate). 156 SignMethod X509 = { 0x00, 0xB1 }; 158 Actually, this document uses the same certificate used in client 159 authentication. Any new signature method MAY be added in future 160 versions (e.g. delegated attributes certificates). 162 The server MAY reject the connection by sending the error alert 163 "unsupported_extension" [TLSExt] and closing the connection. 165 If the server has an interest in getting non-repudiation data from 166 the client and that the cipher_suites list sent by the client does 167 not include any cipher_suite with signature ability, the server MUST 168 close the connection by sending a fatal error. 170 If the server has an interest in getting non-repudiation data from 171 the client and that the cipher_suites list sent by the client 172 includes at least a cipher_suite with signature ability, the server 173 MUST select a cipher_suite with signature ability and MUST provide a 174 certificate (e.g., RSA) that MAY be used for key exchange. Further, 175 the server MUST request a certificate from the client using the TLS 176 certificate request message (e.g., an RSA or a DSS signature-capable 177 certificate). This request however, MUST be appropriate for the 178 selected cipher suite. 180 If the server has no interest in getting non-repudiation data from 181 the client, it replays with an ordinary TLS ServerHello or return a 182 handshake failure alert and close the connection [TLS]. 184 Client Server 185 ------ ------ 187 ClientHello --------> 188 ServerHello 189 Certificate 190 ServerKeyExchange* 191 CertificateRequest 192 <-------- ServerHelloDone 193 Certificate 194 ClientKeyExchange 195 CertificateVerify 196 ChangeCipherSpec 197 Finished --------> 198 ChangeCipherSpec 199 <-------- Finished 200 (Signed) Application Data <-------> (Signed) App. Data 202 However, the client MAY request a non-repudiation data without 203 having a certificate. In this case, the client MAY reject the 204 connection if the server is not ready to give it the non-repudiation 205 service. This MAY be done using the signature type field of the 206 signature_request structure. 208 2.1 Signed data Record type 210 New record type is added in this document: the signed data protocol. 211 The message consists of a single byte of value 1 or 0. 213 enum { 214 change_cipher_spec(20), alert(21), handshake(22), 215 application_data(23), tls_sign(25), (255) 216 } ContentType; 218 struct { 219 enum { tls_sign_off(0), tls_sign_on(1), (255) } type; 220 } TLSSignOnOff; 222 2.1.1 TLS Sign activate/deactivate 224 To manage the generation of evidence, new sub-protocol is added by 225 this document, called tls_sign_on_off. This protocol consists of a 226 single message that is encrypted and compressed under the 227 established connection state. Thus, no man in the middle can replay 228 or inject this message. It consists of a Boolean of value 1 229 (tls_sign_on) or 0 (tls_sign_off). 231 The tls_sign_on_off message is sent by both the client and server to 232 notify the receiving party that subsequent records will carry data 233 under the negotiated parameters and keys. 235 If the client was not authenticated in his first TLS exchange or 236 does not support a signature algorithm, the server who receives 237 tls_sign_on_off message, MAY answer by signed data, ignore it or MAY 238 invite the client to start a new TLS session sending the 239 HelloRequest message. 241 This message can be sent at any time after the TLS session has been 242 established. 244 2.1.2 TLS sign packet format 246 This document defines a new packet format that encapsulates signed 247 data. The packet format is shown below. The fields are transmitted 248 from left to right. 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Content-Type | Length | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Signed Data ... 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Content-Type 260 0 1 2 3 4 5 6 7 261 +-+-+-+-+-+-+-+-+ 262 |A D R R R R R R| 263 +-+-+-+-+-+-+-+-+ 265 A = acknowledgement of receipt 266 D = signed data 267 R = Reserved 269 When the whole signed data is delivered to the receiver, the TLS 270 Sign will check the signature. If the signature is valid and that 271 the sender requires a proof of receipt, the receiver MUST generate a 272 message with Type=A (acknowledgement of receipt). The data-field of 273 that message contains the digest of the whole data. The digest is 274 signed before sending the result to the other side. 276 2.2 Storing signed data 278 The objective of TLS Sign is to provide both parties with evidence 279 that can be stored and later presented to a third party to resolve 280 disputes that arise if and when a communication is repudiated by one 281 of the entities involved. This document provides the two basic types 282 of non-repudiation service: 284 o Non-repudiation with proof of origin: provides the TLS server 285 with evidence proving that the TLS client has sent it the signed 286 data at a certain time. 288 o Non-repudiation with proof of delivery: provides the TLS client 289 with evidence that the server has received the client's signed 290 data at a specific time. 292 TLS Handshake exchanges the current time and date according to the 293 entities internal clock. Thus, the time and date can be stored with 294 the signed data as a proof of communication. For B2C or B2B 295 transactions, non-repudiation with proof of origin and non- 296 repudiation with proof of receipt are both important. If the TLS 297 client requests a non-repudiation service with proof of receipt, the 298 server SHOULD verify and send back to client a signature on the hash 299 of signed data. 301 The following figure explains the different events for proving and 302 storing signed data [RFC2828]. RFC 2828 uses the term "critical 303 action" to refer to the act of communication between the two 304 entities. For a complete non-repudiation deployment, 6 phases should 305 be respected: 307 -------- -------- -------- -------- -------- . -------- 308 Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: . Phase 6: 309 Request Generate Transfer Verify Retain . Resolve 310 Service Evidence Evidence Evidence Evidence . Dispute 311 -------- -------- -------- -------- -------- . -------- 312 Service Critical Evidence Evidence Archive . Evidence 313 Request => Action => Stored => Is => Evidence . Is 314 Is Made Occurs For Later Tested In Case . Verified 315 and Use | ^ Critical . ^ 316 Evidence v | Action Is . | 317 Is +-------------------+ Repudiated . | 318 Generated |Verifiable Evidence|------> ... . ----+ 319 +-------------------+ 321 1- Requesting explicit transaction evidence before sending data. 322 Normally, this action is taken by the SSL/TLS client 324 2- If the server accepts, the client will generate evidence by 325 signing data using his X.509 authentication certificate. Server will 326 go through the same process if the evidence of receipt is requested. 328 3 - The signed data is then sent by the initiator (client or server) 329 and stored it locally, or by a third party, for a later use if 330 needed. 332 4 - The entity that receive the evidence process to verify the 333 signed data. 335 5- The evidence is then stored by the receiver entity for a later 336 use if needed. 338 6- In this phase, which occurs only if the critical action is 339 repudiated, the evidence is retrieved from storage, presented, and 340 verified to resolve the dispute. 342 With this method, the stored signed data (or evidence) can be 343 retrieved by both parties, presented and verified if the critical 344 action is repudiated. 346 Security Considerations 348 Security issues are discussed throughout this memo. 350 References 352 [TLS] Dierks, T., et. al., "The TLS Protocol Version 1.0", 353 RFC 2246, January 1999. 355 [TLSExt] Blake-Wilson, S., et. al., "Transport Layer Security TLS) 356 Extensions", RFC 3546, June 2003. 358 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message 359 Syntax Standard," version 1.5, November 1993. 361 [S/MIME] Ramsdell, B., "S/MIME Version 3 Message Specification", 362 RFC 2633, June 1999. 364 [XMLDSIG] Eastlake, D., et. al, "(Extensible Markup Language) XML 365 Signature Syntax and Processing", RFC 3275, March 2002. 367 [TLSSign] Hajjeh, I., Serhrouchni, A., "Integrating a signature 368 module in SSL/TLS, ICETE2004., ACM/IEEE, First 369 International Conference on E-Business and 370 Telecommunication Networks, Portugal, August 2004. 372 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May 373 2000. 375 Author's Addresses 377 Ibrahim Hajjeh 378 Engineering and Scientific Research Groups (ESRGroups) 379 17 Passage Barrault 380 75013 Paris Phone: NA 381 France Email: Ibrahim.Hajjeh@esrgroups.org 383 Mohamad Badra 384 ENST 385 46 rue Barrault 386 75634 Paris Phone: NA 387 France Email: Mohamad.Badra@enst.fr 389 Ahmed serhrouchni 390 ENST Phone: NA 391 France Email: Ahmed.serhrouchni@enst.fr 393 Jacques Demerjian 394 France Telecom R&D 395 42 rue des coutures 396 14066 Caen Cedex 4 Phone: NA 397 France Email: jacques.demerjian@francetelecom.com 399 Mohammed Achemlal 400 France Telecom R&D Phone: NA 401 France Email: Mohammed.Achemlal@francetelecom.com 403 Acknowledgements 405 The authors would like to thank Eric Rescorla for discussions and 406 comments on the design of TLS Sign. 408 Appendix Changelog 410 Changes from -00 to -01: 412 o Clarifications to the format of the signed data in Section 2. 414 o Small clarifications to TLS SIGN negotiation in Section 2. 416 o Added Jacques Demerjian and Mohammed Achemlal as 417 contributors/authors. 419 Intellectual Property Statement 421 The IETF takes no position regarding the validity or scope of any 422 Intellectual Property Rights or other rights that might be claimed 423 to pertain to the implementation or use of the technology described 424 in this document or the extent to which any license under such 425 rights might or might not be available; nor does it represent that 426 it has made any independent effort to identify any such rights. 427 Information on the IETF's procedures with respect to rights in IETF 428 Documents can be found in BCP 78 and BCP 79. 430 Copies of IPR disclosures made to the IETF Secretariat and any 431 assurances of licenses to be made available, or the result of an 432 attempt made to obtain a general license or permission for the use 433 of such proprietary rights by implementers or users of this 434 specification can be obtained from the IETF on-line IPR repository 435 at http://www.ietf.org/ipr. 437 The IETF invites any interested party to bring to its attention any 438 copyrights, patents or patent applications, or other proprietary 439 rights that may cover technology that may be required to implement 440 this standard. Please address the information to the IETF at ietf- 441 ipr@ietf.org. 443 Disclaimer of Validity 445 This document and the information contained herein are provided on 446 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 447 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 448 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 449 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 450 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 451 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 453 Copyright Statement 455 Copyright (C) The Internet Society (2004). This document is subject 456 to the rights, licenses and restrictions contained in BCP 78, and 457 except as set forth therein, the authors retain all their rights. 459 Acknowledgment 461 Funding for the RFC Editor function is currently provided by the 462 Internet Society.