[OpenID] Phishing resistant policy of PAPE

[Peter Williams]

I for one never considered/read pape as controlling openid auth, discovery, sp discovery, realm enforcement, yadis or hxri resolution. Its function is not to address trust fabric issues or apply mitm countermeasures. Its is an optional signal that guides local (only) functions performed by an op, once opeid auth reaches that processing state.

Im being highly dogmatic, in tone, to force the issues - per a last call process. The comment suggests that pape is misconceived, or improperly written up for what folks thing it actually does, or should do.

The state machines of the op and the rp are not currently linked, by pape signals. There is no information flow linkage between the 2 security models, formally. An app may consider the pape guidance, however, when making reliance decisions on an assertion.

-----Original Message-----
From: Ben Laurie <benl at google.com>
Sent: Tuesday, October 28, 2008 11:09 AM
To: Shishir <send2shishir at gmail.com>
Cc: Rob Johnson <rob at cs.sunysb.edu>; Michael Hart <mahart110 at gmail.com>; general at openid.net <general at openid.net>; Santosh Subramanian <subra.santosh at gmail.com>
Subject: Re: [OpenID] Phishing resistant policy of PAPE


On Mon, Oct 27, 2008 at 8:39 PM, Shishir <send2shishir at gmail.com> 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,

I don't think you mean that - the user agent might provide support for
the protocol below, for example.

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

I think this is a good idea.

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