View Issue Details

IDProjectCategoryView StatusLast Update
0008562Compliance Test Tool (CTT) Unified Architecture4 - Test Case Definitionpublic2023-02-03 16:27
ReporterJim Luth Assigned ToThomas  
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionopen 
Product Version1.04 
Summary0008562: OpenSecureChannel Renew Issue with slow embedded devices
Description

The problem arises from an imprecise definition of Part 6. It occurred
with the HPSDK client and C++ SDK demo server. The later one uses the
legacy UA Stack, which causes the problem.

From the specification: Part 6 - 6.7.4

"The Client shall continue to accept the old SecurityToken until it
receives the OpenSecureChannel response. The Server has to accept
requests secured with the old SecurityToken until that SecurityToken
expires or until it receives a Message from the Client secured with
the new SecurityToken"

This defines only how long to accept old tokens, not when to use the
new token. This can lead to misinterpretations, which then lead to
buggy implementations. Obviously, the client should use the new token
as soon as possible, so after processing the OpenSecureChannel
response.

When the server assumes that after sending the OPN response, the
client "knows" it and so it can directly use the new token in any
response after the OPN response, this is wrong! The client may need
multiple seconds to process the OPN response. Meanwhile, the client is
still using the old token for other requests.

The server should only use the new token in any response, after it
receives the new token the first time from the client. This proves
that the client does actually know it.

Steps To Reproduce

You need to use a security policy != None for this.

1.) Run a server based on the Legacy C Stack
2.) Use a client which needs about 3s to process the OPN Response and does other requests meanwhile (E.g. publish or status read).
3.) When the client uses the old TokenID, but the server responds with the new TokenID, which the client is not aware of yet, the request gets denied, and the connection is terminated.

Additional Information

This is an important IOP problem. Other implementations may be affected as well. We should check all stacks when they switch to the new token.

TagsNo tags attached.
Files Affected

Relationships

related to 0007448 closedRandy Armstrong 10000-006: Mappings OpenSecureChannel Renew Issue with slow embedded devices 

Activities

Randy Armstrong

2023-01-03 16:24

administrator   ~0018385

Cleaned up wording in 6.7.4 to make it clear that the new token is used as soon as possible.

Note that the previous release had already fixed the problem with long processing times on the client side.

Jim Luth

2023-01-03 16:24

administrator   ~0018386

Reviewed and agreed to changed text in 1.05.03. Needs 1.03 and 1.04 Errata to close.

Paul Hunkar

2023-01-03 18:13

administrator   ~0018398

Should create a test case for this (check existing test cases)

Issue History

Date Modified Username Field Change
2023-01-03 16:24 Jim Luth New Issue
2023-01-03 16:24 Jim Luth Issue generated from: 0007448
2023-01-03 16:24 Jim Luth Note Added: 0018385
2023-01-03 16:24 Jim Luth Note Added: 0018386
2023-01-03 16:24 Jim Luth Relationship added related to 0007448
2023-01-03 16:24 Jim Luth Project 10000-006: Mappings => Compliance Test Tool (CTT) Unified Architecture
2023-01-03 16:24 Jim Luth Category Spec => Api Change
2023-01-03 18:13 Paul Hunkar Note Added: 0018398
2023-02-03 16:26 Paul Hunkar Assigned To => Thomas
2023-02-03 16:26 Paul Hunkar Status new => assigned
2023-02-03 16:27 Paul Hunkar Category Api Change => 4 - Test Case Definition