Two Identifiers - no caching advantage

[Dick Hardt]

My head is a little moreclear this morning, so let me clarify.

My key point is that the IdP cannot trust the discovery done by the  
RP since what the request is unsigned and may have been modified  
between the RP and the IdP.

I was showing a potential attack vector where even though I think I  
have resolved the issue, it is not resolved.

-- Dick

On 19-Oct-06, at 8:27 AM, Drummond Reed wrote:

> I don't have time this second to go into more detail, but a quick  
> high-level
> observation about Dick's Cached Discovery Attack: if your blog (or the
> target page of any portable OpenID identifier) can be hacked,  
> you've already
> lost your identity. All the hacker has to do is point the link tag  
> at their
> own XRDS file and their off to the races. They can spoof your portable
> OpenID identifier anywhere and everywhere you've used it, because  
> from the
> standpoint of an RP, all it looks like is that you've changed IdPs...
>
> ...which of course is the whole point of portable OpenID  
> identifiers ;-)
>
> =Drummond
>
> -----Original Message-----
> From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On  
> Behalf
> Of Dick Hardt
> Sent: Thursday, October 19, 2006 12:13 AM
> To: specs at openid.net
> Subject: Two Identifiers - no caching advantage
>
> After reading though:
>
> 	http://www.lifewiki.net/openid/ConsolidatedDelegationProposal
>
> I have concluded there is no caching advantage
>
> Specifically if you look at these two sections:
>
>
>
> RP Rules for Identifier Parameters
>
> Case 3: URL WITH IdP-Specific Identifier
>
> If Portable Identifier is a URL that DOES map to a IdP-Specific
> Identifier, the values are:
>
> openid.identity = IdP-Specific Identifier
> openid.portable = Portable Identifier
>
> IdP Rules for Identifier Parameters
>
> 3. If openid.identity = Portable Identifier that IdP does not
> recognize, IdP MUST to discovery to obtain the IdP-Specific  
> Identifier.
>
>
>
> I conclude the following:
>
> *** Given IdP Rule 3, the IdP must bind the IdP-Specific Identifier
> and the Portable Identifier, so the RP sending both does may save the
> IdP effort, but leaves a potential security issue. (see Cached
> Discovery Attack below)
>
> *** the RP is using the Portable Identifier to identify the user, and
> does nothing with the IdP-Specific Identifier, so there is no value
> in the IdP sending both the Portable Identifier and the IdP-Specific
> Identifier. Note that the RP either maintains state that the IdP is
> bound to the Portable Identifier, or needs to do discover again.
>
> => The only reason for the RP to send the openid.identity to the IdP
> is for backward compatibility with OpenID 1.x, similarly the only
> reason for the IdP to send openid.identity to the RP is for OpenID
> 1.x compatibility. There are no caching advantages.
>
>
>
> Cached Discovery Attack:
>
> A malicious user takes over my blog, opens an account at the same IdP
> I use, inserts her IdP-Specific Identifier into my blog, and then
> uses my blog URL. The IdP will see the blog URL and the IdP-Specific
> Identifier don't match, do discovery on the blog URL, and then map my
> blog URL (Portable Identifier) to her IdP-Specific Identifier.
>
> I discover that my blog URL has been hacked, and restore my IdP-
> Specific Identifier.
>
> The malicious user goes to an RP, that providing her blog URL that
> contains her IdP-Specific Identifier. She captures the message from
> the RP, and changes the Portable Identifier to be my blog URL. The
> IdP still thinks the Portable Identifier is mapped to her IdP-
> Specific Identifier, and allows her to login to the RP as me.
>
> Solutions:
>
> 1) The IdP does discovery on the blog URL each time it is used.
> 2) The IdP has complex logic to ...
>
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>