Internet DRAFT - draft-guballa-tls-terminology
draft-guballa-tls-terminology
WG TLS Jens Guballa (ed.)
Internet Draft Juergen Stoetzer-Bradler
Intended status: Informational Nokia
Expires: April 2017 He Bing
Alcatel-Lucent Shanghai Bell
October 4, 2016
Terminology related to TLS and DTLS
draft-guballa-tls-terminology-05.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Guballa Expires April 4, 2017 [Page 1]
Internet-Draft Terminology related to TLS and DTLS October 2016
This Internet-Draft will expire on March 4, 2017.
Copyright Notice
Copyright (c) 2016 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.
Abstract
Purpose of this RFC is to provide a central place of all key terms
as used by the various RFCs on protocols TLS and DTLS.
Table of Contents
1. Introduction...................................................4
1.1. Background and motivation - Status of (D)TLS terminology..4
1.2. Purpose...................................................4
1.3. Scope.....................................................4
1.4. Relation with Internet Security Glossary..................4
1.5. Disclaimer................................................5
2. Conventions used in this document..............................5
2.1. Prescriptive language: modal verbs........................5
2.2. Notion of '(D)TLS'........................................5
2.3. Additional terminology....................................5
2.4. Abbreviations used........................................5
3. Inventory of (D)TLS terms......................................6
3.1. Terminology related to endpoint entities..................6
3.1.1. Term "(D)TLS endpoint"...............................6
3.1.2. Term "(D)TLS protocol implementation"................6
3.2. Terminology related to session/connection entities........7
3.2.1. Term "(D)TLS connection".............................7
3.2.2. Term "Semi-permannt (D)TLS session"..................7
3.2.3. Term "Transient (D)TLS session"......................8
3.2.4. Term "(D)TLS session"................................8
3.2.5. Term "DTLS association"..............................9
3.3. Terminology related to session/connection endpoint entities
..............................................................10
3.3.1. Term "(D)TLS connection endpoint"...................10
3.3.2. Term "(D)TLS connection endpoint identifier"........10
3.3.3. Term "(D)TLS client connection endpoint"............11
Guballa Expires April 4, 2017 [Page 2]
Internet-Draft Terminology related to TLS and DTLS October 2016
3.3.4. Term "(D)TLS server connection endpoint"............11
3.4. Terminology related to protocol procedures...............12
3.4.1. Term "(D)TLS message"...............................12
3.4.2. Term "(D)TLS client role"...........................12
3.4.3. Term "(D)TLS server role"...........................13
3.4.4. Term "(D)TLS message sequence"......................13
3.4.5. Term "(D)TLS full handshake"........................13
3.4.6. Term "(D)TLS abbreviated handshake".................14
3.4.7. Term "Data transfer ready (D)TLS connection"........14
3.4.8. Term "Semi-permanent (D)TLS client session endpoint
state".....................................................15
3.4.9. Term "Semi-permanent (D)TLS server session endpoint
state".....................................................15
3.4.10. Term "Transient (D)TLS client session endpoint state"
...........................................................15
3.4.11. Term "Transient (D)TLS server session endpoint state"
...........................................................16
3.4.12. Term "(D)TLS client session endpoint state"........16
3.4.13. Term "(D)TLS server session endpoint state"........18
3.4.14. Term "Resumable (D)TLS client session endpoint state"
...........................................................19
3.4.15. Term "Resumable (D)TLS server session endpoint state"
...........................................................20
3.4.16. Term "Resumable (D)TLS session"....................20
3.4.17. Term "Resumed (D)TLS session"......................21
3.4.18. Term "(D)TLS session resumption"...................22
3.4.19. Term "(D)TLS session identifier"...................23
3.5. Colloquially used terms..................................23
3.5.1. Term "(D)TLS session re-establishment"..............23
3.5.2. Term "(D)TLS session rekeying"......................24
3.5.3. Term "(D)TLS rehandshake"...........................24
4. Security Considerations.......................................25
5. IANA Considerations...........................................25
6. References....................................................25
6.1. Normative References.....................................25
6.2. Informative References...................................25
7. CHANGE LOG....................................................26
7.1. Initial draft name "draft-guballa-tls-terminology".......26
7.1.1. Version "-00".......................................26
7.1.2. Changes against "-00"...............................26
7.1.3. Changes against "-01"...............................27
7.1.4. Changes against "-02"...............................27
7.1.5. Changes against "-03"...............................27
Appendix A. Hierarchical Framework...............................28
A.1. Framework for (D)TLS Connection related Definitions......29
A.2. Framework for (D)TLS Session related Terms...............30
Guballa Expires April 4, 2017 [Page 3]
Internet-Draft Terminology related to TLS and DTLS October 2016
A.3. Framework for (D)TLS Session Resumption and (D)TLS Session
renegotiation.................................................31
1. Introduction
1.1. Background and motivation - Status of (D)TLS terminology
The definition of the TLS protocol [RFC5246] is slightly unusual in
the area of protocol specifications, because more like a software
description with a high-level data model, perhaps written after an
implementation. The RFC does not provide explicit definitions for
the main terms, rather providing a glossary in Appendix B/[RFC5246].
The Glossary itself provides descriptions of the main terms, but not
any definitions. At least not definitions at the detailed level as
required for protocol specifications, which implies a precise
linkage to objects as e.g. used within protocol and service data
units and protocol control information elements.
E.g., there are concerns and ongoing debates about the semantics of
some "handshake" related protocol procedures (catchwords "re-
establishment", "resumption", "renegotiation", "rekeying").
Associated to these procedural aspects is the underlying question
concerning the precise distinction between (D)TLS session and (D)TLS
connection level.
Without any doubt, TLS itself is a pretty successful, mature and
well-proven technology. The production of (D)TLS term definition
implies hence reverse engineering of (D)TLS RFCs.
1.2. Purpose
The purpose of this document is to provide a central place of key
terms as used in TLS and DTLS RFCs. The definitions should be
concise, but detailed enough from perspective of a protocol model,
and of course fully consistent and compatible with the existing
RFCs.
1.3. Scope
The focus is put on key terms which caused some controversy so far.
1.4. Relation with Internet Security Glossary
The Internet Security Glossary [RFC4949] provides a comprehensive
set of security related terms. However, protocol specific terms
Guballa Expires April 4, 2017 [Page 4]
Internet-Draft Terminology related to TLS and DTLS October 2016
such as for DTLS and TLS are not part of the glossary. Hence, there
is actually not any overlapping between this document and [RFC4949].
1.5. Disclaimer
Where there are discrepancies between this document and existing
RFCs on TLS and DTLS, the usage and "semantics" of these (D)TLS RFCs
take precedence over those described in this document.
2. Conventions used in this document
2.1. Prescriptive language: modal verbs
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 RFC-2119 [RFC2119].
2.2. Notion of '(D)TLS'
The prefix '(D)TLS' indicate terms common to both protocols. The
prefixes 'TLS' and 'DTLS' indicate protocol specific aspects.
2.3. Additional terminology
<term>:
<definition>
2.4. Abbreviations used
AL Local (IP) Address
AR Remote (IP) Address
DTLS Datagram Transport Layer Security
(D)TLS DTLS or TLS
FQDN Fully Qualified Domain Name
L4 (Protocol) Layer 4 (= IP Transport layer)
PL Local (L4) Port
PR Remote (L4) Port
RL Record Layer
Guballa Expires April 4, 2017 [Page 5]
Internet-Draft Terminology related to TLS and DTLS October 2016
T Transport (L4) protocol
TCP Transmission Control Protocol
TLS Transport Layer Security
UDP User Datagram Protocol
3. Inventory of (D)TLS terms
3.1. Terminology related to endpoint entities
3.1.1. Term "(D)TLS endpoint"
Definition:
An instance of a (D)TLS protocol implementation with exactly one
local IP (transport) address. A (D)TLS endpoint is housing one or
multiple (D)TLS connection endpoints, which are acting either as
(D)TLS clients or as (D)TLS servers (i.e., "(D)TLS client
connection endpoint" and "(D)TLS server connection endpoint") when
executing the (D)TLS handshake protocol.
Reference:
None.
Term relations:
Definition based on terms "(D)TLS protocol implementation" (3.1.2.
), "(D)TLS client connection endpoint" (3.3.3. ), and "(D)TLS
server connection endpoint" (3.3.4. ).
3.1.2. Term "(D)TLS protocol implementation"
Definition:
A (software or hardware) based implementation of the TLS protocol
as specified in [RFC5246] or of the DTLS protocol as specified in
[RFC6347] (DTLS) and is always associated to a real system.
Reference:
[RFC5246] and [RFC6347].
Guballa Expires April 4, 2017 [Page 6]
Internet-Draft Terminology related to TLS and DTLS October 2016
Term relations:
Definition based on term "real system" [ITU-T X.200].
3.2. Terminology related to session/connection entities
3.2.1. Term "(D)TLS connection"
Definition:
A cooperative relationship among a pair of (D)TLS capable systems,
represented by a (D)TLS client connection endpoint and a (D)TLS
server connection endpoint (NOTE 1). A (D)TLS connection allows
the execution of an establishment procedure given by either a
(D)TLS full handshake or a (D)TLS abbreviated handshake (on
request of the (D)TLS served user instance at (D)TLS client side).
Thus, the mode of communication of the (D)TLS connection could be
considered as connection-oriented (i.e., a (D)TLS connection is
stateful, e.g., at the top-level by the 2-state model {IDLE,
ESTABLISHED}).
Notes:
Thus, formally the (D)TLS connection is a set of two 8-tuples,
refer to "(D)TLS connection endpoint".
Reference:
The term "connection" is part of the glossary of [RFC5246].
Term relations:
Definition based on terms "(D)TLS protocol implementation" (3.1.2.
), "(D)TLS client connection endpoint" (3.3.3. ), and "(D)TLS
server connection endpoint" (3.3.4. ).
3.2.2. Term "Semi-permannt (D)TLS session"
Definition:
The pair of a semi-permanent (D)TLS client session endpoint state
and a semi-permanent (D)TLS server session endpoint state, coupled
by the (D)TLS full handshake procedure which was executed across
the associated (D)TLS connection.
Guballa Expires April 4, 2017 [Page 7]
Internet-Draft Terminology related to TLS and DTLS October 2016
Reference:
None.
Term relations:
Definition based on terms "semi-permanent (D)TLS client session
endpoint state" (3.4.8. ), "semi-permanent (D)TLS server session
endpoint state" (3.4.9. ), "(D)TLS full handshake" (3.4.5. ), and
"(D)TLS connection" (3.2.1. ).
3.2.3. Term "Transient (D)TLS session"
Definition:
The pair of a transient (D)TLS client session endpoint state and a
transient (D)TLS server session endpoint state, coupled by the
(D)TLS full handshake procedure which was executed across the
associated (D)TLS connection.
The transient (D)TLS client session endpoint state information and
transient (D)TLS server session endpoint state information is
immediately deleted after the successful (D)TLS full handshake
procedure.
Reference:
None.
Term relations:
Definition based on terms "transient (D)TLS client session
endpoint state" (3.4.10. ), "transient (D)TLS server session
endpoint state" (3.4.11. ), "(D)TLS full handshake" (3.4.5. ), and
"(D)TLS connection" (3.2.1. ).
3.2.4. Term "(D)TLS session"
Definition:
A semi-permanent (D)TLS session or transient (D)TLS session.
Notes:
Thus, a (D)TLS session is a transformed (D)TLS connection after
the successful execution of a (D)TLS full handshake procedure,
constituted by the pair of (D)TLS client session endpoint state
Guballa Expires April 4, 2017 [Page 8]
Internet-Draft Terminology related to TLS and DTLS October 2016
and a (D)TLS server session endpoint state. A (D)TLS session is
consequently an association between the two (D)TLS session
endpoints. The mode of communication of the (D)TLS session could
be considered as connectionless (i.e., a (D)TLS session is either
existing or not).
The nature of a (D)TLS session (from (D)TLS endpoint perspective)
is either volatile (i.e., the local (D)TLS session information
would be immediately discarded after a (D)TLS handshake procedure)
or semi-permanent (in case of resumable (D)TLS sessions).
Notably, a (D)TLS session may still exist after one or even both
(D)TLS connection endpoints, which did exchange the (D)TLS full
handshake messages from which the related (D)TLS session states
were derived from, are already destroyed.
The (D)TLS role (client or server) is a (D)TLS session level
characteristic. (to be confirmed)
Reference:
The term "session" is part of the glossary of [RFC5246].
Term relations:
Definition based on terms "(D)TLS semi-permanent session" (3.2.2.
), and "(D)TLS transient (volatile) session" (3.2.3. ).
3.2.5. Term "DTLS association"
Definition:
Synonym to "DTLS connection".
Reference:
Term introduced by [RFC4347] and still used in [RFC6347].
Term relations:
Definition equal to "(D)TLS connection" (3.2.1. ).
Guballa Expires April 4, 2017 [Page 9]
Internet-Draft Terminology related to TLS and DTLS October 2016
3.3. Terminology related to session/connection endpoint entities
3.3.1. Term "(D)TLS connection endpoint"
Definition:
A part of an instance of a (D)TLS protocol implementation, which
is able to send and receive (D)TLS messages, and which is
associated to exactly one 8-tuple being composed of
1) a creation point in time tc,
2) a destruction point in time td,
3) a non-empty local IP address AL,
4) a non-empty local L4 port PL,
5) an empty or non-empty remote IP address AR,
6) an empty or non-empty remote L4 port PR,
7) a non-empty L4 transport protocol T, and
8) the protocol string "TLS" or "DTLS".
Notes:
If FQDNs are used as (D)TLS endpoint identifiers, then an
additional requirement on the (D)TLS connection endpoint could be
that AL is one of the IP addresses associated to the (D)TLS
endpoint's FQDN.
Reference:
[RFC5246], [RFC5764]
Term relations:
Definition based on terms "(D)TLS protocol implementation" (3.1.2.
) and "(D)TLS message" (3.4.1. ).
3.3.2. Term "(D)TLS connection endpoint identifier"
Definition:
Guballa Expires April 4, 2017 [Page 10]
Internet-Draft Terminology related to TLS and DTLS October 2016
The local IP transport address and indication of "TLS/L4" or
"DTLS/L4" protocol stack, i.e., the 4-tuple of {AL, PL, T,
"TLS"/"DTLS"} from the (D)TLS connection endpoint.
Notes:
Parameter "L4" is required because (D)TLS is a L4 independent
protocol, hence a (D)TLS capable system could offer multiple
(D)TLS endpoints with different L4 protocols.
Reference:
None.
Term relations:
Definition based on terms "(D)TLS protocol implementation" (3.1.2.
) and "(D)TLS message" (3.4.1. ).
3.3.3. Term "(D)TLS client connection endpoint"
Definition:
A (D)TLS connection endpoint which sends a (D)TLS message
containing a ClientHello handshake structure to another (D)TLS
connection endpoint.
Reference:
The TLS ClientHello handshake structure is defined in [RFC5246]
while the DTLS ClientHello handshake structure is defined in
[RFC6347].
Term relations:
Definition based on terms "(D)TLS connection endpoint" (3.3.1. )
and "(D)TLS message" (3.4.1. ).
3.3.4. Term "(D)TLS server connection endpoint"
Definition:
A (D)TLS connection endpoint which receives a (D)TLS message
containing a ClientHello handshake structure and subsequently
sends a (D)TLS message containing a ServerHello handshake
structure back to that other (D)TLS connection endpoint.
Guballa Expires April 4, 2017 [Page 11]
Internet-Draft Terminology related to TLS and DTLS October 2016
Reference:
The (D)TLS ServerHello handshake structure is defined in
[RFC5246].
Term relations:
Definition based on terms "(D)TLS connection endpoint" (3.3.1. )
and "(D)TLS message" (3.4.1. ).
3.4. Terminology related to protocol procedures
3.4.1. Term "(D)TLS message"
Definition:
A unit of (D)TLS-RL user data as produced by the (D)TLS handshake
protocol, the (D)TLS alert protocol or the (D)TLS change cipher
spec protocol.
Notes:
Application Data are excluded from this definition.
Reference:
Clause 6.2.1 of [RFC5246] defines the message type as an
enumeration ("ContentType"). It is contained in the structured
type "TLSPlaintext".Term relations:
3.4.2. Term "(D)TLS client role"
Definition:
A (D)TLS connection endpoint is said to assume the (D)TLS client
role, if it is a (D)TLS client connection endpoint.
Reference:
The term "client" is part of the glossary of [RFC5246].
Term relations:
Guballa Expires April 4, 2017 [Page 12]
Internet-Draft Terminology related to TLS and DTLS October 2016
Definition based on terms "(D)TLS connection endpoint" (3.3.1. )
and "(D)TLS client connection endpoint" (3.3.3. ).
3.4.3. Term "(D)TLS server role"
Definition:
A (D)TLS connection endpoint is said to assume the (D)TLS server
role, if it is a (D)TLS server connection endpoint.
Reference:
The term "server" is part of the glossary of [RFC5246].
Term relations:
Definition based on terms "(D)TLS connection endpoint" (3.3.1. )
and "(D)TLS server connection endpoint" (3.3.4. ).
3.4.4. Term "(D)TLS message sequence"
Definition:
A finite sequence of (D)TLS messages.
Reference:
None.
Term relations:
Definition based on term "(D)TLS message" (3.4.1. ).
3.4.5. Term "(D)TLS full handshake"
Definition:
A (D)TLS message sequence where the first (D)TLS message contains
ClientHello structure and if the sequence constitutes a successful
(D)TLS full handshake message flow as specified in clause 7.3,
Figure 1 of [RFC5246].
Reference:
A full TLS handshake is presented in [RFC5246], clause 7.3, Figure
1. The DTLS' specifics are presented in [RFC6347], clause 4.2.1.
Guballa Expires April 4, 2017 [Page 13]
Internet-Draft Terminology related to TLS and DTLS October 2016
Term relations:
Definition based on term "(D)TLS message" (3.4.1. ).
3.4.6. Term "(D)TLS abbreviated handshake"
Definition:
A (D)TLS message sequence where the first (D)TLS message contains
ClientHello structure and if the sequence constitutes a successful
(D)TLS abbreviated handshake message flow as specified in clause
7.3, Figure 2 of [RFC5246].
Reference:
An abbreviated TLS handshake is presented in [RFC5246], clause
7.3, Figure 2. The DTLS' specifics are presented in [RFC6347],
clause 4.2.1.
Term relations:
Definition based on term "(D)TLS message" (3.4.1. ).
3.4.7. Term "Data transfer ready (D)TLS connection"
Definition:
A (D)TLS connection after the successful execution of a (D)TLS
full handshake or a (D)TLS abbreviated handshake procedure.
Notes:
The notion of "DATA TRANSFER READY" refers to a specific state of
the (D)TLS connection and is synonym to the notion of
"ESTABLISHED". The general term "DATA TRANSFER READY" matches
both connectionless and connection-oriented type of connections,
see [ITU-T X.213 and X.214].
Reference:
None.
Term relations:
Definition based on terms "(D)TLS connection" (3.2.1. ), "(D)TLS
full handshake" (3.4.5. ) and "(D)TLS abbreviated handshake"
(3.4.6. ).
Guballa Expires April 4, 2017 [Page 14]
Internet-Draft Terminology related to TLS and DTLS October 2016
3.4.8. Term "Semi-permanent (D)TLS client session endpoint state"
Definition:
A (D)TLS client session endpoint state if its (D)TLS session
identifier value is non-empty.
Reference:
The term "session identifier" is part of the glossary of
[RFC5246].
Term relations:
Refer to "(D)TLS client session endpoint state" (3.4.12. ) and
"(D)TLS session identifier" (3.4.19.
3.4.9. Term "Semi-permanent (D)TLS server session endpoint state"
Definition:
A (D)TLS server session endpoint state if its (D)TLS session
identifier value is non-empty.
Reference:
The term "session identifier" is part of the glossary of
[RFC5246].
Term relations:
Refer to "(D)TLS server session endpoint state" (3.4.13. ) and
"(D)TLS session identifier" (3.4.19.
3.4.10. Term "Transient (D)TLS client session endpoint state"
Definition:
A (D)TLS client session endpoint state if its (D)TLS session
identifier value is empty.
Reference:
The term "session identifier" is part of the glossary of
[RFC5246].
Term relations:
Guballa Expires April 4, 2017 [Page 15]
Internet-Draft Terminology related to TLS and DTLS October 2016
Refer to "(D)TLS client session endpoint state" (3.4.12. ) and
"(D)TLS session identifier" (3.4.19.
3.4.11. Term "Transient (D)TLS server session endpoint state"
Definition:
A (D)TLS server session endpoint state if its (D)TLS session
identifier value is empty.
Reference:
The term "session identifier" is part of the glossary of
[RFC5246].
Term relations:
Refer to "(D)TLS server session endpoint state" (3.4.13. 3.4.12. )
and "(D)TLS session identifier" (3.4.19.
3.4.12. Term "(D)TLS client session endpoint state"
Definition:
The 17-tuple of following parameter-value pairs, as partially
described in [RFC5246]:
TLS protocol parameter: Type:
1. version: ProtocolVersion
2. prf_algorithm: PRFAlgorithm
3. bulk_cipher_algorithm: BulkCipherAlgorithm
4. cipher_type: CipherType
5. enc_key_length: uint8
6. block_length: unit8
7. fixed_iv_length: unit8
8. record_iv_length: unit8
Guballa Expires April 4, 2017 [Page 16]
Internet-Draft Terminology related to TLS and DTLS October 2016
9. mac_algorithm: MACAlgorithm
10. mac_length: unit8
11. mac_key_length: unit8
12. compression_algorithm: CompressionMethod
13. master_secret: opaque[48]
14. session_id: SessionID (NOTE 1)
Other parameters: Type:
15. creation time tc: time (NOTE 2)
16. destruction time td: time
17. server_address: IPaddress (NOTE 3)
Notes:
1: A (D)TLS client session endpoint state is semi-permanent if and
only if its session_id value is non-empty. Hence it is transient
if and only if its session_id value is empty.
FIX THIS: Session tickets [RFC5077] must be covered as well,
reference to "(D)TLS session identifier" should be used.2: While a
semi-permanent (D)TLS client session endpoint state's creation
point in time correlates with the corresponding (D)TLS full
handshake's end time (which is thus a point in time at which both
TLS connection endpoints, which exchange the (D)TLS full handshake
messages, do still exist), this semi-permanent (D)TLS client
session endpoint state's destruction point in time is independent
of the destruction points in time of these two (D)TLS connection
endpoints. Especially, the semi-permanent (D)TLS client session
endpoint state may still exist after one or even both (D)TLS
connection endpoints are already destroyed.
3: A (D)TLS protocol implementation may add further information to
a (D)TLS client session endpoint state, like e.g. the associated
(D)TLS server endpoint's source IP address. This additional
information may be used by a (D)TLS client connection endpoint in
order to decide if an already stored semi-permanent (D)TLS client
session endpoint state may be used (may be "resumed") for the
Guballa Expires April 4, 2017 [Page 17]
Internet-Draft Terminology related to TLS and DTLS October 2016
establishment of a new (D)TLS connection towards a destination
transport address of another (D)TLS endpoint.
Reference:
The definition of this term is based on the structured type
"SecurityParameters" as defined in clause 6.1 of [RFC5246].
Term relations:
-
3.4.13. Term "(D)TLS server session endpoint state"
Definition:
The 16-tuple of following parameter-value pairs, as partially
described in [RFC5246]:
TLS protocol parameter: Type:
1. version: ProtocolVersion
2. prf_algorithm: PRFAlgorithm
3. bulk_cipher_algorithm: BulkCipherAlgorithm
4. cipher_type: CipherType
5. enc_key_length: uint8
6. block_length: unit8
7. fixed_iv_length: unit8
8. record_iv_length: unit8
9. mac_algorithm: MACAlgorithm
10. mac_length: unit8
11. mac_key_length: unit8
12. compression_algorithm: CompressionMethod
13. master_secret: opaque[48]
Guballa Expires April 4, 2017 [Page 18]
Internet-Draft Terminology related to TLS and DTLS October 2016
14. session_id: SessionID (NOTE 1)
Other parameters (NOTE 3): Type:
15. creation time tc: time (NOTE 2)
16. destruction time td: time
Notes:
1: A (D)TLS server session endpoint state is semi-permanent if and
only if its session_id value is non-empty. Hence it is transient
if and only if its session_id value is empty.
FIX THIS: Session tickets [RFC5077] must be covered as well,
reference to "(D)TLS session identifier" should be used.
2: While a semi-permanent (D)TLS server session endpoint state's
creation point in time correlates with the corresponding (D)TLS
full handshake's end time (which is thus a point in time at which
both (D)TLS connection endpoints, which exchange the (D)TLS full
handshake messages, do still exist), this semi-permanent (D)TLS
server session endpoint state's destruction point in time is
independent of the destruction points in time of these two (D)TLS
connection endpoints. Especially, the semi-permanent (D)TLS
server session endpoint state may still exist after one or even
both (D)TLS connection endpoints are already destroyed.
3: Difference between the (D)TLS server session endpoint state
versus the (D)TLS server session endpoint: the 17th parameter
"server address" (refer to 3.4.12. ) is of course missing at the
server side.
Reference:
The definition of this term is based on the structured type
"SecurityParameters" as defined in clause 6.1 of [RFC5246].
Term relations:
-
3.4.14. Term "Resumable (D)TLS client session endpoint state"
Definition:
Guballa Expires April 4, 2017 [Page 19]
Internet-Draft Terminology related to TLS and DTLS October 2016
Synonym for a semi-permanent (D)TLS client session endpoint state
(3.4.8. ).
Reference:
The term "is resumable" is part of the glossary of [RFC5246].
Term relations:
-
3.4.15. Term "Resumable (D)TLS server session endpoint state"
Definition:
Synonym for a semi-permanent (D)TLS server session endpoint state
(3.4.9. ).
Reference:
The term "is resumable" is part of the glossary of [RFC5246].
Term relations:
-
3.4.16. Term "Resumable (D)TLS session"
Definition:
Synonym for a semi-permanent (D)TLS session (3.2.2. ).
Notes:
Expanded term: A (D)TLS session where the (D)TLS server session
state as well as the (D)TLS client session state are both
resumable. A (D)TLS session state is called resumable, if its
(D)TLS session identifier value is non-empty.
Reference:
The term "is resumable" is part of the glossary of [RFC5246].
Term relations:
-
Guballa Expires April 4, 2017 [Page 20]
Internet-Draft Terminology related to TLS and DTLS October 2016
3.4.17. Term "Resumed (D)TLS session"
Definition:
A resumable (D)TLS session after the successful execution of a
(D)TLS abbreviated handshake procedure.
Notes:
1: The (D)TLS session identifier value (of the resumed (D)TLS
session) is identical to the previous value of the resumable
(D)TLS session.
2: The (D)TLS connection, which is established with the (D)TLS
abbreviated handshake based on the existing resumable (D)TLS
session, may be created while the original (D)TLS connection,
which was established via the (D)TLS full handshake from which the
resumable (D)TLS client and server session endpoint states and
hence the resumable (D)TLS session were derived, is still
established, or only after this original (D)TLS connection is
already terminated.
3: Several new (D)TLS connections may be established using (D)TLS
abbreviated handshakes based on the same resumable (D)TLS session.
If the first (D)TLS connection is established using an (D)TLS
abbreviated handshake based on a resumable (D)TLS session, then we
may say that this (D)TLS session becomes a resumed (D)TLS session
at this first (D)TLS abbreviated handshake's end time.
Reference:
The term is introduced in the glossary of [RFC5246], refer to
"session_id".
Term relations:
Definition based on terms "resumable (D)TLS session" (3.4.16. ),
and "(D)TLS abbreviated handshake" (3.4.6. ).Term "(D)TLS session
renegotiation"
Definition:
A (D)TLS session level concept which leads, - by the execution of
a (D)TLS handshake procedure (full or abbreviated) -, to the
update of the (D)TLS protocol status "connection-level"
information of an DATA TRANSFER READY (D)TLS connection, for the
purpose of the establishment of new cryptographic parameters.
Guballa Expires April 4, 2017 [Page 21]
Internet-Draft Terminology related to TLS and DTLS October 2016
Notes:
1: The initial (D)TLS full handshake or (D)TLS abbreviated
handshake is not regarded as a (D)TLS session renegotiation as
this handshake is executed on a (D)TLS connection which is in the
state IDLE. After this initial handshake is finished the (D)TLS
connection state is changed to DATA TRANSFER READY, and thus all
following (D)TLS full handshakes or (D)TLS abbreviated handshakes
on that (D)TLS connection are regarded as (D)TLS session
renegotiation. The (D)TLS handshake related to a (D)TLS session
renegotiation is always cryptographically protected by the current
(D)TLS connection state.2: The (D)TLS connection state remains in
DATA TRANSFER READY during and after the (D)TLS session
renegotiation.
Reference:
[RFC5246]
Term relations:
Definition based on terms "(D)TLS full handshake" (3.4.5. ),
"(D)TLS abbreviated handshake" (3.4.6. ), and "Data transfer ready
(D)TLS connection" (3.4.7. ).
3.4.18. Term "(D)TLS session resumption"
Definition:
A (D)TLS session level concept which represents the execution of a
(D)TLS abbreviated handshake procedure on an existing (D)TLS
session, i.e., a semi-permanent (D)TLS session, for the purpose of
either deriving a further DATA TRANSFER READY (D)TLS connection or
updating of an existing DATA TRANSFER READY (D)TLS connection.
Reference:
[RFC5246], [RFC5764], [RFC5077]
Term relations:
Refer to "Data transfer ready (D)TLS connection" (3.4.7. 3.4.12.
), "(D)TLS abbreviated handshake" (3.4.6. ), and "Semi-permanent
(D)TLS session" (3.2.2. 3.4.8. )
Guballa Expires April 4, 2017 [Page 22]
Internet-Draft Terminology related to TLS and DTLS October 2016
3.4.19. Term "(D)TLS session identifier"
Definition:
A (D)TLS protocol parameter representing the identification
allocated to a particular semi-permanent (D)TLS session.
Notes:
1: The definition is consistent and not redefining the explanatory
description of a "session identifier" in the TLS glossary, as
contained in Appendix B/[RFC5246].
2: This definition may need to be extended by additional
consideration of the session ticket based TLS session resumption
mechanism as defined in [RFC5077]. There would be then two TLS
protocol parameters (session_id and SessionTicket) as possible
identifiers (both protocol parameters are mutually exclusive).
Reference:
[RFC5077]
Term relations:
Definition based on the term "semi-permanent (D)TLS session"
(3.2.2. ).
3.5. Colloquially used terms
This clause provides a list of terms which are not introduced,
described or defined by (D)TLS RFCs, but sometimes used in
discussions or other documents.
3.5.1. Term "(D)TLS session re-establishment"
Definition:
-
Notes:
There does not exist any definition so far.
Reference:
None.
Guballa Expires April 4, 2017 [Page 23]
Internet-Draft Terminology related to TLS and DTLS October 2016
Term relations:
Still open, dependent on definition.
3.5.2. Term "(D)TLS session rekeying"
Definition:
-
Notes:
There doesn't exist any definition so far (to be confirmed).
[RFC5763], clause 6.8 provides a high-level description of a
"rekeying concept" in context of DTLS-based SRTP key management.
Reference:
None.
Term relations:
Still open, dependent on definition.
3.5.3. Term "(D)TLS rehandshake"
Definition:
-
Notes:
There does not exit any definition so far.
Reference:
The term is used in [RFC5764].
Term relation:
The term can be interpreted as a synonym for "(D)TLS
renegotiation".
Guballa Expires April 4, 2017 [Page 24]
Internet-Draft Terminology related to TLS and DTLS October 2016
4. Security Considerations
FIXTHIS
5. IANA Considerations
FIXTHIS
6. References
6.1. Normative References
[RFC2119] RFC 2119 (03/1997), "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14.
[RFC4949] RFC 4949 (08/2007), "Internet Security Glossary,
Version 2"
[RFC5077] RFC 5077 (01/2008), "Transport Layer Security (TLS)
Session Resumption without Server-Side State"
[RFC5246] RFC 5246 (08/2008), "The Transport Layer Security (TLS)
Protocol, Version 1.2"
[RFC5746] RFC 5746 (02/2010), "Transport Layer Security (TLS)
Renegotiation Indication Extension"
[RFC5763] RFC 5763 (05/2010), "Framework for Establishing a Secure
Real-time Transport Protocol (SRTP) Security Context Using
Datagram Transport Layer Security (DTLS)"
[RFC5764] RFC 5764 (05/2010), "Datagram Transport Layer Security
(DTLS) Extension to Establish Keys for the Secure Real-
time Transport Protocol (SRTP)"
[RFC6347] RFC 6347 (02/2012), "Datagram Transport Layer Security
Version 1.2"
6.2. Informative References
[ITU-T X.200] Recommendation ITU-T X.200 (07/1994), "Information
technology - Open Systems Interconnection - Basic
Reference Model: The basic model."
Guballa Expires April 4, 2017 [Page 25]
Internet-Draft Terminology related to TLS and DTLS October 2016
[ITU-T X.213] Recommendation ITU-T X.213 (10/2001), "Information
technology - Open Systems Interconnection - Network
service definition."
[ITU-T X.214] Recommendation ITU-T X.214 (11/1995), "Information
technology - Open Systems Interconnection - Transport
service definition."
7. CHANGE LOG
7.1. Initial draft name "draft-guballa-tls-terminology"
7.1.1. Version "-00"
Following definition template is used:
Term "<term>"
Definition:
<definition>.
Notes:
<comments, complementary information>
Reference:
<references>
Term relations:
<references to terms reused by this definition>
7.1.2. Changes against "-00"
o Editorial changes according to RFC Style Guide
o Hierarchical framework added (appendix A)
o List of authors extended
o Clarification added: handshakes for session renegotiation are
always cryptographically protected
o Reference to RFC5763 added for "(D)TLS session rekeying"
o Clarification of relation with Internet Security Glossary
[RFC4949]
Guballa Expires April 4, 2017 [Page 26]
Internet-Draft Terminology related to TLS and DTLS October 2016
o Missing references fixed
o List of colloquially used terms extended
7.1.3. Changes against "-01"
o No changes
7.1.4. Changes against "-02"
o Author's Addresses updated
7.1.5. Changes against "-03"
o Editor's address updated
7.1.6. Changes against "-04"
o Author's address updated
Guballa Expires April 4, 2017 [Page 27]
Internet-Draft Terminology related to TLS and DTLS October 2016
Appendix A. Hierarchical Framework
This section provides an overview on the hierarchy of the terms
defined in this draft. The dependency is indicated by arrows as
follows:
"foo"--->"bar" indicates that the definition of term "foo" is based
on the term "bar".
Guballa Expires April 4, 2017 [Page 28]
Internet-Draft Terminology related to TLS and DTLS October 2016
A.1. Framework for (D)TLS Connection related Definitions
+-------+ +---------------+
|(D)TLS | |(D)TLS protocol|<-----------------------+
|message|<-----+ +->|implementation |<---+ |
+-------+ | | +---------------+ | |
^ ^ ^ | | ^ | |
| | | +<---|-----|--+<-----+<---+ | |
| | | ^ | | ^ ^ | | |
| | | +----|----|+ | | | | | |
| | | |(D)TLS | | | | +|--|-------------+ |
| | | |connection| | | | |(D)TLS connection| |
| | | |endpoint | | | | |endpoint | |
| | | |identifier| | | | +-----------------+ |
| | | +----------+ | | | ^ ^ ^ |
| | | | | | | | | |
| | +----------+ | | +----|----|--+ | |
| | | | | | | | | |
| +|-------+ | | +|-----------|+ | +|-|----------+ |
| |(D)TLS | | | |(D)TLS client| | |(D)TLS server| |
| |message | | | |connection | | |connection | |
| |sequence|<-+ | | |endpoint | | |endpoint | |
| +--------+ | | | +-------------+ | +-------------+ |
| ^ | | | ^ ^ | ^ ^ |
| | | | | | | | | | |
+|--------|-+ +|--|-----+ | +<-----|---------|----|-----+ | |
|(D)TLS | |(D)TLS | | ^ | | | | | |
|abbreviated| |full | | | +---|---------|----|-----|-->+ |
|handshake | |handshake| | | | | | | | ^ |
+-----------+ +---------+ | | | | +--->+ | | | |
^ ^ | | | | | ^ | | | |
| | | | | | | | | | | |
+|-------------|+ +---|--|--|+ +|----|+ +|----|+ +|---|--|+
|Data transfer |---->|(D)TLS | |(D)TLS| |(D)TLS| |(D)TLS |
|ready (D)TLS | |connection| |client| |server| |endpoint|
|connection | +----------+ |role | |role | +--------+
+---------------+ +------+ +------+
Figure 1: Terms related to "(D)TLS connection"
Guballa Expires April 4, 2017 [Page 29]
Internet-Draft Terminology related to TLS and DTLS October 2016
A.2. Framework for (D)TLS Session related Terms
+---------+ +----------+ +-----------+ +-----------+ +----------+
|(D)TLS | |(D)TLS | |(D)TLS srv | |(D)TLS clnt| |(D)TLS |
|full | |connection| |session | |session | |session |
|handshake| +----------+ |endp. state| |endp. state| |identifier|
+---------+ ^ +-----------+ +-----------+ +----------+
^ | ^ ^ ^
| +--------+ | | |
| | | | |
| | +---------------->+<------------|-----------+ |
| | | | | |
| | | +---------------->+ | |
| | | | ^ | |
| | | +---|--------->+------|------>+---|-------->+
| | | | | ^ | ^ | ^
| | | | | | | | | |
| | +|---------|+ +|----------|+ +---|-------|+ +|---------|+
| | |Semi-perm. | |Semi-perm. | |Transient | |Transient |
| | |(D)TLS | |(D)TLS | |(D)TLS | |(D)TLS |
| | |srv session| |clnt session| |clnt session| |srv session|
| | |endp. state| |endp. state | |endp. state | |endp. state|
| | +-----------+ +------------+ +------------+ +-----------+
| | ^ ^ ^ ^
| +<--|-------------|-------------------+ | |
| ^ | | | | |
+<-|---|-------------|----------------+ | | |
^ | | | | | | |
| | | | | | | |
+|--|---|------+ | +|--|--|------|+
|Semi-permanent|------+ |Transient |
|(D)TLS session| |(D)TLS session|
+--------------+ +--------------+
^ ^
| +-------+ |
+-------|(D)TLS |--------+
|session|
+-------+
Figure 2: Terms related to "(D)TLS session"
Guballa Expires April 4, 2017 [Page 30]
Internet-Draft Terminology related to TLS and DTLS October 2016
A.3. Framework for (D)TLS Session Resumption and (D)TLS Session
renegotiation
+---------+ +-----------+
|(D)TLS | |(D)TLS |
|full | |abbreviated|
|handshake| |handshake |
+---------+ +-----------+
^ ^ ^ ^
| | | |
| | +-------------------|---+
| | | |
| +|------------------+ | +|-------------+
| |Data transfer ready|-->+ |Semi-permanent|
| |(D)TLS connection | ^ |(D)TLS session|
| +-------------------+ | +--------------+
| ^ ^ | ^
| | +--------------|--->+ |
| | | | ^ |
+|--|--|-------+ +|----|---|----+
|(D)TLS session| |(D)TLS session|
|renegotiation | |resumption |
+--------------+ +--------------+
Figure 3: Terms related to "(D)TLS session resumption" and "(D)TLS
session renegotiation"
Acknowledgments
<Add any acknowledgements>
Guballa Expires April 4, 2017 [Page 31]
Internet-Draft Terminology related to TLS and DTLS October 2016
Authors' Addresses
Jens Guballa (editor)
GERMANY
Email: jens@guballa.de
Juergen Stoetzer-Bradler
GERMANY
Email: Juergen.S-B.ietf@email.de
He Bing
ALCATEL-LUCENT SHANGHAI BELL
388 Ningqiao Road
201206 Shanghai
CHINA
Email: Bing.He@alcatel-sbell.com.cn
Guballa Expires April 4, 2017 [Page 32]
