Log In
Home
04/16/2015
Offline
A customer is using our OPC UA client and attempting to connect to a server that’s setting the timestamp value in the ResponseHeader of the OpenSecureChannelResponse to 0. Is this server compliant with the standard?
Our OPC UA client checks the validity of the timestamp in the ResponseHeader and expects it to be within 5 minutes of the clients time. This is based on our interpretation of the specification in particular:
Part 2, 5.1.4, Message spoofing, “… Messages will always contain a valid …, Timestamp”.
Part 2, 5.1.6, Message replay, “OPC UA uses …, Timestamps”.
Part 4, 7.34, ResponseHeader, the description for the timestamp field is “The time the server sent the response”.
Part 6, 6.3 Time synchronization, “All SecurityProtocols require that system clocks on communicating machines be reasonably synchronized”. The previous version (1.0.4) noted a suitable tolerance for clock differences would be 5 minutes.
Looking at the reference client I don’t see any checks of the timestamp in the response header.
05/30/2017
Online
The timestamp is supposed to be set to the computer clock, however, we removed the requirement to check because it was causing too many IOP problems with embedded devices that have clocks that get reset on reboot or are generally not accurate.
The message replay problem does not exist when messages are sent over an authenticated channel so the check is redundant in the majority of cases.
04/16/2015
Offline
Thanks for the response, are there any plans to amend the specifications in light of this decision, i.e. that the timestamp isn’t checked and may be a random value?
1 Guest(s)
Usage Policy