idnits 2.17.1 draft-guballa-tls-terminology-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 4, 2016) is 2761 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4347' is mentioned on line 401, but not defined ** Obsolete undefined reference: RFC 4347 (Obsoleted by RFC 6347) -- Looks like a reference, but probably isn't: '48' on line 820 == Unused Reference: 'RFC5746' is defined on line 1122, but no explicit reference was found in the text == Unused Reference: 'ITU-T X.213' is defined on line 1142, but no explicit reference was found in the text == Unused Reference: 'ITU-T X.214' is defined on line 1146, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 WG TLS Jens Guballa (ed.) 2 Internet Draft Juergen Stoetzer-Bradler 3 Intended status: Informational Nokia 4 Expires: April 2017 He Bing 5 Alcatel-Lucent Shanghai Bell 6 October 4, 2016 8 Terminology related to TLS and DTLS 9 draft-guballa-tls-terminology-05.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 This document may contain material from IETF Documents or IETF 17 Contributions published or made publicly available before November 18 10, 2008. The person(s) controlling the copyright in some of this 19 material may not have granted the IETF Trust the right to allow 20 modifications of such material outside the IETF Standards Process. 21 Without obtaining an adequate license from the person(s) controlling 22 the copyright in such materials, this document may not be modified 23 outside the IETF Standards Process, and derivative works of it may 24 not be created outside the IETF Standards Process, except to format 25 it for publication as an RFC or to translate it into languages other 26 than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as 36 reference material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on March 4, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. 57 Abstract 59 Purpose of this RFC is to provide a central place of all key terms 60 as used by the various RFCs on protocols TLS and DTLS. 62 Table of Contents 64 1. Introduction...................................................4 65 1.1. Background and motivation - Status of (D)TLS terminology..4 66 1.2. Purpose...................................................4 67 1.3. Scope.....................................................4 68 1.4. Relation with Internet Security Glossary..................4 69 1.5. Disclaimer................................................5 70 2. Conventions used in this document..............................5 71 2.1. Prescriptive language: modal verbs........................5 72 2.2. Notion of '(D)TLS'........................................5 73 2.3. Additional terminology....................................5 74 2.4. Abbreviations used........................................5 75 3. Inventory of (D)TLS terms......................................6 76 3.1. Terminology related to endpoint entities..................6 77 3.1.1. Term "(D)TLS endpoint"...............................6 78 3.1.2. Term "(D)TLS protocol implementation"................6 79 3.2. Terminology related to session/connection entities........7 80 3.2.1. Term "(D)TLS connection".............................7 81 3.2.2. Term "Semi-permannt (D)TLS session"..................7 82 3.2.3. Term "Transient (D)TLS session"......................8 83 3.2.4. Term "(D)TLS session"................................8 84 3.2.5. Term "DTLS association"..............................9 85 3.3. Terminology related to session/connection endpoint entities 86 ..............................................................10 87 3.3.1. Term "(D)TLS connection endpoint"...................10 88 3.3.2. Term "(D)TLS connection endpoint identifier"........10 89 3.3.3. Term "(D)TLS client connection endpoint"............11 90 3.3.4. Term "(D)TLS server connection endpoint"............11 91 3.4. Terminology related to protocol procedures...............12 92 3.4.1. Term "(D)TLS message"...............................12 93 3.4.2. Term "(D)TLS client role"...........................12 94 3.4.3. Term "(D)TLS server role"...........................13 95 3.4.4. Term "(D)TLS message sequence"......................13 96 3.4.5. Term "(D)TLS full handshake"........................13 97 3.4.6. Term "(D)TLS abbreviated handshake".................14 98 3.4.7. Term "Data transfer ready (D)TLS connection"........14 99 3.4.8. Term "Semi-permanent (D)TLS client session endpoint 100 state".....................................................15 101 3.4.9. Term "Semi-permanent (D)TLS server session endpoint 102 state".....................................................15 103 3.4.10. Term "Transient (D)TLS client session endpoint state" 104 ...........................................................15 105 3.4.11. Term "Transient (D)TLS server session endpoint state" 106 ...........................................................16 107 3.4.12. Term "(D)TLS client session endpoint state"........16 108 3.4.13. Term "(D)TLS server session endpoint state"........18 109 3.4.14. Term "Resumable (D)TLS client session endpoint state" 110 ...........................................................19 111 3.4.15. Term "Resumable (D)TLS server session endpoint state" 112 ...........................................................20 113 3.4.16. Term "Resumable (D)TLS session"....................20 114 3.4.17. Term "Resumed (D)TLS session"......................21 115 3.4.18. Term "(D)TLS session resumption"...................22 116 3.4.19. Term "(D)TLS session identifier"...................23 117 3.5. Colloquially used terms..................................23 118 3.5.1. Term "(D)TLS session re-establishment"..............23 119 3.5.2. Term "(D)TLS session rekeying"......................24 120 3.5.3. Term "(D)TLS rehandshake"...........................24 121 4. Security Considerations.......................................25 122 5. IANA Considerations...........................................25 123 6. References....................................................25 124 6.1. Normative References.....................................25 125 6.2. Informative References...................................25 126 7. CHANGE LOG....................................................26 127 7.1. Initial draft name "draft-guballa-tls-terminology".......26 128 7.1.1. Version "-00".......................................26 129 7.1.2. Changes against "-00"...............................26 130 7.1.3. Changes against "-01"...............................27 131 7.1.4. Changes against "-02"...............................27 132 7.1.5. Changes against "-03"...............................27 133 Appendix A. Hierarchical Framework...............................28 134 A.1. Framework for (D)TLS Connection related Definitions......29 135 A.2. Framework for (D)TLS Session related Terms...............30 136 A.3. Framework for (D)TLS Session Resumption and (D)TLS Session 137 renegotiation.................................................31 139 1. Introduction 141 1.1. Background and motivation - Status of (D)TLS terminology 143 The definition of the TLS protocol [RFC5246] is slightly unusual in 144 the area of protocol specifications, because more like a software 145 description with a high-level data model, perhaps written after an 146 implementation. The RFC does not provide explicit definitions for 147 the main terms, rather providing a glossary in Appendix B/[RFC5246]. 148 The Glossary itself provides descriptions of the main terms, but not 149 any definitions. At least not definitions at the detailed level as 150 required for protocol specifications, which implies a precise 151 linkage to objects as e.g. used within protocol and service data 152 units and protocol control information elements. 154 E.g., there are concerns and ongoing debates about the semantics of 155 some "handshake" related protocol procedures (catchwords "re- 156 establishment", "resumption", "renegotiation", "rekeying"). 157 Associated to these procedural aspects is the underlying question 158 concerning the precise distinction between (D)TLS session and (D)TLS 159 connection level. 161 Without any doubt, TLS itself is a pretty successful, mature and 162 well-proven technology. The production of (D)TLS term definition 163 implies hence reverse engineering of (D)TLS RFCs. 165 1.2. Purpose 167 The purpose of this document is to provide a central place of key 168 terms as used in TLS and DTLS RFCs. The definitions should be 169 concise, but detailed enough from perspective of a protocol model, 170 and of course fully consistent and compatible with the existing 171 RFCs. 173 1.3. Scope 175 The focus is put on key terms which caused some controversy so far. 177 1.4. Relation with Internet Security Glossary 179 The Internet Security Glossary [RFC4949] provides a comprehensive 180 set of security related terms. However, protocol specific terms 181 such as for DTLS and TLS are not part of the glossary. Hence, there 182 is actually not any overlapping between this document and [RFC4949]. 184 1.5. Disclaimer 186 Where there are discrepancies between this document and existing 187 RFCs on TLS and DTLS, the usage and "semantics" of these (D)TLS RFCs 188 take precedence over those described in this document. 190 2. Conventions used in this document 192 2.1. Prescriptive language: modal verbs 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in RFC-2119 [RFC2119]. 198 2.2. Notion of '(D)TLS' 200 The prefix '(D)TLS' indicate terms common to both protocols. The 201 prefixes 'TLS' and 'DTLS' indicate protocol specific aspects. 203 2.3. Additional terminology 205 : 207 209 2.4. Abbreviations used 211 AL Local (IP) Address 213 AR Remote (IP) Address 215 DTLS Datagram Transport Layer Security 217 (D)TLS DTLS or TLS 219 FQDN Fully Qualified Domain Name 221 L4 (Protocol) Layer 4 (= IP Transport layer) 223 PL Local (L4) Port 225 PR Remote (L4) Port 227 RL Record Layer 228 T Transport (L4) protocol 230 TCP Transmission Control Protocol 232 TLS Transport Layer Security 234 UDP User Datagram Protocol 236 3. Inventory of (D)TLS terms 238 3.1. Terminology related to endpoint entities 240 3.1.1. Term "(D)TLS endpoint" 242 Definition: 244 An instance of a (D)TLS protocol implementation with exactly one 245 local IP (transport) address. A (D)TLS endpoint is housing one or 246 multiple (D)TLS connection endpoints, which are acting either as 247 (D)TLS clients or as (D)TLS servers (i.e., "(D)TLS client 248 connection endpoint" and "(D)TLS server connection endpoint") when 249 executing the (D)TLS handshake protocol. 251 Reference: 253 None. 255 Term relations: 257 Definition based on terms "(D)TLS protocol implementation" (3.1.2. 258 ), "(D)TLS client connection endpoint" (3.3.3. ), and "(D)TLS 259 server connection endpoint" (3.3.4. ). 261 3.1.2. Term "(D)TLS protocol implementation" 263 Definition: 265 A (software or hardware) based implementation of the TLS protocol 266 as specified in [RFC5246] or of the DTLS protocol as specified in 267 [RFC6347] (DTLS) and is always associated to a real system. 269 Reference: 271 [RFC5246] and [RFC6347]. 273 Term relations: 275 Definition based on term "real system" [ITU-T X.200]. 277 3.2. Terminology related to session/connection entities 279 3.2.1. Term "(D)TLS connection" 281 Definition: 283 A cooperative relationship among a pair of (D)TLS capable systems, 284 represented by a (D)TLS client connection endpoint and a (D)TLS 285 server connection endpoint (NOTE 1). A (D)TLS connection allows 286 the execution of an establishment procedure given by either a 287 (D)TLS full handshake or a (D)TLS abbreviated handshake (on 288 request of the (D)TLS served user instance at (D)TLS client side). 289 Thus, the mode of communication of the (D)TLS connection could be 290 considered as connection-oriented (i.e., a (D)TLS connection is 291 stateful, e.g., at the top-level by the 2-state model {IDLE, 292 ESTABLISHED}). 294 Notes: 296 Thus, formally the (D)TLS connection is a set of two 8-tuples, 297 refer to "(D)TLS connection endpoint". 299 Reference: 301 The term "connection" is part of the glossary of [RFC5246]. 303 Term relations: 305 Definition based on terms "(D)TLS protocol implementation" (3.1.2. 306 ), "(D)TLS client connection endpoint" (3.3.3. ), and "(D)TLS 307 server connection endpoint" (3.3.4. ). 309 3.2.2. Term "Semi-permannt (D)TLS session" 311 Definition: 313 The pair of a semi-permanent (D)TLS client session endpoint state 314 and a semi-permanent (D)TLS server session endpoint state, coupled 315 by the (D)TLS full handshake procedure which was executed across 316 the associated (D)TLS connection. 318 Reference: 320 None. 322 Term relations: 324 Definition based on terms "semi-permanent (D)TLS client session 325 endpoint state" (3.4.8. ), "semi-permanent (D)TLS server session 326 endpoint state" (3.4.9. ), "(D)TLS full handshake" (3.4.5. ), and 327 "(D)TLS connection" (3.2.1. ). 329 3.2.3. Term "Transient (D)TLS session" 331 Definition: 333 The pair of a transient (D)TLS client session endpoint state and a 334 transient (D)TLS server session endpoint state, coupled by the 335 (D)TLS full handshake procedure which was executed across the 336 associated (D)TLS connection. 338 The transient (D)TLS client session endpoint state information and 339 transient (D)TLS server session endpoint state information is 340 immediately deleted after the successful (D)TLS full handshake 341 procedure. 343 Reference: 345 None. 347 Term relations: 349 Definition based on terms "transient (D)TLS client session 350 endpoint state" (3.4.10. ), "transient (D)TLS server session 351 endpoint state" (3.4.11. ), "(D)TLS full handshake" (3.4.5. ), and 352 "(D)TLS connection" (3.2.1. ). 354 3.2.4. Term "(D)TLS session" 356 Definition: 358 A semi-permanent (D)TLS session or transient (D)TLS session. 360 Notes: 362 Thus, a (D)TLS session is a transformed (D)TLS connection after 363 the successful execution of a (D)TLS full handshake procedure, 364 constituted by the pair of (D)TLS client session endpoint state 365 and a (D)TLS server session endpoint state. A (D)TLS session is 366 consequently an association between the two (D)TLS session 367 endpoints. The mode of communication of the (D)TLS session could 368 be considered as connectionless (i.e., a (D)TLS session is either 369 existing or not). 371 The nature of a (D)TLS session (from (D)TLS endpoint perspective) 372 is either volatile (i.e., the local (D)TLS session information 373 would be immediately discarded after a (D)TLS handshake procedure) 374 or semi-permanent (in case of resumable (D)TLS sessions). 376 Notably, a (D)TLS session may still exist after one or even both 377 (D)TLS connection endpoints, which did exchange the (D)TLS full 378 handshake messages from which the related (D)TLS session states 379 were derived from, are already destroyed. 381 The (D)TLS role (client or server) is a (D)TLS session level 382 characteristic. (to be confirmed) 384 Reference: 386 The term "session" is part of the glossary of [RFC5246]. 388 Term relations: 390 Definition based on terms "(D)TLS semi-permanent session" (3.2.2. 391 ), and "(D)TLS transient (volatile) session" (3.2.3. ). 393 3.2.5. Term "DTLS association" 395 Definition: 397 Synonym to "DTLS connection". 399 Reference: 401 Term introduced by [RFC4347] and still used in [RFC6347]. 403 Term relations: 405 Definition equal to "(D)TLS connection" (3.2.1. ). 407 3.3. Terminology related to session/connection endpoint entities 409 3.3.1. Term "(D)TLS connection endpoint" 411 Definition: 413 A part of an instance of a (D)TLS protocol implementation, which 414 is able to send and receive (D)TLS messages, and which is 415 associated to exactly one 8-tuple being composed of 417 1) a creation point in time tc, 419 2) a destruction point in time td, 421 3) a non-empty local IP address AL, 423 4) a non-empty local L4 port PL, 425 5) an empty or non-empty remote IP address AR, 427 6) an empty or non-empty remote L4 port PR, 429 7) a non-empty L4 transport protocol T, and 431 8) the protocol string "TLS" or "DTLS". 433 Notes: 435 If FQDNs are used as (D)TLS endpoint identifiers, then an 436 additional requirement on the (D)TLS connection endpoint could be 437 that AL is one of the IP addresses associated to the (D)TLS 438 endpoint's FQDN. 440 Reference: 442 [RFC5246], [RFC5764] 444 Term relations: 446 Definition based on terms "(D)TLS protocol implementation" (3.1.2. 447 ) and "(D)TLS message" (3.4.1. ). 449 3.3.2. Term "(D)TLS connection endpoint identifier" 451 Definition: 453 The local IP transport address and indication of "TLS/L4" or 454 "DTLS/L4" protocol stack, i.e., the 4-tuple of {AL, PL, T, 455 "TLS"/"DTLS"} from the (D)TLS connection endpoint. 457 Notes: 459 Parameter "L4" is required because (D)TLS is a L4 independent 460 protocol, hence a (D)TLS capable system could offer multiple 461 (D)TLS endpoints with different L4 protocols. 463 Reference: 465 None. 467 Term relations: 469 Definition based on terms "(D)TLS protocol implementation" (3.1.2. 470 ) and "(D)TLS message" (3.4.1. ). 472 3.3.3. Term "(D)TLS client connection endpoint" 474 Definition: 476 A (D)TLS connection endpoint which sends a (D)TLS message 477 containing a ClientHello handshake structure to another (D)TLS 478 connection endpoint. 480 Reference: 482 The TLS ClientHello handshake structure is defined in [RFC5246] 483 while the DTLS ClientHello handshake structure is defined in 484 [RFC6347]. 486 Term relations: 488 Definition based on terms "(D)TLS connection endpoint" (3.3.1. ) 489 and "(D)TLS message" (3.4.1. ). 491 3.3.4. Term "(D)TLS server connection endpoint" 493 Definition: 495 A (D)TLS connection endpoint which receives a (D)TLS message 496 containing a ClientHello handshake structure and subsequently 497 sends a (D)TLS message containing a ServerHello handshake 498 structure back to that other (D)TLS connection endpoint. 500 Reference: 502 The (D)TLS ServerHello handshake structure is defined in 503 [RFC5246]. 505 Term relations: 507 Definition based on terms "(D)TLS connection endpoint" (3.3.1. ) 508 and "(D)TLS message" (3.4.1. ). 510 3.4. Terminology related to protocol procedures 512 3.4.1. Term "(D)TLS message" 514 Definition: 516 A unit of (D)TLS-RL user data as produced by the (D)TLS handshake 517 protocol, the (D)TLS alert protocol or the (D)TLS change cipher 518 spec protocol. 520 Notes: 522 Application Data are excluded from this definition. 524 Reference: 526 Clause 6.2.1 of [RFC5246] defines the message type as an 527 enumeration ("ContentType"). It is contained in the structured 528 type "TLSPlaintext".Term relations: 530 3.4.2. Term "(D)TLS client role" 532 Definition: 534 A (D)TLS connection endpoint is said to assume the (D)TLS client 535 role, if it is a (D)TLS client connection endpoint. 537 Reference: 539 The term "client" is part of the glossary of [RFC5246]. 541 Term relations: 543 Definition based on terms "(D)TLS connection endpoint" (3.3.1. ) 544 and "(D)TLS client connection endpoint" (3.3.3. ). 546 3.4.3. Term "(D)TLS server role" 548 Definition: 550 A (D)TLS connection endpoint is said to assume the (D)TLS server 551 role, if it is a (D)TLS server connection endpoint. 553 Reference: 555 The term "server" is part of the glossary of [RFC5246]. 557 Term relations: 559 Definition based on terms "(D)TLS connection endpoint" (3.3.1. ) 560 and "(D)TLS server connection endpoint" (3.3.4. ). 562 3.4.4. Term "(D)TLS message sequence" 564 Definition: 566 A finite sequence of (D)TLS messages. 568 Reference: 570 None. 572 Term relations: 574 Definition based on term "(D)TLS message" (3.4.1. ). 576 3.4.5. Term "(D)TLS full handshake" 578 Definition: 580 A (D)TLS message sequence where the first (D)TLS message contains 581 ClientHello structure and if the sequence constitutes a successful 582 (D)TLS full handshake message flow as specified in clause 7.3, 583 Figure 1 of [RFC5246]. 585 Reference: 587 A full TLS handshake is presented in [RFC5246], clause 7.3, Figure 588 1. The DTLS' specifics are presented in [RFC6347], clause 4.2.1. 590 Term relations: 592 Definition based on term "(D)TLS message" (3.4.1. ). 594 3.4.6. Term "(D)TLS abbreviated handshake" 596 Definition: 598 A (D)TLS message sequence where the first (D)TLS message contains 599 ClientHello structure and if the sequence constitutes a successful 600 (D)TLS abbreviated handshake message flow as specified in clause 601 7.3, Figure 2 of [RFC5246]. 603 Reference: 605 An abbreviated TLS handshake is presented in [RFC5246], clause 606 7.3, Figure 2. The DTLS' specifics are presented in [RFC6347], 607 clause 4.2.1. 609 Term relations: 611 Definition based on term "(D)TLS message" (3.4.1. ). 613 3.4.7. Term "Data transfer ready (D)TLS connection" 615 Definition: 617 A (D)TLS connection after the successful execution of a (D)TLS 618 full handshake or a (D)TLS abbreviated handshake procedure. 620 Notes: 622 The notion of "DATA TRANSFER READY" refers to a specific state of 623 the (D)TLS connection and is synonym to the notion of 624 "ESTABLISHED". The general term "DATA TRANSFER READY" matches 625 both connectionless and connection-oriented type of connections, 626 see [ITU-T X.213 and X.214]. 628 Reference: 630 None. 632 Term relations: 634 Definition based on terms "(D)TLS connection" (3.2.1. ), "(D)TLS 635 full handshake" (3.4.5. ) and "(D)TLS abbreviated handshake" 636 (3.4.6. ). 638 3.4.8. Term "Semi-permanent (D)TLS client session endpoint state" 640 Definition: 642 A (D)TLS client session endpoint state if its (D)TLS session 643 identifier value is non-empty. 645 Reference: 647 The term "session identifier" is part of the glossary of 648 [RFC5246]. 650 Term relations: 652 Refer to "(D)TLS client session endpoint state" (3.4.12. ) and 653 "(D)TLS session identifier" (3.4.19. 655 3.4.9. Term "Semi-permanent (D)TLS server session endpoint state" 657 Definition: 659 A (D)TLS server session endpoint state if its (D)TLS session 660 identifier value is non-empty. 662 Reference: 664 The term "session identifier" is part of the glossary of 665 [RFC5246]. 667 Term relations: 669 Refer to "(D)TLS server session endpoint state" (3.4.13. ) and 670 "(D)TLS session identifier" (3.4.19. 672 3.4.10. Term "Transient (D)TLS client session endpoint state" 674 Definition: 676 A (D)TLS client session endpoint state if its (D)TLS session 677 identifier value is empty. 679 Reference: 681 The term "session identifier" is part of the glossary of 682 [RFC5246]. 684 Term relations: 686 Refer to "(D)TLS client session endpoint state" (3.4.12. ) and 687 "(D)TLS session identifier" (3.4.19. 689 3.4.11. Term "Transient (D)TLS server session endpoint state" 691 Definition: 693 A (D)TLS server session endpoint state if its (D)TLS session 694 identifier value is empty. 696 Reference: 698 The term "session identifier" is part of the glossary of 699 [RFC5246]. 701 Term relations: 703 Refer to "(D)TLS server session endpoint state" (3.4.13. 3.4.12. ) 704 and "(D)TLS session identifier" (3.4.19. 706 3.4.12. Term "(D)TLS client session endpoint state" 708 Definition: 710 The 17-tuple of following parameter-value pairs, as partially 711 described in [RFC5246]: 713 TLS protocol parameter: Type: 715 1. version: ProtocolVersion 717 2. prf_algorithm: PRFAlgorithm 719 3. bulk_cipher_algorithm: BulkCipherAlgorithm 721 4. cipher_type: CipherType 723 5. enc_key_length: uint8 725 6. block_length: unit8 727 7. fixed_iv_length: unit8 729 8. record_iv_length: unit8 730 9. mac_algorithm: MACAlgorithm 732 10. mac_length: unit8 734 11. mac_key_length: unit8 736 12. compression_algorithm: CompressionMethod 738 13. master_secret: opaque[48] 740 14. session_id: SessionID (NOTE 1) 742 Other parameters: Type: 744 15. creation time tc: time (NOTE 2) 746 16. destruction time td: time 748 17. server_address: IPaddress (NOTE 3) 750 Notes: 752 1: A (D)TLS client session endpoint state is semi-permanent if and 753 only if its session_id value is non-empty. Hence it is transient 754 if and only if its session_id value is empty. 756 FIX THIS: Session tickets [RFC5077] must be covered as well, 757 reference to "(D)TLS session identifier" should be used.2: While a 758 semi-permanent (D)TLS client session endpoint state's creation 759 point in time correlates with the corresponding (D)TLS full 760 handshake's end time (which is thus a point in time at which both 761 TLS connection endpoints, which exchange the (D)TLS full handshake 762 messages, do still exist), this semi-permanent (D)TLS client 763 session endpoint state's destruction point in time is independent 764 of the destruction points in time of these two (D)TLS connection 765 endpoints. Especially, the semi-permanent (D)TLS client session 766 endpoint state may still exist after one or even both (D)TLS 767 connection endpoints are already destroyed. 769 3: A (D)TLS protocol implementation may add further information to 770 a (D)TLS client session endpoint state, like e.g. the associated 771 (D)TLS server endpoint's source IP address. This additional 772 information may be used by a (D)TLS client connection endpoint in 773 order to decide if an already stored semi-permanent (D)TLS client 774 session endpoint state may be used (may be "resumed") for the 775 establishment of a new (D)TLS connection towards a destination 776 transport address of another (D)TLS endpoint. 778 Reference: 780 The definition of this term is based on the structured type 781 "SecurityParameters" as defined in clause 6.1 of [RFC5246]. 783 Term relations: 785 - 787 3.4.13. Term "(D)TLS server session endpoint state" 789 Definition: 791 The 16-tuple of following parameter-value pairs, as partially 792 described in [RFC5246]: 794 TLS protocol parameter: Type: 796 1. version: ProtocolVersion 798 2. prf_algorithm: PRFAlgorithm 800 3. bulk_cipher_algorithm: BulkCipherAlgorithm 802 4. cipher_type: CipherType 804 5. enc_key_length: uint8 806 6. block_length: unit8 808 7. fixed_iv_length: unit8 810 8. record_iv_length: unit8 812 9. mac_algorithm: MACAlgorithm 814 10. mac_length: unit8 816 11. mac_key_length: unit8 818 12. compression_algorithm: CompressionMethod 820 13. master_secret: opaque[48] 821 14. session_id: SessionID (NOTE 1) 823 Other parameters (NOTE 3): Type: 825 15. creation time tc: time (NOTE 2) 827 16. destruction time td: time 829 Notes: 831 1: A (D)TLS server session endpoint state is semi-permanent if and 832 only if its session_id value is non-empty. Hence it is transient 833 if and only if its session_id value is empty. 835 FIX THIS: Session tickets [RFC5077] must be covered as well, 836 reference to "(D)TLS session identifier" should be used. 838 2: While a semi-permanent (D)TLS server session endpoint state's 839 creation point in time correlates with the corresponding (D)TLS 840 full handshake's end time (which is thus a point in time at which 841 both (D)TLS connection endpoints, which exchange the (D)TLS full 842 handshake messages, do still exist), this semi-permanent (D)TLS 843 server session endpoint state's destruction point in time is 844 independent of the destruction points in time of these two (D)TLS 845 connection endpoints. Especially, the semi-permanent (D)TLS 846 server session endpoint state may still exist after one or even 847 both (D)TLS connection endpoints are already destroyed. 849 3: Difference between the (D)TLS server session endpoint state 850 versus the (D)TLS server session endpoint: the 17th parameter 851 "server address" (refer to 3.4.12. ) is of course missing at the 852 server side. 854 Reference: 856 The definition of this term is based on the structured type 857 "SecurityParameters" as defined in clause 6.1 of [RFC5246]. 859 Term relations: 861 - 863 3.4.14. Term "Resumable (D)TLS client session endpoint state" 865 Definition: 867 Synonym for a semi-permanent (D)TLS client session endpoint state 868 (3.4.8. ). 870 Reference: 872 The term "is resumable" is part of the glossary of [RFC5246]. 874 Term relations: 876 - 878 3.4.15. Term "Resumable (D)TLS server session endpoint state" 880 Definition: 882 Synonym for a semi-permanent (D)TLS server session endpoint state 883 (3.4.9. ). 885 Reference: 887 The term "is resumable" is part of the glossary of [RFC5246]. 889 Term relations: 891 - 893 3.4.16. Term "Resumable (D)TLS session" 895 Definition: 897 Synonym for a semi-permanent (D)TLS session (3.2.2. ). 899 Notes: 901 Expanded term: A (D)TLS session where the (D)TLS server session 902 state as well as the (D)TLS client session state are both 903 resumable. A (D)TLS session state is called resumable, if its 904 (D)TLS session identifier value is non-empty. 906 Reference: 908 The term "is resumable" is part of the glossary of [RFC5246]. 910 Term relations: 912 - 914 3.4.17. Term "Resumed (D)TLS session" 916 Definition: 918 A resumable (D)TLS session after the successful execution of a 919 (D)TLS abbreviated handshake procedure. 921 Notes: 923 1: The (D)TLS session identifier value (of the resumed (D)TLS 924 session) is identical to the previous value of the resumable 925 (D)TLS session. 927 2: The (D)TLS connection, which is established with the (D)TLS 928 abbreviated handshake based on the existing resumable (D)TLS 929 session, may be created while the original (D)TLS connection, 930 which was established via the (D)TLS full handshake from which the 931 resumable (D)TLS client and server session endpoint states and 932 hence the resumable (D)TLS session were derived, is still 933 established, or only after this original (D)TLS connection is 934 already terminated. 936 3: Several new (D)TLS connections may be established using (D)TLS 937 abbreviated handshakes based on the same resumable (D)TLS session. 938 If the first (D)TLS connection is established using an (D)TLS 939 abbreviated handshake based on a resumable (D)TLS session, then we 940 may say that this (D)TLS session becomes a resumed (D)TLS session 941 at this first (D)TLS abbreviated handshake's end time. 943 Reference: 945 The term is introduced in the glossary of [RFC5246], refer to 946 "session_id". 948 Term relations: 950 Definition based on terms "resumable (D)TLS session" (3.4.16. ), 951 and "(D)TLS abbreviated handshake" (3.4.6. ).Term "(D)TLS session 952 renegotiation" 954 Definition: 956 A (D)TLS session level concept which leads, - by the execution of 957 a (D)TLS handshake procedure (full or abbreviated) -, to the 958 update of the (D)TLS protocol status "connection-level" 959 information of an DATA TRANSFER READY (D)TLS connection, for the 960 purpose of the establishment of new cryptographic parameters. 962 Notes: 964 1: The initial (D)TLS full handshake or (D)TLS abbreviated 965 handshake is not regarded as a (D)TLS session renegotiation as 966 this handshake is executed on a (D)TLS connection which is in the 967 state IDLE. After this initial handshake is finished the (D)TLS 968 connection state is changed to DATA TRANSFER READY, and thus all 969 following (D)TLS full handshakes or (D)TLS abbreviated handshakes 970 on that (D)TLS connection are regarded as (D)TLS session 971 renegotiation. The (D)TLS handshake related to a (D)TLS session 972 renegotiation is always cryptographically protected by the current 973 (D)TLS connection state.2: The (D)TLS connection state remains in 974 DATA TRANSFER READY during and after the (D)TLS session 975 renegotiation. 977 Reference: 979 [RFC5246] 981 Term relations: 983 Definition based on terms "(D)TLS full handshake" (3.4.5. ), 984 "(D)TLS abbreviated handshake" (3.4.6. ), and "Data transfer ready 985 (D)TLS connection" (3.4.7. ). 987 3.4.18. Term "(D)TLS session resumption" 989 Definition: 991 A (D)TLS session level concept which represents the execution of a 992 (D)TLS abbreviated handshake procedure on an existing (D)TLS 993 session, i.e., a semi-permanent (D)TLS session, for the purpose of 994 either deriving a further DATA TRANSFER READY (D)TLS connection or 995 updating of an existing DATA TRANSFER READY (D)TLS connection. 997 Reference: 999 [RFC5246], [RFC5764], [RFC5077] 1001 Term relations: 1003 Refer to "Data transfer ready (D)TLS connection" (3.4.7. 3.4.12. 1004 ), "(D)TLS abbreviated handshake" (3.4.6. ), and "Semi-permanent 1005 (D)TLS session" (3.2.2. 3.4.8. ) 1007 3.4.19. Term "(D)TLS session identifier" 1009 Definition: 1011 A (D)TLS protocol parameter representing the identification 1012 allocated to a particular semi-permanent (D)TLS session. 1014 Notes: 1016 1: The definition is consistent and not redefining the explanatory 1017 description of a "session identifier" in the TLS glossary, as 1018 contained in Appendix B/[RFC5246]. 1020 2: This definition may need to be extended by additional 1021 consideration of the session ticket based TLS session resumption 1022 mechanism as defined in [RFC5077]. There would be then two TLS 1023 protocol parameters (session_id and SessionTicket) as possible 1024 identifiers (both protocol parameters are mutually exclusive). 1026 Reference: 1028 [RFC5077] 1030 Term relations: 1032 Definition based on the term "semi-permanent (D)TLS session" 1033 (3.2.2. ). 1035 3.5. Colloquially used terms 1037 This clause provides a list of terms which are not introduced, 1038 described or defined by (D)TLS RFCs, but sometimes used in 1039 discussions or other documents. 1041 3.5.1. Term "(D)TLS session re-establishment" 1043 Definition: 1045 - 1047 Notes: 1049 There does not exist any definition so far. 1051 Reference: 1053 None. 1055 Term relations: 1057 Still open, dependent on definition. 1059 3.5.2. Term "(D)TLS session rekeying" 1061 Definition: 1063 - 1065 Notes: 1067 There doesn't exist any definition so far (to be confirmed). 1068 [RFC5763], clause 6.8 provides a high-level description of a 1069 "rekeying concept" in context of DTLS-based SRTP key management. 1071 Reference: 1073 None. 1075 Term relations: 1077 Still open, dependent on definition. 1079 3.5.3. Term "(D)TLS rehandshake" 1081 Definition: 1083 - 1085 Notes: 1087 There does not exit any definition so far. 1089 Reference: 1091 The term is used in [RFC5764]. 1093 Term relation: 1095 The term can be interpreted as a synonym for "(D)TLS 1096 renegotiation". 1098 4. Security Considerations 1100 FIXTHIS 1102 5. IANA Considerations 1104 FIXTHIS 1106 6. References 1108 6.1. Normative References 1110 [RFC2119] RFC 2119 (03/1997), "Key words for use in RFCs to Indicate 1111 Requirement Levels", BCP 14. 1113 [RFC4949] RFC 4949 (08/2007), "Internet Security Glossary, 1114 Version 2" 1116 [RFC5077] RFC 5077 (01/2008), "Transport Layer Security (TLS) 1117 Session Resumption without Server-Side State" 1119 [RFC5246] RFC 5246 (08/2008), "The Transport Layer Security (TLS) 1120 Protocol, Version 1.2" 1122 [RFC5746] RFC 5746 (02/2010), "Transport Layer Security (TLS) 1123 Renegotiation Indication Extension" 1125 [RFC5763] RFC 5763 (05/2010), "Framework for Establishing a Secure 1126 Real-time Transport Protocol (SRTP) Security Context Using 1127 Datagram Transport Layer Security (DTLS)" 1129 [RFC5764] RFC 5764 (05/2010), "Datagram Transport Layer Security 1130 (DTLS) Extension to Establish Keys for the Secure Real- 1131 time Transport Protocol (SRTP)" 1133 [RFC6347] RFC 6347 (02/2012), "Datagram Transport Layer Security 1134 Version 1.2" 1136 6.2. Informative References 1138 [ITU-T X.200] Recommendation ITU-T X.200 (07/1994), "Information 1139 technology - Open Systems Interconnection - Basic 1140 Reference Model: The basic model." 1142 [ITU-T X.213] Recommendation ITU-T X.213 (10/2001), "Information 1143 technology - Open Systems Interconnection - Network 1144 service definition." 1146 [ITU-T X.214] Recommendation ITU-T X.214 (11/1995), "Information 1147 technology - Open Systems Interconnection - Transport 1148 service definition." 1150 7. CHANGE LOG 1152 7.1. Initial draft name "draft-guballa-tls-terminology" 1154 7.1.1. Version "-00" 1156 Following definition template is used: 1158 Term "" 1160 Definition: 1161 . 1163 Notes: 1164 1166 Reference: 1167 1169 Term relations: 1170 1172 7.1.2. Changes against "-00" 1174 o Editorial changes according to RFC Style Guide 1176 o Hierarchical framework added (appendix A) 1178 o List of authors extended 1180 o Clarification added: handshakes for session renegotiation are 1181 always cryptographically protected 1183 o Reference to RFC5763 added for "(D)TLS session rekeying" 1185 o Clarification of relation with Internet Security Glossary 1186 [RFC4949] 1188 o Missing references fixed 1190 o List of colloquially used terms extended 1192 7.1.3. Changes against "-01" 1194 o No changes 1196 7.1.4. Changes against "-02" 1198 o Author's Addresses updated 1200 7.1.5. Changes against "-03" 1202 o Editor's address updated 1204 7.1.6. Changes against "-04" 1206 o Author's address updated 1208 Appendix A. Hierarchical Framework 1210 This section provides an overview on the hierarchy of the terms 1211 defined in this draft. The dependency is indicated by arrows as 1212 follows: 1214 "foo"--->"bar" indicates that the definition of term "foo" is based 1215 on the term "bar". 1217 A.1. Framework for (D)TLS Connection related Definitions 1219 +-------+ +---------------+ 1220 |(D)TLS | |(D)TLS protocol|<-----------------------+ 1221 |message|<-----+ +->|implementation |<---+ | 1222 +-------+ | | +---------------+ | | 1223 ^ ^ ^ | | ^ | | 1224 | | | +<---|-----|--+<-----+<---+ | | 1225 | | | ^ | | ^ ^ | | | 1226 | | | +----|----|+ | | | | | | 1227 | | | |(D)TLS | | | | +|--|-------------+ | 1228 | | | |connection| | | | |(D)TLS connection| | 1229 | | | |endpoint | | | | |endpoint | | 1230 | | | |identifier| | | | +-----------------+ | 1231 | | | +----------+ | | | ^ ^ ^ | 1232 | | | | | | | | | | 1233 | | +----------+ | | +----|----|--+ | | 1234 | | | | | | | | | | 1235 | +|-------+ | | +|-----------|+ | +|-|----------+ | 1236 | |(D)TLS | | | |(D)TLS client| | |(D)TLS server| | 1237 | |message | | | |connection | | |connection | | 1238 | |sequence|<-+ | | |endpoint | | |endpoint | | 1239 | +--------+ | | | +-------------+ | +-------------+ | 1240 | ^ | | | ^ ^ | ^ ^ | 1241 | | | | | | | | | | | 1242 +|--------|-+ +|--|-----+ | +<-----|---------|----|-----+ | | 1243 |(D)TLS | |(D)TLS | | ^ | | | | | | 1244 |abbreviated| |full | | | +---|---------|----|-----|-->+ | 1245 |handshake | |handshake| | | | | | | | ^ | 1246 +-----------+ +---------+ | | | | +--->+ | | | | 1247 ^ ^ | | | | | ^ | | | | 1248 | | | | | | | | | | | | 1249 +|-------------|+ +---|--|--|+ +|----|+ +|----|+ +|---|--|+ 1250 |Data transfer |---->|(D)TLS | |(D)TLS| |(D)TLS| |(D)TLS | 1251 |ready (D)TLS | |connection| |client| |server| |endpoint| 1252 |connection | +----------+ |role | |role | +--------+ 1253 +---------------+ +------+ +------+ 1255 Figure 1: Terms related to "(D)TLS connection" 1257 A.2. Framework for (D)TLS Session related Terms 1259 +---------+ +----------+ +-----------+ +-----------+ +----------+ 1260 |(D)TLS | |(D)TLS | |(D)TLS srv | |(D)TLS clnt| |(D)TLS | 1261 |full | |connection| |session | |session | |session | 1262 |handshake| +----------+ |endp. state| |endp. state| |identifier| 1263 +---------+ ^ +-----------+ +-----------+ +----------+ 1264 ^ | ^ ^ ^ 1265 | +--------+ | | | 1266 | | | | | 1267 | | +---------------->+<------------|-----------+ | 1268 | | | | | | 1269 | | | +---------------->+ | | 1270 | | | | ^ | | 1271 | | | +---|--------->+------|------>+---|-------->+ 1272 | | | | | ^ | ^ | ^ 1273 | | | | | | | | | | 1274 | | +|---------|+ +|----------|+ +---|-------|+ +|---------|+ 1275 | | |Semi-perm. | |Semi-perm. | |Transient | |Transient | 1276 | | |(D)TLS | |(D)TLS | |(D)TLS | |(D)TLS | 1277 | | |srv session| |clnt session| |clnt session| |srv session| 1278 | | |endp. state| |endp. state | |endp. state | |endp. state| 1279 | | +-----------+ +------------+ +------------+ +-----------+ 1280 | | ^ ^ ^ ^ 1281 | +<--|-------------|-------------------+ | | 1282 | ^ | | | | | 1283 +<-|---|-------------|----------------+ | | | 1284 ^ | | | | | | | 1285 | | | | | | | | 1286 +|--|---|------+ | +|--|--|------|+ 1287 |Semi-permanent|------+ |Transient | 1288 |(D)TLS session| |(D)TLS session| 1289 +--------------+ +--------------+ 1290 ^ ^ 1291 | +-------+ | 1292 +-------|(D)TLS |--------+ 1293 |session| 1294 +-------+ 1296 Figure 2: Terms related to "(D)TLS session" 1298 A.3. Framework for (D)TLS Session Resumption and (D)TLS Session 1299 renegotiation 1301 +---------+ +-----------+ 1302 |(D)TLS | |(D)TLS | 1303 |full | |abbreviated| 1304 |handshake| |handshake | 1305 +---------+ +-----------+ 1306 ^ ^ ^ ^ 1307 | | | | 1308 | | +-------------------|---+ 1309 | | | | 1310 | +|------------------+ | +|-------------+ 1311 | |Data transfer ready|-->+ |Semi-permanent| 1312 | |(D)TLS connection | ^ |(D)TLS session| 1313 | +-------------------+ | +--------------+ 1314 | ^ ^ | ^ 1315 | | +--------------|--->+ | 1316 | | | | ^ | 1317 +|--|--|-------+ +|----|---|----+ 1318 |(D)TLS session| |(D)TLS session| 1319 |renegotiation | |resumption | 1320 +--------------+ +--------------+ 1322 Figure 3: Terms related to "(D)TLS session resumption" and "(D)TLS 1323 session renegotiation" 1325 Acknowledgments 1327 1329 Authors' Addresses 1331 Jens Guballa (editor) 1332 GERMANY 1334 Email: jens@guballa.de 1336 Juergen Stoetzer-Bradler 1337 GERMANY 1339 Email: Juergen.S-B.ietf@email.de 1341 He Bing 1342 ALCATEL-LUCENT SHANGHAI BELL 1343 388 Ningqiao Road 1344 201206 Shanghai 1345 CHINA 1347 Email: Bing.He@alcatel-sbell.com.cn