[security] Validating openid.identity in authenticationresponses

[Bradescu, Roxana]

David, I've noticed the use case you describe doesn't actually work at a
many RP's. For example if I go to livejournal.com and just put in just
my IDP pip.verisignlabs.com I get an error. 

It looks like the RPs assume the leftmost part of an OpenID URL is the
identifier and everything else is the IDP address. Is this a bug in the
RPs? Though not quite sure how an RP would know to how to parse an
OpenID URL if it did not always assume the identifier was included in
the URL...


Roxana Bradescu | VeriSign Innovation | rbradescu at verisign.com

 

-----Original Message-----
From: security-bounces at openid.net [mailto:security-bounces at openid.net]
On Behalf Of David Recordon
Sent: Friday, November 16, 2007 9:01 AM
To: Trevor Johns
Cc: security at openid.net
Subject: Re: [security] Validating openid.identity in
authenticationresponses

.On Nov 16, 2007, at 7:10 AM, Trevor Johns wrote:

> There was a question on IRC a few nights ago that I couldn't answer
> and has since been bugging me. I was hoping somebody here would be
> able to clarify this for me...
>
> In reply to an authentication request (either via checkid_immediate or
> checkid_setup), an OpenID provider includes the identifier that has
> been verified as the value for openid.identity. However, what if that
> identity doesn't match what was sent in the original authentication
> request?

This is actually desired functionality to allow for "directed  
identity".  The use case here is that an End User might type their OP  
Identifier such as "http://aol.com" to start the discovery process.   
Then while at the OP, they could potentially create a new OpenID  
Identifier on the fly or might only have one which is where this can  
also serve as a convenience feature.


> Obviously there needs to be some validation here, otherwise a provider
> could make claims about identities on other domains. However, what
> about the less dangerous requests, such as returning an different
> identity within the provider's authoritative domain?

Yes, if you take a look at Section 11 Verifying Assertions
(http://openid.net/specs/openid-authentication-2_0-12.html#verification 
) you'll see that the Relying Party must verify that the verify that  
the OP is authoritative for the Claimed Identifier in the response.

Hope that helps!

--David

> And if that's not
> allowed, then what is the purpose of including openid.identity at all,
> considering that the return_to URL in combination with a nonce (which
> is required for secure operation anyway) would be sufficient to ensure
> the provider's signature isn't reused maliciously for other  
> identities?
>
> -- 
> Trevor Johns
> http://tjohns.net
>
> _______________________________________________
> security mailing list
> security at openid.net
> http://openid.net/mailman/listinfo/security


_______________________________________________
security mailing list
security at openid.net
http://openid.net/mailman/listinfo/security