[security] Nonrepudiation, and Trusting OpenID Providers

Thu Dec 10 04:04:12 UTC 2009

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 <ve7jtb at ve7jtb.com> 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" <annash at paypal.com> 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: openid-security-bounces at lists.openid.net
> [mailto:openid-security-bounces at lists.openid.net] 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
> security at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-security
>
>
>
>
> _______________________________________________
> security mailing list
> security at lists.openid.net
> 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)