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
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
|
<pre>Network Working Group J. Salowey
Request for Comments: 5077 H. Zhou
Obsoletes: <a href="./rfc4507">4507</a> Cisco Systems
Category: Standards Track P. Eronen
Nokia
H. Tschofenig
Nokia Siemens Networks
January 2008
<span class="h1">Transport Layer Security (TLS) Session Resumption without</span>
<span class="h1">Server-Side State</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document describes a mechanism that enables the Transport Layer
Security (TLS) server to resume sessions and avoid keeping per-client
session state. The TLS server encapsulates the session state into a
ticket and forwards it to the client. The client can subsequently
resume a session using the obtained ticket. This document obsoletes
<a href="./rfc4507">RFC 4507</a>.
<span class="grey">Salowey, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5077">RFC 5077</a> Stateless TLS Session Resumption January 2008</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. Overview . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. SessionTicket TLS Extension . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.3">3.3</a>. NewSessionTicket Handshake Message . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.4">3.4</a>. Interaction with TLS Session ID . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4">4</a>. Recommended Ticket Construction . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5.1">5.1</a>. Invalidating Sessions . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5.2">5.2</a>. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5.3">5.3</a>. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5.4">5.4</a>. Denial of Service Attacks . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5.5">5.5</a>. Ticket Protection Key Management . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5.6">5.6</a>. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5.7">5.7</a>. Alternate Ticket Formats and Distribution Schemes . . . . <a href="#page-13">13</a>
<a href="#section-5.8">5.8</a>. Identity Privacy, Anonymity, and Unlinkability . . . . . . <a href="#page-14">14</a>
<a href="#section-6">6</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-7">7</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#appendix-A">Appendix A</a>. Discussion of Changes to <a href="./rfc4507">RFC 4507</a> . . . . . . . . . . <a href="#page-17">17</a>
<span class="grey">Salowey, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5077">RFC 5077</a> Stateless TLS Session Resumption January 2008</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document defines a way to resume a Transport Layer Security
(TLS) session without requiring session-specific state at the TLS
server. This mechanism may be used with any TLS ciphersuite. This
document applies to both TLS 1.0 defined in [<a href="./rfc2246" title=""The TLS Protocol Version 1.0"">RFC2246</a>], and TLS 1.1
defined in [<a href="./rfc4346" title=""The Transport Layer Security (TLS) Protocol Version 1.1"">RFC4346</a>]. The mechanism makes use of TLS extensions
defined in [<a href="./rfc4366" title=""Transport Layer Security (TLS) Extensions"">RFC4366</a>] and defines a new TLS message type.
This mechanism is useful in the following situations:
1. servers that handle a large number of transactions from different
users
2. servers that desire to cache sessions for a long time
3. ability to load balance requests across servers
4. embedded servers with little memory
This document obsoletes <a href="./rfc4507">RFC 4507</a> [<a href="./rfc4507" title=""Transport Layer Security (TLS) Session Resumption without Server-Side State"">RFC4507</a>] to correct an error in the
encoding that caused the specification to differ from deployed
implementations. At the time of this writing, there are no known
implementations that follow the encoding specified in <a href="./rfc4507">RFC 4507</a>. This
update to <a href="./rfc4507">RFC 4507</a> aligns the document with currently deployed
implementations. More details of the change are given in <a href="#appendix-A">Appendix A</a>.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
Within this document, the term 'ticket' refers to a cryptographically
protected data structure that is created and consumed by the server
to rebuild session-specific state.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Protocol</span>
This specification describes a mechanism to distribute encrypted
session-state information to the client in the form of a ticket and a
mechanism to present the ticket back to the server. The ticket is
created by a TLS server and sent to a TLS client. The TLS client
presents the ticket to the TLS server to resume a session.
Implementations of this specification are expected to support both
mechanisms. Other specifications can take advantage of the session
tickets, perhaps specifying alternative means for distribution or
selection. For example, a separate specification may describe an
<span class="grey">Salowey, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5077">RFC 5077</a> Stateless TLS Session Resumption January 2008</span>
alternate way to distribute a ticket and use the TLS extension in
this document to resume the session. This behavior is beyond the
scope of the document and would need to be described in a separate
specification.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Overview</span>
The client indicates that it supports this mechanism by including a
SessionTicket TLS extension in the ClientHello message. The
extension will be empty if the client does not already possess a
ticket for the server. The server sends an empty SessionTicket
extension to indicate that it will send a new session ticket using
the NewSessionTicket handshake message. The extension is described
in <a href="#section-3.2">Section 3.2</a>.
If the server wants to use this mechanism, it stores its session
state (such as ciphersuite and master secret) to a ticket that is
encrypted and integrity-protected by a key known only to the server.
The ticket is distributed to the client using the NewSessionTicket
TLS handshake message described in <a href="#section-3.3">Section 3.3</a>. This message is sent
during the TLS handshake before the ChangeCipherSpec message, after
the server has successfully verified the client's Finished message.
Client Server
ClientHello
(empty SessionTicket extension)-------->
ServerHello
(empty SessionTicket extension)
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Figure 1: Message Flow for Full Handshake Issuing New Session Ticket
<span class="grey">Salowey, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5077">RFC 5077</a> Stateless TLS Session Resumption January 2008</span>
The client caches this ticket along with the master secret and other
parameters associated with the current session. When the client
wishes to resume the session, it includes the ticket in the
SessionTicket extension within the ClientHello message. <a href="#appendix-A">Appendix A</a>
provides a detailed description of the encoding of the extension and
changes from <a href="./rfc4507">RFC 4507</a>. The server then decrypts the received ticket,
verifies the ticket's validity, retrieves the session state from the
contents of the ticket, and uses this state to resume the session.
The interaction with the TLS Session ID is described in <a href="#section-3.4">Section 3.4</a>.
If the server successfully verifies the client's ticket, then it may
renew the ticket by including a NewSessionTicket handshake message
after the ServerHello.
Client Server
ClientHello
(SessionTicket extension) -------->
ServerHello
(empty SessionTicket extension)
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
Figure 2: Message Flow for Abbreviated Handshake Using New Session
Ticket
A recommended ticket format is given in <a href="#section-4">Section 4</a>.
If the server cannot or does not want to honor the ticket, then it
can initiate a full handshake with the client.
In the case that the server does not wish to issue a new ticket at
this time, it just completes the handshake without including a
SessionTicket extension or NewSessionTicket handshake message. This
is shown below (this flow is identical to Figure 1 in <a href="./rfc4346">RFC 4346</a>,
except for the SessionTicket extension in the first message):
<span class="grey">Salowey, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5077">RFC 5077</a> Stateless TLS Session Resumption January 2008</span>
Client Server
ClientHello
(SessionTicket extension) -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Figure 3: Message Flow for Server Completing Full Handshake Without
Issuing New Session Ticket
It is also permissible to have an exchange similar to Figure 3 using
the abbreviated handshake defined in Figure 2 of <a href="./rfc4346">RFC 4346</a>, where the
client uses the SessionTicket extension to resume the session, but
the server does not wish to issue a new ticket, and therefore does
not send a SessionTicket extension.
If the server rejects the ticket, it may still wish to issue a new
ticket after performing the full handshake as shown below (this flow
is identical to Figure 1, except the SessionTicket extension in the
ClientHello is not empty):
<span class="grey">Salowey, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5077">RFC 5077</a> Stateless TLS Session Resumption January 2008</span>
Client Server
ClientHello
(SessionTicket extension) -------->
ServerHello
(empty SessionTicket extension)
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Figure 4: Message Flow for Server Rejecting Ticket, Performing Full
Handshake, and Issuing New Session Ticket
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. SessionTicket TLS Extension</span>
The SessionTicket TLS extension is based on [<a href="./rfc4366" title=""Transport Layer Security (TLS) Extensions"">RFC4366</a>]. The format of
the ticket is an opaque structure used to carry session-specific
state information. This extension may be sent in the ClientHello and
ServerHello.
If the client possesses a ticket that it wants to use to resume a
session, then it includes the ticket in the SessionTicket extension
in the ClientHello. If the client does not have a ticket and is
prepared to receive one in the NewSessionTicket handshake message,
then it MUST include a zero-length ticket in the SessionTicket
extension. If the client is not prepared to receive a ticket in the
NewSessionTicket handshake message, then it MUST NOT include a
SessionTicket extension unless it is sending a non-empty ticket it
received through some other means from the server.
The server uses a zero-length SessionTicket extension to indicate to
the client that it will send a new session ticket using the
NewSessionTicket handshake message described in <a href="#section-3.3">Section 3.3</a>. The
server MUST send this extension in the ServerHello if it wishes to
issue a new ticket to the client using the NewSessionTicket handshake
message. The server MUST NOT send this extension if it does not
receive one in the ClientHello.
<span class="grey">Salowey, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5077">RFC 5077</a> Stateless TLS Session Resumption January 2008</span>
If the server fails to verify the ticket, then it falls back to
performing a full handshake. If the ticket is accepted by the server
but the handshake fails, the client SHOULD delete the ticket.
The SessionTicket extension has been assigned the number 35. The
extension_data field of SessionTicket extension contains the ticket.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. NewSessionTicket Handshake Message</span>
This message is sent by the server during the TLS handshake before
the ChangeCipherSpec message. This message MUST be sent if the
server included a SessionTicket extension in the ServerHello. This
message MUST NOT be sent if the server did not include a
SessionTicket extension in the ServerHello. This message is included
in the hash used to create and verify the Finished message. In the
case of a full handshake, the server MUST verify the client's
Finished message before sending the ticket. The client MUST NOT
treat the ticket as valid until it has verified the server's Finished
message. If the server determines that it does not want to include a
ticket after it has included the SessionTicket extension in the
ServerHello, then it sends a zero-length ticket in the
NewSessionTicket handshake message.
If the server successfully verifies the client's ticket, then it MAY
renew the ticket by including a NewSessionTicket handshake message
after the ServerHello in the abbreviated handshake. The client
should start using the new ticket as soon as possible after it
verifies the server's Finished message for new connections. Note
that since the updated ticket is issued before the handshake
completes, it is possible that the client may not put the new ticket
into use before it initiates new connections. The server MUST NOT
assume that the client actually received the updated ticket until it
successfully verifies the client's Finished message.
The NewSessionTicket handshake message has been assigned the number 4
and its definition is given at the end of this section. The
ticket_lifetime_hint field contains a hint from the server about how
long the ticket should be stored. The value indicates the lifetime
in seconds as a 32-bit unsigned integer in network byte order
relative to when the ticket is received. A value of zero is reserved
to indicate that the lifetime of the ticket is unspecified. A client
SHOULD delete the ticket and associated state when the time expires.
It MAY delete the ticket earlier based on local policy. A server MAY
treat a ticket as valid for a shorter or longer period of time than
what is stated in the ticket_lifetime_hint.
<span class="grey">Salowey, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5077">RFC 5077</a> Stateless TLS Session Resumption January 2008</span>
struct {
HandshakeType msg_type;
uint24 length;
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
case session_ticket: NewSessionTicket; /* NEW */
} body;
} Handshake;
struct {
uint32 ticket_lifetime_hint;
opaque ticket<0..2^16-1>;
} NewSessionTicket;
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Interaction with TLS Session ID</span>
If a server is planning on issuing a session ticket to a client that
does not present one, it SHOULD include an empty Session ID in the
ServerHello. If the server rejects the ticket and falls back to the
full handshake then it may include a non-empty Session ID to indicate
its support for stateful session resumption. If the client receives
a session ticket from the server, then it discards any Session ID
that was sent in the ServerHello.
When presenting a ticket, the client MAY generate and include a
Session ID in the TLS ClientHello. If the server accepts the ticket
and the Session ID is not empty, then it MUST respond with the same
Session ID present in the ClientHello. This allows the client to
easily differentiate when the server is resuming a session from when
it is falling back to a full handshake. Since the client generates a
Session ID, the server MUST NOT rely upon the Session ID having a
particular value when validating the ticket. If a ticket is
presented by the client, the server MUST NOT attempt to use the
Session ID in the ClientHello for stateful session resumption.
Alternatively, the client MAY include an empty Session ID in the
ClientHello. In this case, the client ignores the Session ID sent in
the ServerHello and determines if the server is resuming a session by
the subsequent handshake messages.
<span class="grey">Salowey, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5077">RFC 5077</a> Stateless TLS Session Resumption January 2008</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Recommended Ticket Construction</span>
This section describes a recommended format and protection for the
ticket. Note that the ticket is opaque to the client, so the
structure is not subject to interoperability concerns, and
implementations may diverge from this format. If implementations do
diverge from this format, they must take security concerns seriously.
Clients MUST NOT examine the ticket under the assumption that it
complies with this document.
The server uses two different keys: one 128-bit key for Advanced
Encryption Standard (AES) [<a href="#ref-AES" title=""Advanced Encryption Standard (AES)"">AES</a>] in Cipher Block Chaining (CBC) mode
[<a href="#ref-CBC" title=""Recommendation for Block Cipher Modes of Operation - Methods and Techniques"">CBC</a>] encryption and one 256-bit key for HMAC-SHA-256 [<a href="./rfc4634" title=""US Secure Hash Algorithms (SHA and HMAC-SHA)"">RFC4634</a>].
The ticket is structured as follows:
struct {
opaque key_name[16];
opaque iv[16];
opaque encrypted_state<0..2^16-1>;
opaque mac[32];
} ticket;
Here, key_name serves to identify a particular set of keys used to
protect the ticket. It enables the server to easily recognize
tickets it has issued. The key_name should be randomly generated to
avoid collisions between servers. One possibility is to generate new
random keys and key_name every time the server is started.
The actual state information in encrypted_state is encrypted using
128-bit AES in CBC mode with the given IV. The Message
Authentication Code (MAC) is calculated using HMAC-SHA-256 over
key_name (16 octets) and IV (16 octets), followed by the length of
the encrypted_state field (2 octets) and its contents (variable
length).
<span class="grey">Salowey, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5077">RFC 5077</a> Stateless TLS Session Resumption January 2008</span>
struct {
ProtocolVersion protocol_version;
CipherSuite cipher_suite;
CompressionMethod compression_method;
opaque master_secret[48];
ClientIdentity client_identity;
uint32 timestamp;
} StatePlaintext;
enum {
anonymous(0),
certificate_based(1),
psk(2)
} ClientAuthenticationType;
struct {
ClientAuthenticationType client_authentication_type;
select (ClientAuthenticationType) {
case anonymous: struct {};
case certificate_based:
ASN.1Cert certificate_list<0..2^24-1>;
case psk:
opaque psk_identity<0..2^16-1>; /* from [<a href="./rfc4279" title=""Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)"">RFC4279</a>] */
};
} ClientIdentity;
The structure StatePlaintext stores the TLS session state including
the master_secret. The timestamp within this structure allows the
TLS server to expire tickets. To cover the authentication and key
exchange protocols provided by TLS, the ClientIdentity structure
contains the authentication type of the client used in the initial
exchange (see ClientAuthenticationType). To offer the TLS server
with the same capabilities for authentication and authorization, a
certificate list is included in case of public-key-based
authentication. The TLS server is therefore able to inspect a number
of different attributes within these certificates. A specific
implementation might choose to store a subset of this information or
additional information. Other authentication mechanisms, such as
Kerberos [<a href="./rfc2712" title=""Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)"">RFC2712</a>], would require different client identity data.
Other TLS extensions may require the inclusion of additional data in
the StatePlaintext structure.
<span class="grey">Salowey, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5077">RFC 5077</a> Stateless TLS Session Resumption January 2008</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
This section addresses security issues related to the usage of a
ticket. Tickets must be authenticated and encrypted to prevent
modification or eavesdropping by an attacker. Several attacks
described below will be possible if this is not carefully done.
Implementations should take care to ensure that the processing of
tickets does not increase the chance of denial of service as
described below.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Invalidating Sessions</span>
The TLS specification requires that TLS sessions be invalidated when
errors occur. [<a href="#ref-CSSC" title=""Client-side caching for TLS"">CSSC</a>] discusses the security implications of this in
detail. In the analysis within this paper, failure to invalidate
sessions does not pose a security risk. This is because the TLS
handshake uses a non-reversible function to derive keys for a session
so information about one session does not provide an advantage to
attack the master secret or a different session. If a session
invalidation scheme is used, the implementation should verify the
integrity of the ticket before using the contents to invalidate a
session to ensure that an attacker cannot invalidate a chosen
session.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Stolen Tickets</span>
An eavesdropper or man-in-the-middle may obtain the ticket and
attempt to use it to establish a session with the server; however,
since the ticket is encrypted and the attacker does not know the
secret key, a stolen ticket does not help an attacker resume a
session. A TLS server MUST use strong encryption and integrity
protection for the ticket to prevent an attacker from using a brute
force mechanism to obtain the ticket's contents.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Forged Tickets</span>
A malicious user could forge or alter a ticket in order to resume a
session, to extend its lifetime, to impersonate another user, or to
gain additional privileges. This attack is not possible if the
ticket is protected using a strong integrity protection algorithm
such as a keyed HMAC-SHA-256.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Denial of Service Attacks</span>
The key_name field defined in the recommended ticket format helps the
server efficiently reject tickets that it did not issue. However, an
adversary could store or generate a large number of tickets to send
<span class="grey">Salowey, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5077">RFC 5077</a> Stateless TLS Session Resumption January 2008</span>
to the TLS server for verification. To minimize the possibility of a
denial of service, the verification of the ticket should be
lightweight (e.g., using efficient symmetric key cryptographic
algorithms).
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>. Ticket Protection Key Management</span>
A full description of the management of the keys used to protect the
ticket is beyond the scope of this document. A list of RECOMMENDED
practices is given below.
o The keys should be generated securely following the randomness
recommendations in [<a href="./rfc4086" title=""Randomness Requirements for Security"">RFC4086</a>].
o The keys and cryptographic protection algorithms should be at
least 128 bits in strength. Some ciphersuites and applications
may require cryptographic protection greater than 128 bits in
strength.
o The keys should not be used for any purpose other than generating
and verifying tickets.
o The keys should be changed regularly.
o The keys should be changed if the ticket format or cryptographic
protection algorithms change.
<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>. Ticket Lifetime</span>
The TLS server controls the lifetime of the ticket. Servers
determine the acceptable lifetime based on the operational and
security requirements of the environments in which they are deployed.
The ticket lifetime may be longer than the 24-hour lifetime
recommended in [<a href="./rfc4346" title=""The Transport Layer Security (TLS) Protocol Version 1.1"">RFC4346</a>]. TLS clients may be given a hint of the
lifetime of the ticket. Since the lifetime of a ticket may be
unspecified, a client has its own local policy that determines when
it discards tickets.
<span class="h3"><a class="selflink" id="section-5.7" href="#section-5.7">5.7</a>. Alternate Ticket Formats and Distribution Schemes</span>
If the ticket format or distribution scheme defined in this document
is not used, then great care must be taken in analyzing the security
of the solution. In particular, if confidential information, such as
a secret key, is transferred to the client, it MUST be done using
secure communication so as to prevent attackers from obtaining or
modifying the key. Also, the ticket MUST have its integrity and
confidentiality protected with strong cryptographic techniques to
prevent a breach in the security of the system.
<span class="grey">Salowey, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5077">RFC 5077</a> Stateless TLS Session Resumption January 2008</span>
<span class="h3"><a class="selflink" id="section-5.8" href="#section-5.8">5.8</a>. Identity Privacy, Anonymity, and Unlinkability</span>
This document mandates that the content of the ticket is
confidentiality protected in order to avoid leakage of its content,
such as user-relevant information. As such, it prevents disclosure
of potentially sensitive information carried within the ticket.
The initial handshake exchange, which was used to obtain the ticket,
might not provide identity confidentiality of the client based on the
properties of TLS. Another relevant security threat is the ability
for an on-path adversary to observe multiple TLS handshakes where the
same ticket is used, therefore concluding they belong to the same
communication endpoints. Application designers that use the ticket
mechanism described in this document should consider that
unlinkability [<a href="#ref-ANON" title=""Anonymity, Unlinkability, Unobservability, Pseudonymity, and Identity Management - A Consolidated Proposal for Terminology"">ANON</a>] is not necessarily provided.
While a full discussion of these topics is beyond the scope of this
document, it should be noted that it is possible to issue a ticket
using a TLS renegotiation handshake that occurs after a secure tunnel
has been established by a previous handshake. This may help address
some privacy and unlinkability issues in some environments.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Acknowledgements</span>
The authors would like to thank the following people for their help
with preparing and reviewing this document: Eric Rescorla, Mohamad
Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew,
Rob Dugal, Russ Housley, Amir Herzberg, Bernard Aboba, and members of
the TLS working group.
[<a id="ref-CSSC">CSSC</a>] describes a solution that is very similar to the one described
in this document and gives a detailed analysis of the security
considerations involved. [<a href="./rfc2712" title=""Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)"">RFC2712</a>] describes a mechanism for using
Kerberos [<a href="./rfc4120" title=""The Kerberos Network Authentication Service (V5)"">RFC4120</a>] in TLS ciphersuites, which helped inspire the use
of tickets to avoid server state. [<a href="./rfc4851" title=""The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)"">RFC4851</a>] makes use of a similar
mechanism to avoid maintaining server state for the cryptographic
tunnel. [<a href="#ref-SC97" title=""Stateless Connections"">SC97</a>] also investigates the concept of stateless sessions.
The authors would also like to thank Jan Nordqvist, who found the
encoding error in <a href="./rfc4507">RFC 4507</a>, corrected by this document. In addition
Nagendra Modadugu, Wan-Teh Chang, and Michael D'Errico provided
useful feedback during the review of this document.
<span class="grey">Salowey, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5077">RFC 5077</a> Stateless TLS Session Resumption January 2008</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
IANA has assigned a TLS extension number of 35 to the SessionTicket
TLS extension from the TLS registry of ExtensionType values defined
in [<a href="./rfc4366" title=""Transport Layer Security (TLS) Extensions"">RFC4366</a>].
IANA has assigned a TLS HandshakeType number 4 to the
NewSessionTicket handshake type from the TLS registry of
HandshakeType values defined in [<a href="./rfc4346" title=""The Transport Layer Security (TLS) Protocol Version 1.1"">RFC4346</a>].
This document does not require any actions or assignments from IANA.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2246">RFC2246</a>] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
<a href="./rfc2246">RFC 2246</a>, January 1999.
[<a id="ref-RFC4346">RFC4346</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", <a href="./rfc4346">RFC 4346</a>, April 2006.
[<a id="ref-RFC4366">RFC4366</a>] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", <a href="./rfc4366">RFC 4366</a>, April 2006.
[<a id="ref-RFC4507">RFC4507</a>] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", <a href="./rfc4507">RFC 4507</a>, May 2006.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-AES">AES</a>] National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", Federal Information Processing
Standards (FIPS) Publication 197, November 2001.
[<a id="ref-ANON">ANON</a>] Pfitzmann, A. and M. Hansen, "Anonymity, Unlinkability,
Unobservability, Pseudonymity, and Identity Management - A
Consolidated Proposal for Terminology", <a href="http://dud.inf.tu-dresden.de/literatur/">http://</a>
<a href="http://dud.inf.tu-dresden.de/literatur/">dud.inf.tu-dresden.de/literatur/</a>
Anon_Terminology_v0.26-1.pdf Version 0.26, December 2005.
<span class="grey">Salowey, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5077">RFC 5077</a> Stateless TLS Session Resumption January 2008</span>
[<a id="ref-CBC">CBC</a>] National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation -
Methods and Techniques", NIST Special Publication 800-38A,
December 2001.
[<a id="ref-CSSC">CSSC</a>] Shacham, H., Boneh, D., and E. Rescorla, "Client-side
caching for TLS", Transactions on Information and System
Security (TISSEC) , Volume 7, Issue 4, November 2004.
[<a id="ref-RFC2712">RFC2712</a>] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", <a href="./rfc2712">RFC 2712</a>,
October 1999.
[<a id="ref-RFC4086">RFC4086</a>] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", <a href="https://www.rfc-editor.org/bcp/bcp106">BCP 106</a>, <a href="./rfc4086">RFC 4086</a>, June 2005.
[<a id="ref-RFC4120">RFC4120</a>] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", <a href="./rfc4120">RFC 4120</a>,
July 2005.
[<a id="ref-RFC4279">RFC4279</a>] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", <a href="./rfc4279">RFC 4279</a>,
December 2005.
[<a id="ref-RFC4634">RFC4634</a>] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", <a href="./rfc4634">RFC 4634</a>, July 2006.
[<a id="ref-RFC4851">RFC4851</a>] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", <a href="./rfc4851">RFC 4851</a>,
May 2007.
[<a id="ref-SC97">SC97</a>] Aura, T. and P. Nikander, "Stateless Connections",
Proceedings of the First International Conference on
Information and Communication Security (ICICS '97) , 1997.
<span class="grey">Salowey, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5077">RFC 5077</a> Stateless TLS Session Resumption January 2008</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Discussion of Changes to <a href="./rfc4507">RFC 4507</a></span>
<a href="./rfc4507">RFC 4507</a> [<a href="./rfc4507" title=""Transport Layer Security (TLS) Session Resumption without Server-Side State"">RFC4507</a>] defines a mechanism to resume a TLS session
without maintaining server side state by specifying an encrypted
ticket that is maintained on the client. The client presents this
ticket to the server in a SessionTicket hello extension. The
encoding in <a href="./rfc4507">RFC 4507</a> used the XDR style encoding specified in TLS
[<a href="./rfc4346" title=""The Transport Layer Security (TLS) Protocol Version 1.1"">RFC4346</a>].
An error in the encoding caused the specification to differ from
deployed implementations. At the time of this writing there are no
known implementations that follow the encoding specified in <a href="./rfc4507">RFC 4507</a>.
This update to <a href="./rfc4507">RFC 4507</a> aligns the document with these currently
deployed implementations.
Erroneous encoding in <a href="./rfc4507">RFC 4507</a> resulted in two length fields; one for
the extension contents and one for the ticket itself. Hence, for a
ticket that is 256 bytes long and begins with the hex value FF FF,
the encoding of the extension would be as follows according to <a href="./rfc4507">RFC</a>
<a href="./rfc4507">4507</a>:
00 23 Ticket Extension type 35
01 02 Length of extension contents
01 00 Length of ticket
FF FF .. .. Actual ticket
The update proposed in this document reflects what implementations
actually encode, namely it removes the redundant length field. So,
for a ticket that is 256 bytes long and begins with the hex value FF
FF, the encoding of the extension would be as follows according to
this update:
00 23 Extension type 35
01 00 Length of extension contents (ticket)
FF FF .. .. Actual ticket
A server implemented according to <a href="./rfc4507">RFC 4507</a> receiving a ticket
extension from a client conforming to this document would interpret
the first two bytes of the ticket as the length of this ticket. This
will result in either an inconsistent length field or in the
processing of a ticket missing the first two bytes. In the first
case, the server should reject the request based on a malformed
length. In the second case, the server should reject the ticket
based on a malformed ticket, incorrect key version, or failed
decryption. A server implementation based on this update receiving
an <a href="./rfc4507">RFC 4507</a> extension would interpret the first length field as the
<span class="grey">Salowey, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5077">RFC 5077</a> Stateless TLS Session Resumption January 2008</span>
length of the ticket and include the second two length bytes as the
first bytes in the ticket, resulting in the ticket being rejected
based on a malformed ticket, incorrect key version, or failed
decryption.
Note that the encoding of an empty SessionTicket extension was
ambiguous in <a href="./rfc4507">RFC 4507</a>. An <a href="./rfc4507">RFC 4507</a> implementation may have encoded
it as:
00 23 Extension type 35
00 02 Length of extension contents
00 00 Length of ticket
or it may have encoded it the same way as this update:
00 23 Extension type 35
00 00 Length of extension contents
A server wishing to support <a href="./rfc4507">RFC 4507</a> clients should respond to an
empty SessionTicket extension encoded the same way as it received it.
A server implementation can construct tickets such that it can detect
an <a href="./rfc4507">RFC 4507</a> implementation, if one existed, by including a cookie at
the beginning of the tickets that can be differentiated from a valid
length. For example, if an implementation constructed tickets to
start with the hex values FF FF, then it could determine where the
ticket begins and determine the length correctly from the type of
length fields present.
This document makes a few additional changes to <a href="./rfc4507">RFC 4507</a> listed
below.
o Clarifying that the server can allow session resumption using a
ticket without issuing a new ticket in <a href="#section-3.1">Section 3.1</a>.
o Clarifying that the lifetime is relative to when the ticket is
received in <a href="#section-3.3">section 3.3</a>.
o Clarifying that the NewSessionTicket handshake message is included
in the hash generated for the Finished messages in <a href="#section-3.3">Section 3.3</a>.
o Clarifying the interaction with TLS Session ID in <a href="#section-3.4">Section 3.4</a>.
o Recommending the use of SHA-256 for the integrity protection of
the ticket in <a href="#section-4">Section 4</a>.
o Clarifying that additional data can be included in the
StatePlaintext structure in <a href="#section-4">Section 4</a>.
<span class="grey">Salowey, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc5077">RFC 5077</a> Stateless TLS Session Resumption January 2008</span>
Authors' Addresses
Joseph Salowey
Cisco Systems
2901 3rd Ave
Seattle, WA 98121
US
EMail: jsalowey@cisco.com
Hao Zhou
Cisco Systems
4125 Highlander Parkway
Richfield, OH 44286
US
EMail: hzhou@cisco.com
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
EMail: pasi.eronen@nokia.com
Hannes Tschofenig
Nokia Siemens Networks
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Hannes.Tschofenig@nsn.com
<span class="grey">Salowey, et al. Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc5077">RFC 5077</a> Stateless TLS Session Resumption January 2008</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
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, THE IETF TRUST 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.
Intellectual Property
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 procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
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
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
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.
Salowey, et al. Standards Track [Page 20]
</pre>
|
