[Openid-specs-risc] RISC Compromise Credential event

Tue Jul 19 00:28:25 UTC 2022

I think those are two separate but complementary discussions then, because the compromise credential scenario is not only about transmitting an identifier of the credential in a secure way, but also what information to transmit that the receiver can action upon (e.g. if the receiver doesn't have the plain text, a transmitted hashed password is unverifiable unless stored in the same hash format by the receiver).

As per your discussion and just as a pointer, secevents already denotes that SETs might contain sensitive information, but in the case of PII data those must be encrypted with JWEs or secured by other means [1].

Cheers,
Martin.

[1] https://datatracker.ietf.org/doc/html/rfc8417#section-5.1

From: Atul Tulshibagwale <atul at sgnl.ai>
Sent: Monday, July 18, 2022 8:25 PM
To: Martin Gallo <mgallo at secureauth.com>; Mark Haine <mark at considrd.consulting>
Cc: Jason Garbis <jagarbis at gmail.com>; openid-specs-risc at lists.openid.net
Subject: Re: [Openid-specs-risc] RISC Compromise Credential event

Thanks Jason and Martin for your thoughts and suggestions.

There's also a related concern from the eKYC working group (+Mark Haine<mailto:mark at considrd.consulting>) of not including sensitive information in CAEP events, and instead have the Receiver "check back" with the Transmitter.

I think the discussion we should really have is about how we can handle sensitive information in SSE events. Here are some choices:

  1.  Do we provide for a mechanism by which a Transmitter marks an event as having sensitive data, so that the Receiver can proactively obfuscate / prevent logging or other copying of such data
  2.  Do we specify that SSE events cannot contain sensitive information (e.g. PII or compromised password text) and require the Receiver to do work to fetch this information in a more secure way?
  3.  Do we specify that SSE events may always contain sensitive information, and the Receiver needs to ensure that information it receives from a Transmitter is handled with the same sensitivity and data protection policies that they apply to PII or other sensitive data?
Atul

On Mon, Jul 18, 2022 at 2:07 PM Martin Gallo <mgallo at secureauth.com<mailto:mgallo at secureauth.com>> wrote:
Hey all,
Just wanted to provide some feedback, at least from my perspective, as this topic was discussed when we introduced the Compromise Credential event, but not sure if ended correctly capture in the notes.

I think the "credential compromise" event is one of great value for Identity Providers and other services alike, but as mentioned it has some challenges. In particular, you want to signal that something happened (the compromise) to a particular subject, without revealing the credential itself. For some of the credential types, this is not a problem (e.g. a FIDO2 security key can be referenced by it's public identifier, an X.509 certificate by its serial number or fingerprint) but the problem is with bearer tokens and memorized secrets.

Main challenges IMHO are:
- Compromised credentials can be found in different formats, and the transmitter of the event not always might have it in a reversible format. For example, a data breach might contain users password hashes extracted from a compromised database (sometimes salted, sometimes not), while another data breach might directly contain the users' password in plain text. There might be even cases where the same data breach contains credentials that are store in different formats or using different algorithms.
- There receiver might not have the credential stored at all, or have it in a format that is not reversible and different from the one that the transmitter have.
- Identifying the exact credential (e.g. username and password combination) in the event is not possible without leaking information about the credential itself.

This is a known challenge and has been explored by both the academia as well as the industry, which has several security vendors providing these services with privacy-preserving protocols and mechanisms. A good paper that I like to use as reference is "Protocols for Checking Compromised Credentials" by Lucy Li et.al<http://et.al>. [1], in which the protocol and threat model for checking compromised credentials is formalized.

Going to Jason's point and the actual proposal, I think that having a standardized method to check compromised credentials that works in an interoperable way and covers the different scenarios in a privacy-preserving way is going to be very challenging. My suggestion is that, unless we want to enter into the burden of supporting a secure and privacy-preserving mechanism to actually identify the exact credential (which might be a little bit out of scope), we do keep the current specification of the event with the semantic of signaling that "a credential related to the subject identifier was compromised". The validation of the credential can be provided by the transmitter as a separate or related service, but using a check protocol that provides the aforementioned guarantees. BTW, VeriClouds demo'ed their implementation (with two separate API calls) at the March 22nd SSE WG meeting [2].

Bests,
Martin.

[1] https://dl.acm.org/doi/10.1145/3319535.3354229
[2] https://hackmd.io/@oidf-wg-sse/wg-meeting-2022_03_22#VeriClouds-demo

From: Openid-specs-risc <openid-specs-risc-bounces at lists.openid.net<mailto:openid-specs-risc-bounces at lists.openid.net>> On Behalf Of Jason Garbis via Openid-specs-risc
Sent: Thursday, July 14, 2022 4:33 PM
To: Atul Tulshibagwale <atul at sgnl.ai<mailto:atul at sgnl.ai>>
Cc: openid-specs-risc at lists.openid.net<mailto:openid-specs-risc at lists.openid.net>
Subject: Re: [Openid-specs-risc] RISC Compromise Credential event

Thanks Atul - here's a recap, and an idea for discussion around the the RISC Credential Compromise event

Atul's notes:

Proposal

We should include a "password verifier" field in the Compromise Credential event.

The verifier should contain the digest of the password

A separate field should contain an indicator of the algorithm used to compute the digest

Issues

How can the Transmitter and Receiver agree on the algorithm?

Is it feasible to send the verifier without knowing the "salt" value

Use Case: A service provider discovers an alleged credential (username/password combination) in an untrustworthy location (e.g.  a Dark Web repository).  This credential is for a specific identity and may be claimed to be for a specific service - let's say it's for DarthVader at Comcast.net<mailto:DarthVader at Comcast.net> and the alleged password is "Th3DarkS1deR0cks". In this example, our user Darth likely uses his Comcast email as the identifier for many online services (bank, health club, etc), so this credential is actually for an unknown site or sites. (The compromise may or may not identify the service for which this credential is supposedly valid e.e. EmpireBank). If Darth has poor password security practices, he may in fact reuse this password across multiple sites.

The service provider here wants to emit an event that this credential has been compromised, but wants to to avoid transmitting this password as cleartext.

Problem: How can the transmitter securely convey the password to the receiver for validation and necessary action? It feels wrong to rely on only transport security to encrypt the password, since it's entirely likely that the event will be logged or examined during its transmission.

Approach: The transmitter should be able to obfuscate the password in a receiver-specific way, so that only the intended receiver can access it.

First idea:  Assumption: Receiver only stores the hashed password value. Could the transmitter hash the password, and only send the hashed value to the receiver?

Issue: This would require that the the receiver inform the transmitter of its hashing algorithm and salt mechanism, which is not information that should be shared

Second Idea: The receiver provides a public key to the transmitter as part of a (to-be-specified) registration or stream setup process. The transmitter then uses this key to encrypt the password within the event. Only the intended receiver has the corresponding private key, so the password is obfuscated in transit.  The receiver can then decrypt the password, and then hash it (as needed) to compare it to its stored value, without having to share anything about its hashing mechanism.

Thoughts? How much of a can of worms does this open up, in terms of now needing to specify a stream creation and registration protocol? Or, would it be sufficient for us to recommend that the credential SHOULD be obfuscated, and that the mechanism for that is (for now) out of scope for the spec?

On Tue, Jul 12, 2022 at 7:19 PM Atul Tulshibagwale via Openid-specs-risc <openid-specs-risc at lists.openid.net<mailto:openid-specs-risc at lists.openid.net>> wrote:
Hi all,
A couple of weeks ago, I had agreed to write up the issue regarding the compromise credential event in RISC. Here's the little note: https://hackmd.io/eDzKdeVITr22DNcw7FRt1Q?view

I think Jason Garbis has some interesting suggestions on how we can solve the issue that hashing the password requires the salt value, which is not with the Transmitter in this case. Jason, would you care to comment?

Thanks,
Atul

_______________________________________________
Openid-specs-risc mailing list
Openid-specs-risc at lists.openid.net<mailto:Openid-specs-risc at lists.openid.net>
https://lists.openid.net/mailman/listinfo/openid-specs-risc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20220719/84ba3dbf/attachment-0001.html>