<div class="gmail_quote"><div dir="ltr">
Hi,<br>
<br> We are a research group at Stony Brook University working on OpenID.<br>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.<br>
<br>
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:<br>
OP->user: c<br>
user->OP: r=h(c||password)<br>
But a malicious RP could redirect a user to a malicious OP that acts as a MITM with the real OP:<br>
realOP->MITM: c<br>
MITM->user: c<br>
user->MITM: r=h(c||password)<br>
MITM->realOP: r<br>
<br>
This could be prevented by making the client response specific to the server to which it is authenticating, e.g.<br>
r = h(c||password||server-id)<br>
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).<br>
<br>
So we recommend that "phishing-resistant authentication" be replaced
with "man-in-the-middle-resistant authentication", defined as<br>
"An authentication mechanism that is immune to man-in-the-middle attacks."<br>
<br>
Or is there some external design consideration that makes this impractical? Thanks for reading and considering our proposal.<br>
<br>--<br>Shishir Randive<br>
Santosh Subramanian<br>
Michael Hart<br>Rob Johnson<br><br></div>
</div><br><br clear="all"><br>-- <br>Thanks & Regards,<br>Shishir Randive<br><a href="http://www.cs.sunysb.edu/~srandive">http://www.cs.sunysb.edu/~srandive</a> <br>