UA Part 4: Services - 5.5.2 OpenSecureChannel

Errata exists for this version of the document.

This Service is used to open or renew a SecureChannel that can be used to ensure Confidentiality and Integrity for Message exchange during a Session. This Service requires the Communication Stack to apply the various security algorithms to the Messages as they are sent and received. Specific implementations of this Service for different Communication Stacks are described in OPC 10000-6.

Each SecureChannel has a globally-unique identifier and is valid for a specific combination of Client and Server application instances. Each channel contains one or more SecurityTokens that identify a set of cryptography keys that are used to encrypt and authenticate Messages. SecurityTokens also have globally-unique identifiers which are attached to each Message secured with the token. This allows an authorized receiver to know how to decrypt and verify the Message.

SecurityTokens have a finite lifetime negotiated with this Service. However, differences between the system clocks on different machines and network latencies mean that valid Messages could arrive after the token has expired. To prevent valid Messages from being discarded, the applications should do the following:

Clients should request a new SecurityToken after 75 % of its lifetime has elapsed. This should ensure that Clients will receive the new SecurityToken before the old one actually expires.
Servers shall use the existing SecurityToken to secure outgoing Messages until the SecurityToken expires or the Server receives a Message secured with a new SecurityToken. This should ensure that Clients do not reject Messages secured with the new SecurityToken that arrive before the Client receives the new SecurityToken.
Clients should accept Messages secured by an expired SecurityToken for up to 25 % of the token lifetime. This should ensure that Messages sent by the Server before the token expired are not rejected because of network delays.

Each SecureChannel exists until it is explicitly closed or until the last token has expired and the overlap period has elapsed. A Server application should limit the number of SecureChannels. To protect against misbehaving Clients and denial of service attacks, the Server shall close the oldest SecureChannel that has no Session assigned before reaching the maximum number of supported SecureChannels.

The OpenSecureChannel request and response Messages shall be signed with the sender's private key. These Messages shall always be encrypted. If the transport layer does not provide encryption, then these Messages shall be encrypted with the receiver's public key. These requirements for OpenSecureChannel only apply if the securityPolicyUri is not None.

If the protocol defined in OPC 10000-6 requires that Application Instance Certificates are used in the OpenSecureChannel Service, then Clients and Servers shall verify that the same Certificates are used in the CreateSession and ActivateSession Services. Certificates are not provided and shall not be verified if the securityPolicyUri is None.

If the securityPolicyUri is not None, a Client shall verify the HostName specified in the Server Certificate is the same as the HostName contained in the endpointUrl. If there is a difference then the Client shall report the difference and may choose to not open the SecureChannel. Servers shall add all possible HostNames like MyHost and MyHost.local into the Server Certificate. This includes IP addresses of the host or the HostName exposed by a NAT router used to connect to the Server.

Clients should be prepared to replace the HostName returned in the EndpointDescription with the HostName or the IP addresses they used to call GetEndpoints.

5.5.2.2 Parameters

Table 11 defines the parameters for the Service.

Unlike other Services, the parameters for this Service provide only an abstract definition. The concrete representation on the network depends on the mappings defined in OPC 10000-6.

Table 11 – OpenSecureChannel Service Parameters

Name	Type	Description
Request
requestHeader	RequestHeader	Common request parameters. The authenticationToken is always null. The type RequestHeader is defined in 7.28.
clientCertificate	ApplicationInstance‌Certificate	A Certificate that identifies the Client. The OpenSecureChannel request shall be signed with the private key for this Certificate. The ApplicationInstanceCertificate type is defined in 7.2. If the securityPolicyUri is None, the Server shall ignore the ApplicationInstanceCertificate.
requestType	Enum SecurityToken RequestType	The type of SecurityToken request: An enumeration that shall be one of the following: ISSUE_0creates a new SecurityToken for a new SecureChannel. RENEW_1creates a new SecurityToken for an existing SecureChannel.
secureChannelId	BaseDataType	The identifier for the SecureChannel that the new token should belong to. This parameter shall be null when creating a new SecureChannel. The concrete security protocol definition in OPC 10000-6 chooses the concrete DataType.
securityMode	Enum MessageSecurityMode	The type of security to apply to the messages. The type MessageSecurityMode type is defined in 7.15. A SecureChannel may have to be created even if the securityMode is NONE. The exact behaviour depends on the mapping used and is described in the OPC 10000-6.
securityPolicyUri	String	The URI for SecurityPolicy to use when securing messages sent over the SecureChannel. The set of known URIs and the SecurityPolicies associated with them are defined in OPC 10000-7.
clientNonce	ByteString	A random number that shall not be used in any other request. A new clientNonce shall be generated for each time a SecureChannel is renewed. This parameter shall have a length equal to the SecureChannelNonceLength defined for the SecurityPolicy in OPC 10000-7. The SecurityPolicy is identified by the securityPolicyUri.
requestedLifetime	Duration	The requested lifetime, in milliseconds, for the new SecurityToken. It specifies when the Client expects to renew the SecureChannel by calling the OpenSecureChannel Service again. If a SecureChannel is not renewed, then all Messages sent using the current SecurityTokens shall be rejected by the receiver. Several cryptanalytic attacks become easier as more material encrypted with a specific key is available. By limiting the amount of data processed using a particular key, those attacks are made more difficult. Therefore the volume of data exchanged between Client and Server must be limited by establishing a new SecurityToken after the lifetime. The setting of the requested lifetime depends on the expected number of exchanged messages and their size in the lifetime. A higher volume of data requires shorter lifetime.

Response
responseHeader	ResponseHeader	Common response parameters (see 7.29 for ResponseHeader type definition).
securityToken	ChannelSecurityToken	Describes the new SecurityToken issued by the Server. This structure is defined in-line with the following indented items.
channelId	BaseDataType	A unique identifier for the SecureChannel. This is the identifier that shall be supplied whenever the SecureChannel is renewed. The concrete security protocol definition in OPC 10000-6 chooses the concrete DataType.
tokenId	ByteString	A unique identifier for a single SecurityToken within the channel. This is the identifier that shall be passed with each Message secured with the SecurityToken.
createdAt	UtcTime	The time when the SecurityToken was created.
revisedLifetime	Duration	The lifetime of the SecurityToken in milliseconds. The UTC expiration time for the token may be calculated by adding the lifetime to the createdAt time.
serverNonce	ByteString	A random number that shall not be used in any other request. A new serverNonce shall be generated for each time a SecureChannel is renewed. This parameter shall have a length equal to the SecureChannelNonceLength defined for the SecurityPolicy in OPC 10000-7. The SecurityPolicy is identified by the securityPolicyUri.

5.5.2.3 Service results

Table 12 defines the Service results specific to this Service. Common StatusCodes are defined in Table 177.

Table 12 – OpenSecureChannel Service Result Codes

Symbolic Id	Description
Bad_SecurityChecksFailed	See Table 177 for the description of this result code.
Bad_CertificateTimeInvalid	See Table 177 for the description of this result code.
Bad_CertificateIssuerTimeInvalid	See Table 177 for the description of this result code.
Bad_CertificateHostNameInvalid	See Table 177 for the description of this result code.
Bad_CertificateUriInvalid	See Table 177 for the description of this result code.
Bad_CertificateUseNotAllowed	See Table 177 for the description of this result code.
Bad_CertificateIssuerUseNotAllowed	See Table 177 for the description of this result code.
Bad_CertificateUntrusted	See Table 177 for the description of this result code.
Bad_CertificateRevocationUnknown	See Table 177 for the description of this result code.
Bad_CertificateIssuerRevocationUnknown	See Table 177 for the description of this result code.
Bad_CertificateRevoked	See Table 177 for the description of this result code.
Bad_CertificateIssuerRevoked	See Table 177 for the description of this result code.
Bad_RequestTypeInvalid	The security token request type is not valid.
Bad_SecurityModeRejected	The security mode does not meet the requirements set by the Server.
Bad_SecurityPolicyRejected	The security policy does not meet the requirements set by the Server.
Bad_SecureChannelIdInvalid	See Table 177 for the description of this result code.
Bad_NonceInvalid	See Table 177 for the description of this result code. A Server shall check the minimum length of the Client nonce and return this status if the length is below 32 bytes. A check for duplicated nonce can only be done in OpenSecureChannel calls with the request type RENEW_1.