MODBUS/TCP Sec urity
Protocol Specification
MODBUS
Modbus Organization, Inc.
® is a registered trademark of Schneider Electric USA, Inc., used under license by
Modbus.org
MB-TCP-Security-v21_2018-07-24
1
Table of Contents 1
Conformance Levels ................................................................................................................. 3 3
1
Normative Statements .............................................................................................................. 3 4
2
References ............................................................................................................................... 4 5
3
Glossary of Acronyms & Abbreviations .................................................................................... 5 6
4
Introduction ............................................................................................................................... 6 7
5
Protocol Overview .................................................................................................................... 7 8
6
Transport Layer Security Intr oduct ion .............................................................................. 7 9
6.1
Service Definition .................................................................................................................... 11 10
7
Protocol Specification ............................................................................................................. 11 11
8
TLS Handshake ............................................................................................................. 11 12
8.1
Cipher suite selection..................................................................................................... 15 13
8.2
mbaps Role-Based Client Authorization ........................................................................ 15 14
8.3
System Dependencies ............................................................................................................ 18 15
9
TLS Requirements ............................................................................................................. 18 16
10
TLS Version ................................................................................................................... 19 17
10.1
TLS v1.2 Cryptography .................................................................................................. 19 18
10.2
TLS Key Exchange ................................................................................................ 19 19
10.2.1
TLS Authentication ................................................................................................. 19 20
10.2.2
TLS Encryption ...................................................................................................... 20 21
10.2.3
TLS MAC................................................................................................................ 20 22
10.2.4
TLS PRF ................................................................................................................ 20 23
10.2.5
TLS Cryptography Import/Export Policy ................................................................ 20 24
10.2.6
TLS Fragmentation ........................................................................................................ 21 25
10.3
TLS Compression .......................................................................................................... 21 26
10.4
TLS Session Renegotiation ........................................................................................... 21 27
10.5
APPENDIX A: mbaps Packet Structure ............................................................................. 22 28
11
APPENDIX B: Requirements listing ................................................................................... 24 29
12
30
List of Figures 31
32
Figure 1 Modbus/TCP ADU ............................................................................................................. 6
Figure 2 TLS Communications Protocol Stack ................................................................................ 7
Figure 3 mbap PDU Encapsulated in TLS ....................................................................................... 8
Figure 4 Modbus/TCP Securit y Concept Vie w ................................................................................ 9
Figure 5 Example x.509v3 Certificate with Role Extension (2161 chars) ...................................... 10
Figure 6 TLS Full Handshake Protocol .......................................................................................... 12
Figure 7. TLS Resumption ............................................................................................................. 14
Figure 8 Role-Base Client AuthZ ................................................................................................... 16
Figure 9 Example Role Extension ................................................................................................. 16
Figure 10 mbaps Role-Based Client AuthZ ................................................................................... 17
Figure 11 TLS Transportation of mbap PDU ................................................................................. 22
Figure 12 TLS Record Layer Structure .......................................................................................... 22
Figure 13 TLS Generic Block Cipher ............................................................................................. 22
46
List of Tables 47
48
Table 1 Conformance Levels ........................................................................................................... 3
Table 2 References.......................................................................................................................... 4
Table 3 Glossary of Acronyms & Abbreviations .............................................................................. 5
Table 4 Context Specific Terminology ............................................................................................. 6
Table 5 TLS Full Handshake Protocol ........................................................................................... 12
Table 6. TLS Resumption handshake ........................................................................................... 14
Table 7. Requirements List ............................................................................................................ 24
56
2
33
34
35
36
37
38
39
40
41
42
43
44
45
49
50
51
52
53
54
55
Modbus.org
MB-TCP-Security-v21_2018-07-24
2
1 Conformance Levels 57
Latest
In a standard document, specific notations shall be used to define the
affected area of the Specification.
Compliance
An implementation that satisfies all the MUST / SHALL requirements is
MUST / SHALL requirem ents that it im plements
MUST
All requirements containing the word "MUST / SHALL" are mandatory.
the item is an absolute requirement of the implementation.
MUST NOT
All requirements containing the word "MUST NOT/ SHALL NOT" are
item is an absolute prohibition of the specification.
SHOULD
All recommendations containing the word "SHOULD", or the adjective
choosing a different course.
MAY
The word “MAY”, or the adjective "OPTIONAL", means that this item is
implementer may omit the same item.
R-n.m: Normative statement text goes here.
58
59
Table 1 Conformance Levels 60
conventions
available
up-to-now
SHALL
REQUIRED
SHALL NOT
RECOMMENDED
significance of each particular requirement. These notations (words) are
highlighted by capitalization.
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
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
The word "MUST / SHALL", or the adjective "REQUIRED", means that
mandatory.
The phrase "MUST NOT” or the phrase “SHALL NOT” mean that the
“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
OPTIONAL
61
62
63
truly optional.
One implementer may choose to include the item because a particular
marketplace requires it or because it enhances the product; another
2 Normative Statements 64
65
Normative statements in this technical specification are called out explicitly as follows: 66
67
69
where "n.m" is replaced by the requirement statement tag number which can be a hierarchical 70
number, e.g. R-1.2.3 or a simple integer, e.g. R-1. 71
72
MB-TCP-Security-v21_2018-07-24
Modbus.org
68
3
Each statement contains exactly one requirement level keyword (e.g., "MUST") and one 73
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
[802.1AR2009]
[EST]
IETF RFC 7030, Enrollment over Secure Transport, Oct 2013
[ISASEC]
ISASecure EDSA-311 Functional Security Assessment (FSA)
[MB]
Modbus Application Protocol Specification, V1.1b3, 2012-04-26,
http://modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf
[MBTCP]
Modbus Messaging on TCP/IP Implementation Guide, V1.0b, 2006-10-24,
http://modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf
[PKCS#10]
IETF RFC 2986, PKCS#10: Certificate Request Syntax Specification, v1.7, Nov
2000
[RFC2315]
IETF RFC 2315, PKCS #7: Cryptographic Message Syntax, v1.5, Mar 1998
[RFC2986]
IETF RFC 2986, PKCS#10: Certificate Request Syntax Specification, v1.7, Nov
2000
[RFC3447]
IETF RFC 3447, Public-Key Cryptography Standards (PKCS) #1: RSA
Cryptography Specifications Version 2.1, Feb 2003
[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
[RFC5272]
IETF RFC 5272, Certificate Management over CMS (CMC), Jun 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
[RFC6347]
IETF RFC 6347, Datagram Transport Layer Security Version 1.2, Jan 2012
[RFC6960]
IETF RFC 6960, x.509 Internet PKI Online Certificate Status Protocol - OCSP,
Jun 2013
[SCEP]
IETF draft SCEP v23, Simple Certificate Enrollment Protocol, draft-noursescep-23
[SYSTEMPKI]
System PKI Dependencies companion document
[TLSPARAMS]
IANA’s Transport Layer parameter type registry.
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
conformance target keyword (e.g., "Message"). Example: “The Message MUST be encoded 74
using BER”. 75
76
The scope of the tag, R-n.m, is limited to this technical specification. 77
78
The tag policy is as follows: 79
• A tag value is defined when the specification is released to the public. 80
• Once defined, the requirement statement associated to a tag MUST NOT change as 81
there is no versioning provided. 82
• If a change to a requirement statement is needed, then 83
o The requirement statement requiring change MUST be rendered obsolete and 84
moved to an obsolete tag appendix at the end of the document. 85
o The new requirement statement, with a new tag number, will replace the obsolete 86
requirement statement in the specification. 87
88
3 References 89
Table 2 References 90
IEEE 802.1AR-2009 Secure Device Identity, 2009-12-22
Modbus.org
MB-TCP-Security-v21_2018-07-24
4
91
Reference
Description
ADU
Application Data Unit
AuthN
Authentication
AuthZ
Authorization
CA
Certificate Authority
CDP
CRL Distribution Point
CRL
Certificate Revocation List
DTLS
Datagram Transport Layer Security
EST
Enrollment over Secure Transport
HMAC
Keyed-hash Message Authentication Code
IANA
Internet Assigned Numbers Authority
ICS
Industrial Control System
IEC
International Electrotechnical Commission
ISA
International Society of Automation
MAC
Message Authentication Code
mbap
Modbus Application Protocol
mbaps
Modbus Security Application Protocol
OID
Object Idenitifier standardized by the International Telecommunications Union
OCSP
Online Certificate Status Protocol
PDU
Protocol Data Unit
PKI
Public Key Infrastructure
PRF
Psuedorandom Function Family
RA
Registration Authority
SCEP
Simple Certificate Enrollment Protocol
SSL
Secure Socket Layer
TCP
Transport Control Protocol
TLS
Transport Layer Security
92
93
94
4 Glossary of Acronyms & Abbreviat ions 95
96
97
Table 3 Glossary of Acronyms & Abbreviations 98
99
100
Modbus.org
MB-TCP-Security-v21_2018-07-24
5
5 Introduction 101
Profile
(for brevity)
Port 502
System Port 802
Modbus/TCP
102
The Modbus/TCP protocol is widely deployed in Industrial Control Systems (ICS). The 103
specificat io ns f or Modbus/ TCP are fou nd a t t h e modbus.or g we b site. The M od bus/TCP 104
specificat io n defines an Application D at a U n i t ( AD U ) . T his ADU is d ef i ne d as shown: 105
106
The difference between a traditional Modbus Protocol Data Unit (PDU) and the Modbus/TCP 109
ADU is the addit ion of the Mo dbus App lica tio n Prot oc ol (mbap) header at th e fro nt of the 110
frame. 111
112
Security Principles
• Modbus/TCP Security @
port 802
• x.509v3 certificat e bas ed
identity and authentication
with TLS
• Mutual client/server TLS
authentication
• Authorization usi ng rol es
transferred via certi fic ates
• Authorization rules are
product specific
• No changes to mbap
129
The select ion of TLS as t h e secure tra ns p ort protocols is the result of analyzing representative 130
data flows f r om industr y d omains in the context of [62443-3-3], [62 4 43-4-2], and [ISASEC] 131
Functional S ecur it y requir em ents. 132
133
Table 4 Context S p ec if ic Terminology lists t he names used f or t h e mbap communication 134
profiles in d if f ere nt contexts, e.g. Communicat ion Prof ile, Modbus.org, the IANA Registry, and 135
this specif ic at io n. For reasons of brevity, the remainder of th is specific at i on wi ll use mbap and 136
mbaps to ref er to M odbus/TCP a n d Mo dbus/TCP S e c uri ty respecti ve ly. 137
138
Figure 1 Modbus/TCP ADU 108
107
In 1996 the Mo dbus /T CP pro toc ol, was re gist ere d with I ANA 113
(Internet Assi gne d Num be r Author i t y) and ass igne d t he 114
system port n umber 502. I n t h e course of th is r e g is tr ation 115
process with IANA th e Mo dbus /TC P pro toc ol cam e to be 116
called the mbap protoc o l b ec a us e of the mba p he ad e r in t h e 117
Modbus/TCP AD U . This name, the mbap pr otocol, pers is te d 118
and is stil l us e d for the port 502 reg istr ati on wit h the IANA as 119
mbap/TCP 120
121
The Modbus/TCP Secur ity protocol is a securi ty focused 122
variant of t he Mobdbus/T CP pr o tocol uti lizi n g T r ansport 123
Layer Securit y (T LS). IANA has as signed the M o db u s /TCP 124
Security pr ot oc o l th e system port number 802. Modbus.org 125
has register e d t h e nam e Mod bus Security Application 126
Protocol to t he protocol re gistered at por t 802 wit h I ANA as 127
mbap/TLS/TCP 128
Table 4 Context Specific Terminology 139
Communication
mbap/TCP Modbus/TCP Modbus Application
mbap/TLS/TCP Modbus/TCP Security Modbus Security
140
Modbus.org IANA Re g is t r y This specification
Protocol at System
Application Protocol at
Modbus.org
MB-TCP-Security-v21_2018-07-24
Mbap
Mbaps
6
6 Protocol Overview 141
142
In the tradition of Mo dbus, th e mbaps requirements are kept simple allowing vendors to 143
develop addit ion al inf rastr uc ture arou nd th e pro toc ol and allowi n g bac kwards compatibilit y wi th 144
legacy devices and fieldbuses. Mbaps extends t he origina l mba p prot oco l as de fine d in 145
[MBTCP] and [M B]. Mbaps defin es a client-s er ver protocol t ha t is a part of a c o mplete security 146
system arch it ec t ur e . As ill ustr at ed in Fi gure 3
encapsulate d by TLS. TLS provides a s ec urity focused protoc ol a l ternative to mbap b y adding 148
confidential transport of th e da ta , data inte gr i ty, anti-r epl ay prot ect ion , end poi nt authentication 149
via certificates, and authorization via information embedded in t he c er tificate such as user and 150
device roles. 151
152
The protoco ls mbap and m ba ps are s imilar to http and its secure variant https r es p ec t i ve ly. In 153
mbaps, the mba p pro toco l is tr a nsported via T LS. TLS provides an authentication capability 154
via x.509v3 certificates. The mbaps cl ients and servers mus t b e pr o vis i o ne d wi t h t he these 155
certificates t o par ticipate i n t h e TLS Authe nt ica t io n function. 156
157
An importa nt d if ference between mbap and m ba ps is that mbaps provides the cap ab i l ity of the 158
server in voking an au th or i za t io n f u nc t i on w hose rules ar e dr i ven by the ve ndor or custom er , 159
utilizing role data that is pr o vided v ia an extension field in the x.509v3 certificate. The 160
extension is r e gistered wi t h Mo db us . org’s IANA O I D. TLS pro vides for th e use of pre-shared 161
keys to establ ish a sec ure con nec tio n, but th e us e is not cons ider ed f or this spe cific at ion as it 162
does not allow for the tr asf er of role inf orm at ion to provi de an a uthor iza tio n fun c tion. 163
164
6.1 Transport Layer Security Introduction 165
The mbaps/TLS/TCP pr ofi le uses the s ecur e TL S trans por t prot oco l def ine d in IET F RF C 166
5246. [RFC524 6] def ines T LS v1. 2 wh ich is the m os t c urrent TLS ver s ion at t he pu blis hin g of 167
this document and provides countermeasures and mitigations for known vulnerabilities i n 168
earlier versi ons. Should newer T L S v er sions be av a il ab le, it is recommend ed t o a l lo w t heir use 169
in the clien t /s erver mbaps d e vic e. 170
171
TLS is compose d of a set of pr otoc ols as illus tr ate d in F igur e 2 TLS C om m unicatio ns Pr otoc ol 172
Stack. T he main protoc o l i n t h e set is the T L S R ec ord Protoco l. The remaini ng pr o tocols are 173
sub-protocols which are carried by the TLS Record Protoco l. T hes e are manage d by a TLS 174
middleware. 175
mbap PDU Encapsulated in TLS, th e mbap PDU is 147
Figure 2 TLS Communications Protocol Stack 177
178
The mbap PD U wh ic h is unchanged in t h e mbaps prof i le is encapsul at ed in a TLS Applic at i on 179
Protocol m es sage as il lus trated in Figure 3 mbap PDU Encaps u late d in TL S. 180
181
Modbus.org
MB-TCP-Security-v21_2018-07-24
7
176
Modbus/TCP
Security
• Mutual client/server
TLS Authentication.
Certificate based
•
Identity and
Authentication with
TLS.
Certificate based
•
Authorization using role
information transferred
via certificate
extensions.
Authorization is product
•
specific and invoked by
mbap function code
handler.
Authorization roles to
•
rights rules are product
specific and configured
in the Authorization
function.
Figure 3 mbap PDU Encapsulated in TLS 183
182
The TLS Han dshake Proto c ol shown in Figure 4 184
Modbus/TCP S ecur it y Conc ept V iew: 185
• Negotiates cryptography for s ec ure channe l including 186
algorithms , keys, etc. b etween end p oi nts. 187
• Provides mutual c li en t/server au th entication based on 188
x.509v3 cer t if ica tes 189
• Extracts the client role OID from the c ertificate 190
• Establishes the T L S s es s i on . 191
192
After the T LS s ession is e stablished normal m odbus request 193
and response sequences ar e transmitted in the sec u r ed T LS 194
Application Protocol channel. During the proces i ng of the 195
request, the mbaps prot ocol h andler invokes a vend or 196
specific au th or i za t io n f u nc t io n. This author i za t io n f u n c ti on 197
evaluates a roles-to-rights algorithm usin g i np uts from the 198
mbap PDU an d t h e r o le extracted f rom the x.5 09 cl i e nt 199
certificate of th e connection. T h e a lg or i thm determines if the 200
PDU can b e processed based on r ol e of t he peer. If the 201
authorizati on f unction dete r mines that th e mbap PDU co de 202
cannot be pr oc es sed, the mbap handler r eturns a 01 – Ilegal 203
Function modbus exc e pt i o n code. This authorization process 204
occurs on ever y requ est , ens urin g com pl ete validation of the 205
request stream. 206
207
Modbus.org
MB-TCP-Security-v21_2018-07-24
8
208
Figure 4 Modbus/TCP Security Concept View
209
MB-TCP-Security-v21_2018-07-24
Modbus.org
9
Certificate:
Data:
df:bf:6a:b7
Figure 5 Example x.509v3 Certificate with Role Extension (2161 chars)
Example x.509v3
Certificate with Role
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:
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:
4d:0a:78:96:c0:9e:1f:f1:1d:e7:e8:24:be:06:a1:
b8:6a:67:d3:7f:1c:d4:cb:c3:85:5a:f8:a7:ef:d1:
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:
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:
fd:b1:f3:6f:c9:fa:ac:aa:89:aa:f9:59:ca:bf:fe:
7a:12:cf:88:20:5b:5e:8b:b5:b1:58:04:41:19:2c:
26:91:0d:ce:86:38:93:32:a0:ab:57:01:38:5a:41:
36:77:ae:2b:89:28:8e:22:48:84:b6:18:b9:31:aa:
52:c3:72:3a:19:41:65:21:87:32:4b:c0:53:3e:aa:
36:dd:d6:40:09:55:e3:65:2c:f9:d4:61:24:6d:60:
64:87
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:
Encoded as a
Certificate
Extension
• Example Rol e is Operator
• The OID for the Role is defined in
the Modbus. org Transpar ent
Factory Private MIB whose PEN
(Private Enterprise Number) is
50316.
212
MB-TCP-Security-v21_2018-07-24
210
211
Modbus.org
10
The development of mbaps and its deployment in a device were guided by a set of princ i p les 213
including: 214
• R-01: The TLS Protocol v1.2 as defined in [RFC5246] or newer MUST be used as the 215
secure transport protocol for an mbaps Device. 216
• R-02: Secure communications to an mbaps Device MUST use Mutual client/server 217
authentication as provided by the TLS Handshake Protocol. 218
• R-03: x.509v3 Certificates as defined in [RFC5280] MUST be used as mbaps device 219
credentials for Identity/Authentication by the TLS protocol. 220
• R-04: If the Authorization function is enforced it MUST use the role transferred via 221
x.509v3 certificate extensions. 222
• R-05: There MUST be no c ha ng e to t he mbap protocol as a consequence of it being 223
encapsulated by the secure tra ns p or t . 224
225
226
7 Service Definition 227
228
Standard function codes used on Modbus Application layer protocol are described in details in the 229
[MB] specification. There is no modification to the standard function codes in this specification. 230
231
8 Protocol Specification 232
233
The communication of an mbap PDU is secured using the Transport Layer Secur it y protoco l, 234
TLS, defined in [RFC5246]. Figure 3 mbap PDU Encapsulated in TLS illustrates how an mbap 235
PDU is transmitted via the TLS Application Protocol. 236
237
TLS provides Transport Layer Security between two end points. To do this, the TLS end points 238
execute the TLS Handshake protocol to negotiate security parameters and to create a TLS 239
session. 240
241
8.1 TLS Handshake 242
243
For two mbaps end devices to communicate securely using TLS, a security context between the 244
end points of the TLS connection must be established. The TLS Handshake protocol establishes 245
the secure context, i.e. the TLS session. The TLS session has a session identifier and the 246
security context is described by a set of security parameters as defined in [RFC5246] section A.6. 247
248
Mutual Authentication requires that each end point will send its domain certificate chain to the 249
remote end point. Upon receipt of a certificate chain from the remote peer, the TLS end point will 250
verify the each certificate signature using the next CA certificate in the chain until it can verify the 251
root of the chain. 252
253
The TLS Full Handshake Protocol, which is defined in [RFC5246] section 7.3, is illustrated in 254
Figure 6 TLS Full Handshake Protocol. 255
256
Modbus.org
MB-TCP-Security-v21_2018-07-24
11
257
Message
Description
1:ClientHello
The TlsClient sends a ClientHello message to the TlsServer to
preference.
2:ServerHello
TlsServer sends a ServerHello message in response to
cryptographic algorithms and returns a new sessionID.
3:ServerCertificate
The TlsServer sends its certificate chain as the payload of a
the role of the server. This is not used by the client.
4:VerifyServerCertSig
When peer received certificate of remote peer it will check it by
• check the revocation status of each certificate in the chain
Figure 6 TLS Full Handshake Protocol
258
Table 5 TLS Full Handshake Protocol 259
begin negotiation process. The TlsClient offers a cipher suite list in
the message. The cipher suite list is ordered by the the client’s
ClientHello. The message identifies an acceptable set of
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 also contains
• verifying each certificate’s signature in the chain using
public key of the issuer CA
• validate the certificate path to a trusted root certificate
MB-TCP-Security-v21_2018-07-24
Modbus.org
12
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
application level request.
9:VerifyClientCertSig
When peer received certificate of remote peer it will check it by
• 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
will be sent using newly negotiated cipher spec and keys.
12:Finished
The TlsClient sends a Finished message to the TlsServer. This
algorithms, keys, and secrets.
13:ChangeCipherSpec
The TlsServer sends a ChangeCipherSpec message to the
will be sent using newly negotiated cipher spec and keys.
14:Finished
The TlsServer sends a Finished message to the TlsClient. This
and secrets.
15+n:ApplData()
n ::= { 1 .. m}
15+n+1:ApplData()
n ::= { 1 .. m}
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
• verifying each certificate’s signature in the chain using
public key of the issuer CA
• validate the certificate path to a trusted root certificate
TlsServer to indicate that subsequent messages sent by the Client
message is the first message protected with the just negotiated
TlsClient to indicate that subsequent messages sent by the Server
message is protected with the just negotiated algorithms, keys,
260
TLS [RFC5246] also provides for session resumption. The server side partner caches the last 261
security state known, and pairs it the session ID used in the client and server hello. If the client 262
caches the security context and sessionId it can present this sessionID to the server on the next 263
ClientHello. If this sessionID matches with a cached sessionID on the server, the server will 264
immediately change the cipher spec as shown in Figure 7. TLS Resumption and the connection 265
will resume. This reduces the TLS negotiation time to 1 application round trip time, and removes 266
the public/private key cryptographic function needed to authorize a new peer. This resumption will 267
require the server to cache the role associated with the connection’s client certificate and 268
associate it with the sessionID. 269
270
If the sessionID presented by the clientHello does not match a known server session, a new 271
sessionID is returned in the serverHello message and a full TLS handshake is performed as in 272
Figure 6 TLS Full Handshake Protocol. 273
274
Modbus.org
MB-TCP-Security-v21_2018-07-24
13
Figure 7. TLS Resumption 276
Message
Description
1:ClientHello
The TlsClient sends a ClientHello message to the TlsServer to
the message. It also offers a cached non-zero sessionID
2:ServerHello
TlsServer sends a ServerHello message in response to
record
2:ChangeCipherSpec
The TlsServer sends a ChangeCipherSpec message to the
will be sent using newly negotiated cipher spec and keys.
2:Finished
The TlsServer sends a Finished message to the TlsClient. This
algorithms, keys, and secrets.
3:ChangeCipherSpec
The TlsClient sends a ChangeCipherSpec message to the
will be sent using newly negotiated cipher spec and keys.
Table 6. TLS Resumption handshake 277
begin negotiation process. The TlsClient offers a cipher s uit e lis t in
ClientHello. The message identifies an acceptable cipher suite,
returns the same sessionID, and includes a ChangeCipherSpec
TlsClient to indicate that subsequent messages sent by the Server
message is the first message protected with the just negotiated
TlsServer to indicate that subsequent messages sent by the Client
MB-TCP-Security-v21_2018-07-24
275
Modbus.org
14
3:Finished
The TlsClient sends a Finished message to the TlsServer. This
message is protected with the just negotiated algorithms, keys,
and secrets.
4[1..n]:ApplData()
n ::= { 1 .. m}
5[1..n]:ApplData()
n ::= { 1 .. m}
278
R-06: mbaps end devices MUST provide mutual authentication when executing the TLS 279
Handshake Protocol to create the TLS session. 280
R-07 The TlsServer MUST send the CertificateRequest extension as part of its ServerHello 281
message. 282
R-08 The TlsClient MUST send a ClientCertificate message upon receiving a request containing 283
the Client Certificate Request. 284
R-09 If the TlsServer does not send a CertificateRequest message, then the TlsClient MUST 285
send a ‘fatal alert’ message to the TlsServer and terminate the connection. 286
R-10 If the TlsClient does not send a ClientCertificate message, then the TlsServer MUST send a 287
‘fatal alert’ message to TlsClient and terminate the connection. 288
R-11 Per RFC5246-7.2.2, the TLS connection MUST NOT be resumed after a ‘fatal alert’. 289
290
8.2 Cipher suite selectio n 291
292
The security strength of the resulting TLS session is dependent on the cipher suite negotiated 293
between the TLS end points. Cipher suites designate what cryptography will be used by the TLS 294
session to provide a certain level of security. 295
296
For example, the cipher suite, TLS_RSA_WITH_AES_128_CBC_SHA256, has an identifier of 297
{0x00, 0x3C} at the IANA Registry. Only cipher suites registered with IANA and not known to 298
have current weaknesses should be used in mbaps. 299
300
This example cipher suite indicates that: 301
• RSA will be used for key exchange, 302
• AES 128 CBC will be used for encryption, and 303
• SHA256 will be used for message integrity. 304
305
R-12: Cipher suites used with TLS for mbaps MUST be listed at the IANA Registry found @ 306
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
308
R-13: The cipher allowed for TLS with mbaps MUST accommodate the use of x.509v3 309
certificates.
311
R-14: mbaps Devices MUST provide at minimum the following TLS v1.2 cipher suites: 312
• TLS_RSA_WITH_AES_128_CBC_SHA256, {0x00, 0x3C} 313
• TLS_RSA_WITH_NULL_SHA256, {0x00, 0x3B} 314
315
R-15: The default cipher suite for both mbaps client and server Devices SHOULD be 316
TLS_RSA_WITH_AES_128_CBC_SHA256, {0x00, 0x3C} 317
318
R-66: Client devices with bulk transport encryption and NULL bulk encryption SHOULD always 319
place NULL bulk transport cipher suites last in cipher suite priority 320
321
322
310
8.3 mbaps Role-Based Client Authorization 323
324
. 307
MB-TCP-Security-v21_2018-07-24
Modbus.org
15
...
Figure 8 Role-Base Client AuthZ
mbapsClient
mbapsServer
mbaps server protocol handler
AuthZ Algorithm
Roles-to-Rights Rules Database
mbaps client protocol handler
x.509v3 Client Domain Certificate
Figure 9 Example Role Extension
Role-based
Authorization
function.
• Roles are encoded in
x.509v3 Certificate
Extension.
• Authorization func tion i s
vendor specific.
• Authorization roles t o
rights rules are vendor
specific and configure d
into the Authorizati on
The mbaps protocol provides the capability to perform role-325
based client authorization (AuthZ). The client role data is 326
transported in an extension of its x.509v3 domain certificate. 327
An example of a certificate with a Role extens ion is sh o wn in 328
Figure 5 Example x.509 v3 Cer tif icat e wit h Role Extension 329
(2161 chars). 330
331
332
333
Role-Based Client Authorization for mbaps is illustrated in 334
Figure 8 Role-Base Client AuthZ. 335
336
337
338
339
Once a TLS Session is established between the two TLS end points, the execution of role-based 340
client AuthZ is a two-step process. 341
342
During the first step, the mbaps server obtains the x.509v3 client domain certificate. This step 343
occurs when the mbaps server receives message 8 as shown in Figure 6 TLS Full Handshake 344
Protocol. The role is extracted from the x.509v3 certificate and cached. If a session is resumed, 345
this role must be associated with the resumed session. 346
347
349
350
351
In the example Role extension, shown in Figure 9 Example Role Extension, the Role value is 352
‘Operator’. 353
354
The second step of the mbaps role-based client AuthZ capability involves using the extracted 355
client Role and the Modbus request. Both fields are input to the mbaps AuthZ Algorithm. The 356
AuthZ Algorithm determines whether the client is AUTHORIZED or NOT_AUTHORIZED to 357
perform the indicated function on the indicated resource that was specified in the Modbus 358
Function Code received by the mbaps server using the provisioned Roles-to-Rights Rules 359
Database. If the request is NOT_AUTHORIZED, Modbus exception code 01 – Illegal function 360
code will be returned. If the request is AUTHORIZED, it will be processed as normal by the mbap 361
server. 362
363
Role:
1.3.6.1.4.1.50316.802.1: Operator
Modbus.org
MB-TCP-Security-v21_2018-07-24
16
348
The Authorization Function and Roles-to-Rights Rules Database may exist on the server device 364
or may be remote requiring a separate protocol to determine the authorization status of the 365
request. This is outside the scope of this document. 366
367
The two-step process is shown in Figure 10 mbaps Role-Based Client AuthZ. 368
369
Figure 10 mbaps Role-Based Client AuthZ 371
R-16: A mbaps Server Device SHOULD provide the role-based client AuthZ as described in this 372
section. 373
374
R-17: If a mbaps Server Device provides role-based client AuthZ, it MUST c om pl y with the 375
requirements identified in this section. 376
377
R-18: To provide mbaps role-based client authorization capability the following elements are 378
REQUIRED: 379
x.509v3 client domain certificate ‘Role’ extension, 380
mbaps server AuthZ algorithm, 381
Modbus.org
MB-TCP-Security-v21_2018-07-24
17
370
mbaps server Roles-to-Rights Rules Database. 382
383
R-19: The mbaps client device MUST be provisioned with its x.509v3 domain certificate. 384
385
R-20: The x.509v3 client domain certificate MUST include the Role extension. 386
387
R-21: The Role in the X.509v3 certificate MUST use the Modbus.org PEM OID 388
1.3.6.1.4.1.50316.802.1 389
390
R-22: The Role in the x.509v3 certificate MUST use ASN1:UTF8String encoding 391
392
R-65: There MUST only be one role defined per certificate. The entire string will be treated as one 393
role. 394
395
R-23: If no Role is specified in the X.509v3 certificate, the mbaps server MUST provide a NULL 396
role to the AuthZ algorithm. 397
398
R-24: The mbaps AuthZ Algorithm MUST be defined and provided by the device vendor. 399
400
R-25: The Roles-to-Rights Rules Data base design, bo th s yntax and s em antics, MUST be def ined 401
by the device vendor. 402
403
R-26: The Roles-to-Rights Rules Database for a particular application MUST be configured 404
according to the device vendor’s design, and provisioned in the mbaps Server by the end user. 405
406
R-27: The Roles-to-Rights Rules Database for a partic ular application MUST be configurable b y 407
the end user. 408
409
R-28: The Roles-to-Rights Rules Database for a particular application MUST NOT have hardcoded 410
default roles that are unchangeable. 411
412
R-29: The Role values use d in th e x .50 9v 3 c lient domain certificates MUST be consistent with t he 413
device vendor’s design of the Roles-to-Rights Rules Database. 414
415
R-30: The mbaps server MUST extract the client Role from the received x.509v3 client domain 416
certificate. 417
418
R-31: If the M B A P pro tocol handl er f or authorizat i on r ejec ts a request it MUST use the 419
exception c o de 0 1 – Illeg a l f unc t i on c o de . 420
421
9 System Dependencies 422
423
To participate in a solution architecture, mbaps devices are dependent on the certificate 424
management services of a Public Key Infrastructure (PKI). The details are not materially 425
important to the implementation of the mbaps server or client behaviour. 426
427
Although there are many variations for types and configurations of PKI systems, the [SYSTEM-428
PKI] companion documents discusses a typical local PKI system that is appropriate for use with 429
collaborations of mbaps devices. 430
431
Furthermore the [SYSTEM-PKI] companion document includes recommendations that mbaps 432
devices may need to place on the local PKI system for their successful deployment and 433
operation. 434
10 TLS Requirements 435
436
Modbus.org
MB-TCP-Security-v21_2018-07-24
18
10.1 TLS Version 437
438
R-32: mbaps devices MUST provide TLS v1.2 or better. 439
440
R-33: mbaps Devices MUST conform to the requirements of [RFC5246]. 441
442
R-34: mbaps devices MUST NOT negotiate down to TLS v1.1, TLS v1.0, or SSL V3.0. 443
444
R-35: mbaps devices MUST NOT negotiate the use SSL v2.0 and SSL v1.0 in conformance with 445
[RFC6176]. 446
447
10.2 TLS v1.2 Cryptography 448
449
R-36: mbaps Devices SHOULD provide a counter mode cipher suite. 450
451
Counter mode cipher suites include 452
TLS_RSA_WITH_AES_128_GCM_SHA256, {0x00, 0x9C} 453
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, {0xC0, 0x2B} 454
455
R-37: mbaps Devices MUST NOT negotiate the cipher suite, TLS_NULL_WITH_NULL_NULL 456
457
R-38: Any cipher suite used by mbaps Devices and negotiated in a TLS Handshake Protocol 458
exchange MUST be listed at IANA’s TLS Cipher Suite Registry in the [TLS-PARAMS]. 459
460
10.2.1 TLS Key Exchange 461 462
R-39: mbaps Devices MUST provide TLS Client-Server key exchange based-on RSA technology 463
as specified by the mandatory cipher suite and described in [R FC 52 46]. 464
465
R-40 mbaps Devices SHOULD provide TLS Client-Server key exchange based on ECC 466
technology. 467
468
R-62 mbaps Devices using ECC technology MUST support at least P-256 NIST curve. 469
470
R-63 mbaps Devices using ECC technology MUST support at least the minimum cipher suite of 471
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 472
473
R-61 mbaps Devices using ECC technology MUST specify the curves used in their Client Hello 474
using the Supported Elliptic Curves extension in [RFC4492] 475
476
10.2.2 TLS Authentication 477 Authentication against trust anchors may be done using self signed device certificates. It is 478
recommended to use certificates signed by a Certificate Authority for authentication. 479
480
Session resumption using session tickets or resuming session IDs should be supported to reduce 481
the handshake time of a connection.Session resumption using session IDs is preferred. In 482
session resumption it is the responsibility of the server to cache and maintain session information 483
for later use. It is more well supported and places less demand on clients to manage session 484
information with their peer. 485
486
Session tickets place the burden of session information on the client. This information is 487
encrypted by the server and transmitted to the client. On new session, this information is 488
transmitted back to the server and used to re-establish a connection. Less server resources are 489
Modbus.org
MB-TCP-Security-v21_2018-07-24
19
needed to accomplish this but network resources are wasted and due to the transmission of 490
information it takes longer to re-establish a connection. 491
492
R-41: mbaps Devices MUST support the TLS Client-Server Mutual Authentication Handshake. 493
494
R-42: mbaps Device SHOULD support the TLS Resumed Session Handshake on Client and 495
Server. 496
497
R-43: mbaps Device MAY support the TLS Session Ticket resumption on Client and Server 498
499
R-44: mbaps Servers MUST reject a TLS Handshake where the Client has not responded to a 500
Client Certificate request with certificate. 501
502
R-45: mbaps Devices SHOULD provide x.509v3 Certificates signed by a Certificate Authority. 503
504
R-46: mbaps Devices MUST send the entire certificate chain down to the root CA when sending 505
their certificate 506
507
R-47: x.509v3 Certificates provided by mbaps Devices MUST conform to the requirements of 508
[RFC5280]. 509
510
10.2.3 TLS Encryption 511 512
R-48: If an mbaps Device is to be used in a scenario where encryption is required, then a cipher 513
suite with the required encryption indicator MUST be chosen from the list at IANA’s TLS Cipher 514
Suite Registry in the [TLS-PARAMS]. 515
516
R-49: If an mbaps Device is to be used in a scenario where encryption is not required, then a 517
cipher suite with a NULL bulk encryption indicator MUST be chosen from the list at IANA’s TLS 518
Cipher Suite Registry in the [TLS-PARAMS]. 519
10.2.4 TLS MAC 520 521
R-50: mbaps Devices MUST NOT use the HMAC-MD5 hash algorithm. 522
523
R-51: mbaps Devices MUST NOT use the HMAC-SHA-1 hash algorithm. 524
525
R-52: mbaps Devices MUST provide the HMAC-SHA-256 hash algorithm. 526
527
R-53: mbaps Device MUST NOT use a NULL HMAC hash algorithm 528
529
10.2.5 TLS PRF 530 531
R-54: mbaps Devices MUST NOT provide the HMAC-SHA-1 hash algorithm for use in the PRF 532
function to calculate the key block as defined in [RFC5246] sections 5, 6.3 and 8.1. 533
534
R-55: mbaps Devices MUST provide the HMAC-SHA-256 hash algorithm for use in the PRF 535
function to calculate the key block as defined in [RFC5246] sections 5, 6.3 and 8.1. 536
537
10.2.6 TLS Cryptography Import/Export Pol icy 538 539
R-56: As early as possible in their development cycle, mbaps devices MUST determine that they 540
com p ly wit h the import/export conformance policies of their respective countries for the 541
cryptography they provide. 542
Modbus.org
MB-TCP-Security-v21_2018-07-24
20
10.3 TLS Fragmentation 543
544
R-57: mbaps devices MUST provide the Maximum Fragment Length Negotiation Extension as 545
defined in [RFC6066]. 546
547
R-58: mbaps devices MUST provide the ability to negotiate a Maximum Fragment Length of 2
(512) bytes as defined in [RFC6066]. 549
550
10.4 TLS Compression 551
552
R-59: mbaps devices MUST set the TLS CompressionMethod field of the ClientHello message to 553
the value of NULL. 554
555
10.5 TLS Session Renegotiation 556
557
R-60: mbaps devices MUST provide the TLS Renegotiation Indication Extension defined in 558
[RFC5746] to provide the secure renegotiation of TLS sessions. 559
560
9
548
Modbus.org
MB-TCP-Security-v21_2018-07-24
21
IP
TCP
Port 802
TLS Record Protocol
TLS Application Protocol
TLS Content Type = 23
MBAP PDU
Figure 11 TLS Transportation of mbap PDU
struct {
Figure 12 TLS Record Layer Structure
struct {
Figure 13 TLS Generic Block Cipher
mbap PDU
11 APPENDIX A: mbaps Packet Structure 561
562
Figure 11 TLS Transportation of mbap PDU shows the layering of the TLS protocol on TCP. The 563
mbap PDU encapsulated in a TLS Application Protocol Packet. The mbaps protocol which is the 564
mbap protocol transported by TLS is found at TCP port 802. 565
566
The structure of the TLS Record Layer used by mbaps is defined in [RFC5246] sec A-1, where: 567
573
574
575
576
577
578
579
580
581
582
583
584
585
586
For block ciphers such as AES, the fragment type is GenericBlockCipher. As defined in section 587
10.4 TLS Compression, the CompressionMethod is set to NULL. Consequently, 588
TLSCompressed.length is the same as the uncompressed fragment length. 589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
The content element of the Generic Block Structure is the mbap PDU. 604
• ContentType type = 23, Application Protocol 568
• ProtocolVersion version = {3,3} for TLS v1.2 569
• uint16 length = number of bytes of the following TLSCiphertext.fragment, 570
MUST NOT exceed 16384 + 2048 (18432) 571
• fragment = The encrypted form of TLSCompressed.Fragment, with the MAC 572
ContentType type;
ProtocolVersion version;
uint16 length;
select (SecurityParameters.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
case aead: GenericAEADCipher;
} fragment;
} TLSCiphertext;
opaque IV[SecurityParameters.record_iv_length];
block-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[Securit yPara meters.mac_length];
uint8
padding[GenericBlockCipher.padding_length];
uint8 padding_length;
};
} GenericBlockCipher;
Modbus.org
MB-TCP-Security-v21_2018-07-24
22
605
Modbus.org
MB-TCP-Security-v21_2018-07-24
23
12 APPENDIX B: Requirem ents listin g 606
Section
Requirement
6.1
R-01: The TLS Protocol v1.2 as defined in [RFC5246] or newer MUST be used as
6.1
R-02: Secure communications to an mbaps Device MUST use Mutual client/server
6.1
R-03: x.509v3 Certificates as defined in [RFC5280] MUST be used as mbaps
6.1
R-04: If the Authorization function is enforced it MUST use the role transferred via
6.1
R-05: There MUST be no change to the mbap protocol as a consequence of it
being encapsulated by the secure transport
8.1
R-06: mbaps end devices MUST provide mutual authentication when executing the
8.1
R-07 The TlsServer MUST send the CertificateRequest extension as part of its
8.1
R-08 The TlsClient MUST send a ClientCertificate message upon receiving a
8.1
R-09 If the TlsServer does not send a CertificateRequest message, then the
8.1
R-10 If the TlsClient does not send a ClientCertificate message, then the TlsServer
8.1
R-11 Per RFC5246-7.2.2, the TLS connection MUST NOT be resumed after a ‘fatal
8.2
R-12: Cipher suites used with TLS for mbaps MUST be listed at the IANA Registry
8.2
R-13: The cipher allowed for TLS with mbaps MUST accommodate the use of
8.2
R-14: mbaps Devices MUST provide at minimum the following TLS v1.2 cipher
8.2
R-15: The default cipher suite for both mbaps client and server Devices SHOULD
8.2
R-66: Client devices with bulk transport encryption and NULL bulk encryption
8.3
R-16: A mbaps Server Device SHOULD provide the role-based client AuthZ as
described in this section.
607
Table 7. Requirements List 608
the secure transport protocol to an mbaps Device.
authentication as provided by the TLS Handshake Protocol.
device credentials for Identity/Authentication by the TLS protocol.
x.509v3 certificate extensions.
TLS Handshake Protocol to create the TLS session.
ServerHello message.
request containing the Client Certificate Request.
TlsClient MUST send a ‘fatal alert’ message to the TlsServer and terminate the
connection.
MUST send a ‘fatal alert’ message to TlsClient and terminate the connection.
alert’.
found @ http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml .
x.509v3 certificates.
suites:
• TLS_RSA_WITH_AES_128_CBC_SHA256, {0x00, 0x3C}
• TLS_RSA_WITH_NULL_SHA256, {0x00, 0x3B}
be TLS_RSA_WITH_AES_128_CBC_SHA256, {0x00, 0x3C}
SHOULD always place NULL bulk transport cipher suites last in cipher suite priority
Modbus.org
MB-TCP-Security-v21_2018-07-24
24
8.3
R-17: If a mbaps Server Device provides role-based client AuthZ, it MUST comply
with the requirements identified in this section.
8.3
R-18: To provide mbaps role-based client authorization capability the following
8.3
R-19: The mbaps client device MUST be provisioned with its x.509v3 domain
8.3
R-20: The x.509v3 client domain certificate MUST include the Role extension.
8.3
R-21: The Role in the X.509v3 certificate MUST use the Modbus.org PEM OID
8.3
R-22: The Role in the x.509v3 certificate MUST use ASN1:UTF8String encoding
8.3
R-65: There MUST only be one role defined per certificate. The entire string will be
8.3
8.3
R-24: The mbaps AuthZ Algorithm MUST be defined and provided by the device
8.3
R-25: The Roles-to-Rights Rules Database design, both syntax and semantics,
8.3
R-26: The Roles-to-Rights Rules Database for a particular application MUST be
8.3
R-27: The Roles-to-Rights Rules Database for a particular application MUST be
8.3
R-28: The Roles-to-Ri ghts Rules Database for a particular app lication MUST NOT
8.3
R-29: The Role values used in the x.509v3 client domain certificates MUST be
8.3
R-30: The mbaps server MUST extract the client Role from the received x.509v3
8.3
R-31: If t he M B A P protocol han dl er f or authoriza t i on r ej ects a reques t it MUST
10.1
R-32: mbaps devices MUST provide TLS v1.2 or better.
10.1
R-33: mbaps Devices MUST conform to the requirements of [RFC5246].
10.1
R-34: mbaps devices MUST NOT negotiate down to TLS v1.1, TLS v1.0, or SSL
V3.0.
elements are REQUIRED:
x.509v3 client domain certificate ‘Role’ extension,
mbaps server AuthZ algorithm,
mbaps server Roles-to-Rights Rules Database.
certificate.
1.3.6.1.4.1.50316.802.1
treated as one role.
R-23: If no Role is specified in the X.509v3 certificate, the mbaps server MUST provide a
NULL role to the AuthZ algorithm.
vendor.
MUST be defined by the device vendor.
configured according to t he device vendor’s design, and pro visioned in the mbaps
Server by the end user.
configurable by the end user.
have hardcoded default roles that are unchangeable.
consistent with the device vendor’s design of the Roles-to-Rights Rules Database.
client domain certificate.
use the exc ep ti o n c o d e 01 – Illegal function code.
Modbus.org
MB-TCP-Security-v21_2018-07-24
25
10.1
R-35: mbaps devices MUST NOT negotiate the use SSL v2.0 and SSL v1.0 in
conformance with [RFC6176].
10.2
R-36: mbaps Devices SHOULD provide a counter mode cipher suite.
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, {0xC0, 0x2B}
10.2
R-37: mbaps Devices MUST NOT negotiate the cipher suite,
10.2
R-38: Any cipher suite used by mbaps Devices and negotiated in a TLS Handshake
10.2.1
R-39: mbaps Devices MUST provide TLS Client-Server key exchange based-on
10.2.1
R-40 mbaps Devices SHOULD provide TLS Client-Server key exchange based on
10.2.1
R-61 mbaps Devices using ECC technology MUST support at least P-256 NIST
10.2.1
R-62 mbaps Devices using ECC technology MUST support at least the minimum
10.2.1
R-63 mbaps Devices using ECC technology MUST specify the curves used in their
10.2.1
R-64 mbaps Devices using ECC technology MUST specify the point format used in
their Client Hello using the Supported Point Format extension in [RFC4492]
10.2.2
R-41: mbaps Devices MUST support the TLS Client-Server Mutual Authentication
10.2.2
R-42: mbaps Device SHOULD support the TLS Resumed Session Handshake on
10.2.2
R-43: mbaps Device MAY support the TLS Session Ticket resumption on Client
10.2.2
R-44: mbaps Servers MUST reject a TLS Handshake where the Client has not
10.2.2
R-45: mbaps Devices SHOULD provide x.509v3 Certificates signed by a Certificate
10.2.2
R-46: mbaps Devices MUST send the entire certificate chain down to the root CA
10.2.2
R-47: x.509v3 Certificates provided by mbaps Devices MUST conform to the
10.2.3
R-48: If an mbaps Device is to be used in a scenario where encryption is required,
list at IANA’s TLS Cipher Suite Registry in the [TLS-PARAMS].
Counter mode cipher suites include
TLS_RSA_WITH_AES_128_GCM_SHA256, {0x00, 0x9C}
TLS_NULL_WITH_NULL_NULL.
Protocol exchange MUST be listed at IANA’s TLS Cipher Suite Registry in the
[TLS-PARAMS].
RSA technology as specified by the mandatory cipher suite and described in [RFC
5246].
ECC technology.
curve.
cipher suite of TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
Client Hello using the Supported Elliptic Curves extension in [RFC 4 492]
Handshake.
Client and Server.
and Server
responded to a Client Certificate request with certificate.
Authority.
when sending their certificate
requirements of [RFC5280].
then a cipher suite with the required encryption indicator MUST be chosen from the
Modbus.org
MB-TCP-Security-v21_2018-07-24
26
10.2.3
R-49: If an mbaps Device is to be used in a scenario where encryption is not
required, then a cipher suite with a NULL bulk encryption indicator MUST be
10.2.4
R-50: mbaps Devices MUST NOT use the HMAC-MD5 hash algorithm.
10.2.4
R-51: mbaps Devices MUST NOT use the HMAC-SHA-1 hash algorithm.
10.2.4
R-52: mbaps Devices MUST provide the HMAC-SHA-256 hash algorithm.
10.2.4
R-53: mbaps Device MUST NOT use a NULL HMAC hash algorithm
10.2.5
R-54: mbaps Devices MUST NOT provide the HMAC-SHA-1 hash algorithm for use
10.2.5
R-55: mbaps Devices MUST provide the HMAC-SHA-256 hash algorithm for use in
10.2.6
R-56: As early as possible in their development cycle, mbaps devices MUST
10.3
R-57: mbaps devices MUST provide the Maximum Fragment Length Negotiation
10.3
R-58: mbaps devices MUST provide the ability to negotiate a Maximum Fragment
10.4
R-59: mbaps devices MUST set the TLS CompressionMethod field of the
10.5
R-60: mbaps devices MUST provide the TLS Renegotiation Indication Extension
chosen from the list at IANA’s TLS Cipher Suite Registry in the [TLS-PARAMS].
in the PRF function to calculate the key block as defined in [RFC5246] sections 5,
6.3 and 8.1.
the PRF function to calculate the key block as defined in [RFC5246] sections 5, 6.3
and 8.1.
determine that they comply with the import/export conformance policies of their
respective countries for the cryptography they provide.
Extension as defined in [RFC6066].
Length of 29 (512) bytes as defined in [RFC6066].
ClientHello message to the value of NULL.
defined in [RFC5746] to provide the secure renegotiation of TLS sessions.
609
Modbus.org
MB-TCP-Security-v21_2018-07-24
27
Loading...