Re: Realm spoofing spec patch
Allen, On 5/29/07, Allen Tom [EMAIL PROTECTED] wrote: From an implementation perspective, it might make sense for the OP to verify the RP during the association request, so that the association handle is only returned after the RP has been verified. Were you concerned about implementation complexity or the time it could take to do discovery while the user is waiting? At association time, the provider does not know who the relying party is. Are you proposing that the realm be included in the association request? In that case we'd have to include the discovery URL, in the case of a wildcard realm. I see two potential problems: 1. If the discovery happens during the association request, a single-threaded relying party might not respond to the verification request. This wouldn't come up too frequently in production, but it would raise the bar for example and prototype code. 2. If the form of a return_to URL changes (and the relying party updates the discovery information to match) it would be good if the provider could attempt verification again, so that a valid request could complete successfully. (2) requires the same flow as the proposed implementation (verification during the course of the request), and so I think it's simpler to just leave it in-band. I suppose that the specification could remain silent on *when* to perform the verification, since it doesn't really matter from a security perspective, which would leave both channels open, as long as the pertinent information was added to the association request. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Realm spoofing spec patch
Hi Josh, Having the OP verify the realm/return_to as part of the Authentication Request is fine. OPs should cache the verifcation status to reduce latency for RPs that send many users to the OP. At least from my perspective, it always seemed odd that the Association Request is just an interface for OPs to return shared secrets and association handles without knowing anything about the requestor, except for the IP address. I always thought that RPs should pass some information about themselves to the OP when requesting association so that an OP can bind an association handle with an RP. Anyway, I don't think there's any pressing need to change the association request interface at this time. Thanks! Allen Allen, On 5/29/07, Allen Tom [EMAIL PROTECTED] wrote: From an implementation perspective, it might make sense for the OP to verify the RP during the association request, so that the association handle is only returned after the RP has been verified. Were you concerned about implementation complexity or the time it could take to do discovery while the user is waiting? At association time, the provider does not know who the relying party is. Are you proposing that the realm be included in the association request? In that case we'd have to include the discovery URL, in the case of a wildcard realm. I see two potential problems: 1. If the discovery happens during the association request, a single-threaded relying party might not respond to the verification request. This wouldn't come up too frequently in production, but it would raise the bar for example and prototype code. 2. If the form of a return_to URL changes (and the relying party updates the discovery information to match) it would be good if the provider could attempt verification again, so that a valid request could complete successfully. (2) requires the same flow as the proposed implementation (verification during the course of the request), and so I think it's simpler to just leave it in-band. I suppose that the specification could remain silent on *when* to perform the verification, since it doesn't really matter from a security perspective, which would leave both channels open, as long as the pertinent information was added to the association request. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Realm spoofing spec patch
Josh, On 24-May-07, at 4:19 PM, Josh Hoyt wrote: Please review the additions. If you'd like to see the specific changes, you can look at the diffs in revision control[3]. Looks good to me. One minor issue about the wording - we have now two return URL verifications: one done by the OP and a totally different one done by the RP. Would it make sense to call this new one something different, e.g. RP endpoint verification (or validation)? Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Realm spoofing spec patch
On 24-May-07, at 5:54 PM, Recordon, David wrote: I guess since we're unable to fully resolve this issue from a technical perspective, and no I don't have a better technical solution, I'm wondering if this should actually be an extension to the core protocol versus seeming like a resolution to the problem when it really doesn't completely solve it. -1 An extension is totally optional. On the other hand, when I implement a spec I treat all SHOULDs as MUSTs by default, and only examine them if I can't deal with something. The main issue with this attack I believe was the OP making a false statement to their users, thus compromising their trust. Even with the SHOULDs, the OPs have the means to decide how they interact with their users. If this results in not granting access to unverified RPs, the OP can say well, the RP you're trying to go to really SHOULD implement RP discovery. With an extension the OP's statement would be we're using this extension and can't let you go to this RP because they don't implement it and we can't verify their endpoints. Having said that, I would certainly like some of these SHOULDs to be turned into MUSTs if doing so doesn't lead to other issues (deployments, etc.). Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Realm spoofing spec patch
Hello, I've added a section to the specification[1] about performing verification on the realm to avoid realm spoofing. In short, realm spoofing is the problem of exploiting a bug on a site that a user would trust to trick them into sending their information to a site that they would not trust. This is very similar to many phishing attacks. The difference between this type of attack and a standard phishing attack is that the user will (usually) only see the realm, and the realm may actually be trusted, so even an educated user who's paying attention may be vulnerable. There are also (minor) changes to the section on discovering relying parties[2]. The fix that is described is for the relying party to provide a whitelist of URL patterns that should be usable as return_to URLs. Relying parties should be as restrictive as possible when specifying return_to URLs. This is the fix that was discussed at the Internet Identity Workshop, by all of the spec editors and several prominent members of the OpenID community. Please review the additions. If you'd like to see the specific changes, you can look at the diffs in revision control[3]. Josh 1. http://j3h.janrain.com/openid-specs-rendered/openid-authentication_svn-327.html#return_to_verification 2. http://j3h.janrain.com/openid-specs-rendered/openid-authentication_svn-327.html#return_to_verification 3. http://openid.net/svn/listing.php?repname=specificationspath=rev=326sc=1 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Realm spoofing spec patch
Hey Josh, Thanks for writing this up! I'm a bit confused by the number of SHOULDs in this patch. +Relying Parties SHOULD use the Yadis protocol to publish their +valid return_to URLs. The relying party MAY publish this +information at any URL, and SHOULD publish it under the realm +so that providers can verify return_to URLs. +OpenID providers SHOULD verify that the return_to URL +specified in the request is an OpenID relying party +endpoint. +If verification is attempted and fails, the provider +SHOULD NOT send a positive assertion to that return_to +URL. It seems that this methodology only works if either: 1) Every site (RP or proxy) publishes their return_to endpoints or that they don't have any. 2) An OP refuses to let the user login to a RP which doesn't publish their return_to endpoint. I'm unconvinced that either of those situations will actually become prevalent and thus worried about the effectiveness of this methodology. Using the same example from IIW, I am logging into http://evilrp.com/return_to which is proxying itself through http://www.google.com/translate/. If my OP were to prompt me, We're unable to verify the site (http://www.google.com/translate/?http://evilrp.com/return_to) you're logging into, you should use caution when proceeding I'm unsure how many users would actually not proceed, or rather see google.com and decide it is alright. I guess since we're unable to fully resolve this issue from a technical perspective, and no I don't have a better technical solution, I'm wondering if this should actually be an extension to the core protocol versus seeming like a resolution to the problem when it really doesn't completely solve it. In some senses I see this as a larger problem around trust of Relying Parties. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, May 24, 2007 4:19 PM To: OpenID specs list Subject: Realm spoofing spec patch Hello, I've added a section to the specification[1] about performing verification on the realm to avoid realm spoofing. In short, realm spoofing is the problem of exploiting a bug on a site that a user would trust to trick them into sending their information to a site that they would not trust. This is very similar to many phishing attacks. The difference between this type of attack and a standard phishing attack is that the user will (usually) only see the realm, and the realm may actually be trusted, so even an educated user who's paying attention may be vulnerable. There are also (minor) changes to the section on discovering relying parties[2]. The fix that is described is for the relying party to provide a whitelist of URL patterns that should be usable as return_to URLs. Relying parties should be as restrictive as possible when specifying return_to URLs. This is the fix that was discussed at the Internet Identity Workshop, by all of the spec editors and several prominent members of the OpenID community. Please review the additions. If you'd like to see the specific changes, you can look at the diffs in revision control[3]. Josh 1. http://j3h.janrain.com/openid-specs-rendered/openid-authentication_svn- 327.html#return_to_verification 2. http://j3h.janrain.com/openid-specs-rendered/openid-authentication_svn- 327.html#return_to_verification 3. http://openid.net/svn/listing.php?repname=specificationspath=rev=326; sc=1 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
