<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Apple Color Emoji";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:883755961;
mso-list-template-ids:-254501186;}
@list l1
{mso-list-id:1254507660;
mso-list-type:hybrid;
mso-list-template-ids:52739736 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2
{mso-list-id:1424375886;
mso-list-type:hybrid;
mso-list-template-ids:293112182 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l2:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><i>This thread is about use case A) – a credential is found on the dark web. I will send a separate email about the other use case B) -
</i><i>Transmitter considers cred compromised based on their heuristic.<o:p></o:p></i></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Matt, all good questions. Responses below:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo4">Is the service de-duping scan results on its end? <o:p></o:p></li><ol style="margin-top:0in" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level2 lfo4">Yes, the identity threat intelligence services dedupe the data. They also maintain time stamps, such as ‘first seen,’ and ‘last seen.’ Of the services I’m familiar with all of them
dedupe the data.<o:p></o:p></li></ol>
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo4">Would you emit the plaintext password in the event? <o:p></o:p></li><ol style="margin-top:0in" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level2 lfo4">Based on the previous discussions in the group we decided not to cover the password transmission as part of this spec, but to leave it up to the transmitting and receiving parties
to enter separate agreement that defines a method for transmission of the password. If a receiving party thinks information about the user name is sufficient there will be no need for such additional agreement. Our company’s recommendation is to factor the
password as part of the decision. There are several methods this can be done. If there is an interest in the group, I can explain.<o:p></o:p></li></ol>
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo4">I presume the event would include an event_timestamp value.<o:p></o:p></li><ol style="margin-top:0in" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level2 lfo4">This is a good suggestion. I will add it to the event code. It will be helpful in the case where the receiving party is not factoring passwords. If the process factors passwords then
this attribute will have less value as ‘there are no old passwords – only those that work and those that don’t.’<o:p></o:p></li></ol>
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo4">I presume the event would include an event_timestamp value<o:p></o:p></li><ol style="margin-top:0in" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level2 lfo4">Yes, there will be event timestamp. It will need to have the value of ‘first seen.’ We also need to have a value for ‘last seen.’ Such info will be able to show how far ago this credential
ceased to exist. If it is still available the current date will be used.<o:p></o:p></li></ol>
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo4">Would applications be able to subscribe to events for all sites, or just those proven to be “theirs”? <o:p></o:p></li><ol style="margin-top:0in" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level2 lfo4">Applications will be able to subscribe to events for their domains. For example, Salesforce.com will be able to subscribe for events related to salesforce.com domain across all data
breaches. This will cover salesforce.com employees who created accounts in third party services that got breached.<o:p></o:p></li></ol>
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo4">Would IDPs be able to subscribe to events for all email addresses, or just those proven to be “theirs”? <o:p></o:p></li><ol style="margin-top:0in" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level2 lfo4">IdPs can subscribe only their own domains. There is no legitimate reason for Yahoo.com to get the ‘credential compromise’ event for gmail.com domain.<o:p></o:p></li></ol>
</ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I hope I was able to address your questions. Feel free to ask clarifying questions and thanks for the time stamp suggestion.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Stan<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Openid-specs-risc <openid-specs-risc-bounces@lists.openid.net> on behalf of Matt Domsch via Openid-specs-risc <openid-specs-risc@lists.openid.net><br>
<b>Date: </b>Tuesday, March 16, 2021 at 1:05 PM<br>
<b>To: </b>openid-specs-risc@lists.openid.net <openid-specs-risc@lists.openid.net><br>
<b>Subject: </b>Re: [Openid-specs-risc] "Credential compromise" event discussion tomorrow<o:p></o:p></span></p>
</div>
<p class="MsoNormal">Stan, I have reservations about the practicality of use case A) – a credential is found on the dark web, I need to inform applications within the security mesh about this. Perhaps your use case elaboration can clarify this for me.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">In this scenario, a security service is doing scans of various sites, and (e.g. January 1, 2021) comes across a trove of compromised credentials – say usernames, email address, and plaintext passwords, and the site from which each was exfiltrated.
The service then publishes a “RISC - Credential Compromised” event to subscribers, including identity providers and applications that wish to be aware of such, for which an explicit trust relationship with the security service is established a priori.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Is the service de-duping scan results on its end? There are tons of copies of these troves scattered around. If each time a new trove is found with the same (stale) info as before, it would (incorrectly) generate a new event for all other
actors to deal with.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Would you emit the plaintext password in the event? Without this (or including all possible salted hashed password values in the event for all hash algorithms, ugh!), a service has no way of knowing if the current password for this account
matches, or if the user has rotated their password in the intervening time (perhaps years – I still get phishing attacks with a very old LinkedIn passwords from the 2012 exfiltration). At the same time, emitting plaintext passwords is really poor form.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I presume the event would include an event_timestamp value (following the CAEP model) for when the service believed the credential was compromised, perhaps when the scan first found it, but not updated to now() every time a scan found it
still present. A receiver could then use this, assuming it also tracked timestamps of each credential change – not necessarily true – to ignore events that occurred earlier than the most recent credential change.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Without these protections, if it were to emit an event on every scan, “yes, this credential is still compromised”, receivers would see that the account, even if no longer compromised, and be expected to either de-dupe these themselves,
or force the user through a painful reset process every few hours (scan timeframe). That would feel like a denial-of-service attack.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">If multiple security service companies are doing these scans, by definition separately, a subscriber to more than one service would get duplicated events, and would have to de-duplicate them themselves somehow. I suppose that’s a point
for vendor lock-in. <span style="font-family:"Apple Color Emoji"">😊</span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Would applications be able to subscribe to events for all sites, or just those proven to be “theirs”? For the password reuse concern, they may want to get them for “all sites”. But that is a huge privacy hole then – unrelated 3<sup>rd</sup>
party sites would then be made aware that at least the user once had account on the other site.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Would IDPs be able to subscribe to events for all email addresses, or just those proven to be “theirs”? For corporate-owned email addresses, this would seem to work – the IDP could then emit other events to revoke sessions and the like.
For large consumer email address domains such as yahoo.com, gmail.com, outlook.com, this is again a huge privacy concern especially when a user will rarely be using SSO into downstream applications using these email addresses. Similarly, not all corporate-owned
applications have SSO enabled. One can dream… <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I’m hoping that you have protections outside the definition of the event that address these concerns, and likely many more I haven’t thought about. I’d love to hear about them.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Matt<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Matt Domsch</span></b><span style="font-family:"Arial",sans-serif"><br>
</span><i><span style="font-size:9.0pt;font-family:"Arial",sans-serif">VP, Engineering Fellow</span></i><span style="font-size:9.0pt;font-family:"Arial",sans-serif"><br>
</span><a href="mailto:matt.domsch@sailpoint.com"><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#00B5E2">matt.domsch@sailpoint.com</span></a><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">mobile: 512-981-6486</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#00B5E2">
</span><span style="font-family:"Arial",sans-serif"><br>
</span><a href="http://www.sailpoint.com/"><b><span style="font-size:8.0pt;font-family:"Arial",sans-serif;color:#00B5E2">www.sailpoint.com</span></b></a><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Openid-specs-risc <openid-specs-risc-bounces@lists.openid.net> on behalf of Stan Bounev via Openid-specs-risc <openid-specs-risc@lists.openid.net><br>
<b>Date: </b>Tuesday, March 9, 2021 at 11:01 AM<br>
<b>To: </b>Tim Cappalli <Tim.Cappalli@microsoft.com>, atultulshi@google.com <atultulshi@google.com>, openid-specs-risc@lists.openid.net <openid-specs-risc@lists.openid.net><br>
<b>Subject: </b>Re: [Openid-specs-risc] "Credential compromise" event discussion tomorrow</span><o:p></o:p></p>
</div>
<p class="MsoNormal">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.
<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">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.
<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I see three paths forward:<o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo3">Define the criteria for a credential to be compromised and for a session to be revoked.<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo3">Drop the two use cases #1 and #3 below and just keep use case #2.<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo3">Do nothing. Include the ‘credential-compromise’ as is and leave it the SE to determine how to treat the events by each IdP.<o:p></o:p></li></ol>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Let me know what you think.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Stan<o:p></o:p></p>
</div>
</body>
</html>