The IESG has approved the following document: - 'Transport Layer Security Session Resumption without Server-Side State ' <draft-salowey-tls-ticket-07.txt> as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-salowey-tls-ticket-07.txt 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 _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
