[security] Nonrepudiation, and Trusting OpenID Providers

Nash, Andrew annash at paypal.com
Wed Dec 9 16:18:16 UTC 2009


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
	


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20091209/88261b8d/attachment.htm>


More information about the security mailing list