[OpenID] Phishing resistant policy of PAPE

Tue Oct 28 20:40:51 UTC 2008

Ben Laurie wrote:
> 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.
>   
right. So If I were to self-host an OP, and used every trick available 
(e.g. check URL, look at cert, implement site seal, etc) to ensure that 
I (as user) never presented my password elsewhere, then I (as OP) could 
justifiably claim 'phishing resistant' for myself (as a User).

this is the inherent challenge in describing authentication not in terms 
of what happened (e.g. password, Infocards, OTP, multi-factor, etc) but 
rather in terms of the resulting security characteristics (e.g. phishing 
resistance, MITM resistant, etc) - very different authentication 
'methods' can (if appropriately deployed by the OP and appropriately 
implemented by users ) provide similar security characteristics.  That 
seems like a dangerous 'best-case' model ....

>   
>> Separately, the 'can not' seems optimistic. Are there any absolutes in
>> security?
>>     
>
> No :-)
>   
good to hear I didn't miss some new development :-)
>   
>> 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
>>
>>
>>     
>
>
>   

-- 
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/d6d1613d/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gMwy.1.gif
Type: image/gif
Size: 8570 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081028/d6d1613d/attachment-0002.gif>