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
|
Internet Engineering Task Force M. Badra
INTERNET DRAFT A. Serhrouchni
Expires December 2004 P. Urien
ENST Telecom
June 2004
TLS Express
<draft-badra-tls-express-00.txt>
Status of this Memo
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.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
This document defines a new extension that may be used to add Pre
Shared Key authentication functionality to TLS. It is based on the
TLS abbreviated handshake and it provides the ability to share a
session key for data encryption.
Badra, et. al. Informational - Expires December 2004 [Page 1]
INTERNET-DRAFT TLS express June 2004
1. Introduction
[TLSEXT] describes extensions that MAY be used to add functionality
to Transport Layer Security (TLS). It provides both generic
extension mechanisms for the TLS handshake client and server hellos,
and specific extensions using these generic mechanisms.
In this document, we propose a new extension to add pre shared key
functionality to TLS handshake protocol. It is based on [PIMRC] and
uses the TLS session resume logic. It provides the client and the
server the ability to share a session key for data encryption and to
authenticate each other by sending a correct finished message,
parties thus prove that they know the correct pre shared key.
1.1. Requirements language
The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document
are to be interpreted as described in RFC-2119.
2. Extension Type
The TLS extensions [TLSEXT] specify extensions using the following
generic mechanism:
struct {
ExtensionType extension_type;
opaque extension_data<0.. 2^16-1>;
} Extension;
where "extension_type" identifies the particular extension type, and
"extension_data" contains information specific to the particular
extension type.
enum {
server_name(0), max_fragment_length(1),
client_certificate_url(2), trusted_ca_keys(3),
truncated_hmac(4), status_request(5), srp(6), cert_type(7),
ticket_identity(8), (65535)
} ExtensionType;
A new value, "ticket_identity(8)", has been added to the enumerated
ExtensionType defined in [TLSEXT]. This value is used as the
extension number for the extensions in the client hello message.
This new extension type will be used for shared key type
negotiation.
The "extension_data" field of the ticket extension SHALL contain:
opaque ticket_to_enter<1..2^16-1>
Badra, et. al. Expires - December 2004 [Page 2]
INTERNET-DRAFT TLS express June 2004
where ticket_to_enter is the shared key identifier and/or data
related to the shared key.
Note that the secret key MAY be delivered by a trusted third party.
In [PIMRC], we gave a method for this topic. By the way, the secret
MAY be also issued directly by the server. Kerberos [KERBEROS] is a
particular example for this issue.
2.1. Handshake
In order to indicate the support of the shared key type, the client
will include an extension of type "ticket_identity" to the extended
client hello message.
When the server receives an extended client hello containing the
"ticket_identity" extension, it checks its ticket_identity's
database for a match. If a match is found, the server calculates the
finished and waits for the client one.
If the server understood the client hello extension but does not
recognize the ticket identity, it SHOULD send a "decode_error"
alert. Alternatively and like in [TLSSRP], if the server wishes to
hide the fact that the ticket_identity does not have a match, the
server MAY simulate the protocol as if a ticket existed, but then
reject the client's finished message with a bad_record_mac alert, as
if the shared key was incorrect.
The handshake exchange is given in the following diagram:
ClientHello -------->
(ticket_identity) ServerHello
ChangeCipherSpec
<-------- Finished
ChangeCipherSpec
Finished -------->
3. Security considerations
The server MUST stock the shared key in a secure and protected
manner in order to prevent attackers from retrieving its value.
4. IANA Considerations
To be continued.
Badra, et. al. Expires - December 2004 [Page 3]
INTERNET-DRAFT TLS express June 2004
5. References
5.1 Normative References
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwwod, D., Mikkelsen, J.
and Wright, T., "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003
[KERBEROS]Kohl J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
5.2 Informative References
[TLSSRP] Taylor, D., Wu, T., Mavroyanopoulos, N., and Perrin,
T., "Using SRP for TLS Authentication",
draft-ietf-tls-srp-07.txt, Internet Draft (work in
progress), June 2004.
[PIMRC] Badra, M., and Serhrouchni, A., "A new secure session
exchange key protocol for wireless communications", the
14 IEEE Proceedings on Personal, Indoor and Mobile Radio
Communications, PIMRC 2003, Volume: 3, 7-10 Sept. 2003,
Pages:2765 - 2769. An extracted text could be found at
http://www.infres.enst.fr/~badra/pimrc2003.pdf
6. Author's Addresses
Mohamad Badra
ENST
46 rue Barrault
75634 Paris Phone: NA
France Email: Mohamad.Badra@enst.fr
Ahmed Serhrouchni
ENST
46 rue Barrault
75634 Paris Phone: NA
France Email: Ahmed.Serhrouchni@enst.fr
Pascal Urien
ENST
46 rue Barrault
75634 Paris Phone: NA
France Email: Pascal.Urien@enst.fr
Badra, et. al. Expires - December 2004 [Page 4]
INTERNET-DRAFT TLS express June 2004
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
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.
Badra, et. al. Expires - December 2004 [Page 5]
|
