<HTML>
<HEAD>
<TITLE>Re: [security] Nonrepudiation, and Trusting OpenID Providers</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>John & Andrew,<BR>
<BR>
That you both for your interesting responses and pointers. <BR>
<BR>
Andrew, you said:<BR>
</SPAN></FONT><BLOCKQUOTE><SPAN STYLE='font-size:11pt'><FONT COLOR="#0000FE"><FONT FACE="Arial">your question moves past the security issues associated with the protocol and addresses trust issues in the ecosystem. As John indicated, at the current assurance levels and resulting appropriate usage scenarios, OpenID deployment and the trust levels associated with OP's are probably sufficient.<BR>
<BR>
</FONT></FONT></SPAN></BLOCKQUOTE><SPAN STYLE='font-size:11pt'><FONT FACE="Calibri, Verdana, Helvetica, Arial">And John said:<BR>
</FONT></SPAN><BLOCKQUOTE><SPAN STYLE='font-size:11pt'><FONT FACE="Calibri, Verdana, Helvetica, Arial">Given that openID is only secure enough as a protocol for ICAM LoA 1 (pseudonymous protecting no PII) the most practical path is to provide more trustable OP/IdP.<BR>
</FONT></SPAN></BLOCKQUOTE><SPAN STYLE='font-size:11pt'><FONT FACE="Calibri, Verdana, Helvetica, Arial"><BR>
I think you both are saying that, for what OpenID is intended to do, it works. In other words, OpenID can be used if we can assume that the supported identity providers are honest. I cannot understand why we should have to make that assumption at all. There are well-supported technologies like PKI that provide identification, authentication, and even nonrepudiation without forcing us to put a very large amount of trust in a 3rd party.<BR>
<BR>
Indeed, my point is that OpenID forces us to put a <B>lot</B> of trust in the identity provider: we trust them with the ability to access our RP accounts, and we trust them with the knowledge of the fact that we use these RP services. Just like most attacks, the probability that a provider (or employee thereof) will behave dishonestly is low (but certainly not negligible) --- but I should not have to take that chance. <BR>
<BR>
You might counter that we already put a lot of trust in organizations (that is, potential RPs) --- for example, banks --- so why shouldn’t we also trust an identity provider? That is true, but there is a difference. When I trust bank A, my trust is limited to the cash I give it and the credit accounts I have open with it. When I trust bank B, my trust covers only the accounts I have with that bank. When I trust Amazon.com, I trust it only with the information of one credit card. When I trust my email provider, I trust them only with the email associated with that account. The risk is limited in each case. Now, imagine that I use OpenID to log into all four of those services: I am now trusting my identity provider with all four aspects of my life.<BR>
<BR>
Charles<BR>
<BR>
<BR>
On 12/9/09 8:18 AM, "Nash, Andrew" <<a href="annash@paypal.com">annash@paypal.com</a>> wrote:<BR>
<BR>
</FONT></SPAN><BLOCKQUOTE><SPAN STYLE='font-size:11pt'><FONT COLOR="#0000FF"><FONT FACE="Arial">Charles,<BR>
</FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">your question moves past the security issues associated with the protocol and addresses trust issues in the ecosystem. As John indicated, at the current assurance levels and resulting appropriate usage scenarios, OpenID deployment and the trust levels associated with OP's are probably sufficient.<BR>
</FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">The operating principals, policies controlling activities and personnel, audit trails and verifiable operation by third parties are all aspects to resolving the question you address. IFF you are dealing with low assurance credentials and low value transactions, then as David identifies it probably matters less and their are many alternative problems you could face from your ISP. However, for higher assurance levels, higher value transactions, more sensitive information or whatever, then you need to establish a trusted Identity Services Provider - hopefully using transparent mechanisms rather than just marketing spin, but heh.<BR>
</FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">However, you should be aware that in the area you seem to be addressing, there are corresponding requirements and issues about how a relying party will treat the information that is provided to it and a need to verify (at higher assurance levels) that correct usage and protection of that information takes place. This is an issue that I raised several times in the context of the Federal Govt that Mary Rundle has taken up in the open trust frameworks discussion. For large scale operation this relying party assurance equivalent will not likely consist of audits, but probably will need to rely on relying party agreements (no pun intended :) ). <BR>
</FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">The Kantara Initiative have done some good starting work on Identity Assurance models (based on earlier work by NIST et al). It needs lot more work and does not address a range of deployment challenges, but is worth taking a look at.<BR>
</FONT></FONT><FONT FACE="Arial">--Andrew</FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"> <BR>
<BR>
<BR>
<BR>
<HR ALIGN=CENTER SIZE="3" WIDTH="100%"></FONT><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><B>From:</B> <a href="openid-security-bounces@lists.openid.net">openid-security-bounces@lists.openid.net</a> [<a href="mailto:openid-security-bounces@lists.openid.net">mailto:openid-security-bounces@lists.openid.net</a>] <B>On Behalf Of </B>John Bradley<BR>
<B>Sent:</B> Tuesday, December 08, 2009 3:34 AM<BR>
<B>To:</B> Shearer, Charles Dylan<BR>
<B>Cc:</B> OpenID Security Mailing List<BR>
<B>Subject:</B> Re: [security] Nonrepudiation, and Trusting OpenID Providers<BR>
</FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><BR>
Charles, <BR>
<BR>
It is true that almost all assertion based protocols require that a RP and user have some trust in the OP/IdP. This is equally the case for SAML and managed Info-Cards.<BR>
<BR>
Some thing like PKI and personal info-cards allow the user to have complete control over the authenticator. <BR>
<BR>
There are two basic options:<BR>
1 increase the trustability of the OP/IdP<BR>
2 Use multiple IdP simultaneously and prey.<BR>
<BR>
I don't personally believe that option 2 is all that practical or gives much more security for the average user.<BR>
<BR>
Given that openID is only secure enough as a protocol for ICAM LoA 1 (pseudonymous protecting no PII) the most practical path is to provide more trustable OP/IdP.<BR>
<BR>
That said, with some of the v.Next changes openID will become appropriate for higher LoA.<BR>
<BR>
I don't think Gov or Banks are going to be comfortable with multi Auth solutions. They are going to insist on trusted OP/IdP.<BR>
<BR>
You can have a look at the ICAM site to see where the US Gov is going.<BR>
<a href="http://www.idmanagement.gov/drilldown.cfm?action=openID_openGOV">http://www.idmanagement.gov/drilldown.cfm?action=openID_openGOV</a><BR>
<BR>
I can see binding more than one openID to a RP to allow for recovery, however that needs to be balanced against doubling the attack surface.<BR>
<BR>
Regards<BR>
John Bradley<BR>
<BR>
On 2009-12-07, at 9:47 PM, Shearer, Charles Dylan wrote:<BR>
<BR>
</FONT></SPAN><BLOCKQUOTE><SPAN STYLE='font-size:11pt'><FONT FACE="Calibri, Verdana, Helvetica, Arial"> <BR>
I have some concerns about OpenID, and I would like to see what those involved think about them.<BR>
<BR>
It seems to me that, regardless of how OpenID is deployed, it is always possible for an OpenID provider itself to authenticate with a relying party as any user by forging a request to authenticate using the user’s identifier. This is because a relying party cannot tell the difference between a user attempting to log in using his or her identifier, and the user’s OpenID provider spoofing that user to gain access to whatever services the relying party provides to that user. This seems to require that both users and relying parties put a lot of trust in OpenID providers: for example, if I used my OpenID identifier for online banking and email, my OpenID provider could easily access my email and bank account. <BR>
<BR>
Additionally, even if we assume that OpenID providers will not log into users’ accounts, I still cannot see how OpenID could provide nonrepudiation regarding messages sent to a relying party by an authenticated user: for example, if I authenticate with my bank using my OpenID identifier and then use the bank’s “bill pay” service to pay a bill, there’s no way the bank can prove that I ordered that payment because it is possible that someone working for my OpenID provider logged in as me and ordered it.<BR>
<BR>
Does anyone disagree with my analysis?<BR>
<BR>
Dylan <BR>
_______________________________________________<BR>
security mailing list<BR>
<a href="security@lists.openid.net">security@lists.openid.net</a><BR>
<a href="http://lists.openid.net/mailman/listinfo/openid-security">http://lists.openid.net/mailman/listinfo/openid-security</a><BR>
</FONT></SPAN></BLOCKQUOTE><SPAN STYLE='font-size:11pt'><FONT FACE="Calibri, Verdana, Helvetica, Arial"><BR>
<BR>
</FONT></SPAN></BLOCKQUOTE>
</BODY>
</HTML>