John brings a very important point to this discussion. This relationship of trust involves a triangle, and the user is the one that elects the OpenID to login to the RP.
On Wed, Dec 9, 2009 at 6:44 PM, John Bradley <[email protected]> wrote: > PS, > If you use your email account for account recovery your email provider can > get access to all of your other accounts. That is one of the largest > security problems. > John B. > On 2009-12-09, at 8:53 PM, Shearer, Charles Dylan wrote: > > John & Andrew, > > That you both for your interesting responses and pointers. > > Andrew, you said: > > 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. > > > And John said: > > 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. > > 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. > > Indeed, my point is that OpenID forces us to put a lot 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. > > 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. > > Charles > > > On 12/9/09 8:18 AM, "Nash, Andrew" <[email protected]> wrote: > > Charles, > > 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. > > 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. > > 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 :) ). > > 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. > --Andrew > > > > ________________________________ > From: [email protected] > [mailto:[email protected]] On Behalf Of John Bradley > Sent: Tuesday, December 08, 2009 3:34 AM > To: Shearer, Charles Dylan > Cc: OpenID Security Mailing List > Subject: Re: [security] Nonrepudiation, and Trusting OpenID Providers > > Charles, > > 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. > > Some thing like PKI and personal info-cards allow the user to have complete > control over the authenticator. > > There are two basic options: > 1 increase the trustability of the OP/IdP > 2 Use multiple IdP simultaneously and prey. > > I don't personally believe that option 2 is all that practical or gives much > more security for the average user. > > 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. > > That said, with some of the v.Next changes openID will become appropriate > for higher LoA. > > 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. > > You can have a look at the ICAM site to see where the US Gov is going. > http://www.idmanagement.gov/drilldown.cfm?action=openID_openGOV > > 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. > > Regards > John Bradley > > On 2009-12-07, at 9:47 PM, Shearer, Charles Dylan wrote: > > > I have some concerns about OpenID, and I would like to see what those > involved think about them. > > 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. > > 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. > > Does anyone disagree with my analysis? > > Dylan > _______________________________________________ > security mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-security > > > > > _______________________________________________ > security mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-security > > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) _______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
