RP attack vector - why two identifiers are redundant

Sun Oct 15 02:11:35 UTC 2006

On 13-Oct-06, at 7:45 PM, Drummond Reed wrote:

>> And despite all the "but it can't be stateless without two!"  
>> noise, it
>> actually can:  you put the portable identifier in the return_to  
>> URL and
>> verify it again when you get the signature back from the IdP.   
>> That is,
>> verify the mapping from portable -> IdP-specific still holds.   
>> Because you
>> can't just trust the 1 (or 2) values you get back from the IdP,  
>> otherwise
>> the IdP (which could be malicious) could be fucking with you,  
>> asserting a
>> portable identifier which it's not actually permitted to do,  
>> according to
>> the portable identifer's YADIS/<head>/etc.
>
> Good point. I've never figured an attack vector for the RP to send  
> the wrong
> identifiers to the IdP, since the RP is just "fooling itself". But  
> I agree
> there can be one for a malicious IdP to return the wrong ones to an  
> RP.

The attack vector is not that the RP sends the wrong identifiers, it  
is that a malicious user in between modifies the request that is sent  
to the IdP.

Since the request is not signed and flows through the user, the IdP  
does not know the request message has not been modified. If the IdP  
assumes the two identifiers are bound, then a malicious user can  
pretend to be a different user from the same IdP to the RP. This  
presumes the IdP is using an IdP identifier and the RP is using an RP  
identifier and the binding is assumed by sending both.

Therefore, the IdP MUST make sure the two identifiers are linked, so  
sending both is redundant for the IdP.

As noted in other messages, the RP cannot trust the IdP binding, and  
needs to verify the binding themselves, so the sending the two  
parameters is redundant in the response as well.