Protocol Action: 'Transport Layer Security Session Resumption without Server-Side State' to Proposed Standard

[The IESG <[e-mail]>]

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 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce