[OpenID] Phishing resistant policy of PAPE

[Paul Madsen]

FYI, PAPE 1.0-07 (the version under public review) [1] no longer defines 
the phishing resistant policy in this manner.

Instead

"An authentication mechanism where a party potentially under the control 
of the Relying Party can not gain sufficient information to be able to 
successfully authenticate to the End User's OpenID Provider as if that 
party were the End User."

This would seem to be sufficiently general to encompass both a simple 
phish as well as a more involved MITM (as well as arguably a password 
mechanism supplemented by something like Yahoo site seal).

I preferred the old defn, i.e. defining phishing resistant in terms of 
not relying on a shared secret between OP and user, as it better 
captures the (to me) key distinguishing aspect of protecting the user 
from being fooled into giving away that secret.

Separately, the 'can not' seems optimistic. Are there any absolutes in 
security?

Paul

[1] 
http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-07.html#auth_policies

Shishir wrote:
> Hi,
>
>          We are a research group at Stony Brook University working on 
> OpenID.
> After going through the PAPE 1.0 draft version, we recommend that the 
> phishing-resistant authentication policy be modified to be 
> "man-in-the-middle-resistant authentication".  The phishing-resistant 
> mode is intended to stop the phishing attack in which a malicious RP 
> redirects a user to a malicious OP that impersonates the user's real 
> OP and collects the user's password.  As we read it, this mode does 
> not prevent man-in-the-middle attacks.  This mode already requires 
> client-side software support, so it can be modified to prevent MITM 
> attacks without imposing any additional burden on users/RPs/OPs.
>
> The current draft loosely defines this mode as, "An authentication 
> mechanism where the End User does not provide a shared secret to a 
> party potentially under the control of the Relying Party."  This 
> precludes any authentication mechanism in which the user types a 
> password into their user-agent, so client-side software support is 
> necessary to use this mode.  An obvious method of phishing-resistant 
> authentication that meets the above definition is a challenge-response 
> protocol using a collision-resistant hash function h:
>  OP->user: c
>  user->OP: r=h(c||password)
> But a malicious RP could redirect a user to a malicious OP that acts 
> as a MITM with the real OP:
>  realOP->MITM: c
>  MITM->user:   c
>  user->MITM:   r=h(c||password)
>  MITM->realOP: r
>
> This could be prevented by making the client response specific to the 
> server to which it is authenticating, e.g.
>  r = h(c||password||server-id)
> where server-id could be the server's SSL certificate or, when SSL is 
> not used, the server's IP address.  The above attack would fail 
> because the user would generate r=h(c||password||MITM-id) but the real 
> OP would expect h(c||password||realOP-id).
>
> So we recommend that "phishing-resistant authentication" be replaced 
> with "man-in-the-middle-resistant authentication", defined as
> "An authentication mechanism that is immune to man-in-the-middle attacks."
>
> Or is there some external design consideration that makes this 
> impractical?  Thanks for reading and considering our proposal.
>
> --
> Shishir Randive
> Santosh Subramanian
> Michael Hart
> Rob Johnson
> ------------------------------------------------------------------------
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>   
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG. 
> Version: 7.5.549 / Virus Database: 270.8.3/1747 - Release Date: 26/10/2008 9:27 AM
>   

-- 
ConnectID <http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081028/983d9e06/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gMwy.1.gif
Type: image/gif
Size: 10551 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081028/983d9e06/attachment-0002.gif>