Subject: [Ietf-http-auth] Who is interested in a BOF at IETF 66
From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Wed, 31 May 2006 17:19:27 -0400
List-Id: ietf-http-auth.osafoundation.org

Hi.  So far, there has not been a lot of interest expressed in my BOF
proposal.  I'm surprised by that given general interest in working on
the problem expressed at IETF 65.

It would be good to know who is interested in working on this problem
and who is interested in attending a BOF to discuss chartering a WG
sooner rather than later.  The BOF scheduling deadline is Monday.

--Sam

Date: Wed, 31 May 2006 09:45:22 +1000
From: Chris Drake <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re[2]: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
Cc: [email-masked]

Hi Sam,

Yep - we're on the same page - shared secrets is *how* I propose the
resource authenticates to the user.  The demo's slowly emerging...

Kind Regards,
Chris Drake

To: Chris Drake <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
From: Sam Hartman <[email-masked]>
Date: Tue, 30 May 2006 17:43:45 -0400
Cc: [email-masked]

>>>>> "Chris" == Chris Drake <[email-masked]> writes:
    Chris> Hi Nico, Yep - exactly, but you fell into the trap I was
    Chris> pleading for people to stop falling in to - someone's
    Chris> scammed us all by coining the term "trusted desktop".  Like
    Chris> you alluded to before - you can always paint any UI element
    Chris> in a <DIV>.  This doesn't have to be another browser window
    Chris> - it may as well be the windows "this desktop is locked"
    Chris> dialogue box.  Ultimately, you've got to authenticate the
    Chris> *resource* to the *user* BEFORE the user authenticates to
    Chris> the resource - and if you can do that properly in a
    Chris> "trusted desktop", then it follows that you MUST also be
    Chris> able to do it within a browser (or anything else living on
    Chris> the desktop) as well.

I think you are missing something critical from David and Jeff's
paper.  If the UI contains elements that the attacker does not know,
the attacker cannot spoof the UI.  They propose UI based on shared
secrets between the user and their browser.

I disagree that you need to authenticate the resource to the user
before the user to the resource.  There are two reasons.  Schemes like
Kerberos authenticate both parties more or less in the same exchange
and do so in a manner that is secure.  (Here I'm talking about the
ap-req exchange; I understand the classic Kerberos AS-req exchange is
vulnerable to dictionary attack).  Second, it is reasonable to
authenticate the user first provided that authentication to the wrong
resource has no negative (or very limited negative) consequences.

These two points combined are interesting.  If I authenticate to you
and if the sessions are properly bound together, then you can disclose
confidential information to me that helps establish your identity.
For example, if you know the names of my accounts and my most recent
transactions, then you are more likely to be my bank than a phisher.

It is of course absolutely critical that A man-in-the-middle cannot
use the authentication I have given them to access this confidential
information.

--Sam

Date: Tue, 30 May 2006 15:58:07 -0500
From: Nicolas Williams <[email-masked]>
To: Chris Drake <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
Cc: [email-masked], Sam Hartman <[email-masked]>

On Wed, May 31, 2006 at 06:48:10AM +1000, Chris Drake wrote:
> Yep - exactly, but you fell into the trap I was pleading for people to
> stop falling in to - someone's scammed us all by coining the term
> "trusted desktop".

My employer sells one, thus my use of it.  I don't care so much about
how proper the term is -- I care about what we can learn from softwared
labelled that way (pardon the pun).

>                     Like you alluded to before - you can always paint
> any UI element in a <DIV>.  This doesn't have to be another browser
> window - it may as well be the windows "this desktop is locked"
> dialogue box.  Ultimately, you've got to authenticate the *resource*
> to the *user* BEFORE the user authenticates to the resource - and if
> you can do that properly in a "trusted desktop", then it follows that
> you MUST also be able to do it within a browser (or anything else
> living on the desktop) as well.

Exactly.

BTW, Sam's idea is, I think, that a phisher can't spoof an unknown UI,
so provide for user-configurable local variations to secure UIs that the
phisher can't detect...  But I think Sam wants to assume that all UIs
can be spoofed nonetheless.

I.e., there may be several ways to address the UI spoofing issue.

More importantly, I think the assumption that all UIs can be spoofed is
quite likely wrong.

It may be that assuming that all UIs can be spoofed will lead to more
rigorous designs, but I'm not sure we really can get security w/o secure
UIs.

> I've built my double-blind privacy demo. I'm currently finishing my
> IdP service. My anti phishing demo (secure UI in a browser) is about
> 50% complete - hopefully it should be ready in a week or two.

Cool.

Nico
-- 

Date: Wed, 31 May 2006 06:48:10 +1000
From: Chris Drake <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re[2]: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
Cc: [email-masked], Sam Hartman <[email-masked]>

Hi Nico,

Yep - exactly, but you fell into the trap I was pleading for people to
stop falling in to - someone's scammed us all by coining the term
"trusted desktop".  Like you alluded to before - you can always paint
any UI element in a <DIV>.  This doesn't have to be another browser
window - it may as well be the windows "this desktop is locked"
dialogue box.  Ultimately, you've got to authenticate the *resource*
to the *user* BEFORE the user authenticates to the resource - and if
you can do that properly in a "trusted desktop", then it follows that
you MUST also be able to do it within a browser (or anything else
living on the desktop) as well.

I've built my double-blind privacy demo. I'm currently finishing my
IdP service. My anti phishing demo (secure UI in a browser) is about
50% complete - hopefully it should be ready in a week or two.

Kind Regards,
Chris Drake

Date: Tue, 30 May 2006 14:37:18 -0500
From: Nicolas Williams <[email-masked]>
To: Chris Drake <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
Cc: [email-masked], Sam Hartman <[email-masked]>

On Wed, May 31, 2006 at 05:15:56AM +1000, Chris Drake wrote:
> In case you've not seen this; here's a crosspost of mine from last
> week on the [email-masked] mailling list:

[A picture of a desktop, with a browser, within a browser, clearly the
'inner' browser being spoofed -- unless someone pushes a web desktop
idea, in which case no rule about no-browser-within-a-browser can save
the user from getting confused.]

I know, given a sufficiently large canvas I can always paint something
that looks like the right UI in it and spoof chrome.

I think the assumption should be: phishers can spoof any UI to some
degree of fidelity.  Make it hard to get close to 100% fidelity and
educate users and you can expect to have a secure UI.

How far from 100% UI fidelity can you keep the phishers?  And how far
must that be in order for mere mortal users to be able to wise up to
phishing?

I don't know.  But I think we need to answer these questions before we
declare chrome to be dead.  And I sorely hope that secure UIs are
feasible, because that can simplify a lot of things.

We should probably look at trusted desktops and see what we can learn
from them.

Note that in the GIF you link to it's pretty obvious that the 'inner'
browser is a spoof.  Thus, as an example of spoofing, it's not terribly
convincing of the premise that all UIs can be spoofed (unless we also
teach users to expect nested desktops/browsers).  Surely phishers can do
better, but they can never entirely get rid of whatever outer framing
the browser/desktop can provide (assuming unsubverted browser/OS, of
course, else we'd not be talking about phishing).

Nico
-- 

Date: Wed, 31 May 2006 05:15:56 +1000
From: Chris Drake <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re[2]: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
Cc: [email-masked], Sam Hartman <[email-masked]>

Hi Nico,

Wednesday, May 31, 2006, 3:56:20 AM, you wrote:

[snip]
> provided that the new browser function and HTML elements themselves are
[snip]

In case you've not seen this; here's a crosspost of mine from last
week on the [email-masked] mailling list:

---

Google published an "attack" on Secure Chrome that Jeffrey Altman
described earlier. I've put the relevant slide here:-
http://guardpuppy.com/BrowserChromeIsDead.gif
This came from http://www.w3.org/2005/Security/usability-ws/report
which links to Jeffrey Nelson & David Jeske's paper - their slides are
here:-
http://www.w3.org/2005/Security/usability-ws/presentations/37-google
Their paper here:-
http://www.w3.org/2005/Security/usability-ws/papers/37-google
The picture quite dramatically explains everything!

---

Pardon my silly filename - Chrome's not really dead - just a lot more
complicated than most people realize right now :-)

Kind Regards,
Chris Drake

Date: Tue, 30 May 2006 12:56:20 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
Cc: [email-masked]

On Tue, May 30, 2006 at 12:54:37PM -0400, Sam Hartman wrote:
>     Chris> You assume your identifier is made available to the relying
>     Chris> party (which, as you stated, violates your privacy).  This
>     Chris> isn't necessary.
> 
> Long term, I agree that you want to be able to selectively provide
> information to the relying party.  However I don't see this as an
> requirement for a solution to be useful.  There are a lot of cases
> where I am willing (and even interested) in disclosing my identity to
> a relying party.  If I can solve phishing in those cases, I think I've
> made significant progress.
> 
> I think I'm in an even better solution if I can eventually add
> protocol features so that identity is hidden.
> 
> I just don't see that as a requirement for the first version to be
> useful.

But surely it should be a requirement to not preclude this.

Of course, anything that involves or allows pluggable authentication
should suffice, as then we can always add complex multi-party systems
(e.g., involving IdPs) later.  And your solution does not preclude this,
provided that the new browser function and HTML elements themselves are
sufficiently extensible.

Nico
-- 

Date: Wed, 31 May 2006 03:17:57 +1000
From: Chris Drake <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re[2]: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
Cc: [email-masked]

Hi Sam,

Yes, I agree with your earlier identity solution statement.

I'm in Australia - I put "Eliot's father" into google - seems it's a
TV show I'd never heard of - is this a coincidence, or did you
deliberately pick "Eliot's father" to convey some personality
attributes?  I'd be correct to assume he's not so bright??

I have an interest in persuading BOF's not to "blinker" signon
thinking with negative statements about existing (admittedly failing)
technology (eg: passwords in browsers), because I believe I have an
elegant solution. I also have interest in Identity provider issues,
identity sharing, and privacy/anonymity including use of 1-click,
double-blind internet single signons.  Please "ping" me with a
personal email a few days before your BOF - I can't attend of course,
but I have some crude working demos of this stuff, and might have more
with nice polished interfaces for you to play with by the time you all
get together.

Kind Regards,
Chris Drake

To: Chris Drake <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
From: Sam Hartman <[email-masked]>
Date: Tue, 30 May 2006 12:54:37 -0400
Cc: [email-masked]

>>>>> "Chris" == Chris Drake <[email-masked]> writes:

    Chris> Sorry to weigh in so late on this one, but...
    >>> There is an internet person identifier: an email address.

    >> This is not a good identifier as it is not opaque, and was not
    >> created for that purpose. dick at sxip.comis a unique
    >> identifier, but it is also where I receive email. I will often
    >> want to uniquely identify myself without handing out an
    >> identifier that can be used in another way.

    Chris> You assume your identifier is made available to the relying
    Chris> party (which, as you stated, violates your privacy).  This
    Chris> isn't necessary.

Long term, I agree that you want to be able to selectively provide
information to the relying party.  However I don't see this as an
requirement for a solution to be useful.  There are a lot of cases
where I am willing (and even interested) in disclosing my identity to
a relying party.  If I can solve phishing in those cases, I think I've
made significant progress.

I think I'm in an even better solution if I can eventually add
protocol features so that identity is hidden.

I just don't see that as a requirement for the first version to be
useful.

To: Chris Drake <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing
From: Sam Hartman <[email-masked]>
Date: Tue, 30 May 2006 12:50:55 -0400
Cc: [email-masked]

>>>>> "Chris" == Chris Drake <[email-masked]> writes:

    Chris> Since you solicited comments...
    >> [Sent to the ADs; comments very much appreciated.]

    >> [snip] Any solution to the phishing problem will require UI
    >> changes in web browsers.

    >> [snip] There will never be a single identity that a user can
    >> use on the web

    Chris> I respectfully disagree.  We should focus on a solution
    Chris> without introducing barriers that might stifle creative
    Chris> thinking.

So, I think that solutions that work even if there is no single
identity will work fine if a single identity emerges provided that
they support use of identity from one site on another.

Do you disagree?

Date: Thu, 25 May 2006 20:02:53 +1000
From: Chris Drake <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing

Since you solicited comments...

>[Sent to the ADs; comments very much appreciated.]

> [snip] Any solution to the phishing problem will require UI changes
> in web browsers.

> [snip] There will never be a single identity that a user can use on
> the web 

I respectfully disagree.  We should focus on a solution without
introducing barriers that might stifle creative thinking.

Kind Regards,
Chris Drake

Date: Thu, 25 May 2006 19:45:20 +1000
From: Chris Drake <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father

Sorry to weigh in so late on this one, but...

>> There is an internet person identifier: an email address.

>This is not a good identifier as it is not opaque, and was not
>created for that purpose. dick at sxip.comis a unique identifier, but it
>is also where I receive email. I will often want to uniquely identify
>myself without handing out an identifier that can be used in another
>way.

You assume your identifier is made available to the relying party
(which, as you stated, violates your privacy).  This isn't necessary.

You and your identity service provider can determine what identifier
relying parties "see" - indeed - you probably don't want different
relying parties ever seeing your same identifier.

Kind Regards,
Chris Drake

Date: Wed, 24 May 2006 10:47:34 +0100
From: Thomas Roessler <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements
Mail-Followup-To: Sam Hartman <[email-masked]>, EKR <[email-masked]>, Digital Identity Exchange <[email-masked]>, [email-masked]
Sender: Thomas Roessler <[email-masked]>
Cc: Digital Identity Exchange <[email-masked]>, [email-masked]

On 2006-05-22 13:53:00 -0400, Sam Hartman wrote:

> I think we are in broad agreement that the interesting work
> in this space must involve the UI and is not principally a
> protocol problem.

I very much agree.

Incidentally, you may want have a look at the report from the
March W3C workshop:

  http://www.w3.org/2005/Security/usability-ws/report

We (W3C) are currently thinking about how to best charter work
that would specify some browser user interface components that
would have to be outside the control of web sites, and could be
used to make sure that users know (as opposed to look at on
their screens) where they are going to send their confidential
information.

Another element that we took as important from the workshop in
NYC is to enable user agents to reliably recognize HTML forms
that are used for authentication.  This ability would enable
user agents to manage credentials on behalf of the user. It
would also enable user agents to *not* submit credentials using
HTTP POST (even when entered through HTML forms), but instead
grab them and use them for whatever HTTP-level authentication
mechanism is used.  User agents could also do intelligent
things in the UI to make sure that users understand what they
are doing here.

PS: I'm currently at WWW 2006 in Edinburgh.  If any of you guys
want to chat more about this, please feel free to drop me a
line, so we can meet up somewhere.

Regards,
-- 
Thomas Roessler, W3C   <[email-masked]>

To: [email-masked]
From: Sam Hartman <[email-masked]>
Date: Tue, 23 May 2006 17:34:09 -0400
Subject: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing

[Sent to the ADs; comments very much appreciated.]

BOF Description:

At IETF 65, the DIX BOF demonstrated a consensus to work on a solution
to the problem that there are two many passwords for the web.  This
BOF proposes to develop a authentication architecture for the web and
other HTTP-based applications using existing technology with at most
small changes necessary to improve deployability that addresses this
problem.  One of the critical challenges facing the web today is the
problem of phishing, where users are directed to fraudulent websites
that request confidential information.  Any solution to the phishing
problem will require UI changes in web browsers.  However the HTTP
authentication architecture needs to work with these UI changes and
provide clear technical requirements for the security features
required from the UI.

Proposed Charter:
Web Authentication Resistant to Phishing (WARP)

Applications Area Director(s):

     Ted Hardie <[email-masked]>

     Lisa Dusseault <[email-masked]>

Applications Area Advisor:

     Lisa Dusseault <[email-masked]>
Mailing Lists:

   General Discussion: [email-masked]
   To Subscribe: [email-masked]
   In Body: In Body: subscribe
   Archive: http://www.imc.org/atom-syntax/mail-archive/

Description of Working Group:

   WARP is chartered to develop a method for using existing
   authentication technology to address two critical problems with
   authentication for the web and other HTTP-using applications.  The
   first problem is  that users must remember and maintain passwords
   for each HTTP service they use.  The second problem is that of
   phishing.  While browser UIs must change in order to combat the
   problem of phishing, WARP  must work with these UI changes and must
   provide clear technical requirements for the security features
   needed from authentication UI.  

   WARP will attack the problem of multiple passwords in two ways.
   First, it will be safe from a security standpoint to use  the same
   password with multiple HTTP services.    Second, WARP will support
   the concept of an identity provider, which is a service that
   clients can authenticate to and that can make assertions about
   their identity to third parties.  Employers authenticating their
   employees to business partners, distributed communities that share
   a concept of identity and services like Microsoft's Passport service
   demonstrate the wide variety of identity providers.  There will
   never be a single identity that a user can use on the web: many
   users would not choose to use the same identity in a work context
   that they use personally; similarly business relationships and
   policies  will dictate what identities services can accept.
   However WARP will support the concept of identity providers so
   that when policies permit, users can  minimize the number of
   identities they use.  WARP must support identity providers
   associated with servers and should support identity providers that
   have relationships with users.

   WARP needs to support mobile users, including users that use
   HTTP services from computers they have never used before.  WARP
   must not require per-service or per-identity-provider
   configuration.    While WARP is focused on passwords as that is
   expected to be the primary means  of authentication, WARP needs
   to support other credentials including smart cards, one-time
   passwords and zero-knowledge password protocols.    It is
   desirable that WARP be able to carry assertions about identity such
   as Security Assertion Markup Language assertions.

   The WARP working group will first write a problem statement and a
   requirements draft describing what it means to produce an
   authentication solution that is resistant to phishing.  Then WARP
   will choose a mandatory-to-implement authentication technology and
   protocol for the interaction between the identity provider and
   website.  

   WARP will coordinate with W3C  in working on the UI implications of
   phishing.    WARP will not propose specific UI nor specific
   extensions to HTML, although WARP may  recommend requirements for
   both as these requirements directly impact the security or
   deployability of WARP.

Deliverables:

* Problem statement for WARP

* Requirements for authentication resistant to phishing

*  WARP protocol document describing how an existing authentication
   system  is used  to meet the requirements of WARP.  This document
   may specify mandatory to implement modes in addition to those
   specified in the underlying system.

* A proposed standard describing how an identity is registered  with
  an identity provider or website.

* A proposed standard describing how an identity associated with a
  user is linked to an HTTP service's concept of an account.

BOF Agenda (2.5 hour slot requested):

* Presentation on the multiple passwords problem (10 minutes)
* Presentation on phishing (30 minutes)
* Presentation arguing  that existing technology is available (30
    minutes)
* Description of Charter (10 minutes)
* Discussion

Date: Mon, 22 May 2006 17:09:55 -0500
From: Nicolas Williams <[email-masked]>
To: Robert Sayre <[email-masked]>
Subject: Re: [Ietf-http-auth] New draft on anti-phishing requirements
Cc: [email-masked], [email-masked], Sam Hartman <[email-masked]>

On Mon, May 22, 2006 at 02:45:45PM -0400, Robert Sayre wrote:
> On 5/22/06, Nicolas Williams <[email-masked]> wrote:
> >
> >As Sam says: the browser must change.
> 
> Sure, and I suspect almost all browser vendors are willing to do that,
> but I think better security is an insufficient motivator for web
> authors. The requirement for mutual authentication was interesting to
> me. Groups extending Web formats and APIs[1] often encounter
> situations where a slightly elevated trust level for certain scripts
> would be useful.
> 
> Offering a carrot in the form of an extended JavaScript API for
> authenticated scripts would probably accelerate deployment of these
> new efforts.

Call it an "extended JavaScript API" or something else, it doesn't
matter what it is called, as long as it is:

a) a browser function
b) that can be invoked from an HTML UI element
c) and which ties into the actual protocol and authentication
   mechanism(s) used on the wire

Again, you can call the HTML UI element a form, or something else.

It is a carrot.  Those who don't want to use it won't have to.

But why not use it if it's available?

That this all has to live in the browser should be no obstacle.  That
web site authors have to detect its presence in their client browsers
and choose to use it should be no obstacle either.

Nico
-- 

Date: Mon, 22 May 2006 13:53:30 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re: [Ietf-http-auth] New draft on anti-phishing requirements
Cc: [email-masked], [email-masked]

On Mon, May 22, 2006 at 02:40:36PM -0400, Sam Hartman wrote:
> Assume that examplebank.com is a financial institution that acts as an
> identity provider for themselves and for business partners.  If they
> are given the ability to confirm that the website I'm going to is
> allowed to accept their identity, then they can give me an error if I
> attempt to use their identity with some random phishing site I got a
> link to in email.
> 
> You may disagree that this defense is important.  However it is a
> defense.

It amounts to a hook for white/black-listing.

It can only really work well as a whitelist, and only if the list is
kept very small.

ISPs acting as IdPs may not want to be in the blacklisting business,
and whitelisting won't be an option.

So I see this as an optional feature, not a requirement.

Nico
-- 

To: Sam Hartman <[email-masked]>
Subject: Re: [Ietf-http-auth] New draft on anti-phishing requirements
From: Eric Rescorla <[email-masked]>
Date: Mon, 22 May 2006 11:51:13 -0700
Cc: [email-masked], [email-masked]
Reply-To: EKR <[email-masked]>

Sam Hartman <[email-masked]> writes:

>>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:
>
>     >>  I don't believe that my requirements would require that the
>     >> relying party talk to the identity provider.  I believe that
>     >> assuming a reasonable set of trust anchors, having the web
>     >> browser ask the identity provider if the dnsname is allowed to
>     >> accept the identity.  That provides a protocol hook allowing
>     >> the identity provider to meet the requirement that it MUST
>     >> confirm the relying party is a valid relying party for the
>     >> identity.  If the relying party later proves that it has a
>     >> trusted certificate for this identity it meets the second
>     >> requirement.
>     >> 
>     >> Can you suggest clarifications to the text?
>
>     Eric> I don't think so because we don't agree on the
>     Eric> requirements. My point is that the relying party does not
>     Eric> need to prove its authorization to the identity provider in
>     Eric> any way in order to solve the phishing problem. 
>
> OK, we disagree on the requirements.  I believe that allowing the
> identity provider to validate the identity actually provides
> significant defenses against phishing.
>
>
> Assume that examplebank.com is a financial institution that acts as an
> identity provider for themselves and for business partners.  If they
> are given the ability to confirm that the website I'm going to is
> allowed to accept their identity, then they can give me an error if I
> attempt to use their identity with some random phishing site I got a
> link to in email.
>
> You may disagree that this defense is important.  However it is a
> defense.

And I never said otherwise, but just being a defense does not
make it a requirement.

-Ekr

Date: Mon, 22 May 2006 14:45:45 -0400
From: "Robert Sayre" <[email-masked]>
To: "Nicolas Williams" <[email-masked]>
Subject: Re: [Ietf-http-auth] New draft on anti-phishing requirements
Cc: [email-masked], [email-masked], Sam Hartman <[email-masked]>

On 5/22/06, Nicolas Williams <[email-masked]> wrote:
>
> As Sam says: the browser must change.

Sure, and I suspect almost all browser vendors are willing to do that,
but I think better security is an insufficient motivator for web
authors. The requirement for mutual authentication was interesting to
me. Groups extending Web formats and APIs[1] often encounter
situations where a slightly elevated trust level for certain scripts
would be useful.

Offering a carrot in the form of an extended JavaScript API for
authenticated scripts would probably accelerate deployment of these
new efforts.

[1] http://www.w3.org/2006/webapi/

--=20

Robert Sayre

To: EKR <[email-masked]>
Subject: Re: [Ietf-http-auth] New draft on anti-phishing requirements
From: Sam Hartman <[email-masked]>
Date: Mon, 22 May 2006 14:40:36 -0400
Cc: [email-masked], [email-masked]

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:

    >>  I don't believe that my requirements would require that the
    >> relying party talk to the identity provider.  I believe that
    >> assuming a reasonable set of trust anchors, having the web
    >> browser ask the identity provider if the dnsname is allowed to
    >> accept the identity.  That provides a protocol hook allowing
    >> the identity provider to meet the requirement that it MUST
    >> confirm the relying party is a valid relying party for the
    >> identity.  If the relying party later proves that it has a
    >> trusted certificate for this identity it meets the second
    >> requirement.
    >> 
    >> Can you suggest clarifications to the text?

    Eric> I don't think so because we don't agree on the
    Eric> requirements. My point is that the relying party does not
    Eric> need to prove its authorization to the identity provider in
    Eric> any way in order to solve the phishing problem. 

OK, we disagree on the requirements.  I believe that allowing the
identity provider to validate the identity actually provides
significant defenses against phishing.

Assume that examplebank.com is a financial institution that acts as an
identity provider for themselves and for business partners.  If they
are given the ability to confirm that the website I'm going to is
allowed to accept their identity, then they can give me an error if I
attempt to use their identity with some random phishing site I got a
link to in email.

You may disagree that this defense is important.  However it is a
defense.

To: [email-masked]
From: Sam Hartman <[email-masked]>
Date: Mon, 22 May 2006 14:27:24 -0400
Subject: [Ietf-http-auth] My BOF proposal from last week

Hi.

So, I haven't seen any substantial criticism of the general outline of
a BOF proposal I sent in last week.  It also has not attracted huge
support yet either.  I think that if we're still at the same point in
mid June we should seriously be questioning whether there is
sufficient interest.

However in the interest of giving the ADs accurate planning
information I'm going to submit a BOF request with similar content to
what I sent here last week.

I will forward that request to a broader audience.

I think that I also owe the list a more detailed problem statement
draft.  I hope to write this Friday and over the weekend.

--Sam

To: Sam Hartman <[email-masked]>
Subject: Re: [Ietf-http-auth] New draft on anti-phishing requirements
From: Eric Rescorla <[email-masked]>
Date: Mon, 22 May 2006 11:13:26 -0700
Cc: [email-masked], [email-masked]
Reply-To: EKR <[email-masked]>

Sam Hartman <[email-masked]> writes:

>>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:
>
>     Eric> 1. This is not principally a protocol problem but rather a
>     Eric> UI problem.  The protocol problems are generally well
>     Eric> understood. If the UI problems are solved, nearly any
>     Eric> protocol will work. In particular, there have been a number
>     Eric> of published designs [1] [2] that have mostly adequate
>     Eric> (though not perfect) protocols, though without complete
>
> I agree with you that this is not principally a protocol problem.  I'm
> not sure I agree that this is principally a UI problem; I think it is
> principally an architecture problem where you need the UI and protocol
> to cooperate.

I don't think I agree. Both of the papers I cited above provide
basically acceptable phishing defenses without changing the wire
protocol (they do change the password on the server, of
course). So, you could certainly do better with a protocol,
but I think we have existence proofs that one isn't needed.

>     Eric> 2. It's really important to distinguish between different
>     Eric> levels of attack.  Conventional phishing attacks rely on
>     Eric> generating a reference which appears to be valid but
>     Eric> actually points at the attacker's site. (This is why SSL/TLS
>     Eric> doesn't help much).
>
>     Eric>    But this is different from attacks in which the attacker
>     Eric> actually intercepts the user's communication. In these
>     Eric> settings, some sort of cryptographic protection for the
>     Eric> channel (a la HTTPS) or the messages (a la S-HTTP) must be
>     Eric> provided.
>
> Are there specific places in my document where you believe the distinction is critical?

Well, whenever you're talking about capturing credentials versus
capturing the session. Since non-reusable credentials protect
against credential capture but not against hijacking.

>     Eric> 3. The term "password equivalent" is a bit confusing. See
>     Eric> draft-iab-auth-mech for some discussion of strong versus
>     Eric> weak password equivalent.
>
> Your IAB draft seems to be focusing on what is stored rather than on
> what is transported in the protocol.  I don't have a problem if a
> server stores a weak password equivelant, but I do have a problem if
> the server stores or even receives a strong password equivelant.

Sure.

>
>     Eric> 6. You write:
>
>     Eric>    In situations where there is an identity provider that is
>     Eric> separate from the website as a relying party, additional
>     Eric> requirements are needed.  The identity provider MUST verify
>     Eric> that the website is a valid relying party for this identity.
>     Eric> Some identity providers will allow anyone to accept their
>     Eric> identity.  However particularly for financial institutions
>     Eric> and large service providers it will be common that only
>     Eric> authorized business partners will be able to accept the
>     Eric> identity.  The confirmation that the the relying party is
>     Eric> such a business partner will often be a significant part of
>     Eric> the value provided by the identity provider, so it is
>     Eric> important that the protocol enable this.  The relying party
>     Eric> MUST prove its identity is the one expected by the identity
>     Eric> provider.
>
>     Eric> I agree that this is is a likely business goal for identity
>     Eric> providers, but it's not required for protection against
>     Eric> phishing. Really, there are two interests here:
>
>     Eric> 1. To prove to the user (the guy with the browser) that he
>     Eric> is doing business with an "authorized" provider.  2. To
>     Eric> allow the identity provider to extract rents from the
>     Eric> relying parties.
>
>     Eric> Neither strictly requires the relying party authenticating
>     Eric> to the identity provider during the transaction. The first
>     Eric> can obviously done by issueing the relying party a long-term
>     Eric> credential. The second can be done by encrypting the
>     Eric> credential under the relying party's key. You don't
>     Eric> necessarily need the identity provider to receive a proof
>     Eric> that the relying party was able to decrypt it.
>
> I don't believe that my requirements would require that the relying
> party talk to the identity provider.  I believe that assuming a
> reasonable set of trust anchors, having the web browser ask the
> identity provider if the dnsname is allowed to accept the identity.
> That provides a protocol hook allowing the identity provider to meet
> the requirement that it MUST confirm the relying party is a valid
> relying party for the identity.  If the relying party later proves
> that it has a trusted certificate for this identity it meets the
> second requirement.
>
> Can you suggest clarifications to the text?

I don't think so because we don't agree on the requirements. My 
point is that the relying party does not need to prove its
authorization to the identity provider in any way
in order to solve the phishing problem. It may be required if
the identity provider wants to charge relying parties, but
even then it can be done without "confirming" as I indicated
above.

-Ekr

To: EKR <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements
From: Sam Hartman <[email-masked]>
Date: Mon, 22 May 2006 13:53:00 -0400
Cc: Digital Identity Exchange <[email-masked]>, [email-masked]

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:

    Eric> Sam Hartman <[email-masked]> writes:
    >>>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:
    Eric> Right. I indicated in my message, I'm not sure this draft
    Eric> dissects the reqts correctly.
    >>  Understood. However all your criticisms to date have been
    >> rather minor.

    Eric> Hmm... I didn't mean to give that impression. I certainly
    Eric> don't think the "it's all about UI" point is minor.

I am not sure whether it is minor.  I think we are in broad agreement
that the interesting work in this space must involve the UI and is not
principally a protocol problem.

--Sam

To: Sam Hartman <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements
From: Eric Rescorla <[email-masked]>
Date: Mon, 22 May 2006 10:25:42 -0700
Cc: Digital Identity Exchange <[email-masked]>, [email-masked]
Reply-To: EKR <[email-masked]>

Sam Hartman <[email-masked]> writes:

>>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:
>     Eric> Right. I indicated in my message, I'm not sure this draft
>     Eric> dissects the reqts correctly.
>
> Understood. However all your criticisms to date have been rather
> minor.

Hmm... I didn't mean to give that impression. I certainly don't
think the "it's all about UI" point is minor.

In any case, I'll try to write up a more substantial review when
I have some more time, probably in the next week or so.

-Ekr

To: EKR <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements
From: Sam Hartman <[email-masked]>
Date: Mon, 22 May 2006 13:22:37 -0400
Cc: Digital Identity Exchange <[email-masked]>, [email-masked]

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:
    Eric> Right. I indicated in my message, I'm not sure this draft
    Eric> dissects the reqts correctly.

Understood. However all your criticisms to date have been rather
minor.

Date: Mon, 22 May 2006 12:21:09 -0500
From: Nicolas Williams <[email-masked]>
To: Eric Rescorla <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements
Cc: Digital Identity Exchange <[email-masked]>, [email-masked], Sam Hartman <[email-masked]>

On Mon, May 22, 2006 at 10:12:49AM -0700, Eric Rescorla wrote:
> Sam Hartman <[email-masked]> writes:
> 
> >>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:
> >
> >     Eric> This is all pretty much laid out in the PwdHash and Felten
> >     Eric> papers.
> >
> > Sure.  My goal here is to describe a series of reasonably obvious
> > requirements so that we can evaluate solutions because we'e seen some
> > solutions like the ones you cite that meet a large number of these
> > conditions and we've seen other solutions that do not.
> 
> This was in response to Nico asking:
> 
>  "So, the protocols and the [secure] UI have to be "combined" -- can you
>  expand on this? "

I asked two other questions in the same paragraph.  All three were aimed
at rooting out whether you happen to be in broad agreement with Sam's
position.  This particular question was aimed at understanding in what
respects your view differs from Sam's.  Pointing me at these papers
doesn't answer my question :)

But I'll score you two as being in broad agreement anyways (if nothing
else it's a safe bet).

Nico
-- 

To: Nicolas Williams <[email-masked]>
Subject: Re: [Ietf-http-auth] New draft on anti-phishing requirements
From: Sam Hartman <[email-masked]>
Date: Mon, 22 May 2006 13:15:43 -0400
Cc: [email-masked], [email-masked]

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Mon, May 22, 2006 at 12:14:51PM -0400, Robert Sayre
    Nicolas> wrote:
    >> On 5/22/06, Eric Rescorla <[email-masked]> wrote:
    >> >1. This is not principally a protocol problem but rather a UI
    >> problem.  > The protocol problems are generally well
    >> understood. If the UI > problems are solved, nearly any
    >> protocol will work. In particular, > there have been a number
    >> of published designs [1] [2] that have mostly > adequate
    >> (though not perfect) protocols, though without complete >
    >> solutions to the UI problem.
    >> 
    >> One aspect of Sam's document that concerned me was the section
    >> on possible UI solutions. The requirements around spoofing seem
    >> directly opposed to the branding and usage patterns that web
    >> authors require.  HTTP authentication currently presents a
    >> modal dialog with no design control, and this is a significant
    >> reason most sites opt for form controls.

    Nicolas> Sam wants to put control over the UI in the web site's
    Nicolas> authors' hands.

    Nicolas> But he wants this UI tied intimately to a new browser
    Nicolas> function that is tied intimately to authentication
    Nicolas> protocols.

    >> Roy has previously mentio
Exactly.

I don't think we want today's http authentication dialogues.

Really. the secure UI could be as simple as any of the following:

* You choose what icon is used for bullets in a secure password form
  control when you create your account on a computer.  The standard
  bullet is used if it is a normal HTML control; the one you selected
  is used if it is a control that will make the password available
  only to the trusted authentication part of the browser.

*  You have a keystroke and mouse action that will hide non-trusted components of the UI.

I'm not a UI designer.  I don't know how to come up with a UI that
maximizes the probability that the user will actually notice when they
are typing a password into the wrong place.  I'm just trying to
demonstrate that we need not have something as clunky as current http
authentication dialogues.

To: Sam Hartman <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements
From: Eric Rescorla <[email-masked]>
Date: Mon, 22 May 2006 10:12:49 -0700
Cc: Digital Identity Exchange <[email-masked]>, [email-masked]
Reply-To: EKR <[email-masked]>

Sam Hartman <[email-masked]> writes:

>>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:
>
>     Eric> This is all pretty much laid out in the PwdHash and Felten
>     Eric> papers.
>
> Sure.  My goal here is to describe a series of reasonably obvious
> requirements so that we can evaluate solutions because we'e seen some
> solutions like the ones you cite that meet a large number of these
> conditions and we've seen other solutions that do not.

This was in response to Nico asking:

 "So, the protocols and the [secure] UI have to be "combined" -- can you
 expand on this? "

> I find specific requirements useful in such situations.

Right. I indicated in my message, I'm not sure this draft dissects the
reqts correctly.

-Ekr

To: EKR <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements
From: Sam Hartman <[email-masked]>
Date: Mon, 22 May 2006 13:10:56 -0400
Cc: Digital Identity Exchange <[email-masked]>, [email-masked]

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:

    Eric> This is all pretty much laid out in the PwdHash and Felten
    Eric> papers.

Sure.  My goal here is to describe a series of reasonably obvious
requirements so that we can evaluate solutions because we'e seen some
solutions like the ones you cite that meet a large number of these
conditions and we've seen other solutions that do not.

I find specific requirements useful in such situations.

To: EKR <[email-masked]>
Subject: Re: [Ietf-http-auth] New draft on anti-phishing requirements
From: Sam Hartman <[email-masked]>
Date: Mon, 22 May 2006 12:57:28 -0400
Cc: [email-masked], [email-masked]

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:

    Eric> 1. This is not principally a protocol problem but rather a
    Eric> UI problem.  The protocol problems are generally well
    Eric> understood. If the UI problems are solved, nearly any
    Eric> protocol will work. In particular, there have been a number
    Eric> of published designs [1] [2] that have mostly adequate
    Eric> (though not perfect) protocols, though without complete

I agree with you that this is not principally a protocol problem.  I'm
not sure I agree that this is principally a UI problem; I think it is
principally an architecture problem where you need the UI and protocol
to cooperate.

I also believe that as you point out, the protocol problems are mostly
solved.  I do think there is still work to do on getting a protocol
that is easy to deploy and that for example deals with enrollment,
etc.

    Eric> 2. It's really important to distinguish between different
    Eric> levels of attack.  Conventional phishing attacks rely on
    Eric> generating a reference which appears to be valid but
    Eric> actually points at the attacker's site. (This is why SSL/TLS
    Eric> doesn't help much).

    Eric>    But this is different from attacks in which the attacker
    Eric> actually intercepts the user's communication. In these
    Eric> settings, some sort of cryptographic protection for the
    Eric> channel (a la HTTPS) or the messages (a la S-HTTP) must be
    Eric> provided.

Are there specific places in my document where you believe the distinction is critical?

    Eric>    On a similar note, in current phishing attacks the
    Eric> attacker attempts to directly extract the user's
    Eric> password. If C-R mechanisms are used, a dictionary attack is
    Eric> natural. I assume that's why you wave in the direction of
    Eric> ZKPPs in S 4.3. However, it's worth asking whether we would
    Eric> be satisified with a system that was only partly
    Eric> strengthened against dictionary attacks (see [2] again).

Yes, probably.  I think we'd be satisfied with many things better than
what we have:-) I think we'd like to get a ZKPP, but I think we have
no reason to assume the IPR situation will be any better with this
effort.

    Eric> 3. The term "password equivalent" is a bit confusing. See
    Eric> draft-iab-auth-mech for some discussion of strong versus
    Eric> weak password equivalent.

Your IAB draft seems to be focusing on what is stored rather than on
what is transported in the protocol.  I don't have a problem if a
server stores a weak password equivelant, but I do have a problem if
the server stores or even receives a strong password equivelant.

    Eric> 4. I agree that server authentication is a good, but I'm not
    Eric> totally sold that it's a necessity. 

I will work on selling you or revising my position.
    Eric> 5. You write:

    Eric>    The risk of dictionary attack is always a significant
    Eric> concern for password systems.  Users can (but typically do
    Eric> not) minimize this risk by choosing long, hard to guess
    Eric> phrases for passwords.  The risk can be removed once a
    Eric> password is already established by using a zero-knowledge
    Eric> password protocol.

    Eric> This is not strictly true. A ZKPP removes the risk of
    Eric> offline dictionary attack, but not online attack. These
    Eric> attacks do still get mounted [3]

Yes, and I even know that:-) Thanks for pointing out that I was being
sloppy.  Will fix.

    Eric>    However the risk of dictionary attack is always present
    Eric> when setting up a new password or changing a password.
    Eric> Minimizing the number of services that use the same password
    Eric> and being extra careful to make sure the right server is
    Eric> used when establishing a password can minimize this risk.

    Eric> It's not clear to me that this helps, unless you're assuming
    Eric> a ZKPP.  If the attacker can capture a 
    Eric> hashed password or
    Eric> C-R handshake (which a phisher can generally force in
    Eric> non-ZKPP cases) then they can mount an offline dictionary
    Eric> attack anyway. Consider a typical design where the user has
    Eric> a master password P and then generates per-site passwords as
    Eric> H(Site-Name || P). In the C-R handshake, the user provides:

    Eric> H(challenge || H(Site-Name || P).

    Eric> Dictionary attacking this isn't significantly harder than
    Eric> dictionary attacking H(Site-Name || P).

I'm not sure what you meant by this above.  If you mean using
different passwords, I meant using different master passwords.  I
believe that actually does help.  But I was assuming a ZKPP in that
paragraph, and I believ in the ZKPP case, contacting the right server
does help.  I will update the text.

    Eric> 6. You write:

    Eric>    In situations where there is an identity provider that is
    Eric> separate from the website as a relying party, additional
    Eric> requirements are needed.  The identity provider MUST verify
    Eric> that the website is a valid relying party for this identity.
    Eric> Some identity providers will allow anyone to accept their
    Eric> identity.  However particularly for financial institutions
    Eric> and large service providers it will be common that only
    Eric> authorized business partners will be able to accept the
    Eric> identity.  The confirmation that the the relying party is
    Eric> such a business partner will often be a significant part of
    Eric> the value provided by the identity provider, so it is
    Eric> important that the protocol enable this.  The relying party
    Eric> MUST prove its identity is the one expected by the identity
    Eric> provider.

    Eric> I agree that this is is a likely business goal for identity
    Eric> providers, but it's not required for protection against
    Eric> phishing. Really, there are two interests here:

    Eric> 1. To prove to the user (the guy with the browser) that he
    Eric> is doing business with an "authorized" provider.  2. To
    Eric> allow the identity provider to extract rents from the
    Eric> relying parties.

    Eric> Neither strictly requires the relying party authenticating
    Eric> to the identity provider during the transaction. The first
    Eric> can obviously done by issueing the relying party a long-term
    Eric> credential. The second can be done by encrypting the
    Eric> credential under the relying party's key. You don't
    Eric> necessarily need the identity provider to receive a proof
    Eric> that the relying party was able to decrypt it.

I don't believe that my requirements would require that the relying
party talk to the identity provider.  I believe that assuming a
reasonable set of trust anchors, having the web browser ask the
identity provider if the dnsname is allowed to accept the identity.
That provides a protocol hook allowing the identity provider to meet
the requirement that it MUST confirm the relying party is a valid
relying party for the identity.  If the relying party later proves
that it has a trusted certificate for this identity it meets the
second requirement.

Can you suggest clarifications to the text?

    Eric> -Ekr

P.S. Thanks for the references.

--Sam

To: Nicolas Williams <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements
From: Eric Rescorla <[email-masked]>
Date: Mon, 22 May 2006 09:24:29 -0700
Cc: Digital Identity Exchange <[email-masked]>, [email-masked], Sam Hartman <[email-masked]>
Reply-To: EKR <[email-masked]>

Nicolas Williams <[email-masked]> writes:

> On Mon, May 22, 2006 at 08:58:23AM -0700, Eric Rescorla wrote:
>> 1. This is not principally a protocol problem but rather a UI problem.
>
> I've not read Sam's I-D yet, but he did present to me last week, so
> perhaps I can comment.
>
> This is not just a UI problem, and there are several problems.

I agree that there are several problems, but only some subset of those
problems are the "phishing" problem.

>>    The protocol problems are generally well understood. If the UI
>>    problems are solved, nearly any protocol will work. In particular,
>>    there have been a number of published designs [1] [2] that have mostly
>>    adequate (though not perfect) protocols, though without complete
>>    solutions to the UI problem. Indeed, a slightly different design
>>    for Digest (in which the absolute URI was hashed) combined with
>>    a secure UI would pretty much defeat current phishing attacks.
>
> So, the protocols and the [secure] UI have to be "combined" -- can you
> expand on this? 

This is all pretty much laid out in the PwdHash and Felten papers.

-Ekr

Date: Mon, 22 May 2006 11:18:31 -0500
From: Nicolas Williams <[email-masked]>
To: Robert Sayre <[email-masked]>
Subject: Re: [Ietf-http-auth] New draft on anti-phishing requirements
Cc: [email-masked], [email-masked], Sam Hartman <[email-masked]>

On Mon, May 22, 2006 at 12:14:51PM -0400, Robert Sayre wrote:
> On 5/22/06, Eric Rescorla <[email-masked]> wrote:
> >1. This is not principally a protocol problem but rather a UI problem.
> >  The protocol problems are generally well understood. If the UI
> >  problems are solved, nearly any protocol will work. In particular,
> >  there have been a number of published designs [1] [2] that have mostly
> >  adequate (though not perfect) protocols, though without complete
> >  solutions to the UI problem.
> 
> One aspect of Sam's document that concerned me was the section on
> possible UI solutions. The requirements around spoofing seem directly
> opposed to the branding and usage patterns that web authors require.
> HTTP authentication currently presents a modal dialog with no design
> control, and this is a significant reason most sites opt for form
> controls.

Sam wants to put control over the UI in the web site's authors' hands.

But he wants this UI tied intimately to a new browser function that is
tied intimately to authentication protocols.

> Roy has previously mentioned that 401 Unauthorized responses should be
> displayed to the user. This would allow a site to embed a new type of
> form control for authentication purposes... but as I mentioned above,
> this intermingling could increase the risk of spoofing.

As Sam says: the browser must change.  There are problems we cannot
solve using nothing more than HTML, HTTP/HTTPS and existing browser
functionality.

Nico
-- 

Date: Mon, 22 May 2006 11:14:57 -0500
From: Nicolas Williams <[email-masked]>
To: EKR <[email-masked]>, Digital Identity Exchange <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements
Cc: [email-masked], Sam Hartman <[email-masked]>

On Mon, May 22, 2006 at 08:58:23AM -0700, Eric Rescorla wrote:
> 1. This is not principally a protocol problem but rather a UI problem.

I've not read Sam's I-D yet, but he did present to me last week, so
perhaps I can comment.

This is not just a UI problem, and there are several problems.

Sam seems to assume that enrolment is not the problem he should be
solving, but that it is already solved (even if it isn't).

Given this assumption then the principal problem is about tying the UI
and the protocols.  And I couldn't agree more.

Now, that pesky enrolment problem...  Except it's not quite so pesky; it
requires that the user not get confused (conned) once [per-site?], at
enrolment.

Beyond that, users don't want to have to enroll every time, at least not
with passwords.  But now I must go read Sam's I-D.

>    The protocol problems are generally well understood. If the UI
>    problems are solved, nearly any protocol will work. In particular,
>    there have been a number of published designs [1] [2] that have mostly
>    adequate (though not perfect) protocols, though without complete
>    solutions to the UI problem. Indeed, a slightly different design
>    for Digest (in which the absolute URI was hashed) combined with
>    a secure UI would pretty much defeat current phishing attacks.

So, the protocols and the [secure] UI have to be "combined" -- can you
expand on this?  How is this not what Sam proposes?  Or are you two in
violent agreement?  :)

Nico
-- 

Date: Mon, 22 May 2006 12:14:51 -0400
From: "Robert Sayre" <[email-masked]>
To: EKR <[email-masked]>
Subject: Re: [Ietf-http-auth] New draft on anti-phishing requirements
Cc: [email-masked], [email-masked], Sam Hartman <[email-masked]>

On 5/22/06, Eric Rescorla <[email-masked]> wrote:
> 1. This is not principally a protocol problem but rather a UI problem.
>   The protocol problems are generally well understood. If the UI
>   problems are solved, nearly any protocol will work. In particular,
>   there have been a number of published designs [1] [2] that have mostly
>   adequate (though not perfect) protocols, though without complete
>   solutions to the UI problem.

One aspect of Sam's document that concerned me was the section on
possible UI solutions. The requirements around spoofing seem directly
opposed to the branding and usage patterns that web authors require.
HTTP authentication currently presents a modal dialog with no design
control, and this is a significant reason most sites opt for form
controls.

Roy has previously mentioned that 401 Unauthorized responses should be
displayed to the user. This would allow a site to embed a new type of
form control for authentication purposes... but as I mentioned above,
this intermingling could increase the risk of spoofing.

--=20

Robert Sayre

To: Sam Hartman <[email-masked]>
Subject: Re: [Ietf-http-auth] New draft on anti-phishing requirements
From: Eric Rescorla <[email-masked]>
Date: Mon, 22 May 2006 08:58:23 -0700
Cc: [email-masked], [email-masked]
Reply-To: EKR <[email-masked]>

1. This is not principally a protocol problem but rather a UI problem.
   The protocol problems are generally well understood. If the UI
   problems are solved, nearly any protocol will work. In particular,
   there have been a number of published designs [1] [2] that have mostly
   adequate (though not perfect) protocols, though without complete
   solutions to the UI problem. Indeed, a slightly different design
   for Digest (in which the absolute URI was hashed) combined with
   a secure UI would pretty much defeat current phishing attacks.

2. It's really important to distinguish between different levels of
   attack.  Conventional phishing attacks rely on generating a reference
   which appears to be valid but actually points at the attacker's
   site. (This is why SSL/TLS doesn't help much).

   But this is different from attacks in which the attacker actually
   intercepts the user's communication. In these settings, some sort
   of cryptographic protection for the channel (a la HTTPS) or the
   messages (a la S-HTTP) must be provided.

   On a similar note, in current phishing attacks the attacker 
   attempts to directly extract the user's password. If C-R mechanisms
   are used, a dictionary attack is natural. I assume that's why
   you wave in the direction of ZKPPs in S 4.3. However, it's 
   worth asking whether we would be satisified with a system that
   was only partly strengthened against dictionary attacks (see [2]
   again).

3. The term "password equivalent" is a bit confusing. See draft-iab-auth-mech
   for some discussion of strong versus weak password equivalent.

4. I agree that server authentication is a good, but I'm not totally
   sold that it's a necessity. It's principally important when you're
   changing credentials, but even then with a properly designed scheme
   where the server has a weakly password equivalent credential, the
   exposure is fairly limited. A standard practice is to hash the
   hostname into the password hash stored on the server.

5. You write:

   The risk of dictionary attack is always a significant concern for
   password systems.  Users can (but typically do not) minimize this
   risk by choosing long, hard to guess phrases for passwords.  The risk
   can be removed once a password is already established by using a
   zero-knowledge password protocol.

This is not strictly true. A ZKPP removes the risk of offline dictionary
attack, but not online attack. These attacks do still get mounted [3]

   However the risk of dictionary
   attack is always present when setting up a new password  or changing
   a password.  Minimizing the number of services that use the same
   password and being extra careful to make sure the right server is
   used when establishing a password can minimize this risk.

It's not clear to me that this helps, unless you're assuming a ZKPP.
If the attacker can capture a hashed password or C-R handshake (which
a phisher can generally force in non-ZKPP cases) then they can mount an
offline dictionary attack anyway. Consider a typical design where the user has
a master password P and then generates per-site passwords as
H(Site-Name || P). In the C-R handshake, the user provides:

H(challenge || H(Site-Name || P).

Dictionary attacking this isn't significantly harder than dictionary attacking
H(Site-Name || P).

6. You write:

   In situations where there is an identity provider that is separate
   from the website as a relying party, additional requirements are
   needed.  The identity provider MUST verify that the website  is a
   valid relying party for this identity.  Some identity providers will
   allow anyone to accept their identity.  However particularly for
   financial institutions and large service providers it will be common
   that only authorized business partners will be able to accept the
   identity.  The confirmation that the the relying party is such a
   business partner  will often be a significant part of the value
   provided by the identity provider, so it is important that the
   protocol enable this.  The relying party MUST prove its identity is
   the one expected by the identity provider.

I agree that this is is a likely business goal for identity providers,
but it's not required for protection against phishing. Really, there
are two interests here:

1. To prove to the user (the guy with the browser) that he is doing
   business with an "authorized" provider.
2. To allow the identity provider to extract rents from the relying
   parties.

Neither strictly requires the relying party authenticating to the
identity provider during the transaction. The first can obviously
done by issueing the relying party a long-term credential. The
second can be done by encrypting the credential under the relying
party's key. You don't necessarily need the identity provider to
receive a proof that the relying party was able to decrypt it.

-Ekr

   
[1] Blake Ross, Collin Jackson, Nicholas Miyake, Dan Boneh and John C. Mitchell
Stronger Password Authentication Using Browser Extensions.
Proceedings of the 14th Usenix Security Symposium, 2005.

[2] Halderman, J. A., Waters, B., and Felten, E. W. 2005. A convenient
method for securely managing passwords. In Proceedings of the 14th
international Conference on World Wide Web (Chiba, Japan, May 10 - 14,
2005). WWW '05. ACM Press, New York, NY, 471-479. DOI=
http://doi.acm.org/10.1145/1060745.1060815
      
[3] http://www.whitedust.net/article/27/Recent%20SSH%20Brute-Force%20Attacks/

To: [email-masked], [email-masked]
From: Sam Hartman <[email-masked]>
Date: Mon, 22 May 2006 10:28:08 -0400
Subject: [Ietf-http-auth] New draft on anti-phishing requirements

--=-=-=

Hi folks.

One thing that concerns me thinking about authentication and identity
on the web is how to make sure that we don't make phishing worse and
in fact to make sure that we significantly improve it.  I've written a
draft on requirements for web authentication solutions to minimize
phishing risk.  That draft has been submitted but is not yet in the ID
repository so I'm attaching a copy.

I believe that DIX, my proposal or anything else in this space needs
to meet these requirements or requirements that are very similar.
Some of these requirements apply to the protocol used between an
identity provider and a subject to authenticate to the identity
provider.  Other requirements apply to protocols used to carry
authentication or identity information between identity providers and
relying parties.  Some requirements apply to both.  The line is a bit
blurry in some solutions.

Comments are welcome.

--=-=-=
Content-Disposition: attachment; filename=draft-hartman-webauth-phishing-00.txt
Content-Description: Requirements for web authentication solutions to minimize
	phishing risk

Network Working Group                                         S. Hartman
Internet-Draft                                                       MIT
Expires: November 21, 2006                                  May 20, 2006

       Requirements for Web Authentication Resistant to Phishing
                 draft-hartman-webauth-phishing-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 21, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This memo proposes requirements for protocols between web identity
   providers and users and for requirements for protocols between
   identity providers and relying parties.  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 perform mutual authentication and flag

Hartman                 Expires November 21, 2006               [Page 1]

Internet-Draft          Web Phishing Requirements               May 2006

   situations when the target website is not authorized to accept the
   identity being offered as this is a strong indication of fraud.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  5
   3.  Threat Model . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1   Capabilities of Attackers  . . . . . . . . . . . . . . . .  6
     3.2   Attacks of Interest  . . . . . . . . . . . . . . . . . . .  7
   4.  Requirements for Preventing Phishing . . . . . . . . . . . . .  8
     4.1   Support for Passwords  . . . . . . . . . . . . . . . . . .  8
     4.2   Trusted UI . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.3   No Password Equivelents  . . . . . . . . . . . . . . . . .  9
     4.4   Authenticating the Server  . . . . . . . . . . . . . . . .  9
     4.5   Protecting Enrollment  . . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     6.1   Normative References . . . . . . . . . . . . . . . . . . . 14
     6.2   Informative References . . . . . . . . . . . . . . . . . . 14
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
       Intellectual Property and Copyright Statements . . . . . . . . 15

Hartman                 Expires November 21, 2006               [Page 2]

Internet-Draft          Web Phishing Requirements               May 2006

1.  Introduction

   Typically, web sites ask users to send a user name and password in
   order to log in and authenticate their identity to the website.  The
   user name and plaintext password is often sent over a TLS [RFC4346]
   encrypted connection.  As a result of this, the server learns the
   password and can pretend to be the user to any other system where the
   user has used the same password.  The security of passwords over TLS
   depends on making sure that the password is sent to the right,
   trusted server.  TLS implementations  typically confirm that the name
   entered by the user in the URL corresponds to the certificate as
   described in [RFC2818].

   One serious security threat on the web today is phishing.  Phishing
   is a form of fraud where an attacker convinces a user to provide
   confidential information to the attacker believing they are providing
   the information to a party they trust with that information.  For
   example, an email claiming to be from a user's bank may direct the
   user to go to a website  and verify account information.  The
   attacker captures the user name and password and potentially other
   sensitive information.  Domain names that look like target websites,
   links in email, and many other factors contribute to phishers'
   ability to convince users to trust them.

   It is useful to distinguish two targets of phishing.  Sometimes
   phishing is targeting web authentication credentials such as user
   name and password.  Sometimes phishing is targeting other
   confidential information.  This memo presents requirements that
   significantly reduce the effectiveness of the first category of
   phishing: these requirements  guarantee that even if the user
   authenticates to the wrong server, that server cannot impersonate the
   user to a third party.  However to combat phishing targeted at other
   confidential information the best we can do is try to help the user
   detect fraud before they release confidential information.

   So, the  approach taken by these requirements  is to handle these two
   types of phishing differently.  Users are given some trusted
   mechanism to determine whether they are typing their password into a
   secure browser component that will authenticate them to the web
   server or whether they are typing their password into a legacy
   mechanism that will send their password to the server.  If the user
   types a password into the trusted browser component, they have strong
   assurances that their password has not been disclosed and that the
   page returned from the web server was generated by a party that
   either knows their password or who is authenticated by an identity
   provider who knows their password.  The web server can then use
   confidential information known to the user and web server to enhance
   the user's trust in its identity beyond what is available given the

Hartman                 Expires November 21, 2006               [Page 3]

Internet-Draft          Web Phishing Requirements               May 2006

   social engineering attacks against TLS server authentication.  If a
   user enters their password into the wrong server  but discovers this
   before they give that server any other confidential information, then
   there exposure is very limited.

Hartman                 Expires November 21, 2006               [Page 4]

Internet-Draft          Web Phishing Requirements               May 2006

2.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Hartman                 Expires November 21, 2006               [Page 5]

Internet-Draft          Web Phishing Requirements               May 2006

3.  Threat Model

   This section describes the assumed capabilities of phishers,
   describes assumptions about web security and describes what
   vulnerabilities exist.

   We assume that the browser and operating system are secure and can be
   trusted by the end user.  There are many attacks against browsers and
   operating systems.  However without this assumption we cannot make
   progress  in securing web authentication.  So we will assume that
   browsers and operating systems are secure and note that other work to
   improve the security of browsers and operating systems is critical to
   the security of the entire web authentication system.

   We assume that users have limited motivation to combat phishing.
   Users cannot be expected to read the source of web pages, understand
   how DNS works well enough to look out for spoofed domains, or
   understand URI encoding.  Users  do not typically understand
   certificates and cannot make informed decisions  about whether the
   subject name in a certificate corresponds to the entity they are
   attempting to communicate with.

3.1  Capabilities of Attackers

   Attackers can convince the user to go to a website of their choosing.
   Since the attacker controls the web site and since the user chose to
   go to the website  the TLS certificate will verify and the website
   will appear to be secure.  The certificate will typically not be
   issued to the entity the user thinks they are communicating with, but
   as discussed above, the user will not notice this.

   The attacker can convincingly replicate any part of the UI of the
   website being spoofed.  The attacker can also spoof trust markers
   such as the security lock, URL bar and other parts of the browser UI.
   There is one limitation to the attacker's ability to replicate UI.
   The attacker cannot replicate a UI that depends on information the
   attacker does not know.  For example, an attacker could generally
   replicate the UI of a banking site's login page.  However the
   attacker probably could not replicate the account summary page until
   the attacker  learned the user name and password.

   The attacker can convince the user to do anything with the phishing
   site that they would do with the real target site.  As a consequence,
   if we want to avoid the user giving the attacker their password, we
   must transition to a solution where the user would not give the real
   target site their password.  Instead they will need to
   cryptographically prove that they know their password without
   revealing it.

Hartman                 Expires November 21, 2006               [Page 6]

Internet-Draft          Web Phishing Requirements               May 2006

3.2  Attacks of Interest

   The primary attack of interest is an attack in which the user sends
   confidential information to an unintended recipient.

   Another significant attack is an attack in which a recipient gains
   sufficient credentials to impersonate the user to other recipients.
   The obvious version of this attack is when the recipient learns the
   password of the user.  However even giving the recipient a time-
   limited token that can be used to impersonate the user would be an
   instance of this attack.  Note that some authentication systems such
   as Kerberos [RFC4120] provide a facility to delegate the ability to
   act as the user to the target of the authentication.  Such a facility
   when used with an inappropriately trusted target would be an instance
   of this attack.

   Of less serious concerns at the present time are attacks on data
   integrity where a phisher provides false or misleading information to
   a user.

Hartman                 Expires November 21, 2006               [Page 7]

Internet-Draft          Web Phishing Requirements               May 2006

4.  Requirements for Preventing Phishing

   This section describes requirements for web authentication solutions.
   These solutions are intended to prevent phishing targeted at
   obtaining web authentication credentials.  These requirements will
   make it more difficult for phishers to target other confidential
   information.

   The requirements discussed here are similar to the principles
   outlined in "Limits to Anti-Phishing" [ANTIPHISHING].  Most of this
   work was discovered independently but work from that paper has been
   integrated where appropriate.  Google's perspective on phishing is
   very interesting because of their operational experience.

4.1  Support for Passwords

   The web authentication solution MUST support passwords and MUST be
   secure even when passwords are commonly used.  In many environments,
   users need the ability to walk up to a computer they have never used
   before and log in to a website.  Carrying a smart card or USB token
   significantly increases the deployment cost of the website and
   decreases user convenience.

   IT is desirable that a solution support other forms of authentication
   such as smart cards and one-time passwords as these are useful in
   some environments.

4.2  Trusted UI

   Users need the ability to trust components of the UI in order to know
   that the UI is being presented  by a trusted component of the
   browser.  The primary concern is to  make sure that the user knows
   the password is being given to trusted software rather than being
   filled into an HTML form element that will be sent to the server.

   There are three basic approaches to establishing a trusted UI.  The
   first is to use a dynamic UI based on a secret known by the UI; the
   Google paper [ANTIPHISHING] recommends this approach.  A second
   approach is to provide a UI action  that highlights  trusted or non-
   trusted components in some way.  This could work similarly to the
   Expose  feature in Apple's OS X where a keystroke visually
   distinguishes structural elements of the UI.  Of course such a
   mechanism would only be useful if users actually used it.  Finally,
   the multi-level security community has extensive research in
   designing UIs  to display classified, compartmentalized information.
   It is critical that these UIs be able to label information and that
   these labels not be spoofable.

Hartman                 Expires November 21, 2006               [Page 8]

Internet-Draft          Web Phishing Requirements               May 2006

   In addition to making sure that passwords are only given to trusted
   components, trusted UI will play another important role in the
   overall solution to phishing.  Once the user is authenticated to the
   website then the website can use trusted UI based on a secret shared
   between the user and website to convince the user that they have
   authenticated to the correct site.  This use of trusted UI dependes
   critically on the requirements of Section 4.4 to guarantee that the
   phisher cannot obtain the secret.  It is tempting to use this form of
   trusted UI before authentication.  For example, a website could
   request a user name and then  display  information  based on a secret
   for that user before accepting a password.  The problem with this
   approach is that phishers can obtain this information, because it can
   be obtained without knowing the password.  However if the trusted UI
   is displayed after authentication then phishers could not obtain the
   trusted UI.  This is one of the many reasons why it is important to
   prevent phishing targeted at authentication credentials.

4.3  No Password Equivelents

   A critical requirement is that when a user authenticates to a
   website, the website MUST NOT receive a password equivalent.  A
   password equivalent is anything that  would allow a phisher to
   authenticate to a third party as the user.

   There are two implications of this requirement.  First, strong
   cryptographic authentication protocol needs to be used instead of
   sending the password  encrypted over TLS.  The zero-knowledge class
   of password protocols  such as those discussed in section 8 of the
   IAB authentication mechanisms document [IABAUTH] seem potentially
   useful in this case.  Note that mechanisms in this space tend to have
   significant deployment problems because of intellectual property
   issues.

   The second implication of this requirement is that if an
   authentication token is presented to a website,  the website MUST NOT
   be able to modify the token to authenticate as the user to  a third
   party.  The party generating the token must cryptographically bind it
   to either the website that will receive the token or to a key known
   only to the user.  If tokens are bound to keys, the user MUST prove
   knowledge of this key as part of the authentication process.  The key
   MUST not be disclosed to the server unless the token  is bound to the
   server and the key is only used with that token.

4.4  Authenticating the Server

   The Google paper [ANTIPHISHING] describes a requirement for mutual
   authentication.  A common phishing practice is to accept a user name
   and password as part of an attempt to make the phishing site

Hartman                 Expires November 21, 2006               [Page 9]

Internet-Draft          Web Phishing Requirements               May 2006

   authentic.  The real target is some other confidential information.
   The user name and password are captured, but are not verified.  After
   the user name and password are entered, the phishing site collects
   other confidential information.

   Authentication of the server at the TLS level and authentication  of
   the client within the TLS session is not sufficient.  AS discussed
   previously the attacker can direct the user to a site  that the
   attacker controls so the TLS authentication will succeed.  Then the
   attacker can either ignore the authentication  or  attempt to tunnel
   the authentication exchange  back to the real site.  If successful
   such tunneling could allow the attacker to access the real site as
   the user.

   If authentication is based on a shared secret such as a password,
   then the authentication protocol MUST prove that the secret or a
   suitable verifier is known by both parties.  Interestingly the
   existence of a shared secret will provide better protection that the
   right server is being contacted than if public key credentials are
   used.  By their nature, public key credentials allow parties to be
   contacted without a prior security association.  In protecting
   against phishing targeted at obtaining other confidential
   information, this may prove a liability.  However public key
   credentials provide strong protection against phishing targeted at
   obtaining authentication credentials because they  are not vulnerable
   to dictionary attacks.  Such dictionary attacks are a significant
   weakness of shared secrets such as passwords intended to be
   remembered by humans.

   In situations where there is an identity provider that is separate
   from the website as a relying party, additional requirements are
   needed.  The identity provider MUST verify that the website  is a
   valid relying party for this identity.  Some identity providers will
   allow anyone to accept their identity.  However particularly for
   financial institutions and large service providers it will be common
   that only authorized business partners will be able to accept the
   identity.  The confirmation that the the relying party is such a
   business partner  will often be a significant part of the value
   provided by the identity provider, so it is important that the
   protocol enable this.  The relying party MUST prove its identity is
   the one expected by the identity provider.

   This set of requirements is incompatible with a model where the
   identity of the relying party is hidden from the identity provider.
   Sites that need this level of privacy may wish to provide their own
   identities or to provide aggregation  points that can separate the
   identity provider from the site.  The aggregation point needs to know
   the relying party, but the identity provider only needs to know the

Hartman                 Expires November 21, 2006              [Page 10]

Internet-Draft          Web Phishing Requirements               May 2006

   aggregation point.

   To prevent attacks where the authentication is tunneled, the protocol
   between the web browser and website MUST bind the authentication
   exchange to the channel created by the TLS session.  The general
   concept behind channel binding is discussed in section 2.2.2 of
   [BTNS].  This paragraph needs to be expanded to point to proposals
   for doing channel binding with TLS. xxx

4.5  Protecting Enrollment

   One area of particular vulnerability to phishing is enrollment.
   Protecting against phishing targeted at obtaining other confidential
   information as a new service is established is outside the scope of
   this document.  If confidential information such as credit card
   numbers are provided as part of account setup, then this may be a
   target for phishing.

   However there is one critical aspect in which enrollment impacts the
   security of authentication.  During enrollment, a password is
   typically established for an account at an identity provider.  The
   process of establishing a password MUST NOT  provide a password
   equivalent to the identity provider.  That is, the identity provider
   MUST NOT gain enough information to impersonate the user to a third
   party while establishing a password.

Hartman                 Expires November 21, 2006              [Page 11]

Internet-Draft          Web Phishing Requirements               May 2006

5.  Security Considerations

   This memo discusses the security of  web authentication and how to
   minimize the risk of phishing  in web authentication systems.  This
   section discusses the security of the overall system  and discusses
   how components of the system that are not directly within the scope
   of this document affect the  security of web transactions.  This
   section also discusses residual risks that remain even when the
   requirements proposed here are implemented.

   The approach taken here is to separate the problem of phishing into
   phishing targeted at web authentication credentials and phishing
   targeted at other information.  Users are given some trusted
   mechanism to determine whether they are typing their password into a
   secure browser component that will authenticate them to the web
   server or whether they are typing their password into a legacy
   mechanism that will send their password to the server.  If the user
   types a password into the trusted browser component, they have strong
   assurances that their password has not been disclosed and that the
   page returned from the web server was generated by a party that
   either knows their password or who is authenticated by an identity
   provider who knows their password.  The web server can then use
   confidential information known to the user and web server to enhance
   the user's trust in its identity beyond what is available given the
   social engineering attacks against TLS server authentication.  If a
   user enters their password into the wrong server  but discovers this
   before they give that server any other confidential information, then
   there exposure is very limited.

   This model assumes that the browser and operating system are a
   trusted component.  As discussed in Section 3, there are numerous
   attacks against host security.  Appropriate steps should be taken to
   minimize these risks.  If the host security is compromised, the
   password can be captured as it is typed by the user.

   This model assumes that users will  only enter their passwords into
   trusted browser components.  There are  several potential problems
   with this assumption.  First, users need to understand the UI
   distinction and know what it looks like when they are typing into a
   trusted component and what a legacy HTML form looks like.  Users must
   care enough about the security of their passwords to only type them
   into trusted components.  The browser must be designed in such a way
   that the server cannot create a UI component that appears to be a
   trusted component but is actually a legacy HTML form; Section 4.2
   discusses this requirement.

   IN addition,  a significant risk that users will type their password
   into legacy HTML forms comes from the incremental deployment of any

Hartman                 Expires November 21, 2006              [Page 12]

Internet-Draft          Web Phishing Requirements               May 2006

   web authentication technology.  Websites will need a way to work with
   older web browsers that do not yet support mechanisms that meet these
   requirements.  Not all websites will immediately adopt these
   mechanisms.  Users will sometimes browse from computers that have
   mechanisms meeting these requirements and sometimes from older
   browsers.  They only gain protection from phishing  when they type
   passwords into trusted components.  If a password is sometimes used
   with websites  that meet these requirements and sometimes with legacy
   websites, and if the password is captured by a phisher targeting a
   legacy website, then that captured password can be used even on
   websites meeting these requirements.  Similarly, if a user is tricked
   into using HTML forms when they should not, passwords can be exposed.
   Users can significantly reduce this risk by using different passwords
   for websites that use trusted browser authentication than for those
   that still use HTML forms.

   The risk of dictionary attack is always a significant concern for
   password systems.  Users can (but typically do not) minimize this
   risk by choosing long, hard to guess phrases for passwords.  The risk
   can be removed once a password is already established by using a
   zero-knowledge password protocol.  However the risk of dictionary
   attack is always present when setting up a new password  or changing
   a password.  Minimizing the number of services that use the same
   password and being extra careful to make sure the right server is
   used when establishing a password can minimize this risk.

Hartman                 Expires November 21, 2006              [Page 13]

Internet-Draft          Web Phishing Requirements               May 2006

6.  References

6.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

6.2  Informative References

   [ANTIPHISHING]
              Nelson, J. and D. Jeske, "Limits to Anti Phishing",
              January 2006.

              Proceedings of the W3c Security and Usability Workshop; ht
              tp://www.w3.org/2005/Security/usability-ws/papers/
              37-google/'

   [BTNS]     Touch, J., "Problem and Applicability Statement for Better
              Than Nothing Security",
              draft-ietf-btns-prob-and-applic-02.txt (work in progress),
              February 2006.

   [IABAUTH]  Rescorla, E., "A Survey of Authentication Mechanisms",
              draft-iab-auth-mech-05.txt (work in progress),
              February 2006.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              July 2005.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

Author's Address

   Sam Hartman
   Massachusetts Institute of Technology

   Email: [email-masked]

Hartman                 Expires November 21, 2006              [Page 14]

Internet-Draft          Web Phishing Requirements               May 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Hartman                 Expires November 21, 2006              [Page 15]


--=-=-=--

Date: Wed, 17 May 2006 17:53:41 +0200
From: Eliot Lear <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re: Identifiers -- Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
Cc: [email-masked]

Sam,
> I'm not sure how you can solve password security without binding it to
> an identifier.
>   
To be clear, I'm not saying have NO identifiers but rather that you
should use the ones you've got for maximum effect.  I  claim that if the
authenticator knows already who you are claiming to be because of your
existing user name, then it can reference off of that information to
query your authentication store to ensure you are who you say you are. 
Sound familiar?  I'm not claiming originality here.
> It may be the case that we can only solve the problem for identifiers
> that are meaningful to the server.  I think what I proposed would
> scale down to that fairly easily if there is insufficient interest (or
> success) in making it work with identifiers meaningful to the client.
>
>   
And I agree with much of your thesis in terms of the problem statement. 
In fact we share a lot of ground on the solution space!  I am no
Kerberos expert but it has a lot of the characteristics I would look
for.  It must be possible to not trust the PC, for example.  Indeed I
like your proposed outline for a BoF to the point where I'd like to put
together a submission at some point when is appropriate in the solution
space.  As you point out, realm configuration issues are tricky.  But I
would also like to understand the trust relationships with inter-realm
Kerberos more, and who can glean what knowledge by my snooping.

Think about the case of a patient with AIDS who goes to a web site of an
organization that specializes in support of AIDS patients.  Who learns
that this person has authenticated himself to this site or even visited it?

Eliot

To: Eliot Lear <[email-masked]>
Subject: Re: Identifiers -- Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
From: Sam Hartman <[email-masked]>
Date: Wed, 17 May 2006 10:25:52 -0400
Cc: [email-masked]

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> This is why I say that use of existing identifiers without
    Eliot> introducing a new global name space is a more prudent way
    Eliot> to go, even if it doesn't accomplish as much. The binding
    Eliot> is maintained privately between two parties.

I'm not sure how you can solve password security without binding it to
an identifier.

It may be the case that we can only solve the problem for identifiers
that are meaningful to the server.  I think what I proposed would
scale down to that fairly easily if there is insufficient interest (or
success) in making it work with identifiers meaningful to the client.
I do agree that you want to construct your solution in such a way that
you don't fail simply because you are unable to solve the problem of
binding an identifier meaningful to the client to an account on the
website.

--Sam

Date: Wed, 17 May 2006 08:33:03 -0400
Subject: Re: Identifiers -- Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
From: Peter Davis <[email-masked]>
To: Sam Hartman <[email-masked]>, Eliot Lear <[email-masked]>
Cc: [email-masked]

On 5/16/2006 5:22 PM, "Sam Hartman" <[email-masked]> wrote:

> * the password

While I'm pretty certain you did not intend to convey this as a literal, we
should not narrowly constrain the BOF to considering passwords as the only
security token mechanism. :-P

=peterd  ( http://xri.net/=peterd )

Date: Wed, 17 May 2006 08:39:35 +0200
From: Eliot Lear <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re: Identifiers -- Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
Cc: [email-masked]

Sam,

> OK.  I believe that my proposed BOF agenda is consistent with this
> approach.  I do actually agree with those who believe that identifier
> management is an issue to consider.
>
> I'm hoping that users can remember:
> * an identifier
> *  the identity provider (I think of this as the domain part of an email addres;
> people at large ASPs I've talked to say that they might not be
> comfortable with that approach; the DIX community wants a URI) 
> * the password
>   
If we can solve the whole kitten caboodle, I'm all for it. However, I
think such identifiers are problematic because if you have them then you
must secure the binding. It means that there is a third party who the
other two must trust. I would therefore like to understand three things:

   1. Am I wrong in my analysis above?
   2. If not, is this indeed the problem that Liberty Alliance addressed?
   3. If it is, why haven't we seen broad adoption?

I obviously have my own opinions of the above (no, yes, 3rd party
relationships are HARD).

This is why I say that use of existing identifiers without introducing a
new global name space is a more prudent way to go, even if it doesn't
accomplish as much. The binding is maintained privately between two parties.

Eliot

To: Eliot Lear <[email-masked]>
Subject: Re: Identifiers -- Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
From: Sam Hartman <[email-masked]>
Date: Tue, 16 May 2006 17:22:14 -0400
Cc: [email-masked]

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> Sam Hartman wrote:
    >> What do you mean by solve the problem of the password?
    >> 
    Eliot> My point is that username is not something you need to
    Eliot> focus on.  Rather what is needed is a way for a
    Eliot> server/authenticator to make use of that username to
    Eliot> perform an authentication operation.  Consider for example
    Eliot> how OTPs work.  Now consider a messaging interface to
    Eliot> derive the correct OTP for a given service based on
    Eliot> username.  Also consider how you secure the communication
    Eliot> to the OTP subsystem itself.

OK.  I believe that my proposed BOF agenda is consistent with this
approach.  I do actually agree with those who believe that identifier
management is an issue to consider.

I'm hoping that users can remember:
* an identifier
*  the identity provider (I think of this as the domain part of an email addres;
people at large ASPs I've talked to say that they might not be
comfortable with that approach; the DIX community wants a URI) 
* the password

I agree that when using a home computer, having the system store user
id is a good idea.

Date: Tue, 16 May 2006 22:24:21 +0200
From: Eliot Lear <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re: Identifiers -- Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
Cc: [email-masked]

Sam Hartman wrote:
> What do you mean by solve the problem of the password?
>   
My point is that username is not something you need to focus on.  Rather
what is needed is a way for a server/authenticator to make use of that
username to perform an authentication operation.  Consider for example
how OTPs work.  Now consider a messaging interface to derive the correct
OTP for a given service based on username.  Also consider how you secure
the communication to the OTP subsystem itself.

What does this get you?  Very little FORCED (con)federation limited to
registration actions, a reduced problem space, and hence a more
manageable solution space.

Eliot

To: Eliot Lear <[email-masked]>
Subject: Re: Identifiers -- Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
From: Sam Hartman <[email-masked]>
Date: Tue, 16 May 2006 15:26:26 -0400
Cc: [email-masked]

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> So, first an admission: The problem really wasn't just
    Eliot> Eliot's dad, but Eliot himself.

    Eliot> Now to restate the problem that he/I have:

    Eliot> There are too many damn passwords and keys.  This says very
    Eliot> little about identifiers at all.  In fact, web browsers and
    Eliot> mail readers do a darn good job at remembering identifiers,
    Eliot> and if they do that much and no more to solve the problem I
    Eliot> don't see a security concern.  The problem remains the
    Eliot> password.  If you solve only that problem and do so
    Eliot> securely you've moved the ball substantially.

What do you mean by solve the problem of the password?

Date: Tue, 16 May 2006 13:54:00 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
Cc: [email-masked], [email-masked]

On Tue, May 16, 2006 at 02:47:12PM -0400, Sam Hartman wrote:
> >>>>> "Cat" == Cat Okita <[email-masked]> writes:
>     >> If you need high assurance out of a particular identifier then
>     >> use an identity provider that provides that assurance.  I doubt
>     >> that banks will ever allow identities issued by non-banks as an
>     >> example because doing so would open them up to huge liability.
> 
>     Cat> Do banks in your country not require at least some form of
>     Cat> government issued identification in order to open an account?
> 
> Sorry, I don't see the US government becoming a web identity provider
> right now.  If they do, then yes, banks might accept those identities.

USPS offices are fairly ubiquitous and often have notaries public on
staff, they know how to check IDs (because they process passport
applications), they could sell a certification service.  They don't.

To: Cat Okita <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
From: Sam Hartman <[email-masked]>
Date: Tue, 16 May 2006 14:47:12 -0400
Cc: [email-masked], [email-masked]

>>>>> "Cat" == Cat Okita <[email-masked]> writes:

    >> If you need high assurance out of a particular identifier then
    >> use an identity provider that provides that assurance.  I doubt
    >> that banks will ever allow identities issued by non-banks as an
    >> example because doing so would open them up to huge liability.

    Cat> Do banks in your country not require at least some form of
    Cat> government issued identification in order to open an account?

Sorry, I don't see the US government becoming a web identity provider
right now.  If they do, then yes, banks might accept those identities.

Date: Tue, 16 May 2006 20:41:01 +0200
From: Eliot Lear <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Identifiers -- Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
Cc: [email-masked]

So, first an admission:

The problem really wasn't just Eliot's dad, but Eliot himself.

Now to restate the problem that he/I have:

There are too many damn passwords and keys.  This says very little about
identifiers at all.  In fact, web browsers and mail readers do a darn
good job at remembering identifiers, and if they do that much and no
more to solve the problem I don't see a security concern.  The problem
remains the password.  If you solve only that problem and do so securely
you've moved the ball substantially.

Eliot

Date: Tue, 16 May 2006 14:40:46 -0400 (EDT)
From: Cat Okita <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
Cc: [email-masked], [email-masked]
Reply-To: Cat Okita <[email-masked]>

On Tue, 16 May 2006, Sam Hartman wrote:
>>>>>> "Cat" == Cat Okita <[email-masked]> writes:
>    Cat> This is a dreadful identifier.  Email addresess are not
>    Cat> unique across time, are often reused, and very easily
>    Cat> mistaken - I'm sure I'm not the only person that's received
>    Cat> email for a previous owner - or had their email sent to the
>    Cat> current owner of any given address.
> Perhaps, but consider how well it works in practice.  There are many
> many websites that will be happy to reset a password and send it to an
> email address.

I'm not sold on that being a feature ;>  Having my password sent to
somebody else isn't my idea of a good thing.

> If you need high assurance out of a particular identifier then use an
> identity provider that provides that assurance.  I doubt that banks
> will ever allow identities issued by non-banks as an example because
> doing so would open them up to huge liability.

Do banks in your country not require at least some form of government 
issued identification in order to open an account?

cheers!
==========================================================================
"A cat spends her life conflicted between a deep, passionate and profound
desire for fish and an equally deep, passionate and profound desire to
avoid getting wet.  This is the defining metaphor of my life right now."

To: Cat Okita <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
From: Sam Hartman <[email-masked]>
Date: Tue, 16 May 2006 14:19:54 -0400
Cc: [email-masked], [email-masked]

>>>>> "Cat" == Cat Okita <[email-masked]> writes:

    Cat> This is a dreadful identifier.  Email addresess are not
    Cat> unique across time, are often reused, and very easily
    Cat> mistaken - I'm sure I'm not the only person that's received
    Cat> email for a previous owner - or had their email sent to the
    Cat> current owner of any given address.
Perhaps, but consider how well it works in practice.  There are many
many websites that will be happy to reset a password and send it to an
email address.

If you need high assurance out of a particular identifier then use an
identity provider that provides that assurance.  I doubt that banks
will ever allow identities issued by non-banks as an example because
doing so would open them up to huge liability.

Date: Tue, 16 May 2006 14:10:30 -0400 (EDT)
From: Cat Okita <[email-masked]>
To: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
Cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked]
Reply-To: Cat Okita <[email-masked]>

On Tue, 16 May 2006, Dick Hardt wrote:
>> I think we are all agreed that there is no shortage of strong 
>> authentication solutions for a network.
> Agreed

Indeed.

>> There is an internet person identifier: an email address.
>
> This is not a good identifier as it is not opaque, and was not created for 
> that purpose. [email-masked] a unique identifier, but it is also where I 
> receive email. I will often want to uniquely identify myself without handing 
> out an identifier that can be used in another way.

This is a dreadful identifier.  Email addresess are not unique across
time, are often reused, and very easily mistaken - I'm sure I'm not the 
only person that's received email for a previous owner - or had their 
email sent to the current owner of any given address.

cheers!
==========================================================================
"A cat spends her life conflicted between a deep, passionate and profound
desire for fish and an equally deep, passionate and profound desire to
avoid getting wet.  This is the defining metaphor of my life right now."

To: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF proposal: making the web safe and easy for Eliot's father
From: Sam Hartman <[email-masked]>
Date: Tue, 16 May 2006 13:50:06 -0400
Cc: [email-masked], [email-masked]

>>>>> "Dick" == Dick Hardt <[email-masked]> writes:

    Dick> Sam: great to see you looking to make the web safe and easy!
    Dick> ... some comments inserted below ...

    Dick> On 16-May-06, at 7:59 AM, Sam Hartman wrote:
    >> Initially I'm talking about binding an identifier to a session;
    >> if you will asserting the identity claim that [email-masked]
    >> uniquely applies to the subject of the session.

    Dick> This is one of the use cases of DIX.

Yes.  But I don't think dix meets anti-phishing requirements that I
think are critical.

I'd rather focus on a strong solution to phishing requirements and the
Eliot's dad problem.  If it happens to meet other use cases of dix,
that would be great too.

    >>  I think that long term, protocols will need to scale to
    >> support additional claims.  One of my main disagreements with
    >> the dix effort is over whether the complexity associated with
    >> managing the privacy of claims and standardizing claims is a
    >> good thing to include in the first phase of the solution.

    Dick> Would you elaborate more about what you think is complex?

I think that designing a UI that allows people to express privacy
preferences and handle phishing issues will be really hard.  I'd
rather focus on the phishing problem first and then possibly later
work on additional identity claims and privacy preferences.

    Dick> I think that if it is to scale to support additional claims,
    Dick> standardized claims are necessary.

Agreed.  I think that when you add support for additional claims you
need to also standardize claims.  My argument is simply that solving
the problem of binding a unique identifier of the subject to the
session in a manner that resists phishing is a hard enough problem.
If it turns out we can do more, that's great.

    >> I'm sure that many identity providers will make claims such as
    >> name available.  It's not clear to me that needs to be
    >> happening in the same place as we handle authentication to the
    >> website until we get to a point where we start supporting
    >> sending an identity to the website that is not unique.  Only at
    >> that point does the identity claim set need to be part of the
    >> authentication

    Dick> I see authentication as proving I am a particular entity
    Dick> again.

    Dick> An identity claim (using your term) lets the site know I
    Dick> have a particular property, assuming the site trusts who
    Dick> made the identity claim.

Most of the schemes under discussion have at least a notional third
party which is the identity provider.  You authenticate to the
identity provider.  How you do that is mostly out of scope except that
we need to standardize strong mechanisms for doing that and make one
of them mandatory to implement.

But there is also an authentication protocol carried out between the
identity provider and the relying party.  The identity provider makes
an authenticated assertion of various claims of identity.  This
protocol needs to have various properties to avoid phishing attacks.
One of them is that the relying party must not receieve enough
cryptographic information to make what appears to be an authenticated
assertion of identity from the original identity provider to the third
party.

To: "Hallam-Baker, Phillip" <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
From: Sam Hartman <[email-masked]>
Date: Tue, 16 May 2006 13:37:59 -0400
Cc: [email-masked], [email-masked]

>>>>> "Hallam-Baker," == Hallam-Baker, Phillip <[email-masked]> writes:

    Hallam-Baker,> As an attempt to focus discussion here: I think we
    Hallam-Baker,> are all agreed that there is no shortage of strong
    Hallam-Baker,> authentication solutions for a network.

Right.
And I don't believe I was  proposing inventing a new one.

    Hallam-Baker,> What we need is a way to apply those solutions
    Hallam-Baker,> within an internetwork.
Agreed.

    Hallam-Baker,> In particular I think we need to decide on a single
    Hallam-Baker,> identifier format and a service discovery
    Hallam-Baker,> strategy.  

I think we also need mandatory to
    implement solutions, because I think that's the only way we're
    going to get away from passwords for the web.  Getting away from
    sending tokens to websites that can be replayed to third parties
    is critical in solving the phishing problem.

We also need to develop a deployment
    Hallam-Baker,> strategy.

Agreed.

    Hallam-Baker,> There is a service discovery mechanism: DNS SRV.

Mmm.  I agree we need discovery.  I agree that discovery needs to work
given only an identifier.  I agree SRV is excellent for some uses.  I
think that asserting SRV at this stage is perhaps getting our
implementation details mixed in our requirements.

 Hallam-Baker,> The ultimate goal of a deployment strategy
must be Hallam-Baker,> to get support for interoperable strong
Hallam-Baker,> authentication built into the operating system
Hallam-Baker,> chrome.  Unless we get into the operating systems
Hallam-Baker,> we are going to be playing turtle stacking games
Hallam-Baker,> forever.

I think I agree with you.

Content-class: urn:content-classes:message
Subject: Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
Date: Tue, 16 May 2006 09:04:52 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Dick Hardt" <[email-masked]>
Cc: [email-masked], Sam Hartman <[email-masked]>, [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C67902.77093576
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Let's separate out the identifiers,=20

The identifier I give to the identity system to work out which persona =
to identify me need not be the identity eventually disclosed to the =
relying party

 -----Original Message-----
From: 	Dick Hardt [mailto:[email-masked]]
Sent:	Tue May 16 08:53:45 2006
To:	Hallam-Baker, Phillip
Cc:	Sam Hartman; Cat Okita; [email-masked]; =
[email-masked]
Subject:	Re: [Ietf-http-auth] BOF proposal: making the web safe and easy =
forEliot's father

On 16-May-06, at 8:44 AM, Hallam-Baker, Phillip wrote:
> As an attempt to focus discussion here:
>
> I think we are all agreed that there is no shortage of strong =20
> authentication solutions for a network.

Agreed
>
> In particular I think we need to decide on a single identifier =20
> format and a service discovery strategy. We also need to develop a =20
> deployment strategy.

agreed
>
> There is an internet person identifier: an email address.

This is not a good identifier as it is not opaque, and was not =20
created for that purpose. [email-masked] a unique identifier, but it =20
is also where I receive email. I will often want to uniquely identify =20
myself without handing out an identifier that can be used in another =20
way.

URLs are great, opaque identifiers that allow retrieval of meta-data =20
about the identifier from the resource at the end of the URL.
>
> There is a service discovery mechanism: DNS SRV.
I think it is also important to anticipate that smart browsers will =20
be widely deployed, and that service discovery by the website may not =20
be needed.

-- Dick

------_=_NextPart_001_01C67902.77093576
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Re: [Ietf-http-auth] BOF proposal: making the web safe and easy =
forEliot's father</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Let's separate out the identifiers,<BR>
<BR>
The identifier I give to the identity system to work out which persona =
to identify me need not be the identity eventually disclosed to the =
relying party<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; Dick Hardt [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<BR>
Sent:&nbsp;&nbsp; Tue May 16 08:53:45 2006<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; Hallam-Baker, Phillip<BR>
Cc:&nbsp;&nbsp;&nbsp;&nbsp; Sam Hartman; Cat Okita; =
[email-masked]; [email-masked]<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: [Ietf-http-auth] =
BOF proposal: making the web safe and easy forEliot's father<BR>
<BR>
On 16-May-06, at 8:44 AM, Hallam-Baker, Phillip wrote:<BR>
&gt; As an attempt to focus discussion here:<BR>
&gt;<BR>
&gt; I think we are all agreed that there is no shortage of =
strong&nbsp;<BR>
&gt; authentication solutions for a network.<BR>
<BR>
Agreed<BR>
&gt;<BR>
&gt; In particular I think we need to decide on a single =
identifier&nbsp;<BR>
&gt; format and a service discovery strategy. We also need to develop =
a&nbsp;<BR>
&gt; deployment strategy.<BR>
<BR>
agreed<BR>
&gt;<BR>
&gt; There is an internet person identifier: an email address.<BR>
<BR>
This is not a good identifier as it is not opaque, and was not&nbsp;<BR>
created for that purpose. [email-masked] a unique identifier, but =
it&nbsp;<BR>
is also where I receive email. I will often want to uniquely =
identify&nbsp;<BR>
myself without handing out an identifier that can be used in =
another&nbsp;<BR>
way.<BR>
<BR>
URLs are great, opaque identifiers that allow retrieval of =
meta-data&nbsp;<BR>
about the identifier from the resource at the end of the URL.<BR>
&gt;<BR>
&gt; There is a service discovery mechanism: DNS SRV.<BR>
I think it is also important to anticipate that smart browsers =
will&nbsp;<BR>
be widely deployed, and that service discovery by the website may =
not&nbsp;<BR>
be needed.<BR>
<BR>
-- Dick<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C67902.77093576--

From: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
Date: Tue, 16 May 2006 08:53:20 -0700
To: "Hallam-Baker, Phillip" <[email-masked]>
Cc: [email-masked], Sam Hartman <[email-masked]>, [email-masked]

On 16-May-06, at 8:44 AM, Hallam-Baker, Phillip wrote:
> As an attempt to focus discussion here:
>
> I think we are all agreed that there is no shortage of strong  
> authentication solutions for a network.

Agreed
>
> In particular I think we need to decide on a single identifier  
> format and a service discovery strategy. We also need to develop a  
> deployment strategy.

agreed
>
> There is an internet person identifier: an email address.

This is not a good identifier as it is not opaque, and was not  
created for that purpose. [email-masked] a unique identifier, but it  
is also where I receive email. I will often want to uniquely identify  
myself without handing out an identifier that can be used in another  
way.

URLs are great, opaque identifiers that allow retrieval of meta-data  
about the identifier from the resource at the end of the URL.
>
> There is a service discovery mechanism: DNS SRV.
I think it is also important to anticipate that smart browsers will  
be widely deployed, and that service discovery by the website may not  
be needed.

-- Dick

Content-class: urn:content-classes:message
Subject: Re: [Ietf-http-auth] BOF proposal: making the web safe and easy forEliot's father
Date: Tue, 16 May 2006 08:44:32 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Sam Hartman" <[email-masked]>, "Cat Okita" <[email-masked]>
Cc: [email-masked], [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C678FF.A028458A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

As an attempt to focus discussion here:

I think we are all agreed that there is no shortage of strong =
authentication solutions for a network.

What we need is a way to apply those solutions within an internetwork.

SAML solves some of the problems, but it is designed at a different =
level of generality. WS-* solves similar problems from a slightly =
different perspective.

In particular I think we need to decide on a single identifier format =
and a service discovery strategy. We also need to develop a deployment =
strategy.

There is an internet person identifier: an email address.

There is a service discovery mechanism: DNS SRV.

The ultimate goal of a deployment strategy must be to get support for =
interoperable strong authentication built into the operating system =
chrome. Unless we get into the operating systems we are going to be =
playing turtle stacking games forever.

I think we need to build this tunnel from both sides at once. If =
everyone is willing to cooperate we can meet in the middle.

Phill

 -----Original Message-----
From: 	Sam Hartman [mailto:[email-masked]]
Sent:	Tue May 16 07:59:50 2006
To:	Cat Okita
Cc:	[email-masked]; [email-masked]
Subject:	Re: [Ietf-http-auth] BOF proposal: making the web safe and easy =
forEliot's father

>>>>> "Cat" =3D=3D Cat Okita <[email-masked]> writes:

    Cat> On Mon, 15 May 2006, Sam Hartman wrote:
    >> Hi.  I'm putting together a proposal for a BOF at IETF 66 of
    >> phishing-safe identity for the web an other HTTP applications.

    Cat> Hi Sam -

    >> From reading your email, it's not at all clear to me that
    >> you're
    Cat> talking about identity.  It seems like you're discussing
    Cat> something much closer to a single sign-on solution.  Could
    Cat> you elaborate on what your perceptions of identity and
    Cat> authentication are?

Initially I'm talking about binding an identifier to a session; if you
will asserting the identity claim that [email-masked] uniquely
applies to the subject of the session.

I think that long term, protocols will need to scale to support
additional claims.  One of my main disagreements with the dix effort
is over whether the complexity associated with managing the privacy of
claims and standardizing claims is a good thing to include in the
first phase of the solution.

I do not believe that is the case.

I'm definitely not talking about single sign-on.  Single sign-on
implies that you have one identity.  The Laws of Identity paper and
many other presentations make compelling arguments about why you will
have multiple identities.  My goal is to create a protocol and
architectural solution so that you need not have more identities than
are necessary.

I'm sure that many identity providers will make claims such as name
available.  It's not clear to me that needs to be happening in the
same place as we handle authentication to the website until we get to
a point where we start supporting sending an identity to the website
that is not unique.  Only at that point does the identity claim set
need to be part of the authentication
_______________________________________________
Ietf-http-auth mailing list
[email-masked]
http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth

------_=_NextPart_001_01C678FF.A028458A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Re: [Ietf-http-auth] BOF proposal: making the web safe and easy =
forEliot's father</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>As an attempt to focus discussion here:<BR>
<BR>
I think we are all agreed that there is no shortage of strong =
authentication solutions for a network.<BR>
<BR>
What we need is a way to apply those solutions within an =
internetwork.<BR>
<BR>
SAML solves some of the problems, but it is designed at a different =
level of generality. WS-* solves similar problems from a slightly =
different perspective.<BR>
<BR>
In particular I think we need to decide on a single identifier format =
and a service discovery strategy. We also need to develop a deployment =
strategy.<BR>
<BR>
There is an internet person identifier: an email address.<BR>
<BR>
There is a service discovery mechanism: DNS SRV.<BR>
<BR>
The ultimate goal of a deployment strategy must be to get support for =
interoperable strong authentication built into the operating system =
chrome. Unless we get into the operating systems we are going to be =
playing turtle stacking games forever.<BR>
<BR>
I think we need to build this tunnel from both sides at once. If =
everyone is willing to cooperate we can meet in the middle.<BR>
<BR>
Phill<BR>
<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; Sam Hartman [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<B=
R>
Sent:&nbsp;&nbsp; Tue May 16 07:59:50 2006<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; Cat Okita<BR>
Cc:&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]; =
[email-masked]<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: [Ietf-http-auth] =
BOF proposal: making the web safe and easy forEliot's father<BR>
<BR>
&gt;&gt;&gt;&gt;&gt; &quot;Cat&quot; =3D=3D Cat Okita =
&lt;[email-masked]&gt; writes:<BR>
<BR>
&nbsp;&nbsp;&nbsp; Cat&gt; On Mon, 15 May 2006, Sam Hartman wrote:<BR>
&nbsp;&nbsp;&nbsp; &gt;&gt; Hi.&nbsp; I'm putting together a proposal =
for a BOF at IETF 66 of<BR>
&nbsp;&nbsp;&nbsp; &gt;&gt; phishing-safe identity for the web an other =
HTTP applications.<BR>
<BR>
&nbsp;&nbsp;&nbsp; Cat&gt; Hi Sam -<BR>
<BR>
&nbsp;&nbsp;&nbsp; &gt;&gt; From reading your email, it's not at all =
clear to me that<BR>
&nbsp;&nbsp;&nbsp; &gt;&gt; you're<BR>
&nbsp;&nbsp;&nbsp; Cat&gt; talking about identity.&nbsp; It seems like =
you're discussing<BR>
&nbsp;&nbsp;&nbsp; Cat&gt; something much closer to a single sign-on =
solution.&nbsp; Could<BR>
&nbsp;&nbsp;&nbsp; Cat&gt; you elaborate on what your perceptions of =
identity and<BR>
&nbsp;&nbsp;&nbsp; Cat&gt; authentication are?<BR>
<BR>
Initially I'm talking about binding an identifier to a session; if =
you<BR>
will asserting the identity claim that [email-masked] uniquely<BR>
applies to the subject of the session.<BR>
<BR>
I think that long term, protocols will need to scale to support<BR>
additional claims.&nbsp; One of my main disagreements with the dix =
effort<BR>
is over whether the complexity associated with managing the privacy =
of<BR>
claims and standardizing claims is a good thing to include in the<BR>
first phase of the solution.<BR>
<BR>
I do not believe that is the case.<BR>
<BR>
I'm definitely not talking about single sign-on.&nbsp; Single =
sign-on<BR>
implies that you have one identity.&nbsp; The Laws of Identity paper =
and<BR>
many other presentations make compelling arguments about why you =
will<BR>
have multiple identities.&nbsp; My goal is to create a protocol and<BR>
architectural solution so that you need not have more identities =
than<BR>
are necessary.<BR>
<BR>
<BR>
I'm sure that many identity providers will make claims such as name<BR>
available.&nbsp; It's not clear to me that needs to be happening in =
the<BR>
same place as we handle authentication to the website until we get =
to<BR>
a point where we start supporting sending an identity to the website<BR>
that is not unique.&nbsp; Only at that point does the identity claim =
set<BR>
need to be part of the authentication<BR>
_______________________________________________<BR>
Ietf-http-auth mailing list<BR>
[email-masked]<BR>
<A =
HREF=3D"http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http=
-auth">http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-=
auth</A><BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C678FF.A028458A--

From: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF proposal: making the web safe and easy for Eliot's father
Date: Tue, 16 May 2006 08:20:45 -0700
To: Sam Hartman <[email-masked]>
Cc: [email-masked], [email-masked]

Sam: great to see you looking to make the web safe and easy! ... some  
comments inserted below ...

On 16-May-06, at 7:59 AM, Sam Hartman wrote:
> Initially I'm talking about binding an identifier to a session; if you
> will asserting the identity claim that [email-masked] uniquely
> applies to the subject of the session.

This is one of the use cases of DIX.

>
> I think that long term, protocols will need to scale to support
> additional claims.  One of my main disagreements with the dix effort
> is over whether the complexity associated with managing the privacy of
> claims and standardizing claims is a good thing to include in the
> first phase of the solution.

Would you elaborate more about what you think is complex?

I think that if it is to scale to support additional claims,  
standardized claims are necessary.

> I'm sure that many identity providers will make claims such as name
> available.  It's not clear to me that needs to be happening in the
> same place as we handle authentication to the website until we get to
> a point where we start supporting sending an identity to the website
> that is not unique.  Only at that point does the identity claim set
> need to be part of the authentication

I see authentication as proving I am a particular entity again.

An identity claim (using your term) lets the site know I have a  
particular property, assuming the site trusts who made the identity  
claim.

-- Dick

To: Cat Okita <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF proposal: making the web safe and easy for Eliot's father
From: Sam Hartman <[email-masked]>
Date: Tue, 16 May 2006 10:59:36 -0400
Cc: [email-masked], [email-masked]

>>>>> "Cat" == Cat Okita <[email-masked]> writes:

    Cat> On Mon, 15 May 2006, Sam Hartman wrote:
    >> Hi.  I'm putting together a proposal for a BOF at IETF 66 of
    >> phishing-safe identity for the web an other HTTP applications.

    Cat> Hi Sam -

    >> From reading your email, it's not at all clear to me that
    >> you're
    Cat> talking about identity.  It seems like you're discussing
    Cat> something much closer to a single sign-on solution.  Could
    Cat> you elaborate on what your perceptions of identity and
    Cat> authentication are?

Initially I'm talking about binding an identifier to a session; if you
will asserting the identity claim that [email-masked] uniquely
applies to the subject of the session.

I think that long term, protocols will need to scale to support
additional claims.  One of my main disagreements with the dix effort
is over whether the complexity associated with managing the privacy of
claims and standardizing claims is a good thing to include in the
first phase of the solution.

I do not believe that is the case.

I'm definitely not talking about single sign-on.  Single sign-on
implies that you have one identity.  The Laws of Identity paper and
many other presentations make compelling arguments about why you will
have multiple identities.  My goal is to create a protocol and
architectural solution so that you need not have more identities than
are necessary.

I'm sure that many identity providers will make claims such as name
available.  It's not clear to me that needs to be happening in the
same place as we handle authentication to the website until we get to
a point where we start supporting sending an identity to the website
that is not unique.  Only at that point does the identity claim set
need to be part of the authentication

Date: Mon, 15 May 2006 18:22:59 -0400 (EDT)
From: Cat Okita <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF proposal: making the web safe and easy for Eliot's father
Cc: [email-masked], [email-masked]
Reply-To: Cat Okita <[email-masked]>

On Mon, 15 May 2006, Sam Hartman wrote:
> Hi.  I'm putting together a proposal for a BOF at IETF 66 of
> phishing-safe identity for the web an other HTTP applications.

Hi Sam -

>From reading your email, it's not at all clear to me that you're
talking about identity.  It seems like you're discussing something
much closer to a single sign-on solution.  Could you elaborate on 
what your perceptions of identity and authentication are?

cheers!
==========================================================================
"A cat spends her life conflicted between a deep, passionate and profound
desire for fish and an equally deep, passionate and profound desire to
avoid getting wet.  This is the defining metaphor of my life right now."

To: [email-masked]
From: Sam Hartman <[email-masked]>
Date: Mon, 15 May 2006 15:25:44 -0400
Cc: [email-masked]
Subject: [Ietf-http-auth] BOF proposal: making the web safe and easy for Eliot's father

Hi.  I'm putting together a proposal for a BOF at IETF 66 of
phishing-safe identity for the web an other HTTP applications.

I hope to have both a problem statement draft and a requirements draft
about avoiding phishing attacks.  These drafts will hopefully be done
by May 22.  I'd appreciate it if people would indicate any interest
they may have in this BOF.

During the DIX BOF at IETF 65, Eliot Lear tried to cut through a
complicated discussion of web identity and propose a smaller subset of
the problem for us to solve.  he wants us to create a way for his dad
to securely access websites without having multiple passwords all over
the place.  We spent some time trying to figure out the
characteristics of Eliot's dad.  Eliot's dad and users like him use
the web from many computers, including computers they own, computers
in businesses and computers made available to the public they have
never used before.  They don't understand certificates, are not going
to be good at checking URL bars and certainly will not read the source
of a page before logging into a website.  I propose that we try and
make the web safe and easy to use for Eliot's dad.

To do this, I think it is critical that we present a coherent proposal
for web identity management at the next IETF in response to DIX.
There are two messages I'd like to send.  The first is that we need to
deal with phishing.  The second message we want to send is that
reinventing a new authentication framework is really hard and that we
have technology that should be reused.

So, here's my idea for a set of BOF presentations at IETF 66.

First, we start out by describing the Eliot's father problem.  You
want to be able to use a smaller number of passwords; sometimes you
only want to be able to use them from one computer, sometimes you want
to be able to use them anywhere.  Sometimes you provide the identity,
sometimes the server provides the identity.  A third party can provide
the identity, but they need to be associated with either you or the
site you are trying to connect to in some way.  Long term you need to
support more than passwords, but passwords are the important thing
today.

Then, we get someone to describe the phishing problem.  You must never
send a token that can be used by the website to impersonate you to
third parties: if the website is an attacker then they can become you
on the real site.  Here is where Infocard, DIX, SAML bearer assertions
all fail.  Browsers must change; cite w3c auth workshop.  You need to
have some form of dynamic trusted UI.  Take a look at
http://www.w3.org/2005/Security/usability-ws/papers/37-google/ as a
draft of some requirements in this space.

 show that many situations require a trusted party acting as an
identity provider.  Discuss how difficult designing trusted third
parties are and getting them deployed.  Point out that DIX and
Infocard are new trusted third parties authentication systems.  Desire
to use technology that can scale to Internet-wide deployment.
Establish following requirements for trusted third party:

* Must support smart cards, SRP-like mechanisms, normal passwords, one
  time passwords, anything someone might use.

* Must work with more than the web.  Identity assertions need to
  travel from the web into back office systems even if those systems
do not fully trust the web site as an authorizer.

* Desire to share authentication with email, IM and other services.

Show how much of these requirements we can meet today with existing
technology to argue that using existing technology is plausible.  I
propose showing this based on Kerberos.  Personally I think that
Kerberos has a lot to offer in this space, but the important thing is
to demonstrate that existing authentication frameworks are worth
reusing, not to prematurely push a particular solution.

I believe that if you were trying to show Kerberos in this space you
could demo Kerberos working to enroll an identity in a third party
identity provider.  Demo using that identity to access a website from
a second computer that knows nothing about the identity.  Truthfully
be able to assert that neither computer needed prior configuration
either about the identity provider or the website.  

Proposed deliverables of a working group:

* Requirements document describing the Eliot's father problem.

* Requirements document describing what it means to have web identity
  that is reasonably safe from phishing.
* Guidance to W3C on what information browsers will need from HTML to
  provide a good user experience for authentication.

* An architecture document describing how the solution fits together.
  Unlike most IETF protocols we need to focus on UI issues as well as
  the low level protocol issues.  While we may want the UI issues
  handled in W3C, I think it critical that we be working on the
  architecture in parallel to the UI issues so that requirements can
  filter in both directions.

  * Technical solution to binding a user-provided identity to a
website.  In DIX terms, a technical solution for telling a website
about a homesite.  This is more challenging in an environment where
you care about phishing.

* Technical solution for enrolling a user in  a identity
  provider--again harder than a form asking for your new password if
  you care about phishing.

* A GAP analysis of usability issues in the chosen authentication
  technology.  While I think existing technologies such as Kerberos
  are reusable, there is work to do.  In the case of Kerberos,
  firewall friendly transport and some realm configuration issues.  In
  the case of X.509, lots of enrollment problems and lots of browser
  UI issues.

--Sam

To: HTTP authentication list <[email-masked]>, HTTP working group <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Date: Tue, 9 May 2006 16:50:34 -0700
Subject: [Ietf-http-auth] Hint: Submission of BOF requests recommended by May 22 

--Apple-Mail-5--739773186
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Since I've heard rumours of interest in BOFs, I thought I'd point out  
the deadline and pseudo-deadline...

Lisa

Begin forwarded message:

> From: Brian Carpenter <[email-masked]>
> Date: May 9, 2006 8:28:49 AM PDT
> To: IETF Announcement list <[email-masked]>
> Subject: Submission of BOF requests recommended by May 22
>
> The formal cutoff date for BOF requests for IETF 66 is June 5.
> However, the IESG *strongly* urges that all BOF requests,
> with supporting material, should be sent to the relevant
> Area Director at least two weeks before that date, i.e.
> by May 22, in order to allow time for full consideration by
> the IESG and IAB.
>
> Please see draft-narten-successful-bof-01.txt for
> suggestions on how to plan a successful BOF, and also
> http://www.ietf.org/ietf/1bof-procedures.txt.
>
>     Brian Carpenter, for the IESG
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

--Apple-Mail-5--739773186
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">Since I've heard rumours of =
interest in BOFs, I thought I'd point out the deadline and =
pseudo-deadline...<DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Lisa<BR><DIV><BR><DIV>Begin =
forwarded message:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><B>From: =
</B></FONT><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Brian Carpenter &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</FONT></DIV>=
<DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><B>Date: =
</B></FONT><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">May 9, 2006 8:28:49 AM PDT</FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><B>To: </B></FONT><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">IETF =
Announcement list &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</FON=
T></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" =
color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>Subject: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica"><B>Submission of BOF requests =
recommended by May 22<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></B></FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV> <DIV style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The =
formal cutoff date for BOF requests for IETF 66 is June 5.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">However, the IESG *strongly* urges that all BOF =
requests,</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">with supporting material, should =
be sent to the relevant</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Area Director =
at least two weeks before that date, i.e.</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">by May =
22, in order to allow time for full consideration by</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">the IESG and IAB.</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Please see =
draft-narten-successful-bof-01.txt for</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">suggestions on how to plan a successful BOF, and also</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"http://www.ietf.org/ietf/1bof-procedures.txt">http://www.ietf.org/=
ietf/1bof-procedures.txt</A>.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0 =A0 </SPAN>Brian Carpenter, for the =
IESG</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; =
">_______________________________________________</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">IETF-Announce mailing list</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"mailto:[email-masked]">[email-masked]</A></DIV><DI=
V style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"https://www1.ietf.org/mailman/listinfo/ietf-announce">https://www1=
.ietf.org/mailman/listinfo/ietf-announce</A></DIV> =
</BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-5--739773186--

Date: Thu, 04 May 2006 11:13:43 -0400
From: Cyrus Daboo <[email-masked]>
To: Robert Sayre <[email-masked]>, HTTP authentication list <[email-masked]>
Subject: Re: [Ietf-http-auth] Digest Implementation Report

Hi Robert,

--On May 4, 2006 11:04:39 AM -0400 Robert Sayre <[email-masked]> wrote:

> <http://www.agileprogrammer.com/eightytwenty/archive/2006/05/04/14280.asp
> x>
>
> The author of that post is a protocol engineer for Newsgator, a
> company that sells desktop RSS aggregators and web applications. They
> have a custom HTTP protocol that syncs read/unread state across client
> machines and their web application. They use Digest authentication for
> a lot of the traffic.

The lack of i18n support in 2617 methods is a well known problem. I note 
that the current hmac-digest proposal also does not address that. The SASL 
WG has fixed SASL wrt i18n and hmac-digest could probably follow their 
approach to achieve a fix.

-- 
Cyrus Daboo

Date: Thu, 4 May 2006 11:04:39 -0400
From: "Robert Sayre" <[email-masked]>
To: "HTTP authentication list" <[email-masked]>
Subject: [Ietf-http-auth] Digest Implementation Report

<http://www.agileprogrammer.com/eightytwenty/archive/2006/05/04/14280.aspx>

The author of that post is a protocol engineer for Newsgator, a
company that sells desktop RSS aggregators and web applications. They
have a custom HTTP protocol that syncs read/unread state across client
machines and their web application. They use Digest authentication for
a lot of the traffic.

--

Robert Sayre