idnits 2.17.1 draft-hummen-dtls-extended-session-resumption-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5246], [RFC5077]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC5077, but the abstract doesn't seem to directly say this. It does mention RFC5077 though, so this could be OK. -- The draft header indicates that this document updates RFC5246, but the abstract doesn't seem to directly say this. It does mention RFC5246 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5077, updated by this document, for RFC5378 checks: 2007-06-12) (Using the creation date from RFC5246, updated by this document, for RFC5378 checks: 2006-03-02) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 18, 2013) is 3840 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 426, but not defined -- Looks like a reference, but probably isn't: '8' on line 475 -- Looks like a reference, but probably isn't: '16' on line 473 -- Looks like a reference, but probably isn't: '48' on line 506 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-08 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DICE R. Hummen, Ed. 3 Internet-Draft COMSYS, RWTH Aachen 4 Updates: 5077, 5246 (if approved) J. Gilger 5 Intended status: Experimental IT-Security, RWTH Aachen 6 Expires: April 21, 2014 H. Shafagh 7 ETH Zurich 8 October 18, 2013 10 Extended DTLS Session Resumption for Constrained Network Environments 11 draft-hummen-dtls-extended-session-resumption-01 13 Abstract 15 This draft defines two extensions for the existing session resumption 16 mechanisms of TLS that specifically apply to Datagram TLS (DTLS) in 17 constrained network environments. Session resumption type 18 negotiation enables the client and the server to explicitly agree on 19 the session resumption mechanism for subsequent handshakes, thus 20 avoiding unnecessary overheads occurring with the existing 21 specifications. Session resumption without client-side state 22 additionally enables a constrained DTLS client to resume a session 23 without the need to maintain state while the session is inactive. 24 The extensions defined in this draft update [RFC5077] and [RFC5246]. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 21, 2014. 49 Copyright Notice 51 Copyright (c) 2013 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Session Resumption Type Negotiation . . . . . . . . . . . . . 5 68 2.1. Protocol . . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.2. ResumptionType Extension . . . . . . . . . . . . . . . . 7 70 3. Session Resumption Without Client-Side State . . . . . . . . 8 71 3.1. Protocol . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4. Revised Recommended Ticket Construction . . . . . . . . . . . 10 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 5.1. Session Resumption Type Negotiation . . . . . . . . . . . 12 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 77 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 8.1. Version 1 . . . . . . . . . . . . . . . . . . . . . . . . 13 79 8.2. Version 0 . . . . . . . . . . . . . . . . . . . . . . . . 13 80 9. Informative References . . . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 The complex processing of DTLS handshake packets and the non- 86 negligible computational overhead of cryptographic handshake 87 operations - especially in case of public-key cryptography - render 88 the use of the DTLS protocol in constrained network environments 89 challenging. One of the main goals of the DICE WG therefore is to 90 reduce computation and transmission overheads by defining a 91 lightweight DTLS profile that considers the special characteristics 92 of constrained network environments. 94 In addition to these efforts that mainly target the properties of the 95 base protocol, DTLS extensions afford a further adaptation of the 96 protocol to constrained network environments. Session resumption as 97 defined in [RFC5077] and [RFC5246] denotes one of these extensions. 98 Session resumption is useful in the following scenarios considering 99 constrained environments: 101 o On-path soft-state middleboxes: Middleboxes such as stateful 102 firewalls may require periodic keep-alive messages to allow for a 103 bidirectional packet flow. If application data is transmitted in 104 significantly larger time intervals than the keep-alive interval, 105 session resumption allows to reduce the overall transmission 106 overhead throughout the lifetime of a constrained device by 107 tearing down a connection and resuming it when required. 109 o Short-lived server sessions: Especially large-scale Internet 110 services often employ short-lived server sessions at the security 111 layer to efficiently handle a multitude of clients in parallel. 112 For periodic application data transfers, this implies that 113 constrained clients need to perform the full DTLS handshake on a 114 regular basis. With session resumption, constrained clients can 115 leverage a less complex abbreviated handshake to resume a session 116 at decreased computation and transmission cost. 118 o Limited server memory: A constrained server, e.g., a constrained 119 CoAP server [I-D.ietf-core-coap], may be equipped with 120 insufficient memory resources to handle connections for multiple 121 clients in parallel. Session resumption allows to efficiently 122 manage the limited memory for the per session security context by 123 tearing down and resuming a session when required. 125 However, not surprisingly, the existing session resumption 126 specifications have not specifically been designed with constrained 127 devices (client and/or server) and networks in mind. More precisely, 128 the abbreviated handshake in [RFC5246] requires both communication 129 end-points to store session state across connections 130 opportunistically. As a result of this opportunism, a constrained 131 device may store its session state without a return on its memory 132 investment if the DTLS peer did not maintain session state across 133 connections as well. This is due to the lack of explicit session 134 resumption signaling during the full handshake. 136 [RFC5077] enables a DTLS server to offload its state to the DTLS 137 client for safe-keeping while the session is inactive. This 138 mechanism largely supports the resource asymmetry when a constrained 139 DTLS server communicates with an unconstrained DTLS client. However, 140 it falls short for the reverse resource asymmetry, i.e., when a 141 constrained DTLS client communicates with an unconstrained DTLS 142 server. To leverage the vast resource difference between the DTLS 143 client and the DTLS server in constrained network environments, there 144 is the additional need for session resumption without client-side 145 state. 147 Moreover, the roles of a DTLS client and a DTLS server may not always 148 be readily apparent. For example, a CoAP server may not be 149 restricted to the single role of a DTLS server, but may need to re- 150 establish connections to other nodes due to asynchronous 151 communication as provided by the CoAP Observe extension 152 [I-D.ietf-core-observe]. In such situations, the CoAP server would 153 act as a DTLS client. Hence, session resumption with state 154 offloading also has to cover this interchangeability in roles at the 155 DTLS layer. However, this is currently not possible when purely 156 relying on session resumption as defined in [RFC5077]. 158 Finally, the recommended ticket structure for stored session state as 159 defined in [RFC5077] does not yet fully consider constrained network 160 environments. As a result, especially certificate-based 161 authentication leads to large ticket structures if the 162 recommendations are followed. This in turn considerably increases 163 transmission and memory overhead, thus requiring revised 164 recommendations for constrained network environments. 166 To overcome the above shortcomings in constrained network 167 environments, this document proposes two extensions for the existing 168 session resumption mechanisms: 170 1. session resumption type negotiation, and 172 2. session resumption without client-side state. 174 Session resumption type negotiation enables the DTLS peers to 175 explicitly negotiate the use and the type of the session resumption 176 mechanism for the subsequent DTLS handshakes. As a result, 177 opportunistic storing of session state is no longer required and an 178 agreement for a specific state offloading type becomes possible. 179 Moreover, this document specifies the required handshake signaling 180 for session resumption without client-side state. This enables 181 unconstrained DTLS servers to store session state on behalf of 182 constrained DTLS clients. In combination with the existing session 183 resumption extension specified in [RFC5077], this also allows for 184 session resumption when the client and server roles change at the 185 DTLS layer. 187 Regarding the proposed protocol extensions, this document aims at 188 keeping the changes to [RFC5077] minimal. To this end, the existing 189 SessionTicket extension and the NewSessionTicket message are reused. 190 Moreover, while this document only refers to the DTLS protocol, the 191 defined extensions are similarly applicable to the TLS protocol. 193 2. Session Resumption Type Negotiation 195 Regarding session resumption with an abbreviated DTLS handshake as 196 defined in [RFC5246], i.e., when both peers maintain session state 197 across connections, DTLS currently neither provides a guarantee to 198 the client nor to the server during the full handshake that the peer 199 is in fact willing to store session state beyond the lifetime of the 200 current connection. Specifically, the DTLS peers only discover 201 during the subsequent handshake if both of them kept their session 202 state for session resumption. However, this delayed signaling may 203 lead to a constrained device needlessly occupying its constrained 204 memory resources with state information while the session is 205 inactive. 207 In case of session resumption without server-side state [RFC5077], 208 the client already signals its support for this extension early 209 during the initial full handshake by including the SessionTicket 210 extension in the ClientHello message. The server acknowledges its 211 own support by including the SessionTicket in the ServerHello 212 message. Towards the end of the full handshake, the server then 213 offloads its state to the client by means of the NewSessionTicket 214 message. Due to this explicit negotiation in the current handshake, 215 the client and the server do not store session state unnecessarily. 217 With the introduction of a third session resumption type in this 218 document, i.e., session resumption without client-side state (see 219 Section 3), this simple signaling mechanism introduced in [RFC5077] 220 no longer suffices to clearly differentiate between the available 221 session resumption types early during the Hello-phase of the DTLS 222 handshake. Hence, additional signaling is required when reusing the 223 SessionTicket extension for the signaling of session resumption 224 without client-side state. 226 To explicitly signal the use of session resumption and to 227 differentiate between the different state offloading types, this 228 document defines a new session resumption type negotiation extension 229 for the ClientHello and ServerHello messages, i.e., the 230 ResumptionType extension. This ResumptionType extension enables the 231 DTLS peers to clearly indicate which of the three available 232 resumption types they support: 234 1. The regular abbreviated handshake (with client & server state), 236 2. session resumption without client-side state, and 238 3. session resumption without server-side state. 240 The integration of this extension in the DTLS handshake and the 241 extension structure are defined in the following sections. 243 2.1. Protocol 245 The DTLS client and server use the ResumptionType extension in order 246 to negotiate the session resumption type for the subsequent 247 handshakes. The remaining handshake concludes as originally 248 specified for the negotiated session resumption type. Hence, the 249 session resumption type negotiation extends, but does not modify 250 existing DTLS session resumption mechanisms. 252 Client Server 253 ------ ------ 255 ClientHello 256 (ResumptionType extension) --------> 258 <-------- HelloVerifyRequest 260 ClientHello 261 (ResumptionType extension) --------> 263 ServerHello 264 (ResumptionType extension) 265 <-------- ... 267 ... 269 Figure 1: Message Flow for Negotiating the Session Resumption Type 270 during a DTLS Handshake 272 The client adds the ResumptionType extension to its ClientHello 273 message and indicates its supported session resumption types in the 274 order of preference. The server concludes the negotiation by 275 selecting its preferred session resumption type considering the 276 preference of the client. It signals the chosen session resumption 277 type in the ResumptionType extension of the ServerHello message. 279 Each ResumptionType negotiation refers to the subsequent session 280 resumptions. Hence, a session resumption handshake MAY omit the 281 session resumption type negotiation. In this case, both client and 282 server simply keep using the previously negotiated session resumption 283 type, as long as the client and server roles have not changed. 284 However, it is important to note that both, client and server, can 285 resume the same DTLS session. Hence, if the roles of the client and 286 the server have changed when the session is resumed, the 287 ResumptionType implicitly adapts accordingly in order to keep storing 288 session state at the same communication end-point as negotiated 289 before. More precisely, in case of a negotiated session resumption 290 without client-side state, state offloading follows the specified 291 signaling of session resumption without server-side state. A 292 negotiated session resumption without server-side state adapts vice 293 versa. If both peers maintain session state with the regular 294 abbreviated handshake, the change in roles does not impact this 295 resumption type. 297 2.2. ResumptionType Extension 299 The ResumptionType extension is based on [RFC6066]. The 300 "extension_data" field of this extension SHALL contain 301 "ResumptionTypeList" where: 303 enum { 304 abbreviated(0), 305 without_client_state(1), 306 without_server_state(2), (255) 307 } ResumptionType; 309 struct { 310 ResumptionType resumption_type_list<1..3> 311 } ResumptionTypeList; 313 The ResumptionType extension may be sent in the ClientHello and 314 ServerHello messages. The client adds the ResumptionType extension 315 to the ClientHello message. It thereby orders the resumption types 316 by preference. When receiving the ResumptionType extension, the 317 server select its preferred session resumption type considering the 318 indicated preference of the client. The server then signals the 319 chosen session resumption type in the ResumptionType extension of the 320 ServerHello message. Thus, the ResumptionType extension in the 321 ServerHello message MUST only contain a single session resumption 322 type. 324 The ResumptionType extension has been assigned the number of "TBD". 326 3. Session Resumption Without Client-Side State 328 Traditional client-server communication protocols and architectures 329 typically make the assumption of a number of clients opening 330 connections to a single more powerful server. Scaling the system 331 means to ensure that the server can handle the load of additional 332 clients. With this mindset, [RFC5077] enables a DTLS server to 333 remain stateless while the session is inactive by offloading its 334 session state to the DTLS client. 336 However, in the domain of constrained network environments, not only 337 do some devices have vastly different capabilities and resources, 338 they regularly take the role of both client and server. In terms of 339 higher-layer protocols such as CoAP, the distinction between client 340 and server may still be intact while on the lower layers a device 341 will have to accept inbound as well as establish outbound 342 connections. This fact blurs the distinction between client and 343 server roles at the DTLS layer. 345 For the communication of two devices with highly differing 346 capabilities and resources, e.g., an unconstrained Internet host and 347 a constrained device, enabling the constrained device to save scarce 348 memory resources may actually help the overall system, regardless of 349 whether it is acting as a server or a client. For example, a memory- 350 constrained client may be able to maintain several connections 351 sequentially, but not in parallel. Likewise, a CoAP server may take 352 the role of a DTLS server during the initial session establishment, 353 but re-establish the session as a DTLS client due to the asynchronous 354 communication with CoAP Observe. To support these and other 355 scenarios, this document introduces session resumption without 356 client-side state in addition to the session resumption mechanisms 357 defined in [RFC5077] and [RFC5246]. 359 3.1. Protocol 361 For session resumption without client-side state, the DTLS client and 362 server first agree on this session resumption type with a mandatory 363 session resumption type negotiation in the full handshake. The 364 client then sends its encrypted session state to the server. 366 Client Server 367 ------ ------ 368 ClientHello 369 (ResumptionType extension) 370 (empty SessionTicket extension) --------> 372 <-------- HelloVerifyRequest 374 ClientHello 375 (ResumptionType extension) 376 (empty SessionTicket extension) --------> 378 ServerHello 379 (ResumptionType extension) 380 (empty SessionTicket extension) 381 ServerKeyExchange* 382 CertificateRequest* 383 <-------- ServerHelloDone 385 Certificate* 386 ClientKeyExchange 387 CertificateVerify* 388 NewSessionTicket 389 [ChangeCipherSpec] 390 Finished --------> 392 [ChangeCipherSpec] 393 <-------- Finished 395 Application Data <-------> Application Data 397 Figure 2: Message Flow for Full Handshake Issuing New Session Ticket 399 In the full DTLS handshake, the ClientHello message contains a 400 ResumptionType extension indicating the willingness of the client to 401 perform session resumption without client-side state. The 402 ClientHello message additionally contains an empty SessionTicket 403 extension. This extension is defined in Section 3.2 of [RFC5077]. 405 If supported and preferred by the server, the server echoes back this 406 type in the ResumptionType extension of the ServerHello reply. The 407 client then sends its encrypted session state to the server in the 408 NewSessionTicket message of the fifth message flight. The ticket 409 contains the necessary information for the client to resume the 410 session at a later point in time. The NewSessionTicket message is 411 defined in Section 3.3 of [RFC5077]. 413 Client Server 414 ------ ------ 415 ClientHello 416 (ResumptionType extension) 417 (empty SessionTicket extension) --------> 419 ServerHello 420 (ResumptionType extension) 421 (SessionTicket extension) 422 [ChangeCipherSpec] 423 <-------- Finished 425 NewSessionTicket 426 [ChangeCipherSpec] 427 Finished --------> 429 Application Data <-------> Application Data 431 Figure 3: Message Flow for Abbreviated Handshake Using New Session 432 Ticket 434 When the stateless client subsequently connects to the same server, 435 it is oblivious of the previous full handshake. Hence, the 436 ClientHello message in the abbreviated handshake is equal to the full 437 handshake. On receipt of the ClientHello message, the server tries 438 to re-identify the client (e.g. based on the source IP address or 439 other identifying information) and searches for a matching session 440 ticket. If it finds a matching ticket, it sends the stored session 441 ticket to the client. To this end, the server adds the SessionTicket 442 extension with the corresponding session ticket to its ServerHello 443 reply. 445 If the client is able to authenticate and to decrypt the 446 SessionTicket received by the server, it resumes the previous 447 session. The client can additionally send its new session state in 448 the NewSessionTicket message for the subsequent handshake. 450 4. Revised Recommended Ticket Construction 452 Section 4 of [RFC5077] recommends a ticket construction that may lead 453 to an excessive ticket size for constrained network environments. 454 This recommended ticket construction, for example, includes an entire 455 certificate chain as the client identity in case of certificate-based 456 authentication. The aim of this section is to provide revised 457 recommendations for the ticket construction that take device and 458 network constraints into account. 460 As defined in [RFC5077], the NewSessionTicket handshake message 461 contains a lifetime value and a session ticket. The lifetime 462 indicates the number of seconds until the ticket expires relative to 463 the time of ticket issuing. The ticket structure is opaque to the 464 peer storing the ticket while the session is active. Only the ticket 465 issuer needs to access the session ticket information. Hence, the 466 specific structure of the ticket is not subject to interoperability 467 concerns. 469 The revised session ticket has the following structure: 471 struct { 472 opaque key_name[8]; 473 opaque iv[16]; 474 opaque encrypted_state<0..2^16-1>; 475 opaque ccm_auth_tag[8]; 476 } ticket; 478 Regarding the above structure, key_name refers to the key used by the 479 ticket issuer to protect the confidentiality and integrity of the 480 offloaded session state information. To allow for early detection of 481 forged session tickets during the session resumption handshake, the 482 key_name SHOULD be generated randomly. The ticket issuer MUST take 483 care that it does not use the same key_name for different keys. 485 The session state information of the revised ticket is protected by 486 AES CCM with an 8 byte authentication tag (see [RFC3610]). The 487 integrity protection includes the key_name and the encrypted_state. 488 The key_name and iv are transmitted in plain. The shorter 489 authentication tag compared to the recommendation in [RFC5077] 490 denotes a trade-off between a lower ticket expansion and a higher 491 probability of forgery. Moreover, with AES CCM, the stateless peer 492 only needs to maintain a single 128-bit key instead of one 128-bit 493 key for encryption and one 256-bit key for authentication purposes. 495 The StatePlaintext structure describes the unencrypted session state 496 information carried in a session ticket. In this document, we define 497 a new structure for the peer_identity, which is called 498 client_identity in [RFC5077]. The renaming was deemed necessary due 499 to the fact that a ticket can now be generated by a client as well as 500 a server. 502 struct { 503 ProtocolVersion protocol_version; 504 CipherSuite cipher_suite; 505 CompressionMethod compression_method; 506 opaque master_secret[48]; 507 PeerIdentity peer_identity; 508 uint32 timestamp; 509 } StatePlaintext; 510 enum { 511 anonymous(0), 512 certificate_based(1), 513 psk(2) 514 } PeerAuthenticationType; 516 struct { 517 PeerAuthenticationType peer_authentication_type; 518 select (PeerAuthenticationType) { 519 case anonymous: struct {}; 520 case certificate_based: 521 uint32 certificate_lifetime_hint; 522 case psk: 523 opaque psk_identity<0..2^16-1>; 524 }; 525 } PeerIdentity; 527 Here, the certificate_lifetime_hint indicates how long the validated 528 certificate chain remains valid. To this end, the 529 certificate_lifetime_hint holds the minimum lifetime for all 530 certificates in a chain in seconds. If the time indicated in the 531 lifetime hint is exceeded, a full handshake MUST be performed. 532 Additional information may need to be added to the ticket structure 533 in future revisions of this document in order to enable a state- 534 offloading peer to validate the certificate status via a Certificate 535 Revocation List (CRL) or the Online Certificate Status Protocol 536 (OCSP) during the session resumption handshake. 538 5. Security Considerations 540 Session resumption without client-side state as defined in this 541 document is strongly based on [RFC5077]. As such, the security 542 considerations discussed in Section 5 of [RFC5077] apply here as 543 well. Additional security considerations stem from the introduction 544 of the new ResumptionType extension. 546 5.1. Session Resumption Type Negotiation 548 The ResumptionType extension is part of the regular DTLS handshake 549 and thus covered by the hash in the Finished message. Hence, an on- 550 path attacker cannot enforce a particular session resumption type 551 without the peers noticing. 553 6. IANA Considerations 554 This document specifies the new ResumptionType extension for DTLS. 555 The corresponding IANA considerations will be addressed in a future 556 version of this document. 558 7. Acknowledgements 560 The authors would like to thank Shahid Raza for the discussion and 561 comments regarding the extensions defined in this document. We 562 especially acknowledge the prototyping and implementation efforts of 563 Hossein Shafagh that confirm the feasibility of the proposed 564 extensions in constrained network environments. Finally, the authors 565 appreciate the feedback and suggestions of Sandeep Kumar. This work 566 is funded by the DFG Cluster of Excellence on Ultra High- Speed 567 Mobile Information and Communication (UMIC). 569 8. Changelog 571 8.1. Version 1 573 - Add scenarios where session resumption is beneficial 575 - Add section on ticket construction 577 - Minor editorial changes 579 8.2. Version 0 581 - Initial version 583 9. Informative References 585 [I-D.ietf-core-coap] 586 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 587 Application Protocol (CoAP)", draft-ietf-core-coap-18 588 (work in progress), June 2013. 590 [I-D.ietf-core-observe] 591 Hartke, K., "Observing Resources in CoAP", draft-ietf- 592 core-observe-08 (work in progress), February 2013. 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, March 1997. 597 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 598 CBC-MAC (CCM)", RFC 3610, September 2003. 600 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 601 "Transport Layer Security (TLS) Session Resumption without 602 Server-Side State", RFC 5077, January 2008. 604 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 605 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 607 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 608 Extension Definitions", RFC 6066, January 2011. 610 Authors' Addresses 612 Rene Hummen (editor) 613 Chair of Communication and Distributed Systems, RWTH Aachen 614 Ahornstrasse 55 615 Aachen 52074 616 Germany 618 Email: hummen@comsys.rwth-aachen.de 619 URI: http://www.comsys.rwth-aachen.de/team/rene-hummen/ 621 Johannes Gilger 622 Research Group IT-Security, RWTH Aachen 623 Mies-van-der-Rohe Strasse 15 624 Aachen 52074 625 Germany 627 Email: gilger@itsec.rwth-aachen.de 628 URI: http://itsec.rwth-aachen.de/people/johannes-gilger/ 630 Hossein Shafagh 631 ETH Zurich 632 Universitaetstrasse 6 633 Zurich 8092 634 Switzerland 636 Email: shafgah@inf.ethz.ch 637 URI: http://www.inf.ethz.ch/~mshafagh/