1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
|
Internet Engineering Task Force I. Hajjeh
INTERNET DRAFT A. Serhrouchni
ENST Paris
M. Badra, Ed.
O. Cherkaoui
UQAM University
Expires: June 2005 January 09, 2005
TLS Sign
<draft-hajjeh-tls-sign-00.txt>
Status
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
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.
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.
Hajjeh, et. al. Informational - Expires June 2005 [Page 1]
INTERNET-DRAFT TLS Sign January 2005
Table of Contents
Abstract...........................................................1
1 Introduction.....................................................2
1.2 Requirements language..........................................3
2 TLS Sign overview................................................3
2.1 Signed data Record type.....................................5
2.1.1 TLS Sign activate/deactivate..............................5
2.1.1 TLS sign packet format....................................5
2.2 Storing signed data.........................................6
Security Considerations............................................7
References.........................................................7
Author's Addresses.................................................8
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.
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.
Hajjeh, et. al. Informational - Expires June 2005 [Page 2]
INTERNET-DRAFT TLS Sign January 2005
1.2 Requirements language
The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document
are to be interpreted as described in RFC-2119.
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;
Signature_type sign_type<1..2^16-1>;
} signature_request;
enum {
ssl_client_auth_cert(0), ssl_client_auth_cert_url(1), (255);
} SignMethod;
opaque Signature_type<1..2^16-1>;
The client initiates the TLS Sign module by sending the
ExtendedClientHello including the 'signature' extension. This
extension contains:
- the signature type (e.g., non-repudiation with proof of origin),
- the content format (e.g., PKCS7 [PKCS7], S/MIME [S/MIME], XMLDSIG
[XMLDSIG]),
- the signature method (e.g. X509 authentication certificate).
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.
Hajjeh, et. al. Informational - Expires June 2005 [Page 3]
INTERNET-DRAFT TLS Sign January 2005
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
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
MUST 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 with signing
ability in the certificate request message (e.g., an RSA or a DSS
signature-capable certificate). This request however, MUST be
appropriate for the selected cipher suite.
If the server has no interest in getting non-repudiation data from
the client, the server will select a cipher_suite or, if no
acceptable choices are presented, return a handshake failure alert
and close the connection [TLS]."
However, the client MAY demand a non-repudiation data without having
a certificate. In this case, the client MAY reject the connection if
the server is not ready to give it the non-repudiation service. This
may be done using the signature type field of the signature_request
structure.
Client Server
------ ------
ClientHello -------->
ServerHello
Certificate
ServerKeyExchange*
CertificateRequest
<-------- ServerHelloDone
Certificate
ClientKeyExchange
CertificateVerify
ChangeCipherSpec
Finished -------->
ChangeCipherSpec
<-------- Finished
(Signed) Application Data <-------> (Signed) App. Data
Hajjeh, et. al. Informational - Expires June 2005 [Page 4]
INTERNET-DRAFT TLS Sign January 2005
2.1 Signed data Record type
New record type is added in this document: the signed data protocol.
The message consists of a single byte of value 1 or 0.
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), tls_sign(25), (255)
} ContentType;
struct {
enum { tls_sign_off(0), tls_sign_on(1), (255) } type;
} TLSSignOnOff;
2.1.1 TLS Sign activate/deactivate
To manage the generation of evidence, new record 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. Thus, no man in the middle can replay
or inject this message. It consists of a Boolean of value 1
(tls_sign_on) or 0 (tls_sign_off).
The tls_sign_on_off message is sent by both the client and server to
notify the receiving party that subsequent records will carry data
under the negotiated parameters and keys.
If the client was not authenticated in his first TLS exchange or
does not support a signature algorithm, the server who receives
tls_sign_on_off message, MAY answer by signed data, ignore it or MAY
invite the client to start a new TLS session sending the
HelloRequest message.
This message can be sent at any point after the TLS session has been
established.
2.1.1 TLS sign packet format
This document defines a new packet format that encapsulates signed
data. 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signed Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Content-Type
Hajjeh, et. al. Informational - Expires June 2005 [Page 5]
INTERNET-DRAFT TLS Sign January 2005
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|A D R R R R R R|
+-+-+-+-+-+-+-+-+
A = acknowledgement of receipt
D = signed data
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
message with Type=A (acknowledgement of receipt), and as data-field
the digest of the whole data. The data-field is of course signed by
the receiver before it is sent to the sender.
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
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 [RFC2828]. RFC 2828 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:
Hajjeh, et. al. Informational - Expires June 2005 [Page 6]
INTERNET-DRAFT TLS Sign January 2005
-------- -------- -------- -------- -------- . --------
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.
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.
Security Considerations
Security issues are discussed throughout this memo.
References
[TLS] Dierks, T., et. al, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[TLSExt] Blake-Wilson, S., et. al, "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003.
Hajjeh, et. al. Informational - Expires June 2005 [Page 7]
INTERNET-DRAFT TLS Sign January 2005
[PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message
Syntax Standard," version 1.5, November 1993.
[S/MIME] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999.
[XMLDSIG]Eastlake, D., et. al, "(Extensible Markup Language) XML
Signature Syntax and Processing", RFC 3275, March 2002.
[TLSSign]Hajjeh, I., Serhrouchni, A., "Integrating a signature
module in SSL/TLS, ICETEĈ2004, ACM/IEEE, First
International Conference on E-Business and
Telecommunication Networks, Portugal, August 2004.
[RFC2828]Shirey, R., "Internet Security Glossary", RFC 2828, May
2000.
Author's Addresses
Ibrahim Hajjeh
ENST
46 rue Barrault
75013 Paris Phone: NA
France Email: Ibrahim.Hajjeh@enst.fr
Ahmed serhrouchni
ENST
46 rue Barrault
75013 Paris Phone: NA
France Email: Ahmed.serhrouchni@enst.fr
Mohamad Badra
UQAM University
Montreal (Quebec) Phone: NA
Canada Email: Mohamad.Badra@uqam.ca
Omar Cherkaoui
UQAM University
Montreal (Quebec) Phone: NA
Canada Email: Omar.Cherkaoui@uqam.ca
Acknowledgements
The authors would like to thank Eric Rescorla for discussions and
comments on the design of TLS Sign.
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
Hajjeh, et. al. Informational - Expires June 2005 [Page 8]
INTERNET-DRAFT TLS Sign January 2005
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 IETF's procedures with respect to rights in IETF
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 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 Internet Society (2004). 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, et. al. Informational - Expires June 2005 [Page 9]
|