UA Part 7: Profiles - 5.3 Transport and communication related features

5.3 Transport and communication related features

Errata exists for this version of the document.

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.