Table 11 describes security related ConformanceUnits. All of these ConformanceUnits apply equally to both Clients and Servers, where a Client uses the related security unit and a Server supports the use of it. These items are defined in detail in OPC 10000-6. It is recommended that a Server and Client support 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 ConformanceUnits are exposed in a given deployed Server or Client application.

Table 11 – Security

Category

Title

Description

Security

Security User Name Password

The Server supports 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 Server supports 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 Server supports a Kerberos Server token 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 Server supports the Windows implementation of Kerberos Tokens. This ConformanceUnit only 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 Server supports 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 Server provides 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 Client uses 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 Client uses 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 Client uses a Kerberos Server token. 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 Client uses the Windows implementation of Kerberos tokens. This ConformanceUnit only 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 Client uses 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

Servers shall 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 Service in 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 Methods defined 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 Certificate Validation

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 Server supports being able to be configured for no application authentication, just User authentication and normal encryption/signing:

– Configure Server to accept all certificates

Certificates are 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 Certificates or a Nonce.

Security

Security None CreateSession ActivateSession 1.0

The Client can connect to Servers that require a certificate being passed on Session establishment. The Client in this case will first try without a certificate and if this fails present a certificate.

Security

Security TLS General

This ConformanceUnit indicates that at least one of the transport security Profiles for 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).

Clients and Servers have 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 Server to 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 Certificate Administration

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

Security

Security Role Server Base

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 Server IdentityManagement

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

Security

Security Role Server Management

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

Security

Security Role Server Restrict Applications

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

Security

Security Role Server Restrict Endpoints

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

Security

Security Role Server DefaultRolePermissions

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

Security

Security Role Server RolePermissions

Allow authorized users to set the RolePermissions Attribute on Nodes.

Security

Security Role Server Authorization

Restrict access based on the configured Roles and permissions.

Security

Security Role Client Base

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

Security

Security Role Client Management

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

Security

Security Role Client Restrict Applications

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

Security

Security Role Client Restrict Endpoints

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

Security

Security Role Client DefaultRolePermissions

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

Security

Security Role Client RolePermissions

Support setting the RolePermissions Attribute on Nodes.

Security

Pull Model for Global Certificate and TrustList Management

Use the Certificate Management Services of UA Part 12 for the Pull model to manage Application Instance Certificates and Trust Lists including Revocation Lists.

Security

Push Model for Global Certificate and TrustList Management

Support the Certificate Management Services of UA Part 12 for the Push model to manage Application Instance Certificates and Trust Lists including Revocation Lists.

Security

Pull Model for KeyCredential Service

Use the Methods on 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 Services Push model of UA Part 12 to obtain KeyCredentials. This includes support of one or more instances of the KeyCredentialConfigurationType and the Methods to 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 12 describes protocol and encoding related features that can be profiled. These features are defined in detail in OPC 10000-6. It is recommended that Servers and Clients support 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.