Most Messagesrequire a SecureChannelto be established. A Clientdoes this by sending an OpenSecureChannelrequest to the Server. The Servershall validate the Messageand the ClientCertificateand return an OpenSecureChannelresponse. Some of the parameters defined for the OpenSecureChannelservice are specified in the security header (see 6.7.2) instead of the body of the Message. Table 47lists the parameters that appear in the body of the Message.

Note that OPC 10000-4is an abstract specification which defines interfaces that can work with any protocol. This specification provides a concrete implementation for specific protocols. This document is the normative reference for all protocols and takes precedence if there are differences with OPC 10000-4.

Table 47– OPC UA Secure Conversation OpenSecureChannel Service

Name

Data Type

Request

RequestHeader

RequestHeader

ClientProtocolVersion

UInt32

RequestType

SecurityTokenRequestType

SecurityMode

MessageSecurityMode

ClientNonce

ByteString

RequestedLifetime

UInt32

Response

ResponseHeader

ResponseHeader

ServerProtocolVersion

UInt32

SecurityToken

ChannelSecurityToken

SecureChannelId

UInt32

TokenId

UInt32

CreatedAt

UtcTime

RevisedLifetime

UInt32

ServerNonce

ByteString

The ClientProtocolVersionand ServerProtocolVersionparameters are not defined in OPC 10000-4and are added to the Messageto allow backward compatibility if OPC UA-SecureConversation needs to be updated in the future. Receivers always accept numbers greater than the latest version that they support. The receiver with the higher version number is expected to ensure backward compatibility.

If OPC UA-SecureConversationis used with the OPC UA-TCP protocol (see 7.1) then the version numbers specified in the OpenSecureChannel Messagesshall be the same as the version numbers specified in the OPC UA-TCP protocol Hello/Acknowledge Messages. The receiver shall close the channel and report a Bad_ProtocolVersionUnsupportederror if there is a mismatch.

The Servershall return an error response as described in OPC 10000-4if there are any errors with the parameters specified by the Client.

The RevisedLifetimetells the Clientwhen it shall renew the SecurityTokenby sending another OpenSecureChannelrequest. The Clientshall continue to accept the old SecurityTokenuntil it receives the OpenSecureChannelresponse. The Serverhas to accept requests secured with the old SecurityTokenuntil that SecurityTokenexpires or until it receives a Messagefrom the Clientsecured with the new SecurityToken. The Servershall reject renew requests if the SenderCertificateis not the same as the one used to create the SecureChannelor if there is a problem decrypting or verifying the signature. The Clientshall abandon the SecureChannelif the Certificateused to sign the response is not the same as the Certificateused to encrypt the request. Note that datatype is a UInt32value representing the number of milliseconds instead of the Double(Duration) defined in OPC 10000-4. This optimization is possible because sub-millisecond timeouts are not supported.

The OpenSecureChannel Messagesare signed and encrypted if the SecurityModeis not None(even if the SecurityMode is Sign).

The Noncesshall be cryptographic random numbers with a length specified by the SecureChannelNonceLength of the SecurityPolicy.

See OPC 10000-2for more information on the requirements for random number generators. The OpenSecureChannel Messagesare not signed or encrypted if the SecurityModeis None. The Noncesare ignored and should be set to null. The SecureChannelIdand the TokenIdare still assigned but no security is applied to Messagesexchanged via the channel. The SecurityTokenshall still be renewed before the RevisedLifetimeexpires. Receivers shall still ignore invalid or expired TokenIds.

If the communication channel breaks the Servershall maintain the SecureChannellong enough to allow the Clientto reconnect. The RevisedLifetimeparameter also tells the Clienthow long the Serverwill wait. If the Clientcannot reconnect within that period it shall assume the SecureChannelhas been closed.

The AuthenticationTokenin the RequestHeadershall be set to null.

If an error occurs after the Serverhas verified Messagesecurity it shall return a ServiceFaultinstead of a OpenSecureChannelresponse. The ServiceFault Messageis described in OPC 10000-4.

If the SecurityModeis not None then the Servershall verify that a SenderCertificateand a ReceiverCertificateThumbprintwere specified in the SecurityHeader.