[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

DICE                                                      R. Hummen, Ed.
Internet-Draft                                                 J. Gilger
Updates: 5077, 5246 (if approved)                 RWTH Aachen University
Intended status: Experimental                              July 15, 2013
Expires: January 16, 2014


 Extended DTLS Session Resumption for Constrained Network Environments
            draft-hummen-dtls-extended-session-resumption-00

Abstract

   This draft defines two extensions for the existing session resumption
   mechanisms of TLS that specifically apply to Datagram TLS (DTLS) in
   constrained network environments.  Session resumption type
   negotiation enables the client and the server to explicitly agree on
   the session resumption mechanism for subsequent handshakes, thus
   avoiding unnecessary overheads occurring with the existing
   specifications.  Session resumption without client-side state
   additionally enables a constrained DTLS client to resume a session
   without the need to maintain state while the session is inactive.
   The extensions defined in this draft update [RFC5077] and [RFC5246].

Requirements Language

   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 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 16, 2014.

Copyright Notice




Hummen & Gilger         Expires January 16, 2014                [Page 1]


Internet-Draft      DTLS-Extended-Session-Resumption           July 2013


   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Session Resumption Type Negotiation . . . . . . . . . . . . .   4
     2.1.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  ResumptionType Extension  . . . . . . . . . . . . . . . .   6
   3.  Session Resumption Without Client-Side State  . . . . . . . .   7
     3.1.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Revised Recommended Ticket Construction . . . . . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     5.1.  Session Resumption Type Negotiation . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   8.  Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Version 0 . . . . . . . . . . . . . . . . . . . . . . . .  10
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   The complex processing of DTLS handshake packets and the non-
   negligible computational overhead of cryptographic handshake
   operations - especially in case of public-key cryptography - render
   the use of the DTLS protocol in constrained network environments
   challenging.  One of the main goals of the DICE WG, if approved,
   therefore is to reduce computation and transmission overheads by
   defining a lightweight DTLS profile that considers the special
   characteristics of constrained network environments.

   In addition to these efforts that mainly target the properties of the
   base protocol, DTLS extensions afford a further adaptation of the
   protocol to constrained network environments.  Session resumption as
   defined in [RFC5077] and [RFC5246] denotes one of these extensions.
   However, not surprisingly, the existing session resumption
   specifications have not specifically been designed with constrained



Hummen & Gilger         Expires January 16, 2014                [Page 2]


Internet-Draft      DTLS-Extended-Session-Resumption           July 2013


   devices (client and/or server) and networks in mind.  More precisely,
   the abbreviated handshake in [RFC5246] requires both communication
   end-points to store session state across connections
   opportunistically.  As a result of this opportunism, a constrained
   device may store its session state without a return on its memory
   investment if the DTLS peer did not maintain session state across
   connections as well.  This is due to the lack of explicit session
   resumption signaling during the full handshake.

   [RFC5077] enables a DTLS server to offload its state to the DTLS
   client for safe-keeping while the session is inactive.  This
   mechanism largely supports the resource asymmetry when a constrained
   DTLS server communicates with an unconstrained DTLS client.  However,
   it falls short for the reverse resource asymmetry, i.e., when a
   constrained DTLS client communicates with an unconstrained DTLS
   server.  To leverage the vast resource difference between the DTLS
   client and the DTLS server in constrained network environments, there
   is the additional need for session resumption without client-side
   state.

   Moreover, the roles of a DTLS client and a DTLS server may not always
   be readily apparent.  For example, a CoAP server [I-D.ietf-core-coap]
   may not be restricted to the single role of a DTLS server, but may
   need to re-establish connections to other nodes due to asynchronous
   communication as provided by the CoAP Observe extension
   [I-D.ietf-core-observe].  In such situations, the CoAP server would
   act as a DTLS client.  Hence, session resumption with state
   offloading also has to cover this interchangeability in roles at the
   DTLS layer.  However, this is currently not possible when purely
   relying on session resumption as defined in [RFC5077].

   Finally, the recommended ticket structure for stored session state as
   defined in [RFC5077] does not yet fully consider constrained network
   environments.  As a result, especially certificate-based
   authentication leads to large ticket structures if the
   recommendations are followed.  This in turn considerably increases
   transmission and memory overhead, thus requiring revised
   recommendations for constrained network environments.

   To overcome the above shortcomings in constrained network
   environments, this document proposes two extensions for the existing
   session resumption mechanisms:

   1.  session resumption type negotiation, and

   2.  session resumption without client-side state.





Hummen & Gilger         Expires January 16, 2014                [Page 3]


Internet-Draft      DTLS-Extended-Session-Resumption           July 2013


   Session resumption type negotiation enables the DTLS peers to
   explicitly negotiate the use and the type of the session resumption
   mechanism for the subsequent DTLS handshakes.  As a result,
   opportunistic storing of session state is no longer required and an
   agreement for a specific state offloading type becomes possible.
   Moreover, this document specifies the required handshake signaling
   for session resumption without client-side state.  This enables
   unconstrained DTLS servers to store session state on behalf of
   constrained DTLS clients.  In combination with the existing session
   resumption extension specified in [RFC5077], this also allows for
   session resumption when the client and server roles change at the
   DTLS layer.

   Regarding the proposed protocol extensions, this document aims at
   keeping the changes to [RFC5077] minimal.  To this end, the existing
   SessionTicket extension and the NewSessionTicket message are reused.
   Moreover, while this document only refers to the DTLS protocol, the
   defined extensions are similarly applicable to the TLS protocol.

   Future versions of this document will additionally address revised
   recommendations for the ticket construction that specifically
   consider constrained network environments.

2.  Session Resumption Type Negotiation

   Regarding session resumption with an abbreviated DTLS handshake as
   defined in [RFC5246], i.e., when both peers maintain session state
   across connections, DTLS currently neither provides a guarantee to
   the client nor to the server during the full handshake that the peer
   is in fact willing to store session state beyond the lifetime of the
   current connection.  Specifically, the DTLS peers only discover
   during the subsequent handshake if both of them kept their session
   state for session resumption.  However, this delayed signaling may
   lead to a constrained device needlessly occupying its constrained
   memory resources with state information while the session is
   inactive.

   In case of session resumption without server-side state [RFC5077],
   the client already signals its support for this extension early
   during the initial full handshake by including the SessionTicket
   extension in the ClientHello message.  The server acknowledges its
   own support by including the SessionTicket in the ServerHello
   message.  Towards the end of the full handshake, the server then
   offloads its state to the client by means of the NewSessionTicket
   message.  Due to this explicit negotiation in the current handshake,
   the client and the server do not store session state unnecessarily.





Hummen & Gilger         Expires January 16, 2014                [Page 4]


Internet-Draft      DTLS-Extended-Session-Resumption           July 2013


   With the introduction of a third session resumption type in this
   document, i.e., session resumption without client-side state (see
   Section 3), this simple signaling mechanism introduced in [RFC5077]
   no longer suffices to clearly differentiate between the available
   session resumption types early during the Hello-phase of the DTLS
   handshake.  Hence, additional signaling is required when reusing the
   SessionTicket extension for the signaling of session resumption
   without client-side state.

   To explicitly signal the use of session resumption and to
   differentiate between the different state offloading types, this
   document defines a new session resumption type negotiation extension
   for the ClientHello and ServerHello messages, i.e., the
   ResumptionType extension.  This ResumptionType extension enables the
   DTLS peers to clearly indicate which of the three available
   resumption types they support:

   1.  The regular abbreviated handshake (with client & server state),

   2.  session resumption without client-side state, and

   3.  session resumption without server-side state.

   The integration of this extension in the DTLS handshake and the
   extension structure are defined in the following sections.

2.1.  Protocol

   The DTLS client and server use the ResumptionType extension in order
   to negotiate the session resumption type for the subsequent
   handshakes.  The remaining handshake concludes as originally
   specified for the negotiated session resumption type.  Hence, the
   session resumption type negotiation extends, but does not modify
   existing DTLS session resumption mechanisms.

   Client                                                  Server
   ------                                                  ------

   ClientHello
   (ResumptionType extension)    -------->

                                 <--------     HelloVerifyRequest

   ClientHello
   (ResumptionType extension)    -------->

                                                      ServerHello
                                       (ResumptionType extension)



Hummen & Gilger         Expires January 16, 2014                [Page 5]


Internet-Draft      DTLS-Extended-Session-Resumption           July 2013


                                 <--------                    ...

                                    ...

    Figure 1: Message Flow for Negotiating the Session Resumption Type
                          during a DTLS Handshake

   The client adds the ResumptionType extension to its ClientHello
   message and indicates its supported session resumption types in the
   order of preference.  The server concludes the negotiation by
   selecting its preferred session resumption type considering the
   preference of the client.  It signals the chosen session resumption
   type in the ResumptionType extension of the ServerHello message.

   Each ResumptionType negotiation refers to the subsequent session
   resumptions.  Hence, a session resumption handshake MAY omit the
   session resumption type negotiation.  In this case, both client and
   server simply keep using the previously negotiated session resumption
   type, as long as the client and server roles have not changed.
   However, it is important to note that both, server and client, can
   resume the same DTLS session.  Hence, if the roles of the client and
   the server have changed when the session is resumed, the
   ResumptionType implicitly adapts accordingly in order to keep storing
   session state at the same communication end-point as negotiated
   before.  More precisely, in case of a negotiated session resumption
   without client-side state, state offloading follows the specified
   signaling of session resumption without server-side state.  A
   negotiated session resumption without server-side state adapts vice
   versa.  If both peers maintain session state with the regular
   abbreviated handshake, the change in roles does not impact this
   resumption type.

2.2.  ResumptionType Extension

   The ResumptionType extension is based on [RFC6066].  The
   "extension_data" field of this extension SHALL contain
   "ResumptionTypeList" where:

   enum {
       abbreviated(0),
       without_client_state(1),
       without_server_state(2), (255)
   } ResumptionType;

   struct {
       ResumptionType resumption_type_list<1..3>
   } ResumptionTypeList;




Hummen & Gilger         Expires January 16, 2014                [Page 6]


Internet-Draft      DTLS-Extended-Session-Resumption           July 2013


   The ResumptionType extension may be sent in the ClientHello and
   ServerHello messages.  The client adds the ResumptionType extension
   to the ClientHello message.  It thereby orders the resumption types
   by preference.  When receiving the ResumptionType extension, the
   server select its preferred session resumption type considering the
   indicated preference of the client.  The server then signals the
   chosen session resumption type in the ResumptionType extension of the
   ServerHello message.  Thus, the ResumptionType extension in the
   ServerHello message MUST only contain a single session resumption
   type.

   The ResumptionType extension has been assigned the number of "TBD".

3.  Session Resumption Without Client-Side State

   Traditional client-server communication protocols and architectures
   typically make the assumption of a number of clients opening
   connections to a single more powerful server.  Scaling the system
   means to ensure that the server can handle the load of additional
   clients.  With this mindset, [RFC5077] enables a DTLS server to
   remain stateless while the session is inactive by offloading its
   session state to the DTLS client.

   However, in the domain of constrained network environments, not only
   do some devices have vastly different capabilities and resources,
   they regularly take the role of both client and server.  In terms of
   higher-layer protocols such as CoAP, the distinction between client
   and server may still be intact while on the lower layers a device
   will have to accept inbound as well as establish outbound
   connections.  This fact blurs the distinction between client and
   server roles at the DTLS layer.

   For the communication of two devices with highly differing
   capabilities and resources, e.g., an unconstrained Internet host and
   a constrained device, enabling the constrained device to save scarce
   memory resources may actually help the overall system, regardless of
   whether it is acting as a server or a client.  For example, a memory-
   constrained client may be able to maintain several connections
   sequentially, but not in parallel.  Likewise, a CoAP server may take
   the role of a DTLS server during the initial session establishment,
   but re-establish the session as a DTLS client due to the asynchronous
   communication with CoAP Observe.  To support these and other
   scenarios, this document introduces session resumption without
   client-side state in addition to the session resumption mechanisms
   defined in [RFC5077] and [RFC5246].

3.1.  Protocol




Hummen & Gilger         Expires January 16, 2014                [Page 7]


Internet-Draft      DTLS-Extended-Session-Resumption           July 2013


   For session resumption without client-side state, the DTLS client and
   server first agree on this session resumption type with a mandatory
   session resumption type negotiation in the full handshake.  The
   client then sends its encrypted session state to the server.

   Client                                                  Server
   ------                                                  ------

   ClientHello
   (ResumptionType extension)
   (empty SessionTicket extension) -------->

                                   <--------   HelloVerifyRequest

   ClientHello
   (ResumptionType extension)
   (empty SessionTicket extension) -------->

                                                      ServerHello
                                       (ResumptionType extension)
                                  (empty SessionTicket extension)
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone

   Certificate*
   ClientKeyExchange
   CertificateVerify*
   NewSessionTicket
   [ChangeCipherSpec]
   Finished                        -------->

                                               [ChangeCipherSpec]
                                   <--------             Finished

   Application Data                <------->     Application Data

   Figure 2: Message Flow for Full Handshake Issuing New Session Ticket

   In the full DTLS handshake, the ClientHello message contains a
   ResumptionType extension indicating the willingness of the client to
   perform session resumption without client-side state.  The
   ClientHello message additionally contains an empty SessionTicket
   extension.  This extension is defined in Section 3.2 of [RFC5077].

   If supported and preferred by the server, the server echoes back this
   type in the ResumptionType extension of the ServerHello reply.  The
   client then sends its encrypted session state to the server in the



Hummen & Gilger         Expires January 16, 2014                [Page 8]


Internet-Draft      DTLS-Extended-Session-Resumption           July 2013


   NewSessionTicket message of the fifth message flight.  The ticket
   contains the necessary information for the client to resume the
   session at a later point in time.  The NewSessionTicket message is
   defined in Section 3.3 of [RFC5077].

   Client                                                  Server
   ------                                                  ------

   ClientHello
   (ResumptionType extension)
   (empty SessionTicket extension) -------->

                                                      ServerHello
                                       (ResumptionType extension)
                                        (SessionTicket extension)
                                               [ChangeCipherSpec]
                                   <--------             Finished

   NewSessionTicket
   [ChangeCipherSpec]
   Finished                        -------->

   Application Data                <------->     Application Data

    Figure 3: Message Flow for Abbreviated Handshake Using New Session
                                  Ticket

   When the stateless client subsequently connects to the same server,
   it is oblivious of the previous full handshake.  Hence, the
   ClientHello message in the abbreviated handshake is equal to the full
   handshake.  On receipt of the ClientHello message, the server tries
   to re-identify the client (e.g.  based on the source IP address or
   other identifying information) and searches for a matching session
   ticket.  If it finds a matching ticket, it sends the stored session
   ticket to the client.  To this end, the server adds the SessionTicket
   extension with the corresponding session ticket to its ServerHello
   reply.

   If the client is able to authenticate and to decrypt the
   SessionTicket received by the server, it resumes the previous
   session.  The client can additionally send its new session state in
   the NewSessionTicket message for the subsequent handshake.









Hummen & Gilger         Expires January 16, 2014                [Page 9]


Internet-Draft      DTLS-Extended-Session-Resumption           July 2013


4.  Revised Recommended Ticket Construction

   Section 4 of [RFC5077] recommends a ticket construction that may lead
   to an excessive ticket size for constrained network environments.
   This recommended ticket construction, for example, includes an entire
   certificate chain as the client identity in case of certificate-based
   authentication.  The aim of this section is to provide revised
   recommendations for the ticket construction that take device and
   network constraints into account.  These recommendations will be
   addressed in a future version of this document.

5.  Security Considerations

   Session resumption without client-side state as defined in this
   document is strongly based on [RFC5077].  As such, the security
   considerations discussed in Section 5 of [RFC5077] apply here as
   well.  Additional security considerations stem from the introduction
   of the new ResumptionType extension.

5.1.  Session Resumption Type Negotiation

   The ResumptionType extension is part of the regular DTLS handshake
   and thus covered by the hash in the Finished message.  Hence, an on-
   path attacker cannot enforce a particular session resumption type
   without the peers noticing.

6.  IANA Considerations

   This document specifies the new ResumptionType extension for DTLS.
   The corresponding IANA considerations will be addressed in a future
   version of this document.

7.  Acknowledgements

   The authors would like to thank Hossein Shafagh and Shahid Raza for
   the discussion and comments regarding the extensions defined in this
   document.  We especially acknowledge the prototyping and
   implementation efforts of Hossein Shafagh that confirm the
   feasibility of the proposed extensions in constrained network
   environments.  Finally, the authors appreciate the feedback and
   suggestions of Sandeep Kumar.

8.  Changelog

8.1.  Version 0

   - Initial Version




Hummen & Gilger         Expires January 16, 2014               [Page 10]


Internet-Draft      DTLS-Extended-Session-Resumption           July 2013


9.  Informative References

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., and C. Bormann, "Constrained
              Application Protocol (CoAP)", draft-ietf-core-coap-18
              (work in progress), June 2013.

   [I-D.ietf-core-observe]
              Hartke, K., "Observing Resources in CoAP", draft-ietf-
              core-observe-08 (work in progress), February 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
              "Transport Layer Security (TLS) Session Resumption without
              Server-Side State", RFC 5077, January 2008.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC6066]  Eastlake, D., "Transport Layer Security (TLS) Extensions:
              Extension Definitions", RFC 6066, January 2011.

Authors' Addresses

   Rene Hummen (editor)
   RWTH Aachen University
   Ahornstrasse 55
   Aachen  52074
   Germany

   Email: hummen@cs.rwth-aachen.de
   URI:   http://www.comsys.rwth-aachen.de/team/rene-hummen/


   Johannes Gilger
   RWTH Aachen University
   Mies-van-der-Rohe Strasse 15
   Aachen  52074
   Germany

   Email: gilger@itsec.rwth-aachen.de
   URI:   http://itsec.rwth-aachen.de/people/johannes-gilger/







Hummen & Gilger         Expires January 16, 2014               [Page 11]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/