Re: Realm spoofing spec patch

[Allen Tom]

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 Hoyt]

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

[Allen Tom]

Josh - thanks for writing this up!

David - Many OPs may choose not to let their users login into RPs that
can't be verified. For instance, in the case where a large corporation
like Sun issues their employees OpenIDs, the corporation may want to be
very selective as to which RPs they let their employees sign into.

An OP that is targeting mass market/consumer users may instead want to
sternly warn their users that the RP can't be verified, similar the
warning that browsers display when there are issues with the cert when
using HTTPS. 

I'd expect that if the realm spoofing patch is included in the core
protocol, and if large OPs were to implement RP endpoint discovery, then
most RPs have a very strong incentive to implement this in order to
supress the ugly warning. The solution discussed at IIW and proposed by
Josh should be trivial for all serious RPs to implement. If all serious
RPs and most of the others implment this, then the OP warning should
really be a very rare exception rather than the rule.

David - you are correct in that there is a larger problem around trust
between OPs and RPs, but this can probably be solved via out of band
pre-association. Unfortunately, this process would probably be very
heavyweight and not be easy to automate, and would probably be reserved
for parties that have some sort of business and contractual
relationship. There is no need to have something this heavyweight in the
spec as the process would probably be very proprietary and RP/OP specific.

In the interest of interoperability and ease of implementation, the
proposed solution is very lightweight and does seem to solve the
problem. It would be great if this patch be included in the core spec,
and not as an extension.

>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.

Thanks!
Allen


> 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.  

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Realm spoofing spec patch

[Johnny Bufu]

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

[Johnny Bufu]

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

RE: Realm spoofing spec patch

[Recordon, David]

Hey Josh,
Thanks for writing this up!

I'm a bit confused by the number of "SHOULD"s 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.

2.

3.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs