[security] Nonrepudiation, and Trusting OpenID Providers

Thu Dec 10 14:08:26 UTC 2009

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.
--
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20091210/7829a000/attachment.htm>