View Issue Details

IDProjectCategoryView StatusLast Update
000893810000-002: SecuritySpecpublic2023-11-14 16:13
ReporterV. Monfort Assigned ToPaul Hunkar  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionno change required 
Product Version1.04 
Fixed in Version1.05.03 
Summary0008938: 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:
"Error codes can be used as an attack vector, thus their uses should be limited as described in Part 4.
Part 4 describes that a single generic error is returned before and during the establishment of a secure channel.
Once the secure channel has been established then appropriate specific error codes are returned."

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:
"If decryption or signature validation fails, then a Bad_SecurityChecksFailed error is reported.
[...]
At this point the SecureChannel knows it is dealing with an authenticated Message that was not tampered with or resent.
This means the SecureChannel can return secured error responses if any further problems are encountered."

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:
"Each validation step has a unique error status and audit event type that shall be reported if the check fails."

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) ?
"A single generic error [Bad_SecurityChecksFailed] is returned before and during the establishment of a secure channel.
Once the secure channel has been established then appropriate specific error codes are returned."

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:
https://opcfoundation.org/forum/opc-ua-standard/error-codes-management-during-the-establishment-of-a-secure-channel/

TagsNo tags attached.
Commit Version1.05.03
Fix Due Date2023-09-01

Relationships

related to 0008976 closedPaul Hunkar 10000-002: Security Security level evaluation of the updated certificates compared to the endpoint should be specified 
related to 0008968 closedRandy 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 

Activities

Jim Luth

2023-05-09 17:03

administrator   ~0019304

Last edited: 2023-05-09 17:04

Security sub-group needs to provide recommendation for solution. Please invite the submitter to a meeting.

Randy Armstrong

2023-05-13 08:38

administrator   ~0019367

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?

V. Monfort

2023-05-15 08:17

reporter   ~0019370

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.

Randy Armstrong

2023-05-15 11:28

administrator   ~0019372

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).

Randy Armstrong

2023-05-17 15:13

administrator   ~0019396

The Part 2 text is inconsistent with Part 4 and the Security WG decided that the Part 2 should change.

i.e.
no specific error code should be returned prior to secure channel establishment and then for the certificate validation steps during establishment.

should change to
the error codes specified in Part 4 shall be returned during secure channel establishment and certificate validation steps.

Paul Hunkar

2023-11-07 16:22

developer   ~0020290

Updated text to reflect requested change

Jim Luth

2023-11-14 16:13

administrator   ~0020356

Agreed to changes edited in web meeting.

Issue History

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