View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001731 | 10000-004: Services | public | 2011-09-12 14:10 | 2013-12-10 17:22 | |
Reporter | Ustinov Vetcheslav | Assigned To | Matthias Damm | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Fixed in Version | 1.02 | ||||
Summary | 0001731: Server channel token refresh and Part 4 | ||||
Description | Part 4, 5.5.2.1 says: TcpIp stack implementation uses new SecurityToken before receiving a message secured with a new SecurityToken from the client. In our embedded client implementation we can calculate RSA only asynchronously, because RSA very slow and will block message exchanging for long time. If the server secures messages before client ready we must block execution. In real-time applications it's not acceptable | ||||
Tags | No tags attached. | ||||
Commit Version | |||||
Fix Due Date | |||||
|
Part 6 - 6.6.4 clarifies that the certificate must be used for channel renewal. It is a spec change being requested - not a bug. A spec change that would break all existing implementations. "The RevisedLifetime tells the Client when it shall renew the SecurityToken by sending another OpenSecureChannel request. 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. The Server shall reject renew requests if the SenderCertificate is not the same as the one used to create the SecureChannel or if there is a problem decrypting or verifying the signature. The Client shall abandon the SecureChannel if the Certificate used to sign the response is not the same as the Certificate used to encrypt the request." |
|
Another issue with real-time applications. It relates to sequence numbers. Part 6: |
|
This issue was discussed at the WG meeting last month. There is a fix that we will not add to the spec now but it is a slight modification to the specification that can be added in the future. Right now the the Server implementations start sending messages secured with the new token right away. This is not technically required because the Server is required to keep accepting the old token until it expires or until the client sends a message with the new token. The Server can be changed to keep using the old token until it receives a message secured with a new token. This would allow the client to process the OpenSecureChannel response in the background. Note: the .NET implementation could handle servers that did this. The only reason not to change the spec now is we don't know if all stack implementations can handle this so you could change your applications to do this a test it out. The rule on sequence numbers can also be relaxed. |
|
May be v1.02? Perhaps, only two things are required:
|
|
Discussed in Dallas F2F meeting Proposed change in 5.5.2.1 Description Check with stack implementation if this is an issue and how they implement it today. |
|
Verify with ANSI C stack + JAVA stack how they behave |
|
Feedback ANSI C stack: Change would be not trivial but possible. Interoperability problems with existing ANSI C stack based clients are not expected. |
|
Feedback JAVA Stack: |
|
Changed should to shall Resolved in document IEC 62541-4 - Services [Pre-CDV] 1.02.06.doc |
|
Agreed to changes in doc in telecon. Awaiting 1.02 Errata to close the issue. |
|
Agreed to Errata changes. |
Date Modified | Username | Field | Change |
---|---|---|---|
2011-09-12 14:10 | Ustinov Vetcheslav | New Issue | |
2011-09-12 14:10 | Ustinov Vetcheslav | Found In Build | => 1.01.331 |
2011-09-12 15:02 | Randy Armstrong | Note Added: 0002938 | |
2011-09-12 15:46 | Randy Armstrong | Project | .NET Stack - DEPRECATED - USE GITHUB INSTEAD => 10000-006: Mappings |
2011-10-13 07:48 | Ustinov Vetcheslav | Note Added: 0003040 | |
2011-10-13 08:40 | Ustinov Vetcheslav | Note Edited: 0003040 | |
2011-10-13 10:34 | Randy Armstrong | Note Added: 0003041 | |
2012-01-13 17:41 | Karl Deiretsbacher | Project | 10000-006: Mappings => Feature Requests |
2012-01-13 17:47 | Karl Deiretsbacher | Assigned To | => Matthias Damm |
2012-01-13 17:47 | Karl Deiretsbacher | Status | new => acknowledged |
2012-04-18 07:37 | Ustinov Vetcheslav | Note Added: 0003595 | |
2013-10-09 23:20 | Matthias Damm | Status | acknowledged => assigned |
2013-10-09 23:21 | Jim Luth | Project | Feature Requests => 10000-004: Services |
2013-10-09 23:24 | Matthias Damm | Note Added: 0005045 | |
2013-10-09 23:25 | Matthias Damm | Note Added: 0005046 | |
2013-10-09 23:25 | Matthias Damm | Status | assigned => feedback |
2013-10-10 12:26 | Matthias Damm | Note Added: 0005047 | |
2013-10-11 01:03 | Matthias Damm | Note Added: 0005063 | |
2013-10-11 01:05 | Matthias Damm | Status | feedback => resolved |
2013-10-11 01:05 | Matthias Damm | Resolution | open => fixed |
2013-10-11 01:05 | Matthias Damm | Note Added: 0005064 | |
2013-11-25 18:07 | Jim Luth | Note Added: 0005143 | |
2013-12-10 17:22 | Jim Luth | Status | resolved => closed |
2013-12-10 17:22 | Jim Luth | Note Added: 0005182 | |
2013-12-10 17:22 | Jim Luth | Fixed in Version | => 1.02 |