Technical Summary
This protocol provides a mechanism to a server avoid maintaining per-
client session state for TLS session resumption. This allows for the
session resumption optimized handshake to be used with TLS servers
that have limited memory and processing power compared to the number
of clients they handle.
Working Group Summary
This document was discussed in the TLS working group. The WG chair
asked for a review period from 9-Sep-2005 to 1-Oct-2005. In general,
the feedback from this review was positive. Several comments were
received from reviewers that led to clarifications. No outstanding
issues remain.
Protocol Quality
The protocol has undergone revision based on TLS WG review and
external feedback. Initially the protocol description only contained
the SessionTicket hello extension for presentation of the ticket to
the server. This part of the protocol has been implemented as part of
EAP-FAST (draft-cam-winget-eap-fast) for which there are multiple
interoperable implementations. The ticket issuing handshake message
was added to the document based on contributions and feedback from
Pasi Eronen, Hannes Tschofenig, and Eric Rescorla. The security
implications of this approach are analyzed in [CSSC] which describes a
similar protocol.
[CSSC]
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.
Note to RFC Editor
Please add the following text to the end of section 3.1.
NEW:
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 as shown below (this
flow is identitical to figure 1 in RFC 2246 except for the session
ticket extension in the first message):
ClientHello
(SessionTicket extension) -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
[ChangeCipherSpec]
<-------- Finished
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
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 the first flow in this section except the SessionTicket
extension in the Client Hello is not empty):
ClientHello
(SessionTicket extension) -------->
ServerHello
(empty SessionTicket extension)
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data