[security] Phishing issues with return_to url and realm

[Allen Tom]

Hello OpenID Security Community,

This is my first post here, and before I get started, I'd like to 
compliment you all on the amazing progress that OpenID has made 
recently. As far as protocols go, this is very exciting, and I believe 
that it can be used as the foundation for as-yet unimagined new killerapps.

However, there are some severe phishing issues with the OpenID 2.0 draft 
specification which urgently need to be resolved before the draft is 
finalized.

First of all, anyone can craft valid Auth Requests using spoofed values 
for openid.return_to and openid.realm. This has very nasty consequences 
for sites running redirect servers for click tracking purposes, such as 
these:

http://x.go.com/cgi/x.pl?goto=http://www.jyte.com
http://www.aol.com/ams/clickThruRedirect.adp?1,2,http://www.jyte.com

A rogue RP could mask its identity and claim to be go.com or aol.com by 
hiding behind these redirect servers. When serving the Auth Request, an 
OP like myopenid.com will display this message to the user:

"A site identifying as all sites matching http://anything.go.com has 
asked us for confirmation that xxxx is your identity URL..."

This is EXTREMELY BAD, as users expect to trust their OP, especially if 
they feel extra secure because they configured an anti-phishing image 
(like MyOpenID's Personal Icon) and enabled SafeSignIn.This is 
particularly bad if the OP passes sensitive personal information or 
credentials via an extension in the Auth Response.

The best way to resolve this issue is to define a way for the OP to 
verify that the return_to URL is actually a valid OpenID endpoint, and 
to also verify its association.

I propose that an RP's return_to url expose an interface to allow it to 
identify itself as an OpenID 2.0 endpoint, and to also identify its 
association with the OP. Obviously, OPs must not follow redirects when 
interrogating the RP's endpoint.

A possible interface would be for the RP return the its association 
handle if the OP hits the return_to url with the following parameters:

openid.mode = "check_return_url"
openid.server = "https://url_of_the_op.domain.com"

Instead of doing this on every Authentication Request, it would make 
sense for the OP to verify the RP as part of the association process. 
After the OP issues a shared secret and assoc_handle to the RP, the OP 
should be able to query the RP's return_to url before enabling the 
association, exactly the same way an RP can verify an Auth Response by 
querying the OP. Because this implies that an association should be tied 
to a given return_to url, the Association Request interface should be 
extended to require the return_to url. Once the OP has verified the 
return_to url, the OP can enable the association so that all incoming 
Auth Requests with that assoc_handle and return_to url can be served 
without requiring additional verification of the return_to url.

Verifying that the return_to url is actually a valid OpenID endopoint 
prevents redirect servers from being used by phishers to spoof their 
identify. The additional step of tying an association with an RP's 
endpoint allows an OP a way to easily identify verified endpoints and 
realms, and allows a way for an RP to properly identify itself when 
making an Auth Request.

I believe that resolving this issue would increase the level of trust 
that users place on their OPs, as currently, users cannot trust their OP 
to tell them what site they're logging into.

My apologies for the long winded introductory mail. Comments and 
feedback would be very appreciated.

Thanks,
Allen