Hi Johnny, Having the OP follow all the redirects returned by the return_to all the way to the end, and presenting the final url to the user might seem to be an improvement, however, the evil RP could just be one of many intermediate servers, which would enable all sorts of interesting man in the middle type attacks.
so for instance: return_to=go.com/redirect?1,2,http://evilsite.com/redirect?....good.isp.com If the OP just followed redirects to the end of return_to url, and then matched it up with the realm, the evil RP could claim to be absolutely anything that it wants to be, since the evil RP could just be the redirect server, and the claimed site would just be at the end. evilsite.com would be able grab a positive Auth Response and play it to good.isp.com in a Stateless type request. EvilSite.com could even behave nicely when the OP is probing it (perhaps by recognizing the OP's IP address or User Agent). At any rate, when serving an Auth Request, the OP only knows the return_to url, so there should be a way in the protocol for the OP to somehow verify the return_to url. Instead of performing the verification on every request, the OP and the RP could register themselves and do whatever verification is required during the association process. One possibility would be for the RP to pass its return_to url when making the Association Request, and the OP can probe it before returning the assoc_handle and secret. It might be sufficient for the OP to just bind that assoc_handle to the return_to url, so one possible implementation would be for the OP to encrypt details about the association into the assoc_handle, so that the given assoc_handle can only be used for that return_to. However, it might be necessary for the OP to verify that the RP owning the return_to URL actually initiated the Association request, so perhaps an additional round trip would be needed after the association is initiated. Allen Johnny Bufu wrote: > > Another simpler (though maybe not as solid) solution would be for the > OP to perform a fetch on the return_to URL and present the final URL - > after following the redirects - in the message to the user. So the > user will actually see that he's about to go to http://www.jyte.com, for: > > > return_to=http://www.aol.com/ams/clickThruRedirect.adp?1,2,http://www.jyte.com > > > > If the rogue RP further tries to hide itself by setting > realm=*.aol.com, the realm verification performed by the OP will fail > (again, using the return_to URL after following redirects). > > > Johnny > > > _______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security
