Re: OA2.0d11: Minor nit-pick regarding normalization
On 2/1/07, Martin Atkins [EMAIL PROTECTED] wrote: The normalization table in appendix A.1 lists several examples of the normalization of URIs. The last few examples are as follows: http://example4.com/ = http://example4.com/ https://example5.com/ = https://example5.com/ example6.com = http://example6.com I believe that the last example should instead normalize to: http://example6.com/ You're right that the example needs to have the slash added. I don't think that we need any extra wording because RFC3986, which we reference for the normalization rules says: a URI that uses the generic syntax for authority with an empty path should be normalized to a path of /. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
WS-XACML
OpenID should consider the following: http://blogs.sun.com/beuchelt/entry/ws_xacml ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
Recordon, David wrote: I think we all agree that talking about the method used is far more useful, though with this proposal we're really trying to balance it with simplicity in the authentication protocol itself. Maybe it is better to phrase the discussion around if the user provided a secret (password) to the OP or not to authenticate versus talking about phishing directly.?. If you were to define a URI for common authentication method values, could this value not be returned, simply, in the protocol? I'd hope that this parameter in the auth spec really helps bring the discussion around to the Assertion Quality Extension and that it be implemented to provide the more robust metadata such as what type of authentication was actually preformed. Agreed. If AQE is not mandated, however, I think that the original idea of allowing the OP to make a statement about the authentication method in the actual protocol is still a good one. If you start with a simple URI, returned directly in the protocol, can this not be linked to the equivalent statement in the AQE specification? - John --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of john kemp Sent: Thursday, February 01, 2007 7:13 PM To: Granqvist, Hans Cc: OpenID specs list Subject: Re: Proposal: An anti-phishing compromise Granqvist, Hans wrote: Proposed Change === Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. The receiver should decide what is 'non-phishable', not the sender, so it would be better if the OP just states what mechanism was used, perhaps. Agreed. A statement as to the phishability or not seems to be too vague to be useful. A simple statement of the authentication method used would seem to give the same effect, while providing potentially useful information (assuming the RP trusts statements from the OP at all.) Benefits ... Here's what I think: Since the association step is hardly ever used, it can much more easily be overloaded with extra information without breaking any implementation. If the OP would *require* an OpenID association step from the RP, then this step can include an exchange of meta-information between OP and RP. How does the association step between OP and RP change the relationship between the OP and the user (agent)? I thought the attack we were considering is when a rogue RP directs the user agent to a rogue OP, who then steals the user's credentials? How is that affected by the rogue RP and rogue OP associating? - John ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
Hi Josh, In addition to the protocol parameter that you have proposed, I'd hope that we can add something like what you wrote below as part of the security considerations section of the OpenID 2.0 Auth specification, as this text seems to capture quite succinctly the issues that RPs and OPs should be thinking about when attempting to deal with phishing: Josh Hoyt wrote: The ways that OpenID can potentially make phishing worse: * Redirects to your provider are a fundamental part of the flow of OpenID, so being redirected to a phishing site is easy to miss * Every relying party (necessarily) needs to know who the provider is in order to verify the authentication response. This means that the site knows what UI it needs to use to phish (and even worse, it can just proxy the user to the provider) I think these two issues cover what makes phishing potentially a greater threat when using OpenID. Although these problems are significant, if a user can authenticate to their OpenID provider through an non-phishable mechanism, OpenID can make the phishing problem *less* of a threat, because there are fewer places that will need to ask for credentials. Other relevant issues: * There is no universally deployed solution to the phishing problem * There is not even a universally *accepted* solution to the phishing problem * Any technology that prevents phishing will require user-agent support or else will fundamentally change the flow of OpenID (prevent relying-party-initiated sign-in) * OpenID is intended to be deployed without requiring specific technologies to be present in the user-agent It might also be helpful to add somewhere a specific definition of phishing, and the associated attack - that an OP can steal a user's credentials if they are passed to the OP. Mitigation can only really be performed by applying client-side changes that ensure that long-lived private information shared only between the OP and the user (such as a password) does not pass across the network. Regards, - John ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
On 2-Feb-07, at 7:05 AM, George Fletcher wrote: but I'm still not sure how this helps with the phishing problem. As you pointed out John, the issue is a rogue RP redirecting to a rogue OP. So the rogue OP just steals the credentials and returns whatever it wants. In this case, the rogue RP is not interested at in the the auth response from the rogue OP (or for that matter from the legitimate OP); just in stealing the user's credentials. The phishing field prevents the phisher to later use these credentials on a legitimate RP (which will be contacting the legitimate OP) to impersonate the user -- if the RP enforces phishable = no. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
Johnny Bufu wrote: On 2-Feb-07, at 7:05 AM, George Fletcher wrote: but I'm still not sure how this helps with the phishing problem. As you pointed out John, the issue is a rogue RP redirecting to a rogue OP. So the rogue OP just steals the credentials and returns whatever it wants. In this case, the rogue RP is not interested at in the the auth response from the rogue OP (or for that matter from the legitimate OP); just in stealing the user's credentials. The phishing field prevents the phisher to later use these credentials on a legitimate RP (which will be contacting the legitimate OP) to impersonate the user -- if the RP enforces phishable = no. I guess I'm confused by the above. If the OP has stolen the user's credentials, it can just say phishable = no and pass its assertion regarding those credentials to the RP. This is about a rogue OP, and the relationship between the OP and the user, not really about the relationship between the OP and RP (although if the RP knew whether or not it could trust the OP by some out-of-band means, it would simply not accept an assertion from the OP unless that trust was established). You might use a rogue RP to start the attack, but the attack is actually performed by the rogue OP, not the rogue RP. - John ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
On 2-Feb-07, at 12:25 PM, john kemp wrote: If the authentication mechanism is phishable, a good OP is supposed to say phishable=yes. Otherwise it is cheating the user's trust. Yes, RPs will just have to trust assertions from an OP. But with all due respect, I just don't see how the honour system mitigates phishing. I guess we could argue about where we see the trust. I see it between between the user and the OP. The RP only trusts (or rather accepts) the user's choice of an OP (and the assertions coming from it as representing the user). Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
On 2/2/07, john kemp [EMAIL PROTECTED] wrote: Don't get me wrong - I think it's a good idea for the OP to make a statement about the authentication method used (although I would prefer it to say something like authn_method=urn:openid:2.0:aqe:method:password, rather than phishable=yes). That points to AQE, as David mentioned already. A browser plug-in, like sxipper, that uses a username and (a generated, non-user-visible) password internally and will only submit it to the correct OP can't be phished. Is this a different kind of authentication than password? I don't think so. Is it phishable? I think that the OP can reasonably say that it is not. Therefore, I think that the authentication mechanism is (or at least can be) independent from whether the authentication channel is phishable. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
On 2-Feb-07, at 1:53 PM, Josh Hoyt wrote: Therefore, I think that the authentication mechanism is (or at least can be) independent from whether the authentication channel is phishable. .. or, pushing it a bit further, I could ask/configure my OP to always issue phishable=no for me, because I am a power user, always watch the address bar, check certificates, make sure my machine is not compromised, etc. That's also fine, as long as the OP represents the user's interests. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
Josh Hoyt wrote: On 2/2/07, john kemp [EMAIL PROTECTED] wrote: Don't get me wrong - I think it's a good idea for the OP to make a statement about the authentication method used (although I would prefer it to say something like authn_method=urn:openid:2.0:aqe:method:password, rather than phishable=yes). That points to AQE, as David mentioned already. A browser plug-in, like sxipper, that uses a username and (a generated, non-user-visible) password internally and will only submit it to the correct OP can't be phished. Is this a different kind of authentication than password? I don't think so. Is it phishable? I think that the OP can reasonably say that it is not. Therefore, I think that the authentication mechanism is (or at least can be) independent from whether the authentication channel is phishable. I will agree that the authentication channel might be separated from the authentication method, as you have described those concepts. I'm not sure if that's a meaningful distinction. For example - in Sxipper, does the password get moved across the network to the OP, or does Sxipper act as the OP (on the client side?) If the former, then I'd argue that Sxipper password auth is slightly less phishable, but not completely so. If the latter, then the trust is /really/ only between the RP and the user. - John ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OA2.0d11: Minor nit-pick regarding normalization
Hi Josh / Martin, For the sake of an appropriate short sentence, is it not appropriate to include Martin's text (or similar). Does anyone really want to have read 1/2 a dozen extra specifications for clarification of a single points that could be simply included in the OpenID spec? For the sake of allowing me to more easily adopt OpenID. Sure - we MUST have appropriate references, and SHOULD use a quote from the authorative document - if it is clearly understood. If not, I think it prudent to provide as a plain an English description / example as is possible. I have read a few specifications after being asked to implement/incorporate them into work I was doing here at the university - but for the most part I ended up throwing out the spec and visiting a wiki or a mailing list - with regards to sourcing information on how to implement the specification. I can't ever remember actually reading a spec from start to finish for the purpose of implementing it. Used it as a reference for information I collected elsewhere - most certainly... I realise the importance of the SPEC and I understand the technical space in which they live, but surely we should practice what we preach - ease of uptake etc in our own documentation? On Friday, February 02, 2007 at 20:19, in message [EMAIL PROTECTED], Josh Hoyt [EMAIL PROTECTED] wrote: On 2/1/07, Martin Atkins [EMAIL PROTECTED] wrote: The normalization table in appendix A.1 lists several examples of the normalization of URIs. The last few examples are as follows: http://example4.com/ = http://example4.com/ https://example5.com/ = https://example5.com/ example6.com = http://example6.com I believe that the last example should instead normalize to: http://example6.com/ You're right that the example needs to have the slash added. I don't think that we need any extra wording because RFC3986, which we reference for the normalization rules says: a URI that uses the generic syntax for authority with an empty path should be normalized to a path of /. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
