<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ben Laurie wrote:
<blockquote
cite="mid:1b587cab0810281132i4ebf855t5728229e33ed1734@mail.gmail.com"
type="cite">
<pre wrap="">On Tue, Oct 28, 2008 at 6:09 PM, Paul Madsen <a class="moz-txt-link-rfc2396E" href="mailto:paulmadsen@rogers.com"><paulmadsen@rogers.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
This is a grey area. If a shared secret is carefully protected, then
it is phishing resistant.
</pre>
</blockquote>
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). <br>
<br>
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 ....<br>
<br>
<blockquote
cite="mid:1b587cab0810281132i4ebf855t5728229e33ed1734@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Separately, the 'can not' seems optimistic. Are there any absolutes in
security?
</pre>
</blockquote>
<pre wrap=""><!---->
No :-)
</pre>
</blockquote>
good to hear I didn't miss some new development :-)<br>
<blockquote
cite="mid:1b587cab0810281132i4ebf855t5728229e33ed1734@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Paul
[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>
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
<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>
________________________________
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
<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>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<a href="http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1"><img
src="cid:part1.05020802.00060000@rogers.com" alt="ConnectID"
style="border: 0pt none ;"></a></div>
</body>
</html>