<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
FYI, PAPE 1.0-07 (the version under public review) [1] no longer
defines the phishing resistant policy in this manner. <br>
<br>
Instead<br>
<br>
"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."<br>
<br>
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).<br>
<br>
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.<br>
<br>
Separately, the 'can not' seems optimistic. Are there any absolutes in
security?<br>
<br>
Paul<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-07.html#auth_policies">http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-07.html#auth_policies</a><br>
<br>
Shishir wrote:
<blockquote
cite="mid:ee58ebf90810271339s4ec10a9kcf6f1d30d7d9625f@mail.gmail.com"
type="cite">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
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
general mailing list
<a class="moz-txt-link-abbreviated" href="mailto:general@openid.net">general@openid.net</a>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a>
</pre>
<pre wrap="">
<hr size="4" width="90%">
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
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<a href="http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1"><img
src="cid:part1.00000009.04010400@rogers.com" alt="ConnectID"
style="border: 0pt none ;"></a></div>
</body>
</html>