[OpenID] Phishing resistant policy of PAPE

Peter Williams pwilliams at rapattoni.com
Tue Oct 28 19:51:06 UTC 2008


If we rewrite auth mechanism as the defined-term "authentication method", the new definition seems fine - and assumes NO prior agreement between OP and RP. This satisfies the core rules of the open standards model.

Now, ignoring shared secret keystuff (which violates the no prior agreement rule), we can see that one CAN satisfy the policy using a real method - such as an OTP token with keypad, that can do server (OP) auth.

One may love or hate that method (e.g. deploy the RSA SID900 with its server auth math), when implemented well this "method" WOULD 100% satisfy the policy, without requiring shared secret stuff. This suggests the current formulation without mentioning shared secrets (bar the term update) is right, as an open system CAN obviously be built.

-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Ben Laurie
Sent: Tuesday, October 28, 2008 11:32 AM
To: Paul Madsen
Cc: general at openid.net; Santosh Subramanian; Michael Hart; Rob Johnson; Shishir
Subject: Re: [OpenID] Phishing resistant policy of PAPE

On Tue, Oct 28, 2008 at 6:09 PM, Paul Madsen <paulmadsen at rogers.com> wrote:
> 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.

This is a grey area. If a shared secret is carefully protected, then
it is phishing resistant.

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

No :-)

>
> 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
>
>
> --
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general



More information about the general mailing list