5 Conformance Units ToC Previous Next

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.

Previous Next