ETSI TS 103 523-2 V1.1.1 (2021-02)

CYBER; Middlebox Security Protocol; Part 2: Transport layer MSP, profile for fine grained access control

DTS/CYBER-0027-2

General Information

• Status: Not Published
• Technical Committee: CYBER - Cyber Security
• Current Stage: 12 - Completion
• Due Date: 17-Feb-2021
• Completion Date: 09-Feb-2021

Standards Content (Sample)

TECHNICAL SPECIFICATION
CYBER;
Middlebox Security Protocol;
Part 2: Transport layer MSP, profile for fine
grained access control
2 ETSI TS 103 523-2 V1.1.1 (2021-02)

Reference
DTS/CYBER-0027-2
Keywords
cyber security
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2021.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TS 103 523-2 V1.1.1 (2021-02)
Contents
Intellectual Property Rights . 7
Foreword . 7
Modal verbs terminology . 7
Executive summary . 7
Introduction . 8
1 Scope . 9
2 References . 9
2.1 Normative references . 9
2.2 Informative references . 10
3 Definition of terms, symbols and abbreviations . 11
3.1 Terms . 11
3.2 Symbols . 12
3.3 Abbreviations . 12
4 TLMSP specification . 13
4.1 Introduction . 13
4.2 The Record protocol . 14
4.2.1 Overview . 14
4.2.1.1 General . 14
4.2.1.2 Records, containers and contexts . 14
4.2.1.3 Record and container construction and processing overview . 15
4.2.2 Message unit and record processing: cryptographic state and synchronization . 17
4.2.2.1 General . 17
4.2.2.2 MAC overview . 17
4.2.2.2.1 General . 17
4.2.2.2.2 MAC author determination . 18
4.2.2.3 Sequence numbers . 19
4.2.2.3.1 General . 19
4.2.2.3.2 Outgoing message units and records . 21
4.2.2.3.3 Incoming message units and records . 22
4.2.3 Processing of specific message unit types . 22
4.2.3.1 Container message units . 22
4.2.3.1.1 Container usage . 22
4.2.3.1.2 Modifications . 23
4.2.3.1.3 Insertions generally . 23
4.2.3.1.4 Deletion indication containers . 24
4.2.3.1.5 Audit containers. 25
4.2.3.1.6 Alert containers . 26
4.2.3.2 Record message units . 26
4.2.3.2.1 Handshake message units . 26
4.2.3.2.2 ChangeCipherSpec message units . 26
4.2.3.3 Middlebox processing summary . 26
4.2.3.4 MAC usage summary . 27
4.2.4 Container format . 29
4.2.5 Plaintext record format . 29
4.2.6 Compressed record format . 30
4.2.7 Applying message unit and record protection . 30
4.2.7.1 General . 30
4.2.7.2 MAC generation . 31
4.2.7.2.1 General . 31
4.2.7.2.2 Reader, deleter and writer MACs . 31
4.2.7.2.3 Hop-by-hop MAC . 33
4.2.7.3 Cipher suite specifics . 34
ETSI
4 ETSI TS 103 523-2 V1.1.1 (2021-02)
4.2.7.3.1 General . 34
4.2.7.3.2 Null or stream cipher . 34
4.2.7.3.3 Generic block cipher . 35
4.2.7.3.4 AEAD ciphers . 35
4.3 The Handshake protocol . 35
4.3.1 Overview . 35
4.3.1.1 General . 35
4.3.1.2 Piggy-backing of handshake messages . 38
4.3.2 Middlebox configuration, discovery . 39
4.3.2.1 General . 39
4.3.2.2 Static pre-configuration . 40
4.3.2.3 Dynamic discovery. 40
4.3.2.3.1 General . 40
4.3.2.3.2 Non-transparent middleboxes . 41
4.3.2.3.3 Transparent middleboxes . 42
4.3.2.4 Combined discovery. 43
4.3.2.4.1 Example use case . 43
4.3.2.4.2 Practical considerations . 44
4.3.2.5 Middlebox leave and suspend . 44
4.3.3 Session resumption and renegotiation . 44
4.3.3.1 Resumption . 44
4.3.3.2 Renegotiation . 45
4.3.4 Handshake message types . 45
4.3.5 TLMSP Handshake extensions . 46
4.3.6 Middlebox related messages . 50
4.3.6.1 MboxHello . 50
4.3.6.2 MboxCertificate . 51
4.3.6.3 MboxCertificateRequest . 51
4.3.6.4 Certificate2Mbox . 51
4.3.6.5 MboxKeyExchange . 52
4.3.6.6 MboxHelloDone . 52
4.3.6.7 CertificateVerify2Mbox . 52
4.3.6.8 MboxHelloRequest . 53
4.3.6.9 ServerUnsupport . 53
4.3.6.10 MboxFinished . 53
4.3.7 TLMSPKeyMaterial and TLMSPKeyConf . 54
4.3.7.1 KeyMaterialContribution . 54
4.3.7.2 TLMSPKeyMaterial . 55
4.3.7.3 TLMSPKeyConf . 56
4.3.8 MboxLeaveNotify and MboxLeaveAck . 57
4.3.8.1 Message format . 57
4.3.8.2 Message processing . 57
4.3.8.2.1 General . 57
4.3.8.2.2 Detailed operation . 58
4.3.9 Message hashes . 59
4.3.9.1 ClientHello and ServerHello value substitutions . 59
4.3.9.2 Finished hash. 59
4.3.9.3 MboxFinished hash . 60
4.3.9.4 ClientHello hash (following dynamic discovery). 62
4.3.9.5 TLMSPServerKeyExchange hash . 62
4.3.10 Key generation . 62
4.3.10.1 TLMSPServerKeyExchange . 62
4.3.10.2 General . 63
4.3.10.3 Premaster secret and master secret generation . 63
4.3.10.4 Pairwise encryption and integrity key generation . 64
4.3.10.5 Context specific keys . 65
4.3.10.6 Key extraction . 67
4.4 The Alert protocol . 68
4.4.1 General . 68
4.4.2 Alert message types . 68
4.5 The ChangeCipherSpec protocol . 69
ETSI
5 ETSI TS 103 523-2 V1.1.1 (2021-02)
Annex A (normative): Defined cipher suites . 70
A.1 General . 70
A.2 Key Exchange . 70
A.3 AES_{128,256}_GCM_SHA{256,384} . 70
A.3.1 General . 70
A.3.2 Additional MAC computations . 71
A.4 AES_{128,256}_CBC_SHA{256,384} . 71
A.5 AES_{128,256}_CTR_SHA{256,384} . 71
A.6 Additional cipher suites . 71
A.7 Summary of security parameters . 72
A.8 Cipher suite identifiers . 72
A.9 Future extensions . 73
Annex B (normative): Alternative cipher suites . 74
B.1 General . 74
B.2 Defined alternative cipher suites . 74
B.2.1 Anon . 74
B.2.2 Preshared keys . 74
B.2.2.1 General . 74
B.2.2.2 Technical Details . 74
B.2.2.2.1 ClientHello and ServerHello . 74
B.2.2.2.2 MboxKeyExchange . 75
B.2.2.2.3 TLMSPKeyMaterial . 75
B.2.3 GBA . 75
B.2.3.1 General . 75
B.2.3.2 Technical details . 75
B.2.3.2.1 General . 75
B.2.3.2.2 ClientHello . 76
B.2.3.2.3 MboxKeyExchange . 76
B.2.3.2.4 TLMSPKeyMaterial . 76
Annex C (normative): TLMSP alternative modes . 77
C.1 Fallback to TLS 1.2 . 77
C.2 Fallback to TLMSP-proxying . 78
C.2.1 General . 78
C.2.2 Fallback procedure . 78
C.2.3 Message and processing details . 81
C.2.3.1 TLMSP proxying and delegate extension and message specifications . 81
C.2.3.2 Delegate message specification . 81
C.2.3.3 Processing . 81
C.3 Middlebox security policy enforcement . 82
C.3.1 General . 82
C.3.2 Message formats . 83
Annex D (informative): Contexts and application layer interaction . 84
D.1 Application layer interaction model . 84
D.2 Example context usage . 84
Annex E (informative): Security considerations . 86
E.1 Trust model . 86
E.2 Cryptographic primitives . 87
ETSI
6 ETSI TS 103 523-2 V1.1.1 (2021-02)
E.2.1 General . 87
E.2.2 Handshake verification . 88
E.3 Protection against mcTLS attacks . 89
E.4 Inter-session assurance . 90
E.5 Use of the default context zero . 90
E.6 Removal of middlebox insertions . 90
E.7 Removal of support for renegotiation . 91
Annex F (informative): TLMSP design rationale . 92
F.1 General . 92
F.2 Containers . 92
F.3 Sequence numbers and re-ordering/deletion attacks . 92
F.4 MAC for synchronization purposes . 93
F.5 Removal of support for renegotiation . 93
Annex G (informative): Mapping MSP desired capabilities to TLMSP . 94
G.1 General . 94
G.2 MSP Requirements - Data Protection . 95
G.3 MSP Requirements - Transparency . 96
G.4 MSP Requirements - Access Control . 99
G.5 MSP Requirements - Good Citizen . 101
Annex H (informative): TLMSP compression issues . 103
Annex I (informative): IANA considerations. 104
History . 105

ETSI
7 ETSI TS 103 523-2 V1.1.1 (2021-02)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Cyber Security (CYBER).
The present document is part 2 of a multi-part deliverable covering Middlebox Security Protocols (MSP), defining a
generic security blueprint for a family of profiles of MSP, as identified below:
Part 1: "MSP Framework and Template Requirements";
Part 2: "Transport layer MSP, profile for fine grained access control";
Part 3: "Enterprise Transport Security".
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Executive summary
Requirements exist for network operators, service providers, users, enterprises, and small businesses, to be able to grant
varied (fine grained) permissions and to enable visibility of middleboxes, where the middleboxes in turn gain
observability of the content and metadata of encrypted sessions. Various cyber defence techniques motivate these
requirements. At present, the solutions used often break security mechanisms and/or ignore the desire for explicit
authorization by the endpoints. Man-In-The-Middle (MITM) proxies frequently used by enterprises prevent the use of
certificate pinning and EV (Extended Validation) certificates. Where no such mechanisms exist, some encryption
protocols can even be blocked altogether at the enterprise gateway, forcing users to revert to insecure protocols. As
more datagram network traffic is encrypted, the problems for cyber defence will grow (IETF RFC 8404 [i.4]).
ETSI
8 ETSI TS 103 523-2 V1.1.1 (2021-02)
The present document is one of a series of implementation profiles to achieve these visibility and observability goals,
putting the user in control of the access to their data for cyber defence purposes and protecting against unauthorized
access. It sets forth a "Transport layer MSP (TLMSP), profile for fine grained access control" that meets the capability
requirements found in Middlebox Security Protocol MSP Part 1 (ETSI TS 103 523-1 [i.5]).
Authorized middleboxes rarely need full read and write access to both the headers and full content of both directions of
a communication session to perform their function. TLMSP provides means for classification of the communication
between the endpoints into different so-called "contexts", each of which can have different read, delete, and write
permissions associated with it, following the security principle of least privilege. This subdivision is for the application
to determine and is under endpoint control.
TLMSP is modelled similarly to the TLS protocol (IETF RFC 5246 [1]) and composed of the TLMSP Record Protocol
for the encapsulation of data from higher level protocols, and the TLMSP Handshake Protocol for the agreement of
keys and the authentication of all parties with access to the communication prior to the sending of any application data.
Alert and ChangeCipherSpec Protocols are also provided with similar functionalities as their TLS counterparts. These
protocols: satisfy the same basic properties described in IETF RFC 5077 [2], they give visibility and control of the
security of the entire communication pathway to the endpoints, and they allow the principle of least privilege to be
enforced.
TLMSP is derived from mcTLS [i.1] with added features that include: additional metadata fields that allow
middleboxes to perform not only read and modification operations, but also auditable insertions (of new data,
originating at the middlebox) and deletions; a more flexible message format, allowing adaptation to varying network
conditions; on-path middlebox discovery; improved sequence number handling; fallback to TLS; and additional security
measures against recently discovered security vulnerabilities. Three normative annexes are included that contain
defined cipher suites, TLS fallback mechanisms, and authentication extensions.
Introduction
There are many uses of middlebox technologies. Some examples are: providing a better user experience (content
caching to reduce latency, network prefetching of content); providing user protection and cyber defence (firewalls,
intrusion and malware detection, child protection); providing business protection (data loss prevention and audit).
These middlebox systems rarely require both read and write access to all communication content to function, though
current security protocols necessitate an all-or-nothing approach, forcing to break the security assurances that
underlying encrypted protocols are intended to provide.
EXAMPLE: Man-In-The-Middle proxies used for gateway defence do not provide any assurance of the final
endpoint identity, breaking certificate pinning and violating PKI trust models. They also fail to
provide assurance that the connection beyond the gateway to the endpoint is even encrypted.
On most non-enterprise networks, users generally desire control of their own data - to choose whether to grant access or
not to another party. Users wishing to protect themselves from malicious software on their own systems stealing their
data (or including software that harvests user data without user consent) are not currently well-positioned to insist that
data is forwarded through their own cyber-defence systems or to grant access to the content. Any system that prevents
this can be used as a means of stealing the user data, which is a privacy failure.
To avoid these issues, users need to layer their security architecture and not be forced to rely on endpoint defence alone,
as there will be some platforms where this is not optimal, hard, or even impossible. The best defence is always expected
to be a layered approach and not reliant on a single mechanism at a single location/layer. This is expected to be
particularly true for those low power IoT devices that lack capability of running endpoint protection, where endpoint
protection does not even exist, and where patches are slow or non-existent. Unpatched devices can be protected from
vulnerabilities only by preventing malicious payloads reaching the IoT device at all; this is a requirement that can only
be satisfied by network-based defence.
However, for privacy reasons, network defence ought not to require disabling of data encryption, and maintaining end-
to-end encrypted data is a requirement. In the present document, a protocol profile is defined to allow endpoints in a
session to authenticate, create an end-to-end encrypted session, and then authorize additional parties to access portions
of the encrypted traffic. This profile provides full visibility of all additional middleboxes and their permissions to both
parties prior to the sending of any application layer traffic. Additionally, no middleboxes can be added or have
permissions granted by this protocol without the both endpoints agreeing to both their presence and their permission
level. These requirements assure the fundamental principle that the endpoints are in control of their own data and who
can have access to it.
ETSI
9 ETSI TS 103 523-2 V1.1.1 (2021-02)
1 Scope
The present document specifies a protocol to enable secure transparent communication sessions between network
endpoints with one or more middleboxes between these endpoints, using data encryption and integrity protection, as
well as authentication of the identity of the endpoints and the identity of any middlebox present. This protocol can be
mapped to the abstract MSP protocol capability requirements in ETSI TS 103 523-1 [i.5].
The Middlebox Security Protocol builds on TLS 1.2 [1] and is an extensively modified version of the mcTLS protocol
[i.1]. Whilst basic concepts are inherited from the mcTLS variant, the protocol specified in the present document also
contains significant additional functionality and feature changes that would render it incompatible with the original
version published.
The present document focuses on TLMSP usage with TCP as it is the most common usage. Usages with other transport
protocols are possible but left out of scope. In the remainder of the present document, unless otherwise noted, the word
TLS refers to TLS 1.2 [1].
The present document defines a set of five sub-protocols for specific purposes: Handshake (authenticating endpoints
and middleboxes and negotiating cryptographic configuration among those entities); Alert (signalling errors and
notifications); Application (carrying data generated by higher layers); ChangeCipherSpec (signalling the activation of
the negotiated cryptographic configuration) and a Record protocol, (responsible for applying the activated security
configuration to all of the other aforementioned sub-protocols).
Since TLMSP is a generic protocol, usable with a wide range of applications, issues related to mapping of application-
specific security policy to explicit configurations of TLMSP is largely left out of scope. Further, out-of-band
provisioning aspects relating to policies, pre-configuration of the client, details on actions in error situations are also out
of scope. While some informal discussion on the security properties of TLMSP is provided, a complete (formal)
security analysis of the protocol is currently left out of scope.
A reference implementation of TLMSP is being developed and can be accessed at [i.7].
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] IETF RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".
[2] IETF RFC 5077: "Transport Layer Security (TLS) Session Resumption without Server-side State".
[3] IETF RFC 5116: "An Interface and Algorithms for Authenticated Encryption".
[4] IETF RFC 5746: "Transport Layer Security (TLS) Renegotiation Indication Extension".
[5] IETF RFC 7748: "Elliptic Curves for Security".
[6] IETF RFC 7919: "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport
Layer Security (TLS)".
[7] IETF RFC 8449: "Record Size Limit Extension for TLS".
ETSI
10 ETSI TS 103 523-2 V1.1.1 (2021-02)
[8] IETF RFC 5288: "AES Galois Counter Mode (GCM) Cipher Suites for TLS".
[9] NIST FIPS PUB 186-4: "Digital Signature Standard (DSS)".
[10] NIST SP 800-38D: "Recommendation for Block Cipher Modes of Operation: Galois/Counter
Mode (GCM) and GMAC".
[11] ETSI TS 133 220: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); LTE; Generic Authentication Architecture (GAA); Generic
Bootstrapping Architecture (GBA)".
[12] IETF RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax".
[13] IETF RFC 1983: "Internet Users' Glossary".
[14] IETF RFC 1123: "Requirements for Internet Hosts -- Application and Support".
[15] IETF RFC 793: "Transmission Control Protocol".
[16] IETF RFC 791: "Internet Protocol".
[17] IETF RFC 8200: "Internet Protocol, Version 6 (IPv6) Specification".
[18] IEEE 802-2014: "IEEE Standard for Local and Metropolitan Area Networks: Overview and
Architecture".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For
...