[Openid-specs-risc] "Credential compromise" event discussion tomorrow
Stan Bounev
stanb at vericlouds.com
Mon Mar 15 19:42:33 UTC 2021
Ahead of our meeting tomorrow, I want to solicit feedback on the scope of the ‘credential compromised’ use case.
The issue in question is if we should have a use case where an IdP is sending ‘credential compromised’ event to the receiving party (currently, the main use case is threat intel company sending such event – should an IdP be able to send it too). The concern is that there might be interoperability issue as each IdP has its own criteria for considering a credential as compromised. The other argument is that we shouldn’t prescribe when an IdP should consider a credential compromised as this is currently the case with other events such as ‘session revoked.’ More details in the email below. Let me know what you think.
Thanks,
Stan
From: Openid-specs-risc <openid-specs-risc-bounces at lists.openid.net> on behalf of Stan Bounev via Openid-specs-risc <openid-specs-risc at lists.openid.net>
Date: Tuesday, March 9, 2021 at 11:01 AM
To: Tim Cappalli <Tim.Cappalli at microsoft.com>, atultulshi at google.com <atultulshi at google.com>, openid-specs-risc at lists.openid.net <openid-specs-risc at lists.openid.net>
Subject: Re: [Openid-specs-risc] "Credential compromise" event discussion tomorrow
Annabelle, thanks for your input on ‘credential compromise’ during the meeting. I see your point about potential interoperability issue with the first use case below. For the people who were not able to join today, your argument was that some IdPs could be ‘trigger happy’ and send the ‘credential compromise’ event too often versus other IdPs that are conservative.
The receiving party will be the one to decide how to implement it. The vulnerability and other security systems allow to weigh/prioritize alerts. In the actual implementation, the receiving party can dial up or down the alerts from a given IdP based on the history with that IdP.
Additional point that Tim raised, is that the IdP is the authoritative party. When an IdP blocks, ask for a step-up authn or something else, the receiving party does not question or ask for clarification.
In terms of interoperability, the ‘credential compromise’ seem to be similar to the ‘session revoked’ event. In the latter event, the session is revoked based on the heuristics of the ‘admin’ (as per the event description). Most common reasons for session revoked include compromised accounts, employee termination, and other insider threats. Those are not strictly defined in our spec and an ‘admin’ or IdP could terminate a session based on heuristics.
I see three paths forward:
1. Define the criteria for a credential to be compromised and for a session to be revoked.
2. Drop the two use cases #1 and #3 below and just keep use case #2.
3. Do nothing. Include the ‘credential-compromise’ as is and leave it the SE to determine how to treat the events by each IdP.
Let me know what you think.
Stan
From: Openid-specs-risc <openid-specs-risc-bounces at lists.openid.net> on behalf of Stan Bounev via Openid-specs-risc <openid-specs-risc at lists.openid.net>
Date: Tuesday, March 9, 2021 at 9:43 AM
To: Tim Cappalli <Tim.Cappalli at microsoft.com>, atultulshi at google.com <atultulshi at google.com>, openid-specs-risc at lists.openid.net <openid-specs-risc at lists.openid.net>
Subject: Re: [Openid-specs-risc] "Credential compromise" event discussion tomorrow
Atul, thanks for putting this at the beginning of the meeting.
This event is similar to the ‘credential change’ event and the others we have in the spec. There are three main uses cases for the ‘credential-compromise’ event (not in order of importance):
1. IdP considers an account as compromised based on policies – e.g. user logs in from two US and China within two min; anomaly detection tools also acknowledge compromise or any other way. In this case, IdP sends ‘credential compromise’ event to admin of that domain. Our VeriClouds are hosed by O365. O365 will send notification to the user trying to log in, but I’d like also get information in my security tools.
2. Third party credential monitoring service (CMS) or threat intel service finds compromised credentials for a client of theirs. The CMS sends ‘compromised credential’ event to the client.
3. App authenticating uses finds an account as compromised based on policies – e.g. user logs in from two US and China within two min; anomaly detection tools also acknowledge compromise or any other way. The App sends the ‘credential compromise’ event to the admin (or security tools) of user domain. For example, Box.com determines a Quickbooks.com credential as compromised. Box.com sends ‘credential compromise’ event to Quickbooks. Quickbooks investigates recent activity. The difference with the first use case is that Box.com is not an IdP.
Below is the revised event. Tim, thanks for the input.
{
"iss": "https://idp.example.com/3456790/",
"jti": "756E69717565206964656E746966696572",
"iat": 1508184845,
"aud": "https://sp.example2.net/risc",
"events": {
"https://schemas.openid.net/secevent/risc/event-type/credential-compromise": {
"subject": {
"subject_type": "email",
"sub": "joe.smith at example.com<mailto:joe.smith at example.com>"
},
"reason_admin": "Email found as compromised.",
"reason_user": "The credential associated with this account has been compromised."
}
}
}
From: Tim Cappalli <Tim.Cappalli at microsoft.com>
Date: Tuesday, March 2, 2021 at 11:22 AM
To: atultulshi at google.com <atultulshi at google.com>, openid-specs-risc at lists.openid.net <openid-specs-risc at lists.openid.net>, Stan Bounev <stanb at vericlouds.com>
Subject: Re: [Openid-specs-risc] "Credential compromise" event discussion tomorrow
Atul - let's put this on the top of the list for next Tuesday since we keep running out of time.
tim
________________________________
From: Openid-specs-risc <openid-specs-risc-bounces at lists.openid.net> on behalf of Stan Bounev via Openid-specs-risc <openid-specs-risc at lists.openid.net>
Sent: Tuesday, March 2, 2021 02:29
To: Atul Tulshibagwale <atultulshi at google.com>; Openid-specs-risc <openid-specs-risc at lists.openid.net>
Subject: Re: [Openid-specs-risc] "Credential compromise" event discussion tomorrow
Hi all,
I’d like to add for discussion tomorrow the “credential compromise” event. I’d like to get feedback. See below.
Thanks,
Stan
<section anchor="credential-compromise-examples" title="Examples">
<t>NOTE: The event type URI is wrapped, the backslash is the continuation character.</t>
<t>Credential Compromised signals that the identifier specified in the subject was found to be compromised. The subject type MUST be either <spanx style="verb">email</spanx> or <spanx style="verb">phone</spanx>.</t>
<figure title="Example: Compromised credential found" anchor="credential-compromise-example"><artwork type="json"><![CDATA[
{
"iss": "https://idp.example.com/3456790/",
"jti": "756E69717565206964656E746966696572",
"iat": 1508184845,
"aud": "https://sp.example2.net/caep",
"events": {
"https://schemas.openid.net/secevent/risc/event-type/credential-compromise": {
"subject": {
"subject_type": "iss-sub",
"iss": "https://idp.example.com/3456790/",
"sub": "joe.smith at example.com"
},
"credential-compromise-id": "email", “phone”
}
}
}
-</sourcecode>
-</figure>
+]]></artwork></figure>
+
</section>
From: Openid-specs-risc <openid-specs-risc-bounces at lists.openid.net> on behalf of Atul Tulshibagwale via Openid-specs-risc <openid-specs-risc at lists.openid.net>
Date: Monday, February 22, 2021 at 5:51 PM
To: Openid-specs-risc <openid-specs-risc at lists.openid.net>
Subject: Re: [Openid-specs-risc] "Compound" subject types in SSE
Hi all,
A quick reminder to please review this proposal and provide your feedback and / or comments. It'll be good to review the feedback in the call on Tuesday next week.
Thanks,
Atul
On Tue, Feb 16, 2021 at 12:22 PM Atul Tulshibagwale <atultulshi at google.com<mailto:atultulshi at google.com>> wrote:
Hi all,
We discussed an important topic on the call today, and some of us had separately discussed this earlier. There are a couple of issues with the draft today:
1. The use of "common claims" e.g. "spag_id" conflicts with the Subject Identifiers draft that specifies claims other than those defined within the "subject_type" definition must not be included in a subject claim of that subject_type.
2. We defined a specific "user-device-session" subject type, but are now discovering use cases that create a multitude of other possibilities. The immediate one that caused this discussion was the use of an "application" principal. The use case is where a Transmitter may want to invalidate sessions associated with a specific application on a specific user or device.
To address both these issues, Tim Cappalli (Microsoft) and I came up with this proposal to create multi-valued or "compound" subject claims in SSE events. This will not require the use of common claims such as "spag_id", but we can create specific new subject_types such as "tenant" or "OU" as needed.
Please review the proposal here<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1stTI18cQy8zTw0u0UjC6NLkjBZAYEU1kNCDru7dEdfQ%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Ctim.cappalli%40microsoft.com%7C9c0850397ac343f8ef4708d8dd6a5545%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637502796686207774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bdx%2Be4KTrJUFY9U5SXP95v2hH4ZpSEvhCC5YIDYT6ig%3D&reserved=0>. It will be great if you can provide your comments and feedback in the next couple of weeks so that we can have a productive discussion in our next call on March 2nd. If we can make sufficient progress in the call there, we can incorporate the changes into the draft.
Thanks,
Atul
[https://lh6.googleusercontent.com/fmoDQ26Qu6nUCxkO3-_idifYd4drGNvt7Ab_LQBqsdPH7EwOjHOqIJRzGXtqFHoor0bKiVZNFnj86FL59uqJJ1_-mSVOlfdsnlvDYTpq0wfcQFDXJr7miiOpLOie6c-pxXWWqpFqRg]
Atul Tulshibagwale
Software Engineer,
Google Workspace
atultulshi at google.com<mailto:atultulshi at google.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20210315/5ff8d687/attachment-0001.html>
More information about the Openid-specs-risc
mailing list