Table 11describes security related ConformanceUnits. All of these ConformanceUnitsapply equally to both Clientsand Servers, where a Clientuses the related security unit and a Serversupports the use of it. These items are defined in detail in OPC 10000-6. It is recommended that a Serverand Clientsupport as many of these options as possible in order to achieve increased levels of interoperability. It is the task of an administrator to determine which of these ConformanceUnitsare exposed in a given deployed Serveror Clientapplication.

Table 11– Security

Category

Title

Description

Security

Security User Name Password

The Serversupports User Name/Password combination(s). The token will be encrypted if required by the security policy of the User Token Policy or by the security policy of the endpoint. An unencrypted token either requires message encryption or means outside the scope of OPC UA to secure the identity token so that it cannot be retrieved by sniffing the communication. One option would be a secure transport like a VPN.

Security

Security User X509

The Serversupports a public/private key pair for user identity. The use of this feature must be able to be enabled or disabled by an administrator.

Security

Security User IssuedToken Kerberos

The Serversupports a Kerberos Servertoken for User Identity. The use of this feature must be able to be enabled or disabled by an Administrator. The use of this token is defined in Kerberos Token Documentation.

The token will be encrypted if required by the security policy of the User Token Policy or by the security policy of the endpoint. An unencrypted token either requires message encryption or means outside the scope of OPC UA to secure the identity token so that it cannot be retrieved by sniffing the communication. One option would be a secure transport like a VPN.

Security

Security User IssuedToken Kerberos Windows

The Serversupports the Windows implementation of Kerberos Tokens. This ConformanceUnitonly applies if the "Security User IssuedToken Kerberos" is supported.

The token will be encrypted if required by the security policy of the User Token Policy or by the security policy of the endpoint. An unencrypted token either requires message encryption or means outside the scope of OPC UA to secure the identity token so that it cannot be retrieved by sniffing the communication. One option would be a secure transport like a VPN.

Security

Security User JWT IssuedToken

The Serversupports a JSON Web Token (JWT) for user identity. Part 6 describes OAuth2 and JWTs in more detail. The use of this feature must be able to be enabled or disabled by an Administrator.

The token will be encrypted if required by the security policy of the User Token Policy or by the security policy of the endpoint. An unencrypted token either requires message encryption or means outside the scope of OPC UA to secure the identity token so that it cannot be retrieved by sniffing the communication. One option would be a secure transport like a VPN.

Security

Security User Anonymous

The Serverprovides support for Anonymous access. The use of this feature must be able to be enabled or disabled by an Administrator. By default Anonymous access shall be disabled.

Security

Security User Name Password Client

A Clientuses a User Name/Password combination.

The token will be encrypted if required by the security policy of the User Token Policy or by the security policy of the endpoint. An unencrypted token either requires message encryption or means outside the scope of OPC UA to secure the identity token so that it cannot be retrieved by sniffing the communication. One option would be a secure transport like a VPN.

Security

Security User X509 Client

A Clientuses a public/private key pair for user identity. This includes all validation and trust issues associated with a certificate.

Security

Security User IssuedToken Kerberos Client

A Clientuses a Kerberos Servertoken. The use of this token is defined by the Kerberos documentation.

The token will be encrypted if required by the security policy of the User Token Policy or by the security policy of the endpoint. An unencrypted token either requires message encryption or means outside the scope of OPC UA to secure the identity token so that it cannot be retrieved by sniffing the communication. One option would be a secure transport like a VPN.

Security

Security User IssuedToken Kerberos Windows Client

A Clientuses the Windows implementation of Kerberos tokens. This ConformanceUnitonly applies if the "Security User IssuedToken Kerberos Client" is supported.

The token will be encrypted if required by the security policy of the User Token Policy or by the security policy of the endpoint. An unencrypted token either requires message encryption or means outside the scope of OPC UA to secure the identity token so that it cannot be retrieved by sniffing the communication. One option would be a secure transport like a VPN.

Security

Security User JWT IssuedToken Client

A Clientuses a JSON Web Token (JWT) for user identity. Part 6 describes OAuth2 and JWTs in more detail.

The token will be encrypted if required by the security policy of the User Token Policy or by the security policy of the endpoint. An unencrypted token either requires message encryption or means outside the scope of OPC UA to secure the identity token so that it cannot be retrieved by sniffing the communication. One option would be a secure transport like a VPN.

Security

Security Invalid user token

Serversshall take proper measures to protect against attacks on user identity tokens. Such an attack is assumed if repeated connection attempts with invalid user identity tokens happen. See ActivateSession Servicein UA Part 4.

Security

Security User JWT Token Policy

The Server supports one or more Endpoints with a UserTokenPolicy that includes a JWT IssuerEndpointUrl as defined in UA Part 6.

For JWT the issuerEndpointUrl is a JSON object that includes all parameters that define the AuthorizationService.

As part of the JWT Token Policy, the Server shall support at least one of the following Authority Profile Conformance Units. The URIs defined in the ConformanceUnit shall be exposed in the authorityProfileURI field of the JWT Token Policy.

Security

Security User JWT Token Policy Client

The Client understands and uses the Authorization Service definition inside the JWT UserTokenPolicy returned with GetEndpoints.

It shall support at least one of the following Authority Profile Conformance Units. The URIs defined in the ConformanceUnit are in the authorityProfileURI field of the JWT Token Policy exposed in Server Endpoints.

Security

OAuth2 Authority Profile

This unit indicates support of OAuth2 over HTTPS to request access tokens.

The URI for the interactions with this authority is "http://opcfoundation.org/UA/Authorization#OAuth2"

Security

OPC UA Authority Profile

This unit indicates support of the OPC UA Methodsdefined in UA Part 12 to request access tokens.

The URI for the interactions with this authority is "http://opcfoundation.org/UA/Authorization#OPCUA"

Security

Azure Identity Provider Authority Profile

This unit indicates support of the Azure identity provider to request access tokens.

The URI for the interactions with this authority is "http://opcfoundation.org/UA/Authorization#Azure"

Security

Security CertificateValidation

A certificate will be validated as specified in Part 4. This includes among others structure and signature examination. Allowing for some validation errors to be suppressed by administration directive.

Security

Security Default ApplicationInstance Certificate

An application, when installed, has a default ApplicationInstanceCertificate that is valid. The default ApplicationInstanceCertificate shall either be created as part of the installation or installation instructions explicitly describe the process to create and apply a default ApplicationInstanceCertificate to the application.

Security

Security – No Application Authentication

The Serversupports being able to be configured for no application authentication, just User authentication and normal encryption/signing:

– Configure Serverto accept all certificates

Certificatesare just used for message security (signing and encryption)

– Users level is used for authentication

Security

Security Policy Required

Support at least Security Policy [A] and Security Policy [B].Support of multiple Security Policies - even obsolete ones - is recommended. This will provide best interoperability and allows the end user to choose the required level of security.

Obsolete Security Policies shall not be enabled / usable without administrative intervention.

Security

Security None CreateSession ActivateSession

When SecurityPolicy=None, the CreateSession and ActivateSession service allow for a NULL/empty signature and do not require Application Certificatesor a Nonce.

Security

Security None CreateSession ActivateSession 1.0

The Clientcan connect to Serversthat require a certificate being passed on Sessionestablishment. The Clientin this case will first try without a certificate and if this fails present a certificate.

Security

Security TLS General

This ConformanceUnitindicates that at least one of the transport security Profilesfor TLS is supported by this application. It is used in TLS transport Profiles, but the choice of transport security profile is optional. The actual used security profile will default to the most secure one.

Security

Security TLS_RSA with AES_256_CBC_SHA256

The connection is established using TLS_RSA_WITH_AES_256_CBC_SHA256. That has a MinAsymmetricKeyLength – 2048, MaxAsymmetricKeyLength – 4096, AsymmetricSignatureAlgorithm – RSA_SHA256. (TLS 1.2)

Security

Security TLS_DHE_RSA with AES_nnn_CBC_SHA256

The connection is established using TLS_DHE_RSA with AES_128_CBC_SHA256 or TLS_DHE_RSA with AES_256_CBC_SHA256. That has a MinAsymmetricKeyLength – 2048, MaxAsymmetricKeyLength – 4096, CertificateSignatureAlgorithm – RSA_SHA256. (TLS 1.2).

Clientsand Servershave to support both algorithms.

Security

Security Encryption Required

Encryption is required using the algorithms provided in the security algorithm suite.

Security

Security Signing Required

Signing is required using the algorithms provided in the security algorithm suite.

Security

Security Time Synch – Configuration

Application supports configuring acceptable clock skew.

Security

Security Time Synch – NTP / OS Based support

Application supports time synchronization, either via an implementation of Network Time Protocol (NTP), or via features of a standard operating system.

Security

Security Time Synch – UA based support

An application makes use of the responses header timestamp provided by a configured well know source, such as a Discovery Serverto synchronize the time on the application and that this time synchronization occurs periodically. Use of this TimeSyncing can be configured.

Security

Security Administration

Allow configuration of the following Security related items (when they apply).

* select the allowed User identification policy or policies (e.g. User Name/Password or X509).

* enable/disable the security policy "None" or other security policies.

* enable/disable endpoints with MessageSecurityMode SIGN or SIGNANDENCRYPT.

* set the permitted certification authorities.

* define how to react to unknown Certificates.

* allow accepting any valid Certificate

Security

Security Administration – XML Schema

Support the OPC UA defined XML schema for importing and exporting security configuration information. This schema is defined in Part 6.

Security

Security CertificateAdministration

Allow a site administrator to be able to assign a site specific ApplicationInstanceCertificate and if desired to configure a site specific CertificateAuthority (CA).

Security

Security Role ServerBase

Support the User Authorization Information Model defined in UA Parts 3 and 5 - like Roles - and the RolePermissions and UserRolePermissions Attributes.

Security

Security Role Well Known

Support the well-known Roles "ConfigureAdmin" and "SecurityAdmin" with suggested permissions defined in UA Part 3.

Security

Security Role ServerIdentityManagement

Allow authorized users to add and/or remove Identities from Roles with the appropriate Methods.

Security

Security Role ServerManagement

Allow authorized users to create new Roles and/or remove Roles with the appropriate Methods.

Security

Security Role ServerRestrict Applications

Support adding applications to a Role with the appropriate Methodsso that only these applications can use this Role.

Security

Security Role ServerRestrict Endpoints

Support adding Endpoints to a Role with the appropriate Methods. With this restriction a Role is only applied when a Clientconnects via one of these Endpoints.

Security

Security Role ServerDefaultRolePermissions

Allow authorized users to set the DefaultRolePermissions Propertyfor certain NameSpaces. DefaultRolePermissions are applied if no RolePermissions are associated with a Node.

Security

Security Role ServerRolePermissions

Allow authorized users to set the RolePermissions Attributeon Nodes.

Security

Security Role ServerAuthorization

Restrict access based on the configured Roles and permissions.

Security

Security Role ClientBase

Understand and use the User Authorization Information Model defined in UA Part 5 and the RolePermissions Attribute.

Security

Security Role ClientManagement

Support creating new Roles and adding Identities as well as remove Roles or Identities using the appropriate Methods.

Security

Security Role ClientRestrict Applications

Use the appropriate Methodsto add applications to a Role so that only these applications can use this Role.

Security

Security Role ClientRestrict Endpoints

Use the appropriate Methodsto add Endpoints to a Role. With this restriction a Role is only applied when a Clientconnects via one of these Endpoints.

Security

Security Role ClientDefaultRolePermissions

Ability to set the DefaultRolePermissions Propertyfor certain NameSpaces. DefaultRolePermissions are applied if no RolePermissions are associated with a Node.

Security

Security Role ClientRolePermissions

Support setting the RolePermissions Attributeon Nodes.

Security

Pull Model for Global Certificateand TrustList Management

Use the CertificateManagement Servicesof UA Part 12 for the Pull model to manage Application Instance Certificatesand Trust Lists including Revocation Lists.

Security

Push Model for Global Certificateand TrustList Management

Support the CertificateManagement Servicesof UA Part 12 for the Push model to manage Application Instance Certificatesand Trust Lists including Revocation Lists.

Security

Pull Model for KeyCredential Service

Use the Methodson an instance of the KeyCredentialServiceType (Pull model) to obtain KeyCredentials as specified in UA Part 12.

Security

Push Model for KeyCredential Service

Support the KeyCredential ServicesPush model of UA Part 12 to obtain KeyCredentials. This includes support of one or more instances of the KeyCredentialConfigurationType and the Methodsto update or delete credentials.

Security

Authorization Service Configuration Server

Support the Object Types defined in Part 12 to allow configuration of information needed to accept Access Tokens when presented by the Client during session establishment. Access Tokens are issued by Authorization Services.

Security

Authorization Service Client

Use the RequestAccessToken Method defined in UA Part 12.

Security

SymmetricSignatureAlgorithm_None

This algorithm does not apply.

Security

SymmetricSignatureAlgorithm_HMAC-SHA1

A keyed hash which is defined in https://tools.ietf.org/html/rfc2104.

The hash algorithm is SHA1 and is described in https://tools.ietf.org/html/rfc3174.

The URI is http://www.w3.org/2000/09/xmldsig#hmac-sha1.

No known exploits exist when using SHA1 with a keyed hash, however, SHA1 was broken in 2017 so use of this algorithm is not recommended.

Security

SymmetricSignatureAlgorithm_HMAC-SHA2-256

A keyed hash used for message authentication which is defined in https://tools.ietf.org/html/rfc2104.

The hash algorithm is SHA2 with 256 bits and described in https://tools.ietf.org/html/rfc4634

Security

SymmetricEncryptionAlgorithm_None

This algorithm does not apply.

Security

SymmetricEncryptionAlgorithm_AES128-CBC

The AES encryption algorithm which is defined in http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf.

Multiple blocks encrypted using the CBC mode described in http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf.

The key size is 128 bits. The block size is 16 bytes.

The URI is http://www.w3.org/2001/04/xmlenc#aes128-cbc.

Security

SymmetricEncryptionAlgorithm_AES256-CBC

The AES encryption algorithm which is defined in http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf.

Multiple blocks encrypted using the CBC mode described in http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf.

The key size is 256 bits. The block size is 16 bytes.

The URI is http://www.w3.org/2001/04/xmlenc#aes256-cbc.

Security

SymmetricEncryptionAlgorithm_AES128-CTR

The AES encryption algorithm which is defined in http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf.

Multiple blocks encrypted using the CTR mode described in http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf.

The counter block format is defined in https://tools.ietf.org/html/rfc3686.

The key size is 128 bits. The block size is 16 bytes. The input nonce length is 4 bytes.

The URI is http://opcfoundation.org/UA/security/aes128-ctr.

Security

SymmetricEncryptionAlgorithm_AES256-CTR

The AES encryption algorithm which is defined in http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf.

The key size is 256 bits. The block size is 16 bytes.

Multiple blocks encrypted using the CTR mode described in http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf.

The counter block format is defined in https://tools.ietf.org/html/rfc3686.

The key size is 128 bits. The block size is 16 bytes. The input nonce length is 4 bytes.

The URI is http://opcfoundation.org/UA/security/aes256-ctr.

Security

AsymmetricSignatureAlgorithm_None

This algorithm does not apply.

Security

AsymmetricSignatureAlgorithm_RSA- PKCS15-SHA1

The RSA signature algorithm which is defined in https://tools.ietf.org/html/rfc3447.

The RSASSA-PKCS1-v1_5 scheme is used.

The hash algorithm is SHA1 and is described in https://tools.ietf.org/html/rfc3174.

The URI is http://www.w3.org/2000/09/xmldsig#rsa-sha1.

SHA1 was broken in 2017 so this algorithm should not be used.

Security

AsymmetricSignatureAlgorithm_RSA-PKCS15-SHA2-256

The RSA signature algorithm which is defined in https://tools.ietf.org/html/rfc3447.

The RSASSA-PKCS1-v1_5 scheme is used.

The hash algorithm is SHA2 with 256bits and is described in https://tools.ietf.org/html/rfc6234.

The URI is http://www.w3.org/2001/04/xmldsig-more#rsa-sha256.

Security

AsymmetricSignatureAlgorithm_RSA-PSS -SHA2-256

The RSA signature algorithm which is defined in https://tools.ietf.org/html/rfc3447.

The RSASSA-PSS scheme is used.

The hash algorithm is SHA2 with 256bits and is described in https://tools.ietf.org/html/rfc6234.

The mask generation algorithm also uses SHA2 with 256 bits.

The salt length is 32 bytes.

The URI is http://opcfoundation.org/UA/security/rsa-pss -sha2-256.

Security

AsymmetricEncryptionAlgorithm_None

This algorithm does not apply.

Security

AsymmetricEncryptionAlgorithm_RSA-PKCS15

The RSA encryption algorithm which is defined in https://tools.ietf.org/html/rfc3447.

The RSAES-PKCS1-v1_5 scheme is used.

The URI is http://www.w3.org/2001/04/xmlenc#rsa-1_5.

The RSAES-PKCS1-v1_5 scheme has known weaknesses and is not recommended.

Security

AsymmetricEncryptionAlgorithm_RSA-OAEP-SHA1

The RSA encryption algorithm which is defined in https://tools.ietf.org/html/rfc3447.

The RSAES-OAEP scheme is used.

The hash algorithm is SHA1 and is described in https://tools.ietf.org/html/rfc6234.

The mask generation algorithm also uses SHA1.

The URI is http://www.w3.org/2001/04/xmlenc#rsa-oaep.

No known exploits exist when using SHA1 with RSAES-OAEP, however, SHA1 was broken in 2017 so use of this algorithm is not recommended.

Security

AsymmetricEncryptionAlgorithm_RSA-OAEP-SHA2-256

The RSA encryption algorithm which is defined in https://tools.ietf.org/html/rfc3447.

The RSAES-OAEP scheme is used.

The hash algorithm is SHA2 with 256 bits and is described in https://tools.ietf.org/html/rfc6234.

The mask generation algorithm also uses SHA2 with 256 bits.

The URI is http://opcfoundation.org/UA/security/rsa-oaep-sha2-256.

Security

KeyDerivationAlgorithm_None

This algorithm does not apply.

Security

KeyDerivationAlgorithm_P-SHA1

The P_SHA-1 pseudo-random function defined in https://tools.ietf.org/html/rfc4346.

The URI is http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/dk/p_sha1.

No known exploits exist when using SHA1 with P-SHA-1, however, SHA1 was broken in 2017 so use of this algorithm is not recommended.

Security

KeyDerivationAlgorithm_P-SHA2-256

The P_SHA256 pseudo-random function defined in https://tools.ietf.org/html/rfc5246.

The URI is http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/dk/p_sha256.

Security

CertificateSignatureAlgorithm_None

This algorithm does not apply.

Security

CertificateSignatureAlgorithm_RSA-PKCS15-SHA2-256

The RSA signature algorithm which is defined in https://tools.ietf.org/html/rfc3447.

The RSASSA-PKCS1-v1_5 scheme is used.

The hash algorithm is SHA2 with 256bits and is described in https://tools.ietf.org/html/rfc6234.

The SHA2 algorithm with 384 or 512 bits may be used instead of SHA2 with 256 bits.

The URI is http://www.w3.org/2001/04/xmldsig-more#rsa-sha256.

Security

CertificateSignatureAlgorithm_RSA-PKCS15-SHA1

The RSA signature algorithm which is defined in https://tools.ietf.org/html/rfc3447.

The RSASSA-PKCS1-v1_5 scheme is used.

The hash algorithm is SHA1 and is described in https://tools.ietf.org/html/rfc3174.

The URI is http://www.w3.org/2000/09/xmldsig#rsa-sha1.

SHA1 was broken in 2017 so this algorithm should not be used.

The SHA2 algorithm with 244, 256, 384 or 512 bits may be used instead of SHA1.

The SHA2 algorithm is described in https://tools.ietf.org/html/rfc6234.

Security

SecurtyPolicy_None_Limits

DerivedSignatureKeyLength: 0

Security

Aes128-Sha256-RsaOaep_Limits

-> DerivedSignatureKeyLength: 256 bits

-> MinAsymmetricKeyLength: 2048 bits

-> MaxAsymmetricKeyLength: 4096 bits

-> SecureChannelNonceLength: 32 bytes

Security

Basic256Sha256_Limits

-> DerivedSignatureKeyLength: 256 bits

-> MinAsymmetricKeyLength: 2048 bits

-> MaxAsymmetricKeyLength: 4096 bits

-> SecureChannelNonceLength: 32 bytes

Security

Aes256-Sha256-RsaPss_Limits

-> DerivedSignatureKeyLength: 256 bits

-> MinAsymmetricKeyLength: 2048 bits

-> MaxAsymmetricKeyLength: 4096 bits

-> SecureChannelNonceLength: 32 bytes

Security

Basic128Rsa15_Limits

-> DerivedSignatureKeyLength: 128 bits

-> MinAsymmetricKeyLength: 1024 bits

-> MaxAsymmetricKeyLength: 2048 bits

-> SecureChannelNonceLength: 16 bytes

Security

Basic256_Limits

-> DerivedSignatureKeyLength: 192 bits

-> MinAsymmetricKeyLength: 1024 bits

-> MaxAsymmetricKeyLength: 2048 bits

-> SecureChannelNonceLength: 32 bytes

Table 12describes protocol and encoding related features that can be profiled. These features are defined in detail in OPC 10000-6. It is recommended that Serversand Clientssupport as many of these options as possible for greatest interoperability.

Table 12– Protocol and Encoding

Category

Title

Description

Server

Protocol Reverse Connect Server

Support reverse connectivity by sending a ReverseHello message to a Client. The reverse connect procedure can be applied to several transports as specified in UA Part 6 and shall be supported for all of these that are available in a Server.

Server

Protocol Configuration

Allow administration of the Endpoints and the port number used by the Endpoints.

Client

Protocol Reverse Connect Client

Support reverse connectivity by accepting Reverse Hello messages from Servers and establish a Secure Channel if the URI of the Server is accepted by Client or Client user. The reverse connect procedure can be applied to several transports as specified in UA Part 6 and shall be supported for all of these transports that are supported by the Client.

Transport

Protocol UA TCP

Support the UA TCP transport protocol as defined in UA Part 6.

Transport

Protocol HTTPS

Support the HTTPS protocol as defined in UA Part 6.

Transport

Protocol Web Sockets

Support the WebSocket protocol (WSS) with at least one of the sub-protocols defined in UA Part 6.

Transport

UA Secure Conversation

Support UA Secure Conversation specified in UA Part 6.

Transport

UA Binary Encoding

Support UA Binary Encoding. Values of these data types are encoded in compact binary formats, contiguously and without tagging. I.e. the receiver is assumed to understand the structure it is decoding.

Transport

UA SOAP-XML Encoding

Support Soap V1.2 based Xml Encoding as defined in UA Part 6. The XML elements include all information necessary to convert it back into OPC UA structures of any language.

Transport

JSON Reversible Encoding

Support reversible JSON Encoding as defined in UA Part 6. The JSON object includes all information necessary to convert it back into OPC UA structures of any language.