[security] Nonrepudiation, and Trusting OpenID Providers

Thu Dec 10 14:18:54 UTC 2009

On Thu, Dec 10, 2009 at 2:08 PM, Andrew Arnott <andrewarnott at gmail.com> wrote:
> Why do OPs have to use passwords?  Someone using myvidoop.com or InfoCards
> for example would have a harder time sharing their credential with someone
> else.

Obviously neither OPs nor anyone else has to use passwords. However,
mostly they do, presumably because usability of other options sucks.

> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
>
> On Thu, Dec 10, 2009 at 12:20 AM, Ben Laurie <benl at google.com> wrote:
>>
>> On Thu, Dec 10, 2009 at 2:44 AM, 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.
>>
>> Surely the problem is not that the provider can do it (yes, they can,
>> but how often do they?), but that anyone you give your password away
>> to can do it.
>>
>> > 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
>> >
>> >
>> _______________________________________________
>> security mailing list
>> security at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-security
>
>