No subject
Fri Apr 24 22:39:51 UTC 2009
ed steeping up security.
I understand that is what would normally happen but it violates some basic =
principals.
It also compromises RP discovery.
A wijldcard in the realm may be the better solution. Though you may not wa=
nt to include matching all protocols.
In the other thread we are discussing PPID like identifiers. If they are =
based on the realm as people are discussing, introducing wildcards etc int=
roduces the question of realm normalization on that side.
John Bradley
On 14-May-09, at 11:25 AM, Luke Shepard wrote:
So, RP delegation sounds like a very general solution to the problem, and s=
eems okay to push for. But I think there's a much simpler solution that sol=
ves the specific problem I described below:
RULE:
If the realm is http, then the return_to can be either http or https.
So this would be legal:
realm: http://open.lukeshepard.com/
return_to: https://open.lukeshepard.com/openid/receiver.php
This would NOT be legal - you can't go the other way.
realm: https://open.lukeshepard.com/
return_to: http://open.lukeshepard.com/openid/receiver.php
So, the receiver should be allowed to INCREASE its security level from the=
realm, but not decrease.
This is analogous to wildcards for the protocol instead of just subdomain.=
Another alternative would be to have explicit wildcards for the protocol, =
or to allow realms with relative protocols, like:
explicit wildcard: *://open.lukeshepard.com
relative protocol: //open.lukeshepard.com
On 5/14/09 7:19 AM, "John Bradley" <jbradley at mac.com> wrote:
I agree that RP delegation should be possible and even desirable.
To do that safely the OP needs to do RP discovery over SSL or discover a X=
RD with detached sig for the RP.
Otherwise you open up Man in the Middle attacks.
My point was that in the existing spec to prevent interception of tokens a=
nd attributes, the Realm that is displayed by the OP to the user needs to =
match where the assertion is sent.
I agree that this is something that should be addressed in openID 2.1 ethe=
r for XRD with dsig or via XRDS with TLS.
John B.
On 14-May-09, at 12:24 AM, Dirk Balfanz wrote:
I don't see why a realm shouldn't be able to delegate to a return_to URL th=
e same way that a user id can delegate to an OP endpoint. This includes del=
egating from http to https, or even to a different domain altogether. Over =
on the XRI TC we've been talking about how to do this securely, e.g., by si=
gning the XRD that does the delegation: http://wiki.oasis-open.org/xri/XrdO=
ne/XmlDsigProfile
Dirk.
On Wed, May 13, 2009 at 7:43 PM, John Bradley <jbradley at mac.com> wrote:
> Luke,
> Realm was called trust_root in 1.1, and is a bit like audience restricti=
on
> in SAML.
> It is the display version of the return_to, and also used for RP discove=
ry
> by the OP.
> I am not certain what the problem is with it being https: if the return_=
to
> is https:.
> There is explicitly no connection to be inferred by DNS authority betwe=
en
> URI differing in scheme.
> Differentiating TLS by its own scheme is a decision we have to live with=
.
> The user should consent to authentication for the site they are logging
> into.
> http://open.lukesheppard.com and https://open.lukesheppard.com could
> be different sites.
> If the RP has both HTTP and HTTPS the best practice would be to always u=
se
> the https: version for realm so that RP discovery cant be spoofed via D=
NS.
> Regards
> John B.
> On 13-May-09, at 2:10 AM, specs-request at openid.net wrote:
>
> Date: Tue, 12 May 2009 23:10:38 -0700
> From: Luke Shepard <lshepard at facebook.com>
> Subject: Should we recommend that return_to url is always HTTPS? What
> about realm?
> To: OpenID Specs Mailing List <specs at openid.net>
> Message-ID: <C62FB26E.BCE7%lshepard at facebook.com <mailto:C62FB26E.BCE7%2=
5lshepard at facebook.com> >
> Content-Type: multipart/related;
> boundary=3D"_004_C62FB26EBCE7lshepardfacebookcom_";
> type=3D"multipart/alternative"
>
> --_004_C62FB26EBCE7lshepardfacebookcom_
> Content-Type: multipart/alternative;
> boundary=3D"_000_C62FB26EBCE7lshepardfacebookcom_"
>
> --_000_C62FB26EBCE7lshepardfacebookcom_
> Content-Type: text/plain; charset=3D"iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> In testing my relying party, it seems clear that the return_to url SHOUL=
D a=3D
> lways be HTTPS. Therefore, then, the realm will always need to be HTTPS =
as =3D
> well.
>
> If the return_to is HTTP, then if the response comes in the form of a PO=
ST =3D
> from a provider that supports SSL, then the user will see a browser war=
ning=3D
> for posting to an insecure form.
>
> Here's an example:
>
> - realm: http://open.lukeshepard.com/
> - return_to: http://open.lukeshepard.com/openid/receiver.php
> - provider endpoint: https://www.google.com/accounts/o8/ud
>
> Let's suppose that the response is too long for a GET redirect, so the p=
rov=3D
> ider chooses to POST (as Google and others sometimes do).
>
> The user would see a warning like this:
>
> [cid:3325014638_6495490]
>
> To preserve the user experience and avoid that popup, relying parties wo=
uld=3D
> want to make sure their receiver is HTTPS.
>
> Alternative
>
> What do you think about loosening the realm/return_to protocol/domain ma=
tch=3D
> requirements?
>
> This kinda sucks though, since it means the REALM also must be HTTPS, ev=
en =3D
> though the HTTP version would seem to be "canonical". I wonder, would we=
al=3D
> low an HTTPS return_to if the realm was HTTP? It seems that the HTTP ver=
sio=3D
> n of the realm would be better, and should be able to mean "accept eith=
er p=3D
> rotocol". Or better yet, you should be able to specify a realm without a=
pr=3D
> otocol at all.
>
> Thoughts?
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>
--_000_C6319712BECClshepardfacebookcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<HTML>
<HEAD>
<TITLE>Re: Should we recommend that return_to url is always HTTPS? What abo=
ut realm?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
11pt'>Thanks for your feedback John.<BR>
<BR>
> From a URI point of view the two URI are different and it can't be con=
sidered steeping up security.<BR>
> I understand that is what would normally happen but it violates some b=
asic principals.<BR>
<BR>
I’d like to see if we can find a compromise between the core principa=
ls and how those are actually applied in the real world. Frankly, this rule=
of protocol matching has been a royal pain when coding my OpenID relying p=
arty, making it more difficult than it needs to be.<BR>
<BR>
For Facebook apps, we configure apps based on their domain, and don’t=
care about the protocol. Similarly, I’d like to enable RPs that just=
don’t care to be able to say “I just don’t care – =
either protocol is fine”.<BR>
<BR>
What are the attack vectors that you worry would be exposed with this rule =
change, that aren’t allowed in the current spec?<BR>
<BR>
> It also compromises RP discovery. <BR>
<BR>
How come? The OP can still perform discovery against the realm, the return_=
to doesn’t really matter.<BR>
<BR>
> A wildcard in the realm may be the better solution. Though you m=
ay not want to include matching all protocols.<BR>
<BR>
Maybe the spec could declare that a wildcard only applies to HTTP and HTTPS=
. Are there others we care about?<BR>
<BR>
> PPID like identifiers. <BR>
<BR>
I’m not familiar with PPID, do you mind explaining how this affects t=
he proposal?<BR>
<BR>
<BR>
<BR>
On 5/14/09 9:29 AM, "John Bradley" <<a href=3D"jbradley at mac.co=
m">jbradley at mac.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'>Luke,<BR>
<BR>
More information about the specs
mailing list