Subject: Re: [Ietf-http-auth] Discussion and Review of draft-hartman-webauth-phishing
From: Sam Hartman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 19 Aug 2008 18:15:11 -0400
List-Id: ietf-http-auth.osafoundation.org

I realized that the new version notification does not include a URI.
Please see http://tools.ietf.org/id/draft-hartman-webauth-phishing for the latest version.

From: Sam Hartman <[email-masked]>
To: [email-masked], [email-masked]
Date: Tue, 19 Aug 2008 12:44:31 -0400
Subject: [Ietf-http-auth] Discussion and Review of draft-hartman-webauth-phishing

--=-=-=

Alexey, I've completed a number of revisions to draft-hartman-webauth-phishing and believe that the document is ready for review and discussion prior to a second publication request and last call.

There have been fairly significant text changes although I think the
core concepts and requirements remain the same.  As such, we need
significant re-review from those who have reviewed previous versions.

In addition, two points require explicit consensus discussion.  First,
section 1.1 contains a purpose statement that I believe would need to
be included in an IETF wide last call and would need to achieve
community consensus.  Secondly, the requirement for mutual
authentication has been somewhat contentious; I believe we need
explicit discussion of that requirement.

I think the best thing to do at this point is to ask for review from
the http working group, saag, secdir, and apps discussion list and
direct comments to ietf-http-auth.  Then once you're satisfied, we
take this back to Lisa.

Does that sound reasonable?

--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline

From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Subject: New Version Notification for draft-hartman-webauth-phishing-09 
Date: Mon, 18 Aug 2008 13:32:35 -0700 (PDT)
	IETF, 0.00724, IETF, 0.00724, I+D, 0.00742, The+IETF, 0.00772,
	IETF+Secretariat, 0.00791, Revision, 0.00907,
	posted+to, 0.00939, Secretariat, 0.00948, This+memo, 0.00976,
	txt, 0.00994
MIME-Version: 1.0

A new version of I-D, draft-hartman-webauth-phishing-09.txt has been successfuly submitted by Sam Hartman and posted to the IETF repository.

Filename:	 draft-hartman-webauth-phishing
Revision:	 09
Title:		 Requirements for Web Authentication Resistant to Phishing
Creation_date:	 2008-08-18
WG ID:		 Independent Submission
Number_of_pages: 30

Abstract:
This memo proposes requirements for protocols between web browsers
and relying parties at websites; these requirements also impact third
parties involved in the authentication process.  These requirements
minimize the likelihood that criminals will be able to gain the
credentials necessary to impersonate a user or be able to
fraudulently convince users to disclose personal information.  To
meet these requirements browsers must change.  Websites must never
receive information such as passwords that can be used to impersonate
the user to third parties.  Browsers should authenticate the website
to the browser as part of authenticating the user to the website.
Browsers MUST flag situations when this authentication fails and flag
situations when the target website is not authorized to accept the
identity being offered as this is a strong indication of fraud.
These requirements may serve as a basis for requirements for
preventing fraud in environments other than the web.

The IETF Secretariat.

--=-=-=--

From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Tue, 19 Aug 2008 12:37:28 -0400
Cc: [email-masked]
Subject: [Ietf-http-auth] Please Review version 09 of draft-hartman-webauth-phishing

Dear Eric:

I believe I have responded to many of the issues you raised during the
last call of draft-hartman-webauth-phishing and think things are at a
point where it would be productive for you to review the document and
see what issues remain.  I've tried to include a change history but
let me summarize major points below.  Some of these changes (and the
document as a whole) require review for consensus.  Please see my next
message to Alexey on that point.

* Section 1.1 and section 1.2 have been added to the document in order
  to help clarify the purpose of the document.  Section 1.1 is text
  that would need to gain some level of consensus and then be included
  in an ietf-wide last call.  I've tried to make it clear that this
  document is not calling for new security mechanisms to be developed.
  You reviewed a previous version of section 1.1 that actually did end
  up focusing on developing authentication mechanisms; my apologies
  for that wording.  It was a result of how I'm thinking about the
  layers involved, and I believe meant something very different to me
  than to anyone else who read it.

As an aside, Microsoft has been looking at strengthening their HTTP
authentication for the enterprise.  They managed to find much simpler
solutions to extending existing mechanisms than I had suspected were
possible.  I never expected that developing new security mechanisms
would be desirable, but I thought that more work would be needed on
how existing mechanisms fit into HTTP than appears to be needed in
practice.  I still think there is some limited work to do within the
scope of the IETF, but much less than I thought when I started this
document.

* I've taken your suggestion of splitting the concept of passwords
  into plaintext password protocols and passwords as a user interface
  concept.  This  is described in section 2.1 and I think has been
  integrated throughout the rest of the document.

* Rephrased all the discussion of UI to make it clear that we have no
  confidence (and evidence against) the idea that the UI concepts will
  work.  I've specifically removed any language that implies that UI
  suggestions are exhaustive; that was never my intent.

* Significantly worked on the text of the threat model in order to improve clarity.

* Worked on the clarity of the requirements.  In a number of cases I
  had proposed requirements that seemed likely to be true of potential
  solutions and that were easier to analyze than the actual
  constraints.  I've tried to remove that and actually state the base
  requirements.

* I've added a discussion of the pwdhash class of mechanisms in the
  discussion of mutual authentication.  My position is that pwdhash is
  an improvement over what we have today.  However the phishing
  possibilities opened up by not doing mutual authentication are
  serious enough that we want to eventually end up with solutions that
  support mutual authentication.  We don't want to discourage
  deployment of pwdhash or similar mechanisms though.  I think this is
  an issue where we need to come to some level of consensus.

* I've strengthened the text that makes it clear that zero-knowledge
  mechanisms are non-starters for IPR reasons.  If you read text in
  the current version as implying that this document recommends going
  down the zero-knowledge path, please point it out so I can remove
  it.

* I've integrated references to the W3C security context work in this space.

There is one set of comments I have intentionally not addressed.  I
disagree with you that the references section of this document should
be a reasonable biography of the space.  I'm happy to include
references that enhance specific new or existing text, but am not
interested in a survey of the space.  I think this issue was discussed
enough during the last call and the IESG telechat that I feel
confident it has been reviewed by the  community.

From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Wed, 13 Aug 2008 13:14:43 -0400
Subject: [Ietf-http-auth] Alignment of draft-hartman-webauth-phishing with W3C draft on user interface guidelines for usable authentication

As people here are probably aware, the W3C is last calling a draft on
user interface guidelines for web security context.  Please read
http://www.w3.org/TR/2008/WD-wsc-ui-20080724/ .

It seems like a really good document.  However I don't think it
obsoletes draft-hartman-webauth-phishing.  The W3 document is focused
on helping users get the indications they need for TLS to be useful
with today's authentication mechanisms.  My draft is focused on
requirements for authentication mechanisms that will reduce the impact
of mistakes.  If you believe that the W3C recommendations will be so
good that people will never be spoofed with a user agent that
implements them, then my draft is probably unnecessary.  I don't think
anyone--especially not the participants in the W3C security context
working group--believes that.  Instead, I believe we are all working
on a layered approach to security, trying to increase the probability
that when someone attempts to commit fraud, some mechanism somewhere
will detect that with high enough confidence that the user agent can
positively flag the situation.  It is critical that we do not generate
so many false positives that users lose confidence in fraud signals
when they do happen.

As such, I believe that new authentication mechanisms, security
context usability improvements, reputation systems and lists of known
frauds can all work together in improving web security.

It turns out that my draft is reasonably aligned with the W3C draft:

* They focus on creating situations where the user agent can raise a
  danger signal--interrupting the user's task and indicating that with
  high confidence something is risking the user's information.  My draft tries to create situations where the same signal can be raised by the authentication mechanism.

* The W3C draft recommends establishing trust in the UI via shared
  secrets.  They note that these mechanisms have questionable
  effectiveness.  I should note we're taking the same approach and
  continue my plan of accurately describing the limitations of this
  mechanism.

* The W3C draft seems consistent with the idea that making security
  context relevant to the transaction that the user is actually
  performing may help.

So, I propose to:

* Add a discussion of how these technologies can work together to the front.

* Add references from the discussion of trusted UI to the appropriate sections from the W3C draft.

In addition I will continue my plan to:

* Go through the document and clean up areas where the claims are stronger than is justified.

* Address Eric's comments about why we exclude mechanisms like pwdhash.

* Clean up and prepare for a discussion here and on the list.

I made some improvements before Dublin but other work got in the way
and I did not finish.  I expect to get to a version I think is ready
for discussion here within a couple of weeks.