<html xmlns:v="urn:schemas-microsoft-com:vml" 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;}
/* 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.EmailStyle22
{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:1424375886;
mso-list-type:hybrid;
mso-list-template-ids:293112182 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:2118745633;
mso-list-template-ids:928401282;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<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:"Segoe UI Emoji",sans-serif">😊</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><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#00B5E2"><o:p></o:p></span></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<o:p></o:p></span></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:l0 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:l0 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:l0 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>