security hole in signature algorithm

[Dick Hardt]

Scenario
-------------
By manipulating the return_to parameter, an attacked can impersonate  
another user at an RP.


1) Attacker goes to an RP and initiates an authentication pretending  
to be http://victim.op.com.
RP sends the following parameters in the request:

openid.return_to=http://rp.com/result?p=x
openid.identity=http://victim.op.com


2) The attacker modifies the parameters as such:

openid.return_to=http://rp.com/result?p=x&identityhttp://victim.op.com
openid.identity=http://attacker.op.com

Then sends them to the OP.

3) The attacker has an account at the OP, and authenticates. The OP  
sends a response with the following parameters:

openid.signed=return_to,response_nonce,identity
openid.return_to=http://rp.com/result?p=x&identityhttp://victim.op.com
openid.response_nonce=2006-11-11T06:66:66Z0123
openid.identity=http://attacker.op.com

Given the above parameters, the signature is calculated on the  
following string:

return_tohttp://rp.com/result?p=x&identityhttp:// 
victim.op.comresponse_nonce2006-11-11T06:66:66Z0123identityhttp:// 
attacker.op.com

4) The attacker modifies the OP response as such and sends it to the RP:

openid.signed=return_to,identity,response_nonce
openid.return_to=http://rp.com/result?p=x&
openid.identity=http://victim.op.com
openid.response_nonce=2006-11-11T06:66:66Z0123identityhttp:// 
attacker.op.com

which results in the same string for checking the signature as in (3)  
above

return_tohttp://rp.com/result?p=x&identityhttp:// 
victim.op.comresponse_nonce2006-11-11T06:66:66Z0123identityhttp:// 
attacker.op.com

Since the random value at the end of the response_nonce is not known  
to the RP, it does not know it was modified. The extra "&" in the  
return to is likely ignored.

Including openid.signed in the list of signed parameters just adds  
complexity to the attack, it does not prevent it.

Possible Solution
-------------------------
It would seem the only way to prevent this attack is to insert a  
delimiter between parameters like what was done with DIX so that  
arbitrary data cannot be interpreted as a valid data. Since a newline  
is not allowed in parameter data, I would suggest a newline be  
inserted between parameters.

String from OP
return_tohttp://rp.com/result?p=x&identityhttp://victim.op.com/n
response_nonce2006-11-11T06:66:66Z0123/n
identityhttp://attacker.op.com

Modified signature string from attacker no longer matches
return_tohttp://rp.com/result?p=x&/n
identityhttp://victim.op.com/n
response_nonce2006-11-11T06:66:66Z0123identity=http://attacker.op.com