View Issue Details

IDProjectCategoryView StatusLast Update
001026610000-004: ServicesSpecpublic2025-11-12 16:57
ReporterBernd Edlinger Assigned ToRandy Armstrong  
PrioritynormalSeveritymajorReproducibilityhave not tried
Status assignedResolutionopen 
Product Version1.05.04 
Summary0010266: CreateSessionResponse shold not always drop the Certificates
Description

From the recent ECC IOP workshop I have learned that some
vendors do already support multiple certificates on a single endpoint.

But there is a problem with the specification of the CreateSessionResponse,
which says that CreateSessionResponse-.serverEndpoints
shall only have only.applicationUri, endpointUrl, securityMode, securityPolicyUri,
userIdentityTokens, transportProfileUri and securityLevel with all other parameters
set to null or empty.

The client is supposed to check that the prior unencrypted GetEndpointsResponse
was not modified by MITM attacks.

But that assumed that the server does only have one certificate.
But when the server has multiple certificates, an attacker can either replace
some trusted certificate with an untrusted one, or a trusted one that does not
meet the securityPolicy requirements, in order to make the client choose a
less secure encryption.

The spec should be amended, that only those serverCertificates can be omitted that
do match the server certificate of the secure channel, any certificate that does
not match the secure channel's server certificate should not be set to zero,
and the client should only ignore empty certificates but check any non-empty
certificate to be identical as returned in the GetEndpointsResponse.

That should hopefully be an upward compatible change, that prevents this
potential security leak.

Tagssg.Security
Commit Version
Fix Due Date

Activities

Randy Armstrong

2025-04-09 15:19

administrator   ~0022624

Discussed in meeting. There is a potential downgrade attack possible because of the missing certificate.
But changing it now could introduce IOP problems.
Maybe just say that ECC certificates need to be returned.

Randy Armstrong

2025-04-09 15:20

administrator   ~0022625

Option require certificate when ECC and not used for current SecureChannel.

Bernd Edlinger

2025-10-22 05:20

reporter   ~0023480

Can we please make this mandatory for the new Security-Enhanced profiles?

Randy Armstrong

2025-11-12 16:34

administrator   ~0023530

Last edited: 2025-11-12 16:57

Risk: a downgrade attack can be triggered by putting bad certificates in the endpointdescriptions for high security policies.

Clients would only discover the bad certificate after choosing an endpointdescription. We need to dcoument what a client should do in this case:

1) Warn user that it is using a lower security because of a bad certificates (confirm/continue prompt?)
2) After establishing a securechannel call GetEndpoints before calling CreateSession to check if a MIM messed with the high security policies. If difference - report attack.
3) If same then continue with lower security policy.

Note: this only applies to client that actually attempt a fallback after certificate validation failure. Clients that always abort if the first choice has an invalid certificate would not have this risk.

Randy Armstrong

2025-11-12 16:48

administrator   ~0023531

Add a flow chart that shows the connection process with three paths:
green - no errors,
yellow - errors on first choice but not on second choice,
red - any material mismatch between endpoints returned after securechannel established and the set the client got with no security.

Issue History

Date Modified Username Field Change
2025-04-03 08:38 Bernd Edlinger New Issue
2025-04-09 15:19 Randy Armstrong Note Added: 0022624
2025-04-09 15:20 Randy Armstrong Note Added: 0022625
2025-07-22 16:55 Jim Luth Tag Attached: sg.Security
2025-07-22 16:57 Jim Luth Assigned To => Randy Armstrong
2025-07-22 16:57 Jim Luth Status new => assigned
2025-10-22 05:20 Bernd Edlinger Note Added: 0023480
2025-11-12 16:34 Randy Armstrong Note Added: 0023530
2025-11-12 16:48 Randy Armstrong Note Added: 0023531
2025-11-12 16:57 Randy Armstrong Note Edited: 0023530