This Serviceis used to open or renew a SecureChannelthat can be used to ensure Confidentialityand Integrityfor Messageexchange during a Session. This Servicerequires the Communication Stackto apply the various security algorithms to the Messagesas they are sent and received. Specific implementations of this Servicefor different Communication Stacksare described in OPC 10000-6.

Each SecureChannelhas a globally-unique identifier and is valid for a specific combination of Clientand Serverapplication instances. Each channel contains one or more SecurityTokensthat identify a set of cryptography keys that are used to encrypt and authenticate Messages. SecurityTokensalso have globally-unique identifiers which are attached to each Messagesecured with the token. This allows an authorized receiver to know how to decrypt and verify the Message.

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

  1. Clientsshould request a new SecurityTokenafter 75 % of its lifetime has elapsed. This should ensure that Clientswill receive the new SecurityTokenbefore the old one actually expires.
  2. Serversshall use the existing SecurityTokento secure outgoing Messagesuntil the SecurityTokenexpires or the Serverreceives a Messagesecured with a new SecurityToken. This should ensure that Clientsdo not reject Messagessecured with the new SecurityTokenthat arrive before the Clientreceives the new SecurityToken.
  3. Clientsshould accept Messagessecured by an expired SecurityToken for up to 25 % of the token lifetime. This should ensure that Messagessent by the Serverbefore the token expired are not rejected because of network delays.

Each SecureChannelexists until it is explicitly closed or until the last token has expired and the overlap period has elapsed. A Serverapplication should limit the number of SecureChannels. To protect against misbehaving Clientsand denial of service attacks, the Servershall close the oldest unused SecureChannelthat has no Sessionassigned before reaching the maximum number of supported SecureChannels. When Session-less Serviceinvocation is done through a transport mapping that requires the OpenSecureChannel Service, the Servershall maintain a last used time for the SecureChannelto detect the oldest unused SecureChannel.

The OpenSecureChannelrequest and response Messagesshall be signed with the sender's private key. These Messagesshall always be encrypted. If the transport layer does not provide encryption, then these Messagesshall be encrypted with the receiver's public key. These requirements for OpenSecureChannelonly apply if the securityPolicyUriis not None.

If the protocol defined in OPC 10000-6requires that Application Instance Certificatesare used in the OpenSecureChannel Service, then Clientsand Serversshall verify that the same Certificatesare used in the CreateSessionand ActivateSession Services. Certificatesare not provided and shall not be verified if the securityPolicyUriis None.

If the securityPolicyUriis not None, a Clientshall verify the HostNamespecified in the Server Certificateis the same as the HostNamecontained in the endpointUrl. If there is a difference then the Clientshall report the difference and may choose to not open the SecureChannel.Serversshall add all possible HostNameslike MyHost and MyHost.local into the Server Certificate. This includes IP addresses of the host or the HostNameexposed by a NAT router used to connect to the Server.

Clientsshould be prepared to replace the HostNameand port returned in the EndpointDescriptionwith the HostNameor the IP addresses and the port they used to call GetEndpoints. The Clientshall still execute the HostNameverification comparing the HostNameused by the Clientto create the SecureChannelwith the HostNamelist in the Server Certificate. See Table 106for more details.

Table 11defines the parameters for the Service.

Unlike other Services, the parameters for this Serviceprovide 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 authenticationTokenis always null.

The type RequestHeaderis defined in 7.33.

clientCertificate

ApplicationInstance‌Certificate

A Certificatethat identifies the Client.

The OpenSecureChannelrequest shall be signed with the private key for this Certificate.

The ApplicationInstanceCertificatetype is defined in 7.3.

If the securityPolicyUriis None, the Servershall ignore the ApplicationInstanceCertificate.

requestType

Enum

SecurityToken RequestType

The type of SecurityTokenrequest:

An enumeration that shall be one of the following:

ISSUEcreates a new SecurityTokenfor a new SecureChannel.

RENEW creates a new SecurityTokenfor an existing SecureChannel.

secureChannelId

BaseDataType

The identifier for the SecureChannelthat the new token should belong to. This parameter shall be null when creating a new SecureChannel.

The concrete security protocol definition in OPC 10000-6chooses the concrete DataType.

securityMode

Enum

MessageSecurityMode

The type of security to apply to the messages.

The type MessageSecurityModetype is defined in 7.20.

A SecureChannelmay need to be created even if the securityModeis NONE. The exact behaviour depends on the mapping used and is described in the OPC 10000-6.

securityPolicyUri

String

The URI for SecurityPolicyto 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 clientNonceshall be generated for each time a SecureChannelis renewed.

This parameter shall have a length equal to the SecureChannelNonceLengthdefined for the SecurityPolicyin OPC 10000-7. The SecurityPolicyis identified by the securityPolicyUri.

requestedLifetime

Duration

The requested lifetime, in milliseconds, for the new SecurityToken. It specifies when the Clientexpects to renew the SecureChannelby calling the OpenSecureChannel Serviceagain. If a SecureChannelis not renewed, then all Messagessent using the current SecurityTokensshall 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 Clientand Servershall be limited by establishing a new SecurityTokenafter 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.34for ResponseHeadertype definition).

securityToken

ChannelSecurityToken

Describes the new SecurityTokenissued 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 SecureChannelis renewed.

The concrete security protocol definition in OPC 10000-6chooses the concrete DataType.

tokenId

ByteString

A unique identifier for a single SecurityTokenwithin the channel. This is the identifier that shall be passed with each Messagesecured with the SecurityToken.

createdAt

UtcTime

The time when the SecurityTokenwas created.

revisedLifetime

Duration

The lifetime of the SecurityTokenin milliseconds. The UTC expiration time for the token may be calculated by adding the lifetime to the createdAttime.

The revised lifetime shall be used by the Clientto renew a SecureChannelbefore it expires even if the MessageSecurityModeis NONE.

serverNonce

ByteString

A random number that shall not be used in any other request. A new serverNonceshall be generated for each time a SecureChannelis renewed.

This parameter shall have a length equal to the SecureChannelNonceLengthdefined for the SecurityPolicyin OPC 10000-7. The SecurityPolicyis identified by the securityPolicyUri.

Table 12defines the Serviceresults specific to this Service. Common StatusCodesare defined in Table 182.

Table 12– OpenSecureChannel Service Result Codes

Symbolic Id

Description

Bad_SecurityChecksFailed

See Table 182for the description of this result code.

Bad_CertificateTimeInvalid

See Table 182for the description of this result code.

Bad_CertificateIssuerTimeInvalid

See Table 182for the description of this result code.

Bad_CertificateHostNameInvalid

See Table 182for the description of this result code.

Bad_CertificateUriInvalid

See Table 182for the description of this result code.

Bad_CertificateUseNotAllowed

See Table 182for the description of this result code.

Bad_CertificateIssuerUseNotAllowed

See Table 182for the description of this result code.

Bad_CertificateUntrusted

See Table 182for the description of this result code.

Bad_CertificateRevocationUnknown

See Table 182for the description of this result code.

Bad_CertificateIssuerRevocationUnknown

See Table 182for the description of this result code.

Bad_CertificateRevoked

See Table 182for the description of this result code.

Bad_CertificateIssuerRevoked

See Table 182for the description of this result code.

Bad_RequestTypeInvalid

The SecurityTokenrequest type is not valid.

Bad_SecurityModeRejected

See Table 182for the description of this result code.

Bad_SecurityPolicyRejected

The security policy does not meet the requirements set by the Server.

Bad_SecureChannelIdInvalid

See Table 182for the description of this result code.

Bad_NonceInvalid

See Table 182for the description of this result code.

A Servershall check the minimum length of the Clientnonce and return this status if the length is below 32 bytes. A check for duplicated nonce can only be done in OpenSecureChannelcalls with the request type RENEW.