View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0008938 | 10000-002: Security | Spec | public | 2023-05-05 13:31 | 2023-11-14 16:13 |
Reporter | V. Monfort | Assigned To | Paul Hunkar | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | no change required | ||
Product Version | 1.04 | ||||
Fixed in Version | 1.05.03 | ||||
Summary | 0008938: Part 4 §6.1.3 should indicate that the error reported by the server to the client is Bad_SecurityChecksFailed for all steps | ||||
Description | Part 4 (v1.04) table 106 contains several items where it is not indicated that Server shall report Bad_SecurityChecksFailed to the Client instead of the detailed status. But it should be the cases due to additional information provided by Part 2 and Part 6. Indeed, in Part 2 §6.3 indicates: Thus no specific error code should be returned prior to secure channel establishment and then for the certificate validation steps during establishment. In addition, in Part 6 §6.7.6 it is indicated: This section only indicates reporting Bad_SecurityChecksFailed error code and that secured error responses can only be sent after establishment. In my opinion the Part 4 §6.1.3 should be modified to indicate that the server shall only report to client SecurityChecksFailed for every step it is missing. In addition, the following sentence might be modified to reflect that the server does not return the error status to the client but should log it: And we might want to add the sentence of Part 2 in an appropriate section of Part 4, may be the Secure Channel service section (§5.5.1) ? Moreover UACTT certificate validation tests should check for Bad_SecurityChecksFailed error, might display a warning if specific error code is reported to client and specific error codes might be checked manually in logs. Note: this subject was originally discussed in the OPC Foundation forum leading to the same conclusion on expected behavior of Server: | ||||
Tags | No tags attached. | ||||
Commit Version | 1.05.03 | ||||
Fix Due Date | 2023-09-01 | ||||
related to | 0008976 | closed | Paul Hunkar | 10000-002: Security | Security level evaluation of the updated certificates compared to the endpoint should be specified |
related to | 0008968 | closed | Randy Armstrong | 10000-004: Services | Part 4 §6.1.3 should indicate that the error reported by the server to the client is Bad_SecurityChecksFailed for all steps |
|
Security sub-group needs to provide recommendation for solution. Please invite the submitter to a meeting. |
|
It is not clear what this sentence means: In my opinion the Part 4 §6.1.3 should be modified to indicate that the server shall only report to client SecurityChecksFailed for every step it is missing. What does "missing" mean in this context? |
|
Sorry if it was not clear enough. I mean that for each row of table 106, "Bad_SecurityChecksFailed" should always be present as possible error in "Error/AuditEvent" column and the following sentence should always be present in the "Description" column: "If this check fails on the Server side, the error Bad_SecurityChecksFailed shall be reported back to the Client." Therefore, it concerns the following steps for which the generic error Bad_SecurityChecksFailed is not mentioned: Validity Period, Host Name, URI, Certificate Usage, Find Revocation List. Note: for the "Revocation Check" step it is mentioned that Bad_SecurityChecksFailed shall be reported by the Server in the Description but the error code is not present in the Error/AuditEvent column. |
|
The Bad_SecurityChecksFailed code exists to prevent exploits related to cryptography operations. It is expected to be combined with constant time algorithms that protect against timing attacks (i.e. attacks that deduce the reason for an error from the time it takes to return the error). Extending the Bad_SecurityChecksFailed to non-cryptography operations would not add security but would adversely impact interoperability because the client would not get timely feedback the reason for the failure. This is particularly true for errors which are known to the client if they paid attention (i.e. expired certificates or bad URIs). |
|
The Part 2 text is inconsistent with Part 4 and the Security WG decided that the Part 2 should change. i.e. should change to |
|
Updated text to reflect requested change |
|
Agreed to changes edited in web meeting. |
Date Modified | Username | Field | Change |
---|---|---|---|
2023-05-05 13:31 | V. Monfort | New Issue | |
2023-05-09 17:03 | Jim Luth | Note Added: 0019304 | |
2023-05-09 17:03 | Jim Luth | Assigned To | => Randy Armstrong |
2023-05-09 17:03 | Jim Luth | Status | new => assigned |
2023-05-09 17:04 | Jim Luth | Note Edited: 0019304 | |
2023-05-13 08:38 | Randy Armstrong | Status | assigned => feedback |
2023-05-13 08:38 | Randy Armstrong | Note Added: 0019367 | |
2023-05-15 08:17 | V. Monfort | Note Added: 0019370 | |
2023-05-15 08:17 | V. Monfort | Status | feedback => assigned |
2023-05-15 11:28 | Randy Armstrong | Status | assigned => resolved |
2023-05-15 11:28 | Randy Armstrong | Resolution | open => fixed |
2023-05-15 11:28 | Randy Armstrong | Note Added: 0019372 | |
2023-05-15 11:29 | Randy Armstrong | Status | resolved => assigned |
2023-05-15 11:29 | Randy Armstrong | Status | assigned => resolved |
2023-05-15 11:29 | Randy Armstrong | Resolution | fixed => no change required |
2023-05-17 15:10 | Randy Armstrong | Project | UA Specification => 10000-002: Security |
2023-05-17 15:13 | Randy Armstrong | Status | resolved => confirmed |
2023-05-17 15:13 | Randy Armstrong | Note Added: 0019396 | |
2023-05-17 15:18 | Randy Armstrong | Issue cloned: 0008968 | |
2023-05-26 14:57 | Paul Hunkar | Relationship added | related to 0008976 |
2023-05-26 14:57 | Paul Hunkar | Assigned To | Randy Armstrong => Paul Hunkar |
2023-05-26 14:57 | Paul Hunkar | Status | confirmed => assigned |
2023-06-06 15:24 | Jim Luth | Relationship added | related to 0008968 |
2023-07-25 16:07 | Jim Luth | Commit Version | => 1.05.03 |
2023-07-25 16:07 | Jim Luth | Fix Due Date | => 2023-09-01 |
2023-11-07 16:22 | Paul Hunkar | Status | assigned => resolved |
2023-11-07 16:22 | Paul Hunkar | Fixed in Version | => 1.05.03 |
2023-11-07 16:22 | Paul Hunkar | Note Added: 0020290 | |
2023-11-14 16:13 | Jim Luth | Status | resolved => closed |
2023-11-14 16:13 | Jim Luth | Note Added: 0020356 |