[OpenID] Phishing resistant policy of PAPE

Peter Williams pwilliams at rapattoni.com
Tue Oct 28 16:28:43 UTC 2008


Back to core semantics (which we MUST be seen to agree on, if the spec is to be deemed finalized):-

Encrypted under the SA of openid auth, the pape signal from the requestor is processed by the local OP app (but not the OP protocol machine). The local app can affix an assurance claim to the responding assertion, which is an advisory (only) level signal. It does not impact the RP's protocol machine however. It MAY impact the creation of a local user security context.

Lets recall, given the opennatur of the protocol stack that

1. The openid auth channel, bearing the pape extensions, may itself already have suffered MITM, due to inadequacies in its DH + discoveries setup process.

2. If used, the https channels underlying discovery, spdiscovery....openid auth, may have already suffered from the MITM present in the underlying (uncareful) use of https.

So, we have

A The https comms bearer may already have MITM
B Openid auth handshake may already have Openid-specific MITM
C Insecure discovery process may lead to the RP to redirect to an MITM OP (without visual server auth which facilitates classical phishing by UI social engineering)

According to the comment, advisory pape signal shall indicate that one or more of these issues have been addressed. From the followup comment, the change of name of the signal means, the obligation on the protocol entities shall change, and they MUST ensure that all of A B and C (and any other) have been addressed. Precisely how this is done in an open system is polymorphous, consistent with the notions of those particular NIST levels.

I don't believe that this is what the PAPE signal says or intends.

But...I'm not an author or a steering group member who set the charter! So, do continue to disagree if you are still not convinced.


-----Original Message-----
From: Rob Johnson [mailto:rob at cs.sunysb.edu]
Sent: Tuesday, October 28, 2008 9:02 AM
To: Peter Williams
Cc: Ben Laurie; Shishir; Michael Hart; general at openid.net; Santosh Subramanian
Subject: Re: [OpenID] Phishing resistant policy of PAPE

Peter Williams wrote:
> 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.

I agree that some of the above notions, such as discovery, are out of
scope for PAPE.  However, PAPE was specifically created to address one
form of man-in-the-middle attack -- phishing -- and our suggestion is
that it should address _all_ man-in-the-middle attacks since it can do
so without imposing any additional burden on end-users.

It is true that PAPE is a signal from RPs to OPs that guides the local
actions of the OP, but the OP also communicates information about the
result back to the RP, and the RP will make decisions based on that
information.  That is the expected use-case, so I think the OP and RP
state machines are linked.

The PAPE framework looks fine, but the phishing-resistant authentication
standard will not solve the problem of criminals impersonating other
users.  It will only force them to engage in on-line MITM attacks.
Thus, if PAPE gets standardized with only phishing-resistant
authentication, then in a year or two we will need yet-another-extension
addressing general MITM attacks.  Why not address MITM attacks now,
since it won't cost anything?

Best,
Rob

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




More information about the general mailing list