MODBUS/TCP Security

Protocol Specification

MODBUS® is a registered trademark of Schneider Electric USA, Inc., used under license by
Modbus Organization, Inc.

Modbus.org
MB-TCP-Security-v36_2021-07-30
1
 1 Table of Contents
2
3 1 Conformance Levels ................................................................................................................. 3
4 2 Normative Statements .............................................................................................................. 3
5 3 References ............................................................................................................................... 4
6 4 Glossary of Acronyms & Abbreviations .................................................................................... 4
7 5 Introduction ............................................................................................................................... 5
8 6 Protocol Overview .................................................................................................................... 6
9 6.1 General ............................................................................................................................ 6
10 6.2 Transport Layer Security Introduction.............................................................................. 6
11 7 Service Definition .................................................................................................................... 10
12 8 Protocol Specification ............................................................................................................. 10
13 8.1 General .......................................................................................................................... 10
14 8.2 TLS Handshake ............................................................................................................. 10
15 8.3 Cipher suite selection..................................................................................................... 14
16 8.4 mbaps Role-Based Client Authorization ........................................................................ 14
17 9 System Dependencies ............................................................................................................ 16
18 10 TLS Requirements ............................................................................................................. 16
19 10.1 TLS Version ................................................................................................................... 16
20 10.2 TLS v1.2 Cryptography .................................................................................................. 17
21 10.2.1 General .................................................................................................................. 17
22 10.2.2 TLS Key Exchange ................................................................................................ 17
23 10.2.3 TLS Authentication ................................................................................................. 17
24 10.2.4 TLS Encryption ...................................................................................................... 18
25 10.2.5 TLS MAC................................................................................................................ 18
26 10.2.6 TLS PRF ................................................................................................................ 18
27 10.2.7 TLS Cryptography Import/Export Policy ................................................................ 18
28 10.3 TLS Fragmentation ........................................................................................................ 19
29 10.4 TLS Compression .......................................................................................................... 19
30 10.5 TLS Session Renegotiation ........................................................................................... 19
31 11 APPENDIX A: mbaps Packet Structure ............................................................................. 20
32
33 List of Figures
34
35 Figure 1 Modbus/TCP ADU ............................................................................................................. 5
36 Figure 2 TLS Communications Protocol Stack ................................................................................ 6
37 Figure 3 mbap ADU Encapsulated in TLS ....................................................................................... 7
38 Figure 4 Modbus/TCP Security Concept View ................................................................................ 8
39 Figure 5 Example x.509v3 Certificate with Role Extension ............................................................. 9
40 Figure 6 TLS Full Handshake Protocol .......................................................................................... 11
41 Figure 7 TLS Resumption .............................................................................................................. 13
42 Figure 8 Role-Base Client AuthZ ................................................................................................... 15
43 Figure 9 Example Role Extension ................................................................................................. 15
44 Figure A.1 TLS Transportation of mbap ADU ................................................................................ 20
45 Figure A.2 TLS Record Layer Structure ........................................................................................ 20
46 Figure A.3 TLS Generic Block Cipher............................................................................................ 20
47
48 List of Tables
49
50 Table 1 Conformance Levels ........................................................................................................... 3
51 Table 2 References.......................................................................................................................... 4
52 Table 3 Glossary of Acronyms & Abbreviations .............................................................................. 4
53 Table 4 Context Specific Terminology ............................................................................................. 5
54 Table 5 TLS Full Handshake Protocol ........................................................................................... 11
55 Table 6 TLS Resumption handshake ............................................................................................ 13
56

Modbus.org
MB-TCP-Security-v36_2021-07-30
2
57 1 Conformance Levels
58
59
60 Table 1 Conformance Levels

Latest In a standard document, specific notations shall be used to define the

conventions significance of each particular requirement. These notations (words) are
available highlighted by capitalization.
up-to-now As Consistency Rules may have the target to be presented to a
standards body in order to become an international standard, the
selection of the words "SHALL" and "MUST" should be made according
to the rules of the organization that covers the standardization in the
affected area of the Specification.
Compliance An implementation that satisfies all the MUST / SHALL requirements is
said to be “unconditionally compliant”.
One that satisfies all the MUST requirements but not all the SHOULD
recommendations is said to be “conditionally compliant”.
An implementation is not compliant if it fails to satisfy one or more of the
MUST / SHALL requirements that it implements
MUST All requirements containing the word "MUST / SHALL" are mandatory.
SHALL
REQUIRED The word "MUST / SHALL", or the adjective "REQUIRED", means that
the item is an absolute requirement of the implementation.
MUST NOT All requirements containing the word "MUST NOT/ SHALL NOT" are
SHALL NOT mandatory.

The phrase "MUST NOT” or the phrase “SHALL NOT” mean that the
item is an absolute prohibition of the specification.
SHOULD All recommendations containing the word "SHOULD", or the adjective
RECOMMENDED “RECOMMENDED” are considered desired behaviour.

These recommendations should be used as a guideline when choosing

between different options to implement functionality. In uncommon
circumstances, valid reasons may exist to ignore this item, but the full
implication should be understood and the case carefully weighed before
choosing a different course.
MAY The word “MAY”, or the adjective "OPTIONAL", means that this item is
OPTIONAL truly optional.

One implementer may choose to include the item because a particular

marketplace requires it or because it enhances the product; another
implementer may omit the same item.
61
62
63
64 2 Normative Statements
65
66 Normative statements in this technical specification are called out explicitly as follows:
67
R-n.m: Normative statement text goes here.
68
69
70 where "n.m" is replaced by the requirement statement tag number which can be a hierarchical
71 number, e.g. R-1.2.3 or a simple integer, e.g. R-1.
72

Modbus.org
MB-TCP-Security-v36_2021-07-30
3
73 Each statement contains exactly one requirement level keyword (e.g., "MUST") and one
74 conformance target keyword (e.g., "Message"). Example: “The Message MUST be encoded using
75 BER”.
76
77
78 3 References
79 Table 2 References

Reference Description
[62443-3-3] IEC 62443-3-3: System security requirements and security levels
[62443-4-2] IEC 62443-4-2: Technical security requirements for IACS components
[MB] Modbus Application Protocol Specification, V1.1b3, 2012-04-26,
https://modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf
[MBTCP] Modbus Messaging on TCP/IP Implementation Guide, V1.0b, 2006-10-24,
https://modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf
[RFC4492] IETF RFC 4492, Elliptic Curve Cryptography (ECC) Cipher Suites for Transport
Layer Security (TLS)
[RFC5246] IETF RFC 5246, The Transport Layer Security (TLS) Protocol, v1.2, Aug 2008
[RFC5280] IETF RFC 5280, Internet x.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile, May 2008
[RFC5746] IETF RFC 5746, TLS Renegotiation Indication Extension, Feb 2010
[RFC6066] IETF RFC 6066, TLS Extensions: Extension Definitions, Jan 2011
[RFC6176] IETF RFC 6176, Prohibiting Secure Sockets Layer (SSL) Version 2.0, Mar 2011
[TLS- IANA’s Transport Layer parameter type registry.
PARAMS] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
80
81
82 4 Glossary of Acronyms & Abbreviations
83
84 Table 3 Glossary of Acronyms & Abbreviations

Reference Description
ADU Application Data Unit
AuthZ Authorization
CA Certificate Authority
CDP CRL Distribution Point
CRL Certificate Revocation List
HMAC Keyed-hash Message Authentication Code
IANA Internet Assigned Numbers Authority
ICS Industrial Control System
IEC International Electrotechnical Commission
MAC Message Authentication Code
mbap Modbus Application Protocol
mbaps Modbus Security Application Protocol
OID Object Idenitifier standardized by the International Telecommunications
Union
PEN Private Enterprise Number
PDU Protocol Data Unit
PKI Public Key Infrastructure
PRF Psuedorandom Function Family
RA Registration Authority
SSL Secure Socket Layer
TCP Transport Control Protocol
TLS Transport Layer Security
85

Modbus.org
MB-TCP-Security-v36_2021-07-30
4
 86 5 Introduction
87
88 The Modbus/TCP protocol is widely deployed in Industrial Control Systems (ICS). The
89 specifications for Modbus/TCP are found at the modbus.org web site. The Modbus/TCP
90 specification defines an Application Data Unit (ADU). This ADU is defined as shown in Figure
91 1 Modbus/TCP ADU:
92

93
94 Figure 1 Modbus/TCP ADU

95 The difference between a traditional Modbus Protocol Data Unit (PDU) and the Modbus/TCP
96 ADU is the addition of the Modbus Application Protocol (mbap) header at the front of the
97 frame.
98
99 In 1996 the Modbus/TCP protocol, was registered with IANA
Modbus/TCP 100 (Internet Assigned Number Authority) and assigned the
101 system port number 502. In the course of this registration
Security Principles
102 process with IANA the Modbus/TCP protocol came to be
• Modbus/TCP Security 103 called the mbap protocol because of the mbap header in the
@ port 802 104 Modbus/TCP ADU. This name, the mbap protocol, persisted
• x.509v3 certificate 105 and is still used for the port 502 registration with the IANA as
based identity and 106 mbap/TCP
authentication with TLS
107
• Mutual client/server TLS
108 The Modbus/TCP Security protocol is a security focused
authentication
• Authorization using
109 variant of the Mobdbus/TCP protocol utilizing Transport
roles transferred via 110 Layer Security (TLS). IANA has assigned the Modbus/TCP
certificates 111 Security protocol the system port number 802. Modbus.org
• 112
Authorization rules are has registered the name Modbus Security Application
product specific 113 Protocol to the protocol registered at port 802 with IANA as
• No changes to mbap 114 mbap/TLS/TCP
115
116 The selection of TLS as the secure transport protocols is the result of analyzing representative
117 data flows from industry domains in the context of [62443-3-3] and [62443-4-2].
118
119 Table 4 Context Specific Terminology lists the names used for the mbap communication
120 profiles in different contexts, e.g. Communication Profile, Modbus.org, the IANA Registry, and
121 this specification. For reasons of brevity, the remainder of this specification will use mbap and
122 mbaps to refer to Modbus/TCP and Modbus/TCP Security respectively.
123
124 Table 4 Context Specific Terminology

Communication Modbus.org IANA Registry This specification

Profile (for brevity)
mbap/TCP Modbus/TCP Modbus Application mbap
Protocol at System
Port 502
mbap/TLS/TCP Modbus/TCP Modbus Security mbaps
Security Application Protocol
at System Port 802
125
Modbus.org
MB-TCP-Security-v36_2021-07-30
5
126
127 6 Protocol Overview
128 6.1 General
129
130 In the tradition of Modbus, the mbaps requirements are kept simple allowing vendors to
131 develop additional infrastructure around the protocol and allowing backwards compatibility with
132 legacy devices and fieldbuses. Mbaps extends the original mbap protocol as defined in
133 [MBTCP] and [MB]. Mbaps defines a client-server protocol that is a part of a complete security
134 system architecture. As illustrated in Figure 3 mbap ADU Encapsulated in TLS, the mbap ADU
135 is encapsulated by TLS. TLS provides a security focused protocol alternative to mbap by
136 adding confidential transport of the data, data integrity, anti-replay protection, endpoint
137 authentication via certificates, and authorization via information embedded in the certificate
138 such as user and device roles.
139
140 The protocols mbap and mbaps are similar to http and its secure variant https respectively. In
141 mbaps, the mbap protocol is transported via TLS. TLS provides an authentication capability
142 via x.509v3 certificates. The mbaps clients and servers must be provisioned with the these
143 certificates to participate in the TLS Authentication function.
144
145 An important difference between mbap and mbaps is that mbaps provides the capability of the
146 server invoking an authorization function whose rules are driven by the vendor or customer,
147 utilizing role data that is provided via an extension field in the x.509v3 certificate. The
148 extension is registered with Modbus.org’s IANA OID. TLS provides for the use of pre-shared
149 keys to establish a secure connection, but the use is not considered for this specification as it
150 does not allow for the trasfer of role information to provide an authorization function.
151
152 6.2 Transport Layer Security Introduction
153 The mbaps/TLS/TCP profile uses the secure TLS transport protocol defined in IETF RFC
154 5246. [RFC5246] defines TLS v1.2 and provides countermeasures and mitigations for known
155 vulnerabilities in earlier versions. While this specification is based on TLS v1.2, newer
156 versions will be considered as their implementations become widely adopted.
157
158 TLS is composed of a set of protocols as illustrated in Figure 2 TLS Communications Protocol
159 Stack. The main protocol in the set is the TLS Record Protocol. The remaining protocols are
160 sub-protocols which are carried by the TLS Record Protocol. These are managed by a TLS
161 middleware.

162
163 Figure 2 TLS Communications Protocol Stack

164 The mbap ADU which is unchanged in the mbaps profile is encapsulated in a TLS Application
165 Protocol message as illustrated in Figure 3 mbap ADU Encapsulated in TLS.
166

Modbus.org
MB-TCP-Security-v36_2021-07-30
6
167
168 Figure 3 mbap ADU Encapsulated in TLS

169 The TLS Handshake Protocol shown in Figure 4

Modbus/TCP 170 Modbus/TCP Security Concept View:
Security 171 • Negotiates cryptography for secure channel including
172 algorithms, keys, etc. between end points.
• Mutual client/server 173 • Provides mutual client/server authentication based on
TLS Authentication. 174 x.509v3 certificates
• Certificate based 175 • Extracts the client role OID from the certificate
Identity and 176 • Establishes the TLS session.
Authentication with 177
TLS. 178 After the TLS session is established normal modbus request
• Certificate based 179 and response sequences are transmitted in the secured TLS
Authorization using role
180 Application Protocol channel. During the procesing of the
information transferred
via certificate 181 request, the mbaps protocol handler invokes a vendor
extensions. 182 specific authorization function. This authorization function
• Authorization is product
183 evaluates a roles-to-rights algorithm using inputs from the
184
specific and invoked by mbap ADU and the role extracted from the x.509 client
mbap function code 185 certificate of the connection. The algorithm determines if the
handler. 186 ADU can be processed based on role of the peer. If the
• Authorization roles to187 authorization function determines that the mbap ADU code
rights rules are product
188 cannot be processed, the mbap handler returns a 01 – IIlegal
specific and configured
in the Authorization 189 Function Modbus exception code. This authorization process
function. 190 occurs on every request, ensuring complete validation of the
191 request stream.
192

Modbus.org
MB-TCP-Security-v36_2021-07-30
7
193

194
195 Figure 4 Modbus/TCP Security Concept View

Modbus.org
MB-TCP-Security-v36_2021-07-30
8
 Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4135 (0x1027)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=STATE, L=LOCAL, O=ORG, OU=SUBORG, CN=INTER-CA
Validity
Not Before: Oct 27 12:58:27 2017 GMT
Not After : Oct 27 12:58:27 2018 GMT
Subject: C=US, ST=STATE, L=LOCAL, O=ORG, OU=SUBORG, CN=ModbusSecurityClient
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:be:3d:4d:9e:8c:fe:1e:06:e6:19:cd:52:68:07:
54:c6:d3:b3:cd:bb:da:dd:29:29:b5:2d:2f:3b:bf:
b9:3c:c7:c2:f4:a9:98:ce:6e:47:f5:64:7d:6d:e8: Example x.509v3
a3:6b:02:da:4c:e9:05:b8:aa:30:d9:95:13:1f:14:
58:3e:c1:dc:a7:21:ca:c0:90:c9:e5:80:70:2b:8d: Certificate with Role
4d:0a:78:96:c0:9e:1f:f1:1d:e7:e8:24:be:06:a1: Encoded as a
b8:6a:67:d3:7f:1c:d4:cb:c3:85:5a:f8:a7:ef:d1: Certificate
e0:df:30:60:44:29:a3:4d:63:24:d2:7f:e9:45:29:
2d:e9:fa:53:3d:be:f8:cd:72:64:08:dc:7e:b0:e9: Extension
d1:c2:e7:52:de:eb:9d:b0:60:b1:73:62:24:ac:ba:
08:5f:65:23:9a:38:b5:48:53:08:bc:79:ae:b1:55: • Example Role is
fd:b1:f3:6f:c9:fa:ac:aa:89:aa:f9:59:ca:bf:fe: Operator
7a:12:cf:88:20:5b:5e:8b:b5:b1:58:04:41:19:2c: • The OID for the Role is
26:91:0d:ce:86:38:93:32:a0:ab:57:01:38:5a:41: defined in the
36:77:ae:2b:89:28:8e:22:48:84:b6:18:b9:31:aa: Modbus.org Private MIB
52:c3:72:3a:19:41:65:21:87:32:4b:c0:53:3e:aa: whose PEN (Private
36:dd:d6:40:09:55:e3:65:2c:f9:d4:61:24:6d:60: Enterprise Number) is
64:87 50316.
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
B3:09:92:E3:60:44:DE:F5:5B:30:8B:3B:D3:EA:78:FF:CE:DA:E3:48
X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment
RoleOID:1.3.6.1.4.1.50316.802.1:
Operator
X509v3 Subject Alternative Name:
IP Address:192.168.2.12, IP Address:192.168.2.22
Signature Algorithm: sha256WithRSAEncryption
4f:a2:ca:1f:ea:11:b8:55:89:97:6a:b8:f2:bc:a6:30:e4:6a:
d7:1e:25:8e:db:cb:f1:54:23:9a:ce:39:e4:dd:96:5f:ce:2a:
0c:73:43:23:06:7d:a4:fa:33:48:2c:86:42:a7:eb:d8:d4:fa:
d1:08:07:e9:b1:9c:51:b6:78:9c:e7:2e:fb:22:cc:89:28:ef:
8f:7a:30:a9:73:e8:28:9a:ab:a4:f2:d5:ec:29:e8:dc:77:a7:
f5:e1:71:8a:0f:76:4c:78:a5:5c:b7:ea:4e:86:c7:fe:01:17:
8c:4a:b1:7c:11:d7:f7:a6:81:d4:1c:bb:86:af:d5:20:fe:05:
ec:0f:de:8d:d1:c0:76:40:31:0f:15:23:65:4d:5c:7c:52:d3:
cd:c7:81:a5:8a:4f:51:e1:2b:07:9a:8b:83:0d:95:91:97:37:
6d:59:c5:ca:2e:5d:82:a8:ac:1c:f8:0a:56:06:dc:47:93:db:
bc:c6:21:94:dd:55:ee:90:3f:ad:f8:15:22:16:99:cf:3f:bc:
2f:af:aa:04:16:0d:e6:89:c2:f4:af:cb:0e:27:fc:5c:d9:3f:
5c:5a:b7:4b:aa:d9:a5:eb:0a:3e:53:16:1a:3f:10:20:7b:52:
ea:93:ed:b8:21:43:b3:dd:cb:38:1f:d9:38:d1:10:09:c0:25:
df:bf:6a:b7
196
197 Figure 5 Example x.509v3 Certificate with Role Extension

Modbus.org
MB-TCP-Security-v36_2021-07-30
9
198 The development of mbaps and its deployment in a device were guided by a set of principles
199 including:
200 • R-01: The TLS Protocol v1.2 as defined in [RFC5246] or newer MUST be used as the
201 secure transport protocol for an mbaps Device.
202 • R-02: Secure communications to an mbaps Device MUST use Mutual client/server
203 authentication as provided by the TLS Handshake Protocol.
204 • R-03: x.509v3 Certificates as defined in [RFC5280] MUST be used as mbaps device
205 credentials for Identity/Authentication by the TLS protocol.
206 • R-04: If the Authorization function is enforced it MUST use the role transferred via
207 x.509v3 certificate extensions.
208 • R-05: There MUST be no change to the mbap protocol as a consequence of it being
209 encapsulated by the secure transport.
210
211 7 Service Definition
212
213 Standard function codes used on Modbus Application layer protocol are described in details in the
214 [MB] specification. There is no modification to the standard function codes in this specification.
215
216 8 Protocol Specification
217 8.1 General
218
219 The communication of an mbap ADU is secured using the Transport Layer Security protocol,
220 TLS, defined in [RFC5246]. Figure 3 mbap ADU Encapsulated in TLS illustrates how an mbap
221 ADU is transmitted via the TLS Application Protocol.
222
223 TLS provides Transport Layer Security between two end points. To do this, the TLS end points
224 execute the TLS Handshake protocol to negotiate security parameters and to create a TLS
225 session.
226
227 8.2 TLS Handshake
228
229 For two mbaps end devices to communicate securely using TLS, a security context between the
230 end points of the TLS connection must be established. The TLS Handshake protocol establishes
231 the secure context, i.e. the TLS session. The TLS session has a session identifier and the
232 security context is described by a set of security parameters as defined in [RFC5246] section A.6.
233
234 Mutual Authentication requires that each end point will send its domain certificate chain to the
235 remote end point. Upon receipt of a certificate chain from the remote peer, the TLS end point will
236 verify the each certificate signature using the next CA certificate in the chain until it can verify the
237 root of the chain.
238
239 The TLS Full Handshake Protocol, which is defined in [RFC5246] section 7.3, is illustrated in
240 Figure 6 TLS Full Handshake Protocol.
241

Modbus.org
MB-TCP-Security-v36_2021-07-30
10
242
243 Figure 6 TLS Full Handshake Protocol

244
245 Table 5 TLS Full Handshake Protocol

Message Description
1:ClientHello The TlsClient sends a ClientHello message to the TlsServer to
begin negotiation process. The TlsClient offers a cipher suite list in
the message. The cipher suite list is ordered by the the client’s
preference.
2:ServerHello TlsServer sends a ServerHello message in response to
ClientHello. The message identifies an acceptable set of
cryptographic algorithms and returns a new sessionID.
3:ServerCertificate The TlsServer sends its certificate chain as the payload of a
Certificate message. This chain contains the server device’s
domain certificate, as well as the certificate for each issuing CA
down to the root CA. This server’s domain certificate may also
contain the role of the server; when it happens this role is not used
by the client.

Modbus.org
MB-TCP-Security-v36_2021-07-30
11
 Message Description
4:VerifyServerCertSig When peer received certificate of remote peer it will check it by
• verifying each certificate’s signature in the chain using
public key of the issuer CA
• validate the certificate path to a trusted root certificate
• check the revocation status of each certificate in the chain
5:ServerKeyExchange The TlsServer sends a ServerKeyExchange message to the
TlsClient to provide data for setting the pre-master key.
6:CertificateRequest The TlsServer sends a Certificate Request message to the
TlsClient to obtain the Client Certificate.
7:ServerHelloDone The TlsServer sends a ServerHelloDone message to the TlsClient
to indicate the end of the ServerHello and associated messages.
8:ClientCertificate The TlsClient sends its certificate chain as the payload of a
Certificate message. This chain contains the client device’s
domain certificate, as well as the certificate for each issuing CA
down to the root CA. This client’s end certificate also contains the
role of the client. This is used by the server to authorize a later
application level request.
9:VerifyClientCertSig When peer received certificate of remote peer it will check it by
• verifying each certificate’s signature in the chain using
public key of the issuer CA
• validate the certificate path to a trusted root certificate
• check the revocation status of each certificate in the chain
10:ClientKeyExchange The TlsClient sends a ClientKeyExchange message to the
TlsServer. With this message the pre-master secret is set.
11:ChangeCipherSpec The TlsClient sends a ChangeCipherSpec message to the
TlsServer to indicate that subsequent messages sent by the Client
will be sent using newly negotiated cipher spec and keys.
12:Finished The TlsClient sends a Finished message to the TlsServer. This
message is the first message protected with the just negotiated
algorithms, keys, and secrets.
13:ChangeCipherSpec The TlsServer sends a ChangeCipherSpec message to the
TlsClient to indicate that subsequent messages sent by the Server
will be sent using newly negotiated cipher spec and keys.
14:Finished The TlsServer sends a Finished message to the TlsClient. This
message is protected with the just negotiated algorithms, keys,
and secrets.
15+n:ApplData() n ::= { 0 .. m}
15+n+1:ApplData() n ::= { 0 .. m}
246
247 TLS [RFC5246] also provides for session resumption. The server side partner caches the last
248 security state known, and pairs it the session ID used in the client and server hello. If the client
249 caches the security context and sessionId it can present this sessionID to the server on the next
250 ClientHello. If this sessionID matches with a cached sessionID on the server, the server will
251 immediately change the cipher spec as shown in Figure 7 TLS Resumption and the connection
252 will resume. This reduces the TLS negotiation time to 1 application round trip time, and removes
253 the public/private key cryptographic function needed to authorize a new peer. This resumption will
254 require the server to cache the role associated with the connection’s client certificate and
255 associate it with the sessionID.
256
257 If the sessionID presented by the ClientHello does not match a known server session, a new
258 sessionID is returned in the serverHello message and a full TLS handshake is performed as in
259 Figure 6 TLS Full Handshake Protocol.
260

Modbus.org
MB-TCP-Security-v36_2021-07-30
12
261
262 Figure 7 TLS Resumption

263
264 Table 6 TLS Resumption handshake

Message Description
1:ClientHello The TlsClient sends a ClientHello message to the TlsServer to
begin negotiation process. The TlsClient offers a cipher suite list in
the message. It also offers a cached non-zero sessionID
2:ServerHello TlsServer sends a ServerHello message in response to
ClientHello. The message identifies an acceptable cipher suite,
returns the same sessionID, and includes a ChangeCipherSpec
record
2:ChangeCipherSpec The TlsServer sends a ChangeCipherSpec message to the
TlsClient to indicate that subsequent messages sent by the Server
will be sent using newly negotiated cipher spec and keys.
2:Finished The TlsServer sends a Finished message to the TlsClient. This
message is the first message protected with the just negotiated
algorithms, keys, and secrets.
3:ChangeCipherSpec The TlsClient sends a ChangeCipherSpec message to the
TlsServer to indicate that subsequent messages sent by the Client
will be sent using newly negotiated cipher spec and keys.
Modbus.org
MB-TCP-Security-v36_2021-07-30
13
 Message Description
3:Finished The TlsClient sends a Finished message to the TlsServer. This
message is protected with the just negotiated algorithms, keys,
and secrets.
4+n:ApplData() n ::= { 0 .. m}
4+n+1:ApplData() n ::= { 0 .. m}
265
266 R-06: mbaps end devices MUST provide mutual authentication when executing the TLS
267 Handshake Protocol to create the TLS session.
268 R-07: The TlsServer MUST send the CertificateRequest message during the TLS handshake.
269 R-08: The TlsClient MUST send a ClientCertificate message upon receiving a request containing
270 the Client Certificate Request.
271 R-10: If the TlsClient does not send a ClientCertificate message, then the TlsServer MUST send
272 a ‘fatal alert’ message to TlsClient and terminate the connection.
273 R-11: Per RFC5246-7.2.2, the TLS connection MUST NOT be resumed after a ‘fatal alert’.
274
275 8.3 Cipher suite selection
276
277 The security strength of the resulting TLS session is dependent on the cipher suite negotiated
278 between the TLS end points. Cipher suites designate what cryptography will be used by the TLS
279 session to provide a certain level of security.
280
281 Only cipher suites registered with IANA and not known to have current weaknesses should be
282 used in mbaps.
283
284 R-12: Cipher suites used with TLS for mbaps MUST be listed at the IANA Registry found @
285 https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml .
286
287 R-13: The cipher allowed for TLS with mbaps MUST accommodate the use of x.509v3
288 certificates.
289
290 R-14: mbaps Devices MUST provide at minimum the following TLS v1.2 ciper suites when using
291 an RSA private key:
292 • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
293
294 R-66: Client devices with bulk transport encryption and NULL bulk encryption SHOULD always
295 place NULL bulk transport cipher suites last in cipher suite priority
296
297 R-67: Server devices SHOULD have the ability to enable use of the authentication only cipher
298 suite TLS_RSA_WITH_NULL_SHA256.
299
300 8.4 mbaps Role-Based Client Authorization
301
302 The mbaps protocol provides the capability to perform role-
Role-based 303 based client authorization (AuthZ). The client role data is
Authorization 304 transported in an extension of its x.509v3 domain certificate.
305 An example of a certificate with a Role extension is shown in
306 Figure 5 Example x.509v3 Certificate with Role Extension.
• Roles are encoded in
307
x.509v3 Certificate
Extension. 308
• Authorization function309
is
vendor specific. 310 Role-Based Client Authorization for mbaps is illustrated in
• Authorization roles to311 Figure 8 Role-Base Client AuthZ.
312
rights rules are vendor
313
specific and configured
into the Authorization314
function. 315
Modbus.org
MB-TCP-Security-v36_2021-07-30
14
 mbapsServer

mbapsClient mbaps server protocol handler

mbaps client protocol handler

AuthZ Algorithm

x.509v3 Client Domain Certificate

Roles-to-Rights Rules Database

316
317 Figure 8 Role-Base Client AuthZ

318 Once a TLS Session is established between the two TLS end points, the execution of role-based
319 client AuthZ is a two-step process.
320
321 During the first step, the mbaps server obtains the x.509v3 client domain certificate. This step
322 occurs when the mbaps server receives message 8 as shown in Figure 6 TLS Full Handshake
323 Protocol. The role is extracted from the x.509v3 certificate and cached. If a session is resumed,
324 this role must be associated with the resumed session.
325
326 The role extension is an ASN1 encoded UTF8 string.
327
...
Role:
1.3.6.1.4.1.50316.802.1:Operator
328
329 Figure 9 Example Role Extension

330 In the example Role extension, shown in Figure 9 Example Role Extension, the Role value
331 is ’Operator’.
332
333 The second step of the mbaps role-based client AuthZ capability involves using the extracted
334 client Role and the Modbus request. Both fields are input to the mbaps AuthZ Algorithm. The
335 AuthZ Algorithm determines whether the client is AUTHORIZED or NOT_AUTHORIZED to
336 perform the indicated function on the indicated resource that was specified in the Modbus
337 Function Code received by the mbaps server using the provisioned Roles-to-Rights Rules
338 Database. If the request is NOT_AUTHORIZED, Modbus exception code 01 – Illegal function
339 code will be returned. If the request is AUTHORIZED, it will be processed as normal by the mbap
340 server.
341
342 The Authorization Function and Roles-to-Rights Rules Database may exist on the server device
343 or may be remote requiring a separate protocol to determine the authorization status of the
344 request. This is outside the scope of this document.
345
346 The two-step process is shown in Figure 4 Modbus/TCP Security Concept View.
347
348 R-16: A mbaps Server Device SHOULD provide the role-based client AuthZ as described in this
349 section.
350
351 R-17: If a mbaps Server Device provides role-based client AuthZ, it MUST comply with the
352 requirements identified in this section.
353
354 R-18: To provide mbaps role-based client authorization capability the following elements are
355 REQUIRED:
Modbus.org
MB-TCP-Security-v36_2021-07-30
15
356 x.509v3 client domain certificate ‘Role’ extension,
357 mbaps server AuthZ algorithm,
358 mbaps server Roles-to-Rights Rules Database.
359
360 R-19: The mbaps client device MUST be provisioned with its x.509v3 domain certificate.
361
362 R-20: The x.509v3 client domain certificate SHOULD include the Role extension.
363
364 R-21: The Role in the X.509v3 certificate MUST use the Modbus.org PEM OID
365 1.3.6.1.4.1.50316.802.1
366
367 R-22: The Role in the x.509v3 certificate MUST use ASN1:UTF8String encoding
368
369 R-65: There MUST only be one role defined per certificate. The entire string will be treated as one
370 role.
371
372 R-23: If no Role is specified in the X.509v3 certificate, the mbaps server MUST provide a NULL
373 role to the AuthZ algorithm.
374
375 R-24: The mbaps AuthZ Algorithm MUST be defined and provided by the device vendor.
376
377 R-25: The Roles-to-Rights Rules Database design, both syntax and semantics, MUST be defined
378 by the device vendor.
379
380 R-26: The Roles-to-Rights Rules Database for a particular application MUST be configured
381 according to the device vendor’s design, and provisioned in the mbaps Server by the end user.
382
383 R-27: The Roles-to-Rights Rules Database for a particular application MUST be configurable by
384 the end user.
385
386 R-28: The Roles-to-Rights Rules Database for a particular application MUST NOT have hardcoded
387 default roles that are unchangeable.
388
389 R-29: The Role values used in the x.509v3 client domain certificates MUST be consistent with the
390 device vendor’s design of the Roles-to-Rights Rules Database.
391
392 R-30: The mbaps server MUST extract the client Role from the received x.509v3 client domain
393 certificate.
394
395 R-31: If the mbap protocol handler for authorization rejects a request it MUST use the
396 exception code 01 – Illegal function code.
397
398 9 System Dependencies
399
400 To participate in a solution architecture, mbaps devices are dependent on the certificate
401 management services of a Public Key Infrastructure (PKI). The details are not materially
402 important to the implementation of the mbaps server or client behaviour.

403 10 TLS Requirements

404 10.1 TLS Version
405
406 R-32: mbaps devices MUST provide TLS v1.2 or better.
407
408 R-33: mbaps Devices MUST conform to the requirements of [RFC5246].
409

Modbus.org
MB-TCP-Security-v36_2021-07-30
16
410 R-34: mbaps devices MUST NOT negotiate down to TLS v1.1, TLS v1.0, or SSL V3.0.
411
412 R-35: mbaps devices MUST NOT negotiate the use SSL v2.0 and SSL v1.0 in conformance with
413 [RFC6176].
414

415 10.2 TLS v1.2 Cryptography

416 10.2.1 General
417 R-36: mbaps Devices SHOULD provide a counter mode cipher suite.
418
419 Counter mode cipher suites include
420 TLS_RSA_WITH_AES_128_GCM_SHA256, {0x00, 0x9C}
421 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, {0xC0, 0x2B}
422
423 R-37: mbaps Devices MUST NOT negotiate the cipher suite, TLS_NULL_WITH_NULL_NULL
424
425 R-38: Any cipher suite used by mbaps Devices and negotiated in a TLS Handshake Protocol
426 exchange MUST be listed at IANA’s TLS Cipher Suite Registry in the [TLS-PARAMS].
427

428 10.2.2 TLS Key Exchange

429
430 R-39: mbaps Devices MUST provide TLS Client-Server key exchange based-on RSA technology
431 as specified by the mandatory cipher suite and described in [RFC 5246].
432
433 R-40: mbaps Devices SHOULD provide TLS Client-Server key exchange based on ECC
434 technology.
435
436 R-61: mbaps Devices using ECC technology MUST support at least P-256 NIST curve.
437
438 R-62: mbaps Devices using ECC technology MUST support at least the minimum cipher suite of
439 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
440
441 R-63: mbaps Devices using ECC technology MUST specify the curves used in their ClientHello
442 using the Supported Elliptic Curves extension in [RFC4492]
443
444 R-64: mbaps Devices using ECC technology MUST specify the point format used in their
445 ClientHello using the Supported Point Format extension in [RFC4492]
446

447 10.2.3 TLS Authentication

448 Authentication against trust anchors may be done using self signed device certificates. It is
449 recommended to use certificates signed by a Certificate Authority for authentication.
450
451 Session resumption using session tickets or resuming session IDs should be supported to reduce
452 the handshake time of a connection.Session resumption using session IDs is preferred. In
453 session resumption it is the responsibility of the server to cache and maintain session information
454 for later use. It is more well supported and places less demand on clients to manage session
455 information with their peer.
456
457 Session tickets place the burden of session information on the client. This information is
458 encrypted by the server and transmitted to the client. On new session, this information is
459 transmitted back to the server and used to re-establish a connection. Less server resources are
460 needed to accomplish this but network resources are wasted and due to the transmission of
461 information it takes longer to re-establish a connection.

Modbus.org
MB-TCP-Security-v36_2021-07-30
17
462
463 R-41: mbaps Devices MUST support the TLS Client-Server Mutual Authentication Handshake.
464
465 R-42: mbaps Device SHOULD support the TLS Resumed Session Handshake on Client and
466 Server.
467
468 R-43: mbaps Device MAY support the TLS Session Ticket resumption on Client and Server
469
470 R-44: mbaps Servers MUST reject a TLS Handshake where the Client has not responded to a
471 Client Certificate request with certificate.
472
473 R-45: mbaps Devices SHOULD provide x.509v3 Certificates signed by a Certificate Authority.
474
475 R-46: mbaps Devices MUST send the entire certificate chain down to the root CA when sending
476 their certificate
477
478 R-47: x.509v3 Certificates provided by mbaps Devices MUST conform to the requirements of
479 [RFC5280].
480

481 10.2.4 TLS Encryption

482
483 R-48: If an mbaps Device is to be used in a scenario where encryption is required, then a cipher
484 suite with the required encryption indicator MUST be chosen from the list at IANA’s TLS Cipher
485 Suite Registry in the [TLS-PARAMS].
486
487 R-49: If an mbaps Device is to be used in a scenario where encryption is not required, then a
488 cipher suite with a NULL bulk encryption indicator MUST be chosen from the list at IANA’s TLS
489 Cipher Suite Registry in the [TLS-PARAMS].

490 10.2.5 TLS MAC

491
492 R-50: mbaps Devices MUST NOT use the HMAC-MD5 hash algorithm.
493
494 R-51: mbaps Devices MUST NOT use the HMAC-SHA-1 hash algorithm.
495
496 R-52: mbaps Devices MUST provide the HMAC-SHA-256 hash algorithm.
497
498 R-53: mbaps Device MUST NOT use a NULL HMAC hash algorithm
499

500 10.2.6 TLS PRF

501
502 R-54: mbaps Devices MUST NOT provide the HMAC-SHA-1 hash algorithm for use in the PRF
503 function to calculate the key block as defined in [RFC5246] sections 5, 6.3 and 8.1.
504
505 R-55: mbaps Devices MUST provide the HMAC-SHA-256 hash algorithm for use in the PRF
506 function to calculate the key block as defined in [RFC5246] sections 5, 6.3 and 8.1.
507

508 10.2.7 TLS Cryptography Import/Export Policy

509
510 R-56: As early as possible in their development cycle, mbaps devices MUST determine that they
511 comply with the import/export conformance policies of their respective countries for the
512 cryptography they provide.

Modbus.org
MB-TCP-Security-v36_2021-07-30
18
513 10.3 TLS Fragmentation
514
515 R-57: mbaps devices MUST provide the Maximum Fragment Length Negotiation Extension as
516 defined in [RFC6066].
517
518 R-58: mbaps devices MUST provide the ability to negotiate a Maximum Fragment Length of 29
519 (512) bytes as defined in [RFC6066].
520

521 10.4 TLS Compression

522
523 R-59: mbaps devices MUST set the TLS CompressionMethod field of the ClientHello message to
524 the value of NULL.
525

526 10.5 TLS Session Renegotiation

527
528 R-60: mbaps devices MUST provide the TLS Renegotiation Indication Extension defined in
529 [RFC5746] to provide the secure renegotiation of TLS sessions.
530

Modbus.org
MB-TCP-Security-v36_2021-07-30
19
531 11 APPENDIX A: mbaps Packet Structure
532
533 Figure A.1 TLS Transportation of mbap ADU shows the layering of the TLS protocol on TCP. The
534 mbap ADU encapsulated in a TLS Application Protocol Packet. The mbaps protocol which is the
535 mbap protocol transported by TLS is found at TCP port 802.

536
537 Figure A.1 TLS Transportation of mbap ADU

538 The structure of the TLS Record Layer used by mbaps is defined in [RFC5246] sec A-1, where:
539 • ContentType type = 23, Application Protocol
540 • ProtocolVersion version = {3,3} for TLS v1.2
541 • uint16 length = number of bytes of the following TLSCiphertext.fragment,
542 MUST NOT exceed 16384 + 2048 (18432)
543 • fragment = The encrypted form of TLSCompressed.Fragment, with the MAC
544
struct {
545
ContentType type;
546
ProtocolVersion version;
547
uint16 length;
548
select (SecurityParameters.cipher_type) {
549
case stream: GenericStreamCipher;
550
case block: GenericBlockCipher;
551
case aead: GenericAEADCipher;
552
} fragment;
553
} TLSCiphertext;
554
555
556 Figure A.2 TLS Record Layer Structure

557 For block ciphers such as AES, the fragment type is GenericBlockCipher. As defined in section
558 10.4 TLS Compression, the CompressionMethod is set to NULL. Consequently,
559 TLSCompressed.length is the same as the uncompressed fragment length.
560
struct {
561
opaque IV[SecurityParameters.record_iv_length];
562
block-ciphered struct {
563
opaque content[TLSCompressed.length];
564
opaque MAC[SecurityParameters.mac_length];
565
uint8
566
padding[GenericBlockCipher.padding_length];
567
uint8 padding_length;
568
};
569 mbap ADU
} GenericBlockCipher;
570
571
572 Figure A.3 TLS Generic Block Cipher

573 The content element of the Generic Block Structure is the mbap ADU.

Modbus.org
MB-TCP-Security-v36_2021-07-30
20