Subject: Re: [Ietf-http-auth] Bar BoF in Vancouver?
From: Eliot Lear <[email-masked]>
To: Mark Nottingham <[email-masked]>
Cc: [email-masked]
Date: Thu, 29 Nov 2007 13:59:10 -0800
List-Id: ietf-http-auth.osafoundation.org

Mark Nottingham wrote:
>
> How about Tuesday 6pm (unless ltans a potential conflict)?
Unfortunately everyone else wants to meet for a bar bof at that time :-(

From: Mark Nottingham <[email-masked]>
Subject: Re: [Ietf-http-auth] Bar BoF in Vancouver?
Date: Thu, 29 Nov 2007 13:31:46 -0800
To: Eliot Lear <[email-masked]>
Cc: [email-masked]

How about Tuesday 6pm (unless ltans a potential conflict)?

On 2007/11/29, at 11:52 AM, Eliot Lear wrote:

> Mark Nottingham wrote:
>> With draft-hartman-06 out, and the new discussion around draft-oiwa,
>> is anyone interested in an informal discussion in Vancouver?
>>
>
> Absolutely!!

--
Mark Nottingham       [email-masked]

Date: Thu, 29 Nov 2007 11:52:54 -0800
From: Eliot Lear <[email-masked]>
To: Mark Nottingham <[email-masked]>
Subject: Re: [Ietf-http-auth] Bar BoF in Vancouver?
Cc: [email-masked]

Mark Nottingham wrote:
> With draft-hartman-06 out, and the new discussion around draft-oiwa,
> is anyone interested in an informal discussion in Vancouver?
>

Absolutely!!

To: Eric Rescorla <[email-masked]>
Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
From: Yutaka OIWA <[email-masked]>
Date: Fri, 30 Nov 2007 04:41:41 +0900
Cc: [email-masked]

Dear Eric and other people discussing the issue recently,

Thank you very much for the comment.

Eric Rescorla <[email-masked]> writes:

> A few questions/comments:
>
> 1. I don't see why this makes sense to do at the HTTP layer. Wouldn't
>    it be more straightforward to do this in TLS rather than adapting
>    Digest? I also would note that TLS-SRP has already been approved
>    by the IESG.

In short, We found that TLS-SRP is not well suited for web applications.

Web authentications are basically application-layer issues.  In real
web sites like Google or Yahoo!, there are both unauthenticated
contents and authenticated contents on one server, and also there are
many independent "authentication realms" which request different sets
of authentication credentials.  One of these realms (including
"no-authentication" realm) are assigned for each requested Web
resource, which is determined by the HTTP-layer request URI and other
headers.  When TLS-SRP is used, however, the authentication starts
before the client tells the server what resource are requested.  This
gives great difficulty for designing web sites and inapplicability for
many existing systems.

Actually, when we started discussing the extension, we did discuss
about applying TLS-SRP protocol to the current Web systems.  However,
we found that TLS-SRP is not suitable for this purpose in some reasons
described here. This was the first motivating period that we need to
develop a new HTTP-layer protocol.

(Of course, I think that TLS-SRP is useful for the protocols which
 requires only simple and uniform patterns of password-based
 authentications, like IPP/HTTPS, IMAP/TLS or POP3/TLS.  In those
 cases, authentications in transport-layer are sufficient.)

One might also think that combination of TLS-SRP and TLS renegotiation
can be useful to solve the issue. But it is very unlikely to specify
and implement correctly an appropriate mechanism for Web
authentication using some kinds of tricky "authentication tunneling"
behaviors.  The simple HTTP-layer authentication is much clearer and
better.  Furthermore, introduced in HTTP/1.1, there is HTTP Keep-alive
feature that allows more than one HTTP-layer requests on one TLS (or
TCP) transport-layer connections.  This adds further complexity for
such specifications.

> 2. Do you have a pointer to a complete description of the crypto
>    protocol this is based on? A little searching didn't turn
>    up anything non-free.

We would add the detail of the crypto in the next draft.

> 3. There are a large number of PAKE/ZKPP protocols. Can you please
>    explain why one would want this protocol versus others?

There are some criteria which are required for use in our Mutual
Authentication Protocol:

  (1) There are only four messages for one authentication
      (including key sharing confirmation).

  (2) Among those, key sharing is done in first two messages,
      and final two messages are only for lightweight key confirmation.
      This is required because our scheme uses one shared key for
      several requests by re-sending final two messages only.
      This reduces overhead for repeatedly performing public-key
      cryptographic operations.

  (3) Those final two messages must be able to be extended so that we
      can put additional confirmation data such as nonces and
      validation tokens (v) into that messages.  Note that this is
      very important point: in our scheme, this modification to the
      messages are important to prevent man-in-the-middle attacks.

In addition to this, In KAM3 required secret is asymmetric: the server
only needs "encrypted" (or "hashed") password, and does not need
having the real password value (pi) itself.  These are the reasons we
chose ISO-defined variant as a basis.

If there is a PAKE/ZKPP protocol which meets all of those criteria and
has some advantages over KAM3, we think that such a protocol should be
used.

> 4. I see you've filed an IPR disclosure on this technique. Is your
>    own IPR the only IPR which you're aware of?

First, we can guarantee that the disclosed patents are the only patent
that the authors (Oiwa, Watanabe, Takagi and Suzuki) have submitted or
even concerned which affect the protocol.

(Of course, the patent is only for the modification of the protocol
 from ISO specification and the application to HTTP authentication.
 The original ISO KAM3 protocol is out of the patent's scope for the
 obvious reason.)

Second, there are well-known, very fundamental patents about elliptic
curve cryptography which the people think (or at least worry) that the
patents are effectively valid.  Those patents may have relation with
this protocol, as stated in the draft.

Third, it is known that the original inventor of the KAM3 PAKE
variant is not claiming any patent over the (original) protocol.
It can be confirmed in http://grouper.ieee.org/groups/1363/WorkingGroup/presentations/p1363_200403.ppt .

Finally, we currently think that, as far as we know, other patents on
related fields are not applicable for this technique either because it
is out of the claim or there are prior arts (as far as our protocol is
concerned).

-- 
Yutaka OIWA, Ph.D.                                       Research Scientist
                            Research Center for Information Security (RCIS)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[995DD3E1] fp[3C21 17D0 D953 77D3 02D7 4FEC 4754 40C1 995D D3E1]

To: [email-masked]
From: Mark Nottingham <[email-masked]>
Date: Thu, 29 Nov 2007 10:53:45 -0800
Subject: [Ietf-http-auth] Bar BoF in Vancouver?

With draft-hartman-06 out, and the new discussion around draft-oiwa,  
is anyone interested in an informal discussion in Vancouver?

Cheers,

--
Mark Nottingham       [email-masked]

Date: Thu, 29 Nov 2007 02:24:48 -0800
From: Chris Newman <[email-masked]>
Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Sender: [email-masked]
To: Eric Rescorla <[email-masked]>, Yutaka OIWA <[email-masked]>
Cc: [email-masked]

Eric Rescorla wrote on 11/26/07 21:31 -0800:
> A few questions/comments:
>
> 1. I don't see why this makes sense to do at the HTTP layer. Wouldn't
>    it be more straightforward to do this in TLS rather than adapting
>    Digest? I also would note that TLS-SRP has already been approved
>    by the IESG.

Some people believe stuffing user authentication into the TLS layer to be bad 
design.  Here's the text from my IESG abstain vote when TLS-SRP went 
informational:

---
This is a weak abstain (I'm not asking other area directors to join my
position).  If the target were standards track, this would be a strong
abstain.

This a matter of application software architecture that applies to any
user-based authentication mechanism embedded in TLS that involves
or may involve unspecified server storage of per-user credential
information.

TLS stacks and the APIs to TLS stacks have started to ossify into
operating systems, mobile devices and shipping application software.
Such stacks are absolutely critical to application security, and are
already so complex that they are the cause of a significant number of
software defects and security updates.  I am very concerned about
adding unnecessary complexity to such a critical software component.
There is already a great deal of flux upgrading the cipher suites,
cipher modes and hash functions in these stacks.

Meanwhile, all the software infrastructure in applications surrounding
user identity, server credential repositories for users, and identity
federation is highly complex and in a great deal of flux.  If one looks
at the amount of complexity in the GSSAPI or deployed general
purpose SASL APIs and imagines the complexity of a software stack
including all those APIs blended with a TLS API, I find the prospect
daunting.  Indeed the complexity is sufficiently great that I consider
it bad architecture.

Meanwhile, there's a viable alternative.  If TLS and an authentication
framework such as GSSAPI, EAP or SASL are loosely bound using a
mechanism such as TLS channel bindings (TLS negotiates the security
layer which is subsequently bound to a completely separate user
authentication), then there is a very simple and clean boundary
between the two software stacks, leading to a much more pragmatic
real-world architecture.
---

                - Chris

Date: Wed, 28 Nov 2007 18:37:38 -0600
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Cc: [email-masked]

[re-send without my slides attached, so it makes it to the list faster.]

On Wed, Nov 28, 2007 at 06:35:19PM -0600, Nicolas Williams wrote:
> On Wed, Nov 28, 2007 at 07:22:41PM -0500, Sam Hartman wrote:
> > He's attempting to take advantage of membership in a federation to
> > avoid dependence on CAs.  I.E. section 4.6 of my draft.
> > 
> > My text in this regard needs to be improved significantly.  Nico
> > Williams managed to state it much more clearly in a presentation he
> > gave to Liberty and I need to incorporate his restatements.
> 
> My presentation to the Liberty Staff is attached.  See also my blog:
> 
> http://blogs.sun.com/nico
> 
> The short version is this:

Ha!  Not so short I guess.  It's hard to summarize this, I'm afraid.

>  - we need to mutually authenticate users and servers
> 
>  - there must be a link between the authentication of users to servers
>    and servers to users
> 
>  - this link must be such that users can determine whether to trust the
>    server according to what "federation" was used to authenticate the
>    user to the server
> 
>  - "federation" matters because federations are (must) be smaller than
>    the capital-I Internet and, therefore, are able to effectively
>    white-/black-list member sites.
> 
>    I.e., a "Bank of Foo" federation should only allow my identity in
>    that federation to be used to authenticate to sites that the "Bank of
>    Foo" federation administrators trust.  The "Bank of Foo" federation
>    can check for confusables, etc... in applicant members because they
>    have few members compared to the number of domains that exist in each
>    TLD (say).
> 
>    A "Bloggers Union of Foobar" federation might have many, many more
>    members, and thus be less able to keep out phishers, but users would
>    know not to trust, with important non-blogging data, sites to which
>    they authenticate with "Bloggers Union of Foobar" identities.
> 
>  - That last point brings up something important: UIs matter.  The UI
>    in this proposal *must* make it clear to the user not just the name
>    of the site (think: status bar) but the identity/federation used to
>    authenticate the user.
> 
>  - The binding/mutuality of user<->server authentication is necessary to
>    prevent MITM attacks.
> 
> Nico
> -- 

From: Sam Hartman <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Date: Wed, 28 Nov 2007 19:22:41 -0500
Cc: [email-masked]

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

    Eliot> Roy T. Fielding wrote:
    >> Perhaps.  I don't believe that CAs are careful enough in
    >> issuing certificates, and it is certainly the case that not all
    >> TLS sites bother to pay the tax for CA-signed certs.  This
    >> algorithm should not be dependent on them.  Perhaps what I am
    >> looking for is a mechanism that doesn't require Mutual Auth
    >> (aside from proving knowledge of a shared secret), but can
    >> still detect MITM.

    Eliot> Fundamentally phishing is possible because of an absence of
    Eliot> mutual authentication.  I guess I don't understand what
    Eliot> problem you are attempting to solve.

He's attempting to take advantage of membership in a federation to
avoid dependence on CAs.  I.E. section 4.6 of my draft.

My text in this regard needs to be improved significantly.  Nico
Williams managed to state it much more clearly in a presentation he
gave to Liberty and I need to incorporate his restatements.

--Sam

From: "Roy T. Fielding" <[email-masked]>
Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Date: Tue, 27 Nov 2007 18:18:07 -0800
To: Yutaka OIWA <[email-masked]>
Cc: [email-masked]

On Nov 26, 2007, at 11:14 PM, Yutaka OIWA wrote:
> Please allow me to answer some of your questions (simple to answer)  
> first.
>
> "Roy T. Fielding" <[email-masked]> writes:
>
>>     The equations for J, w_A, T, z, K_i, and w_B are those  
>> specified for
>>     KAM3 in [ISO.11770-4.2006], given that pi is derived in the above
>>     equation.
>>
>> should be replaced by the actual equations, with only an informative
>> reference to [ISO.11770-4.2006].
>
> I see.  As I am not expert of the exact requirements for IETF
> standardization processes, this kind of suggestions are very
> helpful.  Maybe I could include the full equation in the next
> draft.

Please do.  I do not think that it is a formal requirement for IETF,
since the IETF would only need a stable reference (ISO is good for
that).  However, none of my projects would allow a "standard" for
the web to be defined by a pay-per-view spec.

>>  [I don't understand the reasoning behind
>> tls-cert being used at all, since in actual practice "certificate
>> verification" is a waste of time (CAs are not secure).  What
>> matters is that the server reject a channel binding that
>> would indicate a MITM attack, for which the tls-key should
>> be sufficient.  However, I am not a crypto expert.]
>
> This is because I am worrying about that forcing tls-key
> authentication would cause some implementation difficulty
> where black-box TLS implementations are used.
> Tls-keys are usually hidden inside TLS modules, but
> certs must be (in some way) available to the browser layer.
> We are asking our implementation people under collaboration
> to find out how exactly difficult to implement the tls-key,
> so if the answer is "easy", we think we can safely drop the
> tls-cert entirely.

Ah, okay.  That would be a nice "use case" to add to the draft
to describe why each of these choices have been made.

> In security, tls-cert itself can ensure safety even if self-signed
> certificate is used, because the tls-cert validation effectively
> checks matching of used secret key.  When the server secret key paired
> with the certificate is leaked, tls-cert will become vulnerable.

Okay, my mistake. I thought that the tls-cert check was limited to
CA-signed keys.  In that case, I would suggest not having the
tls-key option.

...

> Actually, "sid" correspond to "server nonce" in Digest authentication
> which must be kept in server-side. The name differs because
> in Digest "nonce" is both a session identifier and an encryption  
> key at
> the same time,  but in Mutual authentication it is just an identifier.
>
> We carefully designed the protocol so that servers can be implemented
> without having complex state managements.  Server-side session caches
> can be erased at any time after one request is served, this is just
> the same as Digest does.

Yes, but Digest was only implemented after a long period of failed
attempts, MD5-sess only works on shared memory platforms, and
even then the implementation we provide is at best a dummy
implementation that needs to be hand-tweaked by real sites.
None of that complexity was necessary for the original purpose
of Digest to be a replacement for sending passwords.

>> I think that the nonce and nc mechanisms are far too complex
>> and dependent on both server state and "remembering" previous
>> nonce values.  What goals do these mechanisms serve?  I suspect
>> they can be accomplished by a single fixed server-provided
>> nonce (64 bit server timestamp of nonce generation) and a simple
>> client-provided nonce (counter).  These values do not need to be
>> "remembered" by the server -- the client is responsible for its
>> own increments and the server can reject a returned server-nonce
>> if its value is outside the TTL range of its own timestamp.
>
> Actually, nc mechanism seems to be complex in the specification, but
> the requirements are very simple to implement.  The purpose of the
> nonce specification in the draft is to make Mutual authentication
> secure against passive eavesdropping and limited replay attacks, to
> the same level proper implementations of Digest authentication
> provides. (Of course we recommend to use TLS for complete protection.)
>
> Seeing the real implementation of Digest mechanism, duplication check
> of cnonce value is usually omitted.  I observe that one reason for
> this is that clients can choose whatever cnonces of their favorite,
> and the server must remember all of those received cnonces for the
> lifetime of the server nonce.  This makes impossible to implement
> servers to handle one session (specified by a server nonce) in fixed
> amount of memory and makes it unscalable.  The key point of our nc
> specification is that server is explicitly allowed to reject any nc
> values which are "old" (as defined by nc-window) as invalid requests,
> and makes possible to check nc duplication in fixed amount of memory.
>
>
> To answer auth-domain issue, we have to describe requirements to us  
> from
> web-application designer's side, as I said, our proposal is to replace
> flexible form-based authentication at the same time.  Please let me  
> have
> some minutes to assemble those up.

Thanks, but there is no rush -- I will be in Vancouver and maybe that
will give me a chance to understand the Apache module implementation.

....Roy

Date: Tue, 27 Nov 2007 19:37:11 -0500
From: "Robert Sayre" <[email-masked]>
To: "Eric Rescorla" <[email-masked]>
Subject: Re: Re[2]: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Cc: [email-masked]

On Nov 27, 2007 6:36 PM, Eric Rescorla <[email-masked]> wrote:
> At Tue, 27 Nov 2007 18:16:51 -0500,
> Robert Sayre wrote:
> >
> > On Nov 27, 2007 5:09 PM, Eric Rescorla <[email-masked]> wrote:
> > >
> > > In my experience, the content for which phishing is a real concern
> > > is mostly dynamic and therefore is extremely difficult to cache.
> >
> > This is true of the HTML content, but not necessarily for the rest of
> > the resources on the page, like images. Mixing HTTPS and HTTP
> > resources results in warnings, display failures, etc in most modern
> > browsers.
>
> Yes, as it should. Integrity of the images is important. Of course,
> since what we're doing is talking about changing the client,
> there are ways to solve this problem. The most obvious is to
> attach a digest of the expected content to the link. Then it
> would be safe to serve over HTTP.
>
>
> > This is the reason well-funded sites like banks still serve
> > forms over HTTP on their homepages (one exception I know of is
> > bankofamerica.com).
>
> Hmm... Wells Fargo is also an exception. TLS is getting cheaper,
> so I expect this to be near universal relatively soon.

Counterexamples: http://wachovia.com, http://chase.com,
http://gmail.com (though you can force https here)

> > Serving non-cached ancillary resources over TLS
> > connections to every unauthenticated client is expensive.
>
> I agree that it's more expensive than not doing so. I don't agree
> that it's really prohibitively expensive.

Depends how big your site is, and how bursty the traffic is. It seems
hard to make the claim ahead of the requirements.

>
> > > > TLS is an appropriate solution for some authentication use cases, but
> > > > certainly not all.
> > >
> > > Hmm... So there are a number of different security aspects to
> > > disentangle here, but fundamentally, if you're going to bother with
> > > mutual authentication, you probably need to provide message integrity
> > > for the server's response. Otherwise, the attacker can simply proxy
> > > your authentication handshake and then rewrite the pages to suit
> > > himself, including attacking your authentication tokens (remember,
> > > same site policy doesn't apply here). And once you're doing that, it's
> > > really not much easier or proxy friendly to provide auth at the HTTP
> > > layer than the TLS layer. If you think I'm wrong on this, I'd
> > > love to see your protocol design.
> >
> > There is a desirable property concerning both request and response
> > bodies that we're glossing over. The message recipient should be able
> > to authenticate the message before processing the body.
>
> I agree that this is nice. I don't agree that it's critical.
> Mostly, having to do the integrity check at the end
> allows a sort of lame DoS attack. That seems irritating, but
> not critical to fix.

The importance varies with expected payloads. For form submissions, I
agree it's probably not a big deal. Counterexample: The Content-MD5
approach is required by Amazon AWS.

> Moreover, you still need an integrity check over the entire
> message. This calls for some sort of chunked integrity. Luckily, TLS
> has this.

Could you explain further here?

>
> Even ignoring this issue, I'm not sure I understand what you are
> proposing: when I fetch data out of the proxy cache, how do you
> envision me getting message integrity.

Ah, this is a good point, and maybe fatal if the cost of TLS
approaches the cost of regular HTTP traffic. I was thinking of the
text dealing with this issue in RFC 2617 (section 3.2.2.5), but it
looks like that won't be sufficient, because it seems to rely on the
proxy cache acting in good faith. A big underspecification in 2617, I
think.

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

Date: Tue, 27 Nov 2007 15:36:58 -0800
From: Eric Rescorla <[email-masked]>
To: "Robert Sayre" <[email-masked]>
Subject: Re: Re[2]: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Cc: [email-masked]

At Tue, 27 Nov 2007 18:16:51 -0500,
Robert Sayre wrote:
> 
> On Nov 27, 2007 5:09 PM, Eric Rescorla <[email-masked]> wrote:
> >
> > In my experience, the content for which phishing is a real concern
> > is mostly dynamic and therefore is extremely difficult to cache.
> 
> This is true of the HTML content, but not necessarily for the rest of
> the resources on the page, like images. Mixing HTTPS and HTTP
> resources results in warnings, display failures, etc in most modern
> browsers.

Yes, as it should. Integrity of the images is important. Of course,
since what we're doing is talking about changing the client,
there are ways to solve this problem. The most obvious is to
attach a digest of the expected content to the link. Then it
would be safe to serve over HTTP.

> This is the reason well-funded sites like banks still serve
> forms over HTTP on their homepages (one exception I know of is
> bankofamerica.com).

Hmm... Wells Fargo is also an exception. TLS is getting cheaper,
so I expect this to be near universal relatively soon.

> Serving non-cached ancillary resources over TLS
> connections to every unauthenticated client is expensive.

I agree that it's more expensive than not doing so. I don't agree
that it's really prohibitively expensive.

> > > TLS is an appropriate solution for some authentication use cases, but
> > > certainly not all.
> >
> > Hmm... So there are a number of different security aspects to
> > disentangle here, but fundamentally, if you're going to bother with
> > mutual authentication, you probably need to provide message integrity
> > for the server's response. Otherwise, the attacker can simply proxy
> > your authentication handshake and then rewrite the pages to suit
> > himself, including attacking your authentication tokens (remember,
> > same site policy doesn't apply here). And once you're doing that, it's
> > really not much easier or proxy friendly to provide auth at the HTTP
> > layer than the TLS layer. If you think I'm wrong on this, I'd
> > love to see your protocol design.
> 
> There is a desirable property concerning both request and response
> bodies that we're glossing over. The message recipient should be able
> to authenticate the message before processing the body.

I agree that this is nice. I don't agree that it's critical.
Mostly, having to do the integrity check at the end
allows a sort of lame DoS attack. That seems irritating, but
not critical to fix.

Moreover, you still need an integrity check over the entire
message. This calls for some sort of chunked integrity. Luckily, TLS
has this.

> That is,
> message integrity is only checked once credentials have been verified.
> There are three distinct situations the scheme needs to check for:
> 
>   1.) Request bodies
>   2.) Cacheable response bodies
>   3.) Non-cacheable response bodies
> 
> 1 and 2 can be handled by including the value of a Content-MD5
> header as part of the digest. This allows servers to ignore message
> bodies and skip integrity checks of client requests (e.g. video
> uploads). The client must calculate the hash ahead of the request
> for POST/PUT, but this burden is small for all but the most
> write-heavy clients. It's also not much of a burden for servers to
> calculate Content-MD5 once, in the case of cacheable resources. It's
> the third situation that makes TLS message integrity more
> appealing. One solution is to require either Content-MD5 (and thus
> buffering of the full response) or a multipart response where the
> second part contains the hash of the first part. For the latter, the
> client would have to process the body, of course.

Yes, one could optimize the situation beyond what TLS currently does,
but the result is that one is forced to force-fit an
authentication/handshake system that TLS already has (and is expensive
to design and maintain) into the not particularly congenial HTTP
dataflow. If you trust the cache and are just trying to avoid warnings
from the browser (and are willing to change the browser) there are
more attractive options, especially since there are plenty of
settings where the page containing the media MUST be confidential,
which means TLS.

Even ignoring this issue, I'm not sure I understand what you are
proposing: when I fetch data out of the proxy cache, how do you
envision me getting message integrity.

-Ekr

Date: Tue, 27 Nov 2007 18:16:51 -0500
From: "Robert Sayre" <[email-masked]>
To: "Eric Rescorla" <[email-masked]>
Subject: Re: Re[2]: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Cc: [email-masked]

On Nov 27, 2007 5:09 PM, Eric Rescorla <[email-masked]> wrote:
>
> In my experience, the content for which phishing is a real concern
> is mostly dynamic and therefore is extremely difficult to cache.

This is true of the HTML content, but not necessarily for the rest of
the resources on the page, like images. Mixing HTTPS and HTTP
resources results in warnings, display failures, etc in most modern
browsers. This is the reason well-funded sites like banks still serve
forms over HTTP on their homepages (one exception I know of is
bankofamerica.com). Serving non-cached ancillary resources over TLS
connections to every unauthenticated client is expensive.

>
> > TLS is an appropriate solution for some authentication use cases, but
> > certainly not all.
>
> Hmm... So there are a number of different security aspects to
> disentangle here, but fundamentally, if you're going to bother with
> mutual authentication, you probably need to provide message integrity
> for the server's response. Otherwise, the attacker can simply proxy
> your authentication handshake and then rewrite the pages to suit
> himself, including attacking your authentication tokens (remember,
> same site policy doesn't apply here). And once you're doing that, it's
> really not much easier or proxy friendly to provide auth at the HTTP
> layer than the TLS layer. If you think I'm wrong on this, I'd
> love to see your protocol design.

There is a desirable property concerning both request and response
bodies that we're glossing over. The message recipient should be able
to authenticate the message before processing the body. That is,
message integrity is only checked once credentials have been verified.
There are three distinct situations the scheme needs to check for:

  1.) Request bodies
  2.) Cacheable response bodies
  3.) Non-cacheable response bodies

1 and 2 can be handled by including the value of a Content-MD5 header
as part of the digest. This allows servers to ignore message bodies
and skip integrity checks of client requests (e.g. video uploads). The
client must calculate the hash ahead of the request for POST/PUT, but
this burden is small for all but the most write-heavy clients. It's
also not much of a burden for servers to calculate Content-MD5 once,
in the case of cacheable resources.

It's the third situation that makes TLS message integrity more
appealing. One solution is to require either Content-MD5 (and thus
buffering of the full response) or a multipart response where the
second part contains the hash of the first part. For the latter, the
client would have to process the body, of course.

- Rob

Date: Tue, 27 Nov 2007 14:09:44 -0800
From: Eric Rescorla <[email-masked]>
To: "Robert Sayre" <[email-masked]>
Subject: Re: Re[2]: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Cc: [email-masked]

At Tue, 27 Nov 2007 13:48:19 -0500,
Robert Sayre wrote:
> 
> On Nov 27, 2007 9:58 AM, Eric Rescorla <[email-masked]> wrote:
> >
> > Again, support for this is ALREADY IN TLS, which solves all the
> > relevant channel security issues.
> 
> Unfortunately, HTTP scalability relies on caching by intermediaries.

I'm not sure I believe this, but let's stipulate that it's true.

In my experience, the content for which phishing is a real concern
is mostly dynamic and therefore is extremely difficult to cache. If
you have extensive static content, you can do TLS for the initial
authentication and then use cookies over HTTP for continuing 
authentication to allow caching.

> TLS is an appropriate solution for some authentication use cases, but
> certainly not all.

Hmm... So there are a number of different security aspects to
disentangle here, but fundamentally, if you're going to bother with
mutual authentication, you probably need to provide message integrity
for the server's response. Otherwise, the attacker can simply proxy
your authentication handshake and then rewrite the pages to suit
himself, including attacking your authentication tokens (remember,
same site policy doesn't apply here). And once you're doing that, it's
really not much easier or proxy friendly to provide auth at the HTTP
layer than the TLS layer. If you think I'm wrong on this, I'd 
love to see your protocol design.

Now, one *could* argue that one's only concern was dictionary attack
and that therefore mutual auth wasn't needed, but I think that's
wrong for the reasons Chris alluded to earlier.

-Ekr

Date: Tue, 27 Nov 2007 13:48:19 -0500
From: "Robert Sayre" <[email-masked]>
To: "Eric Rescorla" <[email-masked]>
Subject: Re: Re[2]: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Cc: [email-masked]

On Nov 27, 2007 9:58 AM, Eric Rescorla <[email-masked]> wrote:
>
> Again, support for this is ALREADY IN TLS, which solves all the
> relevant channel security issues.

Unfortunately, HTTP scalability relies on caching by intermediaries.
TLS is an appropriate solution for some authentication use cases, but
certainly not all.

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

Date: Tue, 27 Nov 2007 06:58:17 -0800
From: Eric Rescorla <[email-masked]>
To: "Robert Sayre" <[email-masked]>
Subject: Re: Re[2]: [Ietf-http-auth] submitted	draft-oiwa-http-mutualauth-01.txt
Cc: [email-masked]

At Tue, 27 Nov 2007 05:35:42 -0500,
Robert Sayre wrote:
> 
> On Nov 27, 2007 5:25 AM, Chris Drake <[email-masked]> wrote:
> > Hi Roy,
> >
> > While it may be cool to deny phishers access to passwords - that's not
> > really solving the whole underlying problem.  Look-alike sites can and
> > do exist for other reasons, and if a potential victim entered their
> > password, which was then scrambled and sent to the wrong place
> > (phisher), but the phisher ignored it and displayed the expected
> > "next page", that's giving the user false confidence that they're on
> > some trusted site now...
> 
> It is the first, easier step needed to solve the problem. Mutual
> authentication combined new browser UI would be needed to combat the
> problem you're describing.
> 
> FWIW, I got pretty far with a Firefox patch for a Digest variant that
> uses SRP. I had to shelve it in Firefox 3 for scheduling reasons.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=356855
> 
> The scheme in the bug and linked drafts might invest too much effort
> in message integrity. It is easy to go too far there in an effort to
> prevent MITM attacks.

Unfortunately, I don't think that's true. Unless you provide
server->client message integrity, you're extremely susceptible
to "mafia fraud/bucket brigade" type attacks. And of course,
unless you tie this to the TLS connection somehow you've still
got confidentiality issues for any data passed over the connection.

Again, support for this is ALREADY IN TLS, which solves all the
relevant channel security issues.

-Ekr

Date: Tue, 27 Nov 2007 06:55:16 -0800
From: Eric Rescorla <[email-masked]>
To: Chris Drake <[email-masked]>
Subject: Re: Re[2]: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Cc: [email-masked]

At Tue, 27 Nov 2007 20:25:08 +1000,
Chris Drake wrote:
> 
> Hi Roy,
> 
> While it may be cool to deny phishers access to passwords - that's not
> really solving the whole underlying problem.  Look-alike sites can and
> do exist for other reasons, and if a potential victim entered their
> password, which was then scrambled and sent to the wrong place
> (phisher), but the phisher ignored it and displayed the expected
> "next page", that's giving the user false confidence that they're on
> some trusted site now

Yes, this is exactly why techniques that use the password to establish
a secure channel are attractive: if the phisher doesn't know the
password then you can't establish a connection with them at all.

There are actually two issues getting conflated here:

1. The current HTTP authentication techniques involve the client
   proving to the server that they share a secret, but not vice
   versa. There are a variety of solutions that fix this problem,
   but the general idea is to use the shared secret to form
   a cryptographic key which is used to encipher/MAC/whatever
   the messages flowing between client and server so that the
   phisher can't impersonate the server using the attack you
   suggest. 

2. There are at least two basic techniques for building a protocol of
   type (1) above. The first is to use the password directly, e.g.,
   key = Hash(Password). The difficulty here is that an exhaustive
   search of the password space can be used to recover the key based
   on a single recorded transaction.  

   The second is to use what's called Password Authenticated Key
   Agreement (PAKE) or Zero Knowledge Password Proof (ZKPP). These are
   public key based schemes that have the interesting property that
   they bootstrap a password up to a key in such a way that you
   can't do dictionary search. The simplest of these schemes is
   EKE. The difficulty here is that most of these schemes have an
   uh, interesting IPR story.

The attack you're discussing is actually stopped by (1). The
phisher then has to do a dictionary attack on your password
to impersonate the server. Obviously, (2) is more secure.

Again, I want to stress that TLS *already has* support for both
kinds of schemes in TLS-PSK (RFC 4279) and in TLS-SRP
(draft-ietf-tls-srp-14, currently in RFC Ed queue.) If this
is the path you want to go down, there is with high probability
no need to invent anything new, and almost certainly no need
to put it in HTTP.

-Ekr

Date: Tue, 27 Nov 2007 06:39:45 -0800
From: Eric Rescorla <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Cc: [email-masked]

At Tue, 27 Nov 2007 00:28:14 -0800,
Roy T. Fielding wrote:
> 
> On Nov 26, 2007, at 9:37 PM, Eric Rescorla wrote:
> >> IMO, auth-domain needs to be the entire URI prefix for the area
> >> over which the same authentication applies (scheme, authority,
> >> and path-prefix [what the draft calls host + path]), what I
> >> would call the auth-prefix, and should be required as a field
> >> value on all requests in addition to being included within
> >> the hash.  The validation would always include this auth-prefix
> >> for unencrypted channels, and *both* the auth-prefix and tls-key
> >> for TLS channels.  [I don't understand the reasoning behind
> >> tls-cert being used at all, since in actual practice "certificate
> >> verification" is a waste of time (CAs are not secure).
> >
> > As a side note, this claim strikes me as substantially too
> > strong.
> 
> Perhaps.  I don't believe that CAs are careful enough in issuing
> certificates, and it is certainly the case that not all TLS sites
> bother to pay the tax for CA-signed certs.  This algorithm should
> not be dependent on them.  Perhaps what I am looking for is a
> mechanism that doesn't require Mutual Auth (aside from proving
> knowledge of a shared secret), but can still detect MITM.

I agree with all of this.

-Ekr

Date: Tue, 27 Nov 2007 13:24:20 +0100
From: Eliot Lear <[email-masked]>
To: Chris Drake <[email-masked]>
Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Cc: [email-masked]

Chris Drake wrote:
> Hi Roy,
>
> While it may be cool to deny phishers access to passwords - that's not
> really solving the whole underlying problem.  Look-alike sites can and
> do exist for other reasons, and if a potential victim entered their
> password, which was then scrambled and sent to the wrong place
> (phisher), but the phisher ignored it and displayed the expected
> "next page", that's giving the user false confidence that they're on
> some trusted site now [...]

So what you want is some proof that this site X is the same site X with
which you previously registered.  You actually don't care if anyone else
is asserting that Site X is actually THE Site X.

Eliot

Date: Tue, 27 Nov 2007 21:40:15 +1000
From: Chris Drake <[email-masked]>
To: "Robert Sayre" <[email-masked]>
Subject: Re[4]: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Cc: [email-masked]

Hi Robert,

Congrats on your initial solution.  I would have thought thought, that
after coding this, you'd have realized that the problem of phishing
obsoletes the paradigm of solution "components" - it's just not
possible to solve the problem in pieces.  You need to start with a
"blank page" and a complete understanding of what you want to fix,
then devise the whole solution.  If you just fix one bit - you'll
quickly discover that the "before and after" components that you were
hoping someone else might do one day will never "fit" - if they're
even possible to do at all, and if anyone ever does them anyhow...

Kind Regards,
Chris Drake

Tuesday, November 27, 2007, 8:35:42 PM, you wrote:

RS> On Nov 27, 2007 5:25 AM, Chris Drake <[email-masked]> wrote:
>> Hi Roy,
>>
>> While it may be cool to deny phishers access to passwords - that's not
>> really solving the whole underlying problem.  Look-alike sites can and
>> do exist for other reasons, and if a potential victim entered their
>> password, which was then scrambled and sent to the wrong place
>> (phisher), but the phisher ignored it and displayed the expected
>> "next page", that's giving the user false confidence that they're on
>> some trusted site now...

RS> It is the first, easier step needed to solve the problem. Mutual
RS> authentication combined new browser UI would be needed to combat the
RS> problem you're describing.

RS> FWIW, I got pretty far with a Firefox patch for a Digest variant that
RS> uses SRP. I had to shelve it in Firefox 3 for scheduling reasons.

RS> https://bugzilla.mozilla.org/show_bug.cgi?id=356855

RS> The scheme in the bug and linked drafts might invest too much effort
RS> in message integrity. It is easy to go too far there in an effort to
RS> prevent MITM attacks.

Date: Tue, 27 Nov 2007 05:35:42 -0500
From: "Robert Sayre" <[email-masked]>
To: "Chris Drake" <[email-masked]>
Subject: Re: Re[2]: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Cc: [email-masked]

On Nov 27, 2007 5:25 AM, Chris Drake <[email-masked]> wrote:
> Hi Roy,
>
> While it may be cool to deny phishers access to passwords - that's not
> really solving the whole underlying problem.  Look-alike sites can and
> do exist for other reasons, and if a potential victim entered their
> password, which was then scrambled and sent to the wrong place
> (phisher), but the phisher ignored it and displayed the expected
> "next page", that's giving the user false confidence that they're on
> some trusted site now...

It is the first, easier step needed to solve the problem. Mutual
authentication combined new browser UI would be needed to combat the
problem you're describing.

FWIW, I got pretty far with a Firefox patch for a Digest variant that
uses SRP. I had to shelve it in Firefox 3 for scheduling reasons.

https://bugzilla.mozilla.org/show_bug.cgi?id=356855

The scheme in the bug and linked drafts might invest too much effort
in message integrity. It is easy to go too far there in an effort to
prevent MITM attacks.

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

Date: Tue, 27 Nov 2007 20:25:08 +1000
From: Chris Drake <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Subject: Re[2]: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Cc: [email-masked]

Hi Roy,

While it may be cool to deny phishers access to passwords - that's not
really solving the whole underlying problem.  Look-alike sites can and
do exist for other reasons, and if a potential victim entered their
password, which was then scrambled and sent to the wrong place
(phisher), but the phisher ignored it and displayed the expected
"next page", that's giving the user false confidence that they're on
some trusted site now - thus they're highly susceptible to all kinds
of subsequent attacks - "click here to install our new banking access
security component", or, "your password has expired - please choose a
new one", or, "we need to verify your account - please enter your
phone-number/social-security-number/password-again/credit-card/...";
the brazen could even phone the victim in real-time, and ask for their
password.  I recall listening to my Dad taking a (legit) call from his
phone company - they asked for his date of birth, full name, and
account PIN - all of which he gave without questioning.  After the
call, I told him he was mad for giving some random stranger all that
info, and he called me an idiot - "Who else would ever need to ask me
that information" he snapped.

Phishers are not stupid.  If you plug only one hole, they'll just
switch to another.  Only a holistic solution is worthwhile.

If you don't 100% protect stupid users against smart phishers, you're
just wasting everyone's time and potentially making things worse.

Kind Regards,
Chris Drake

Tuesday, November 27, 2007, 7:37:18 PM, you wrote:

RTF> On Nov 27, 2007, at 1:10 AM, Eliot Lear wrote:

>> Roy T. Fielding wrote:
>>> Perhaps.  I don't believe that CAs are careful enough in issuing
>>> certificates, and it is certainly the case that not all TLS sites
>>> bother to pay the tax for CA-signed certs.  This algorithm should
>>> not be dependent on them.  Perhaps what I am looking for is a
>>> mechanism that doesn't require Mutual Auth (aside from proving
>>> knowledge of a shared secret), but can still detect MITM.
>>
>> Fundamentally phishing is possible because of an absence of mutual
>> authentication.

RTF> They may not be mutually exclusive -- it is possible to defeat phishing
RTF> by proving that the server knows the same secret that the client knows
RTF> (usually a password) in a way that can't be relayed/mirrored by a MITM.
RTF> Exchanging that proof without actually exchanging the secret and
RTF> without enclosing the entire session in TLS is what I want.

RTF> I would call that a form of mutual authentication, whereas
RTF> I think others tend to assume that Mutual Auth has to include
RTF> domain/ownership association as well.  YMMV.  I don't know what
RTF> is included in the "real" definition of mutual auth, or even if
RTF> there is one such definition that security folks prefer.

RTF> ....Roy
RTF> _______________________________________________
RTF> Ietf-http-auth mailing list
RTF> [email-masked]
RTF> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth

From: "Roy T. Fielding" <[email-masked]>
Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Date: Tue, 27 Nov 2007 01:37:18 -0800
To: Eliot Lear <[email-masked]>
Cc: [email-masked]

On Nov 27, 2007, at 1:10 AM, Eliot Lear wrote:

> Roy T. Fielding wrote:
>> Perhaps.  I don't believe that CAs are careful enough in issuing
>> certificates, and it is certainly the case that not all TLS sites
>> bother to pay the tax for CA-signed certs.  This algorithm should
>> not be dependent on them.  Perhaps what I am looking for is a
>> mechanism that doesn't require Mutual Auth (aside from proving
>> knowledge of a shared secret), but can still detect MITM.
>
> Fundamentally phishing is possible because of an absence of mutual
> authentication.

They may not be mutually exclusive -- it is possible to defeat phishing
by proving that the server knows the same secret that the client knows
(usually a password) in a way that can't be relayed/mirrored by a MITM.
Exchanging that proof without actually exchanging the secret and
without enclosing the entire session in TLS is what I want.

I would call that a form of mutual authentication, whereas
I think others tend to assume that Mutual Auth has to include
domain/ownership association as well.  YMMV.  I don't know what
is included in the "real" definition of mutual auth, or even if
there is one such definition that security folks prefer.

....Roy

Date: Tue, 27 Nov 2007 10:10:05 +0100
From: Eliot Lear <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Cc: [email-masked]

Roy T. Fielding wrote:
> Perhaps.  I don't believe that CAs are careful enough in issuing
> certificates, and it is certainly the case that not all TLS sites
> bother to pay the tax for CA-signed certs.  This algorithm should
> not be dependent on them.  Perhaps what I am looking for is a
> mechanism that doesn't require Mutual Auth (aside from proving
> knowledge of a shared secret), but can still detect MITM.

Fundamentally phishing is possible because of an absence of mutual
authentication.  I guess I don't understand what problem you are
attempting to solve.

Eliot

From: "Roy T. Fielding" <[email-masked]>
Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Date: Tue, 27 Nov 2007 00:28:14 -0800
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]

On Nov 26, 2007, at 9:37 PM, Eric Rescorla wrote:
>> IMO, auth-domain needs to be the entire URI prefix for the area
>> over which the same authentication applies (scheme, authority,
>> and path-prefix [what the draft calls host + path]), what I
>> would call the auth-prefix, and should be required as a field
>> value on all requests in addition to being included within
>> the hash.  The validation would always include this auth-prefix
>> for unencrypted channels, and *both* the auth-prefix and tls-key
>> for TLS channels.  [I don't understand the reasoning behind
>> tls-cert being used at all, since in actual practice "certificate
>> verification" is a waste of time (CAs are not secure).
>
> As a side note, this claim strikes me as substantially too
> strong.

Perhaps.  I don't believe that CAs are careful enough in issuing
certificates, and it is certainly the case that not all TLS sites
bother to pay the tax for CA-signed certs.  This algorithm should
not be dependent on them.  Perhaps what I am looking for is a
mechanism that doesn't require Mutual Auth (aside from proving
knowledge of a shared secret), but can still detect MITM.

....Roy

From: "Roy T. Fielding" <[email-masked]>
Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Date: Mon, 26 Nov 2007 23:47:58 -0800
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]

On Nov 26, 2007, at 9:41 PM, Eric Rescorla wrote:

> At Mon, 26 Nov 2007 21:37:31 -0800,
> Eric Rescorla wrote:
>>
>> At Mon, 26 Nov 2007 20:36:59 -0800,
>> Roy T. Fielding wrote:
>>> should be replaced by the actual equations, with only an informative
>>> reference to [ISO.11770-4.2006].  I suspect these are just a  
>>> variation
>>> of the SRP or PwdHash techniques that have been published before,  
>>> but
>>> I have no access to the ISO document to verify.
>>
>> It's important to note that PwdHash and SRP really are quite
>> qualitatively different.
>>
>> - SRP is a mechanism for a pair of agents to derive a strong
>>   shared key starting with only a weak shared secret.
>> - PwdHash is purely a password diversification technique: it
>>   allows you to use a single memorized password to produce
>>   different passwords for each server you communicate with.
>>
>> These really aren't the same thing at all. In the context of
>
> Oops. Hit send too early.
>
> In the setting we're talking about here, the major differences
> include:
>
> - PwdHash is subject to offline dictionary attacks. SRP is not.
> - SRP is designed to be used to key a data security protocol.
>   PwdHash is designed to simply give you a new password you
>   feed into the ordinary password mechanisms.

Yeah, I meant to delete that reference to PwdHash but forgot in
my rush to get home for dinner -- it's been at least 18 months
since I read those papers and others on EKE, SAKA, PAKE
(Katz/Ostrovsky/Yung 2001), IEEE P1363.2/D23, ... and it is all
a blur at this point.

....Roy

To: "Roy T. Fielding" <[email-masked]>
Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
From: Yutaka OIWA <[email-masked]>
Date: Tue, 27 Nov 2007 16:14:06 +0900
Cc: [email-masked]

Dear Roy,

Thank you very much for very prompt reply.

Please allow me to answer some of your questions (simple to answer) first.

"Roy T. Fielding" <[email-masked]> writes:

>     The equations for J, w_A, T, z, K_i, and w_B are those specified for
>     KAM3 in [ISO.11770-4.2006], given that pi is derived in the above
>     equation.
>
> should be replaced by the actual equations, with only an informative
> reference to [ISO.11770-4.2006].

I see.  As I am not expert of the exact requirements for IETF
standardization processes, this kind of suggestions are very
helpful.  Maybe I could include the full equation in the next
draft.

>  [I don't understand the reasoning behind
> tls-cert being used at all, since in actual practice "certificate
> verification" is a waste of time (CAs are not secure).  What
> matters is that the server reject a channel binding that
> would indicate a MITM attack, for which the tls-key should
> be sufficient.  However, I am not a crypto expert.]

This is because I am worrying about that forcing tls-key
authentication would cause some implementation difficulty
where black-box TLS implementations are used.
Tls-keys are usually hidden inside TLS modules, but
certs must be (in some way) available to the browser layer.
We are asking our implementation people under collaboration
to find out how exactly difficult to implement the tls-key,
so if the answer is "easy", we think we can safely drop the
tls-cert entirely.

In security, tls-cert itself can ensure safety even if self-signed
certificate is used, because the tls-cert validation effectively
checks matching of used secret key.  When the server secret key paired
with the certificate is leaked, tls-cert will become vulnerable.

> "logout-timeout" should be named "ttl" (bits matter) and its
> expiration MUST result in clearing the authentication state
> unless updated by a later ttl.  In addition, clients should
> be reminded (again) that any login UI should have a
> corresponding client-side logout UI, even though that logout
> is not communicated via the protocol.

I agree.  For the UI matter, please let me think again what amount of
requirements to be stated "REQUIRED" in protocol specification, and
what kind of issues are kept to be informational.

> I don't think it is necessary to have a sid -- that adds
> session state to the protocol, for no apparent reason, and
> thus greatly reduces the scalability of servers.

Actually, "sid" correspond to "server nonce" in Digest authentication
which must be kept in server-side. The name differs because
in Digest "nonce" is both a session identifier and an encryption key at
the same time,  but in Mutual authentication it is just an identifier.

We carefully designed the protocol so that servers can be implemented
without having complex state managements.  Server-side session caches
can be erased at any time after one request is served, this is just
the same as Digest does.

> I think that the nonce and nc mechanisms are far too complex
> and dependent on both server state and "remembering" previous
> nonce values.  What goals do these mechanisms serve?  I suspect
> they can be accomplished by a single fixed server-provided
> nonce (64 bit server timestamp of nonce generation) and a simple
> client-provided nonce (counter).  These values do not need to be
> "remembered" by the server -- the client is responsible for its
> own increments and the server can reject a returned server-nonce
> if its value is outside the TTL range of its own timestamp.

Actually, nc mechanism seems to be complex in the specification, but
the requirements are very simple to implement.  The purpose of the
nonce specification in the draft is to make Mutual authentication
secure against passive eavesdropping and limited replay attacks, to
the same level proper implementations of Digest authentication
provides. (Of course we recommend to use TLS for complete protection.)

Seeing the real implementation of Digest mechanism, duplication check
of cnonce value is usually omitted.  I observe that one reason for
this is that clients can choose whatever cnonces of their favorite,
and the server must remember all of those received cnonces for the
lifetime of the server nonce.  This makes impossible to implement
servers to handle one session (specified by a server nonce) in fixed
amount of memory and makes it unscalable.  The key point of our nc
specification is that server is explicitly allowed to reject any nc
values which are "old" (as defined by nc-window) as invalid requests,
and makes possible to check nc duplication in fixed amount of memory.

To answer auth-domain issue, we have to describe requirements to us from
web-application designer's side, as I said, our proposal is to replace
flexible form-based authentication at the same time.  Please let me have
some minutes to assemble those up.

-- 
Yutaka OIWA, Ph.D.                                       Research Scientist
                            Research Center for Information Security (RCIS)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[995DD3E1] fp[3C21 17D0 D953 77D3 02D7 4FEC 4754 40C1 995D D3E1]

Date: Mon, 26 Nov 2007 21:41:04 -0800
From: Eric Rescorla <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Cc: [email-masked]

At Mon, 26 Nov 2007 21:37:31 -0800,
Eric Rescorla wrote:
> 
> At Mon, 26 Nov 2007 20:36:59 -0800,
> Roy T. Fielding wrote:
> > should be replaced by the actual equations, with only an informative
> > reference to [ISO.11770-4.2006].  I suspect these are just a variation
> > of the SRP or PwdHash techniques that have been published before, but
> > I have no access to the ISO document to verify.
> 
> It's important to note that PwdHash and SRP really are quite
> qualitatively different. 
> 
> - SRP is a mechanism for a pair of agents to derive a strong
>   shared key starting with only a weak shared secret. 
> - PwdHash is purely a password diversification technique: it
>   allows you to use a single memorized password to produce
>   different passwords for each server you communicate with.
> 
> These really aren't the same thing at all. In the context of 

Oops. Hit send too early.

In the setting we're talking about here, the major differences
include:

- PwdHash is subject to offline dictionary attacks. SRP is not.
- SRP is designed to be used to key a data security protocol.
  PwdHash is designed to simply give you a new password you
  feed into the ordinary password mechanisms.

-Ekr

Date: Mon, 26 Nov 2007 21:37:31 -0800
From: Eric Rescorla <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Cc: [email-masked]

At Mon, 26 Nov 2007 20:36:59 -0800,
Roy T. Fielding wrote:
> should be replaced by the actual equations, with only an informative
> reference to [ISO.11770-4.2006].  I suspect these are just a variation
> of the SRP or PwdHash techniques that have been published before, but
> I have no access to the ISO document to verify.

It's important to note that PwdHash and SRP really are quite
qualitatively different. 

- SRP is a mechanism for a pair of agents to derive a strong
  shared key starting with only a weak shared secret. 
- PwdHash is purely a password diversification technique: it
  allows you to use a single memorized password to produce
  different passwords for each server you communicate with.

These really aren't the same thing at all. In the context of 

> IMO, auth-domain needs to be the entire URI prefix for the area
> over which the same authentication applies (scheme, authority,
> and path-prefix [what the draft calls host + path]), what I
> would call the auth-prefix, and should be required as a field
> value on all requests in addition to being included within
> the hash.  The validation would always include this auth-prefix
> for unencrypted channels, and *both* the auth-prefix and tls-key
> for TLS channels.  [I don't understand the reasoning behind
> tls-cert being used at all, since in actual practice "certificate
> verification" is a waste of time (CAs are not secure).

As a side note, this claim strikes me as substantially too
strong. 

-Ekr

Date: Mon, 26 Nov 2007 21:31:04 -0800
From: Eric Rescorla <[email-masked]>
To: Yutaka OIWA <[email-masked]>
Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Cc: [email-masked]

At Tue, 27 Nov 2007 05:26:10 +0900,
Yutaka OIWA wrote:
> We have recently submitted an Internet-Draft named
> draft-oiwa-http-mutualauth-01.txt.
> 
> This memo proposes a method for strong password-based mutual
> authentication on HTTP.  It is an intermediate result of the joint
> research project between Yahoo! Japan, Inc and us (Research Center for
> Information Security (RCIS), National Institute of Advanced Industrial
> Science and Technology (AIST)).
> 
> Main idea behind the proposal is that when user-memorable passwords
> are used with existing protocols, phishing attacks are very effective
> to steal both user passwords and other private information.  When
> either Basic or form-based authentication are used, it is trivial to
> steal the passwords, and furthermore, it is very easy to convince
> (phish) users that they have been successfully logged into the
> original site.  Digest authentication also does not solve the problem:
> the server can blindly accept the clients without knowing the correct
> passwords, and by using recent powerful CPU, it is easy to reverse the
> simple MD5 hashes unless the passwords are significantly long (such as
> 25+ characters).  Other hash-based protocols are also vulnerable for
> similar offline attacks by its nature.
> 
> Our proposal prevents all of those attacks.  By using a (modified)
> variant of PAKE cryptographic authentication protocol, fake servers
> can't forge authentication success unless the correct passwords are
> known to them.  Furthermore, even if clients have negotiated with
> phishing servers, the phishers can't acquire user's password even if
> offline blute-force attacks are performed.  It means that it is "safe"
> to perform authentication with phishing servers, and users can check
> whether they have contacted with genuine hosts by simply checking the
> result of the authentication.
> 
> For further information, please refer to the draft, or our
> presentation materials at recent APWG '07 eCrime Workshop on
> 
> http://staff.aist.go.jp/y.oiwa/publications/2007-APWG-MutualAuth-Abstract.pdf
> http://staff.aist.go.jp/y.oiwa/publications/2007-APWG-MutualAuth.pdf
> 
> 
> We intend to supersede both current HTTP header-based authentications
> and form-based authentications by our proposal.  To achieve this goal,
> some extensions to current HTTP Authorization mechanism are also
> proposed.  We will research further possibilities and requirements for
> replacing form-based authentication by HTTP authentications, and
> we will incorporate it in future revisions of the draft.
> 
> Currently, we have implemented a preliminary version of this protocol
> to both Apache and Mozilla Firefox.  Both implementations will be
> available to public once the implementation and testing are finished.
> We are also preparing to have some public field experiments on some
> part of the Yahoo! Japan website in 1Q or 2Q in the next year,
> hopefully.
> 
> Comments are always welcome.
> If you visit IETF 70, we look forward to seeing you at Vancouver.

A few questions/comments:

1. I don't see why this makes sense to do at the HTTP layer. Wouldn't
   it be more straightforward to do this in TLS rather than adapting
   Digest? I also would note that TLS-SRP has already been approved
   by the IESG.

2. Do you have a pointer to a complete description of the crypto
   protocol this is based on? A little searching didn't turn
   up anything non-free.

3. There are a large number of PAKE/ZKPP protocols. Can you please
   explain why one would want this protocol versus others?

4. I see you've filed an IPR disclosure on this technique. Is your
   own IPR the only IPR which you're aware of?

-Ekr

From: "Roy T. Fielding" <[email-masked]>
Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt
Date: Mon, 26 Nov 2007 20:36:59 -0800
To: Yutaka OIWA <[email-masked]>
Cc: [email-masked]

On Nov 26, 2007, at 12:26 PM, Yutaka OIWA wrote:

> We have recently submitted an Internet-Draft named
> draft-oiwa-http-mutualauth-01.txt.

Dear Yutaka,

I think that something like this proposal is capable of being
deployed on a fairly rapid basis.  However, the draft needs to
disclose all of the details of the algorithms -- it can't rely
on reference to [ISO.11770-4.2006] because that document is not
readily available and may be subject to additional intellectual
property disclaimers that would hinder adoption.  In particular

    The equations for J, w_A, T, z, K_i, and w_B are those specified for
    KAM3 in [ISO.11770-4.2006], given that pi is derived in the above
    equation.

should be replaced by the actual equations, with only an informative
reference to [ISO.11770-4.2006].  I suspect these are just a variation
of the SRP or PwdHash techniques that have been published before, but
I have no access to the ISO document to verify.

In addition, here are my suggestions for future drafts.  Most are
for the sake of reducing variants in how the algorithm is used
to those actually necessary for interoperability.  If you have
use cases in mind that cannot be achieved without all of the
variants, then we should include those use cases in the draft.

IMO, auth-domain needs to be the entire URI prefix for the area
over which the same authentication applies (scheme, authority,
and path-prefix [what the draft calls host + path]), what I
would call the auth-prefix, and should be required as a field
value on all requests in addition to being included within
the hash.  The validation would always include this auth-prefix
for unencrypted channels, and *both* the auth-prefix and tls-key
for TLS channels.  [I don't understand the reasoning behind
tls-cert being used at all, since in actual practice "certificate
verification" is a waste of time (CAs are not secure).  What
matters is that the server reject a channel binding that
would indicate a MITM attack, for which the tls-key should
be sufficient.  However, I am not a crypto expert.]

The server MUST validate that the request-URI matches the
auth-prefix for all authenticated requests.  Including the
auth-prefix in the request allows the data for the hash to
be communicated through gateways (which will have to perform
their own validation of that data).

"logout-timeout" should be named "ttl" (bits matter) and its
expiration MUST result in clearing the authentication state
unless updated by a later ttl.  In addition, clients should
be reminded (again) that any login UI should have a
corresponding client-side logout UI, even though that logout
is not communicated via the protocol.

I don't think it is necessary to have a sid -- that adds
session state to the protocol, for no apparent reason, and
thus greatly reduces the scalability of servers.

I think that the nonce and nc mechanisms are far too complex
and dependent on both server state and "remembering" previous
nonce values.  What goals do these mechanisms serve?  I suspect
they can be accomplished by a single fixed server-provided
nonce (64 bit server timestamp of nonce generation) and a simple
client-provided nonce (counter).  These values do not need to be
"remembered" by the server -- the client is responsible for its
own increments and the server can reject a returned server-nonce
if its value is outside the TTL range of its own timestamp.

Finally, please note that all of these concepts (except maybe
optional mutual auth) have been discussed in public mailing lists
in the past.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

To: [email-masked]
From: Yutaka OIWA <[email-masked]>
Date: Tue, 27 Nov 2007 05:26:10 +0900
Subject: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt

Dear Ietf-http-auth members,

We have recently submitted an Internet-Draft named
draft-oiwa-http-mutualauth-01.txt.

This memo proposes a method for strong password-based mutual
authentication on HTTP.  It is an intermediate result of the joint
research project between Yahoo! Japan, Inc and us (Research Center for
Information Security (RCIS), National Institute of Advanced Industrial
Science and Technology (AIST)).

Main idea behind the proposal is that when user-memorable passwords
are used with existing protocols, phishing attacks are very effective
to steal both user passwords and other private information.  When
either Basic or form-based authentication are used, it is trivial to
steal the passwords, and furthermore, it is very easy to convince
(phish) users that they have been successfully logged into the
original site.  Digest authentication also does not solve the problem:
the server can blindly accept the clients without knowing the correct
passwords, and by using recent powerful CPU, it is easy to reverse the
simple MD5 hashes unless the passwords are significantly long (such as
25+ characters).  Other hash-based protocols are also vulnerable for
similar offline attacks by its nature.

Our proposal prevents all of those attacks.  By using a (modified)
variant of PAKE cryptographic authentication protocol, fake servers
can't forge authentication success unless the correct passwords are
known to them.  Furthermore, even if clients have negotiated with
phishing servers, the phishers can't acquire user's password even if
offline blute-force attacks are performed.  It means that it is "safe"
to perform authentication with phishing servers, and users can check
whether they have contacted with genuine hosts by simply checking the
result of the authentication.

For further information, please refer to the draft, or our
presentation materials at recent APWG '07 eCrime Workshop on

http://staff.aist.go.jp/y.oiwa/publications/2007-APWG-MutualAuth-Abstract.pdf
http://staff.aist.go.jp/y.oiwa/publications/2007-APWG-MutualAuth.pdf

We intend to supersede both current HTTP header-based authentications
and form-based authentications by our proposal.  To achieve this goal,
some extensions to current HTTP Authorization mechanism are also
proposed.  We will research further possibilities and requirements for
replacing form-based authentication by HTTP authentications, and
we will incorporate it in future revisions of the draft.

Currently, we have implemented a preliminary version of this protocol
to both Apache and Mozilla Firefox.  Both implementations will be
available to public once the implementation and testing are finished.
We are also preparing to have some public field experiments on some
part of the Yahoo! Japan website in 1Q or 2Q in the next year,
hopefully.

Comments are always welcome.
If you visit IETF 70, we look forward to seeing you at Vancouver.

Best Regards,

-- 
Yutaka OIWA, Ph.D.                                       Research Scientist
                            Research Center for Information Security (RCIS)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[995DD3E1] fp[3C21 17D0 D953 77D3 02D7 4FEC 4754 40C1 995D D3E1]

Date: Sun, 25 Nov 2007 08:26:35 -0800
From: Eric Rescorla <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re: [Ietf-http-auth] Submitted draft 06
Cc: [email-masked]

At Sun, 25 Nov 2007 07:35:50 -0500,
Sam Hartman wrote:
> 
> >>>>> "Eric" == Eric Rescorla <[email-masked]> writes:
> 
> 
>     Eric> - The coverage of the literature is still grossly deficient.
>     Eric> Seriously, there has been a lot of work on phishing
>     Eric> resistant authentication mechanisms and having a document
>     Eric> which doesn't credit any of it (a) isn't very useful and (b)
>     Eric> looks bad.  I appreciate this isn't an academic paper, but
>     Eric> that doesn't mean it's OK to appear to neglect all the prior
>     Eric> work.
> 
> We disagree on this point; it's my reading of the discussion during
> the last call that people agreed adding some citations would be a good
> idea but disagreed with your claim here. 

Yes, I appreciate that, but you asked people to read and comment
on this document. I did.

> I do not intend to fix this
> to your satisfaction unless directed to do so by ALexey or lisa.

Again, I'd like to make the procedural point that this document is
not with the IESG and Alexey is not the shepherd, so he can't
direct you do to anything. For that matter, since this is an
individual submission, neither can Lisa. 

>     Eric> At an even higher level, I also find myself pretty puzzled
>     Eric> by the putative purpose of this document. (1) It's destined
>     Eric> for informational (2) it says that it doesn't levy
>     Eric> requirements on WGs and yet (3) it's represented as the
>     Eric> opinion of the IETF (see S 1.1.) and (4) uses RFC 2119
>     Eric> normative language. This seems odd. 
> 
> I think the use of RFC 2119 languague is consistent with a lot of
> informational documents I've reviewed for the IESG.
> 
> Section 1.1 is a new section and I may have gotten it wrong.  I
> certainly don't know that we have agreement to that text; we
> definitely need to discuss that section.
> 
> However if section 1.1 claims that there is an IETF consensus behind
> this document then I didn't say what I intended to say and would
> appreciate help saying it more clearly.  What I intended to say (and
> hope to achieve) is that the IETF has consensus that working on authentication systems that meet these requirements is a useful step.

Well, I don't agree with that statement either.

-Ekr

Date: Sun, 25 Nov 2007 22:53:43 +1000
From: Chris Drake <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re[2]: [Ietf-http-auth] Submitted draft 06
Cc: [email-masked]

Hi,

I don't think the document does what it claims - ie: to represent
"Requirements for Web Authentication Resistant to Phishing"). 

Please don't be offended - I'm only stating my opinion here - but it
appears to spell out one (Sams?) solution and the requirements for 
it, while discrediting or ignoring everything else.  Yes - there are a
lot of useful "Requirements" - but if a document seriously wanted to
live up to that title - it would need to be a comprehensive study of
existing art, categorized into existing and theoretical solutions,
with each having it's own set of requirements.  One set of
requirements is simply not suitable for all solutions, and only one
solution is not really suitable for an IETF document with this title.

Kind Regards,
Chris Drake

Sunday, November 25, 2007, 10:35:50 PM, you wrote:

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

SH>     Eric> - The coverage of the literature is still grossly deficient.
SH>     Eric> Seriously, there has been a lot of work on phishing
SH>     Eric> resistant authentication mechanisms and having a document
SH>     Eric> which doesn't credit any of it (a) isn't very useful and (b)
SH>     Eric> looks bad.  I appreciate this isn't an academic paper, but
SH>     Eric> that doesn't mean it's OK to appear to neglect all the prior
SH>     Eric> work.

SH> We disagree on this point; it's my reading of the discussion during
SH> the last call that people agreed adding some citations would be a good
SH> idea but disagreed with your claim here.  I do not intend to fix this
SH> to your satisfaction unless directed to do so by ALexey or lisa.  I'd
SH> assume that they would direct me to do so if they believe the
SH> consensus of the ietf or this list is that doing so would be a useful investment in
SH> time and would improve the document.

SH>     Eric> - The document still focuses on cryptographic mutual
SH>     Eric> authentication mechanisms. Given that there are mechanisms
SH>     Eric> (e.g., PwdHash) which provide substantial phishing
SH>     Eric> resistance without modifying the server and that the mutual
SH>     Eric> auth mechanisms do, rejecting them without even discussing
SH>     Eric> them (see S 4.3) seems quite inappropriate.

SH> True; this is not within the scope of the changes I claimed to make
SH> for 06 and I agree it is still an open issue.

SH>     Eric> - The document mentions ZKPP/PAKE systems (twice) but
SH>     Eric> somehow omits TLS-PSK. I understand that there are technical
SH>     Eric> reasons why one might prefer ZKPPs--though TLS-PSK is an
SH>     Eric> enormous improvement over the current systems--but you need
SH>     Eric> to explain it, not just assert it.

SH> I agree this has not been dealt with and should be.

SH>     Eric> At a higher level, if you're going to levy requirements, you
SH>     Eric> need to actually explain what they are, not just levy
SH>     Eric> them. This document does a quite inadequate job of that.

SH> I'm not sure I agree with this claim.  I think I understand what you
SH> are saying but I'm not sure I think the document strikes the wrong
SH> balance here.  I'd appreciate input from others besides Eric as I
SH> suspect the two of us would quickly spin on this issue.

SH>     Eric> At an even higher level, I also find myself pretty puzzled
SH>     Eric> by the putative purpose of this document. (1) It's destined
SH>     Eric> for informational (2) it says that it doesn't levy
SH>     Eric> requirements on WGs and yet (3) it's represented as the
SH>     Eric> opinion of the IETF (see S 1.1.) and (4) uses RFC 2119
SH>     Eric> normative language. This seems odd. 

SH> I think the use of RFC 2119 languague is consistent with a lot of
SH> informational documents I've reviewed for the IESG.

SH> Section 1.1 is a new section and I may have gotten it wrong.  I
SH> certainly don't know that we have agreement to that text; we
SH> definitely need to discuss that section.

SH> However if section 1.1 claims that there is an IETF consensus behind
SH> this document then I didn't say what I intended to say and would
SH> appreciate help saying it more clearly.  What I intended to say (and
SH> hope to achieve) is that the IETF has consensus that working
SH> on authentication systems that meet these requirements is a useful
SH> step.

SH> I'd appreciate comments both on whether we're trying to do that with
SH> this document and on  whether I successfully say that in section 1.1.

SH>     Eric> I don't agree that this
SH>     Eric> document has the consensus of the IETF (it doesn't have
SH>     Eric> mine) and don't think it should be represented as such. 

SH> I believe that section 1.1 will need to be explicitly included in an
SH> ietf last call and that section 1.1 is not a true statement until such
SH> a last call succeeds.

SH>     Eric> I've
SH>     Eric> got no problem with it being published and represented as
SH>     Eric> Sam Hartman's opinion.

SH> If I just wanted to publish my opinion I'd long ago have written a
SH> blong entry or published an independent submission.  If we (meaning
SH> the community, probably not you and I) cannot reach agreement I may
SH> well submit the resulting draft to the rfc editor (obviously without
SH> section 1.1).  However I think the document will be far more valuable
SH> if we can get to a point where something like section 1.1 is
SH> appropriate.

SH> _______________________________________________
SH> Ietf-http-auth mailing list
SH> [email-masked]
SH> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth

From: Sam Hartman <[email-masked]>
To: Eric Rescorla <[email-masked]>
Subject: Re: [Ietf-http-auth] Submitted draft 06
Date: Sun, 25 Nov 2007 07:35:50 -0500
Cc: [email-masked]

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

    Eric> - The coverage of the literature is still grossly deficient.
    Eric> Seriously, there has been a lot of work on phishing
    Eric> resistant authentication mechanisms and having a document
    Eric> which doesn't credit any of it (a) isn't very useful and (b)
    Eric> looks bad.  I appreciate this isn't an academic paper, but
    Eric> that doesn't mean it's OK to appear to neglect all the prior
    Eric> work.

We disagree on this point; it's my reading of the discussion during
the last call that people agreed adding some citations would be a good
idea but disagreed with your claim here.  I do not intend to fix this
to your satisfaction unless directed to do so by ALexey or lisa.  I'd
assume that they would direct me to do so if they believe the
consensus of the ietf or this list is that doing so would be a useful investment in
time and would improve the document.

    Eric> - The document still focuses on cryptographic mutual
    Eric> authentication mechanisms. Given that there are mechanisms
    Eric> (e.g., PwdHash) which provide substantial phishing
    Eric> resistance without modifying the server and that the mutual
    Eric> auth mechanisms do, rejecting them without even discussing
    Eric> them (see S 4.3) seems quite inappropriate.

True; this is not within the scope of the changes I claimed to make
for 06 and I agree it is still an open issue.

    Eric> - The document mentions ZKPP/PAKE systems (twice) but
    Eric> somehow omits TLS-PSK. I understand that there are technical
    Eric> reasons why one might prefer ZKPPs--though TLS-PSK is an
    Eric> enormous improvement over the current systems--but you need
    Eric> to explain it, not just assert it.

I agree this has not been dealt with and should be.

    Eric> At a higher level, if you're going to levy requirements, you
    Eric> need to actually explain what they are, not just levy
    Eric> them. This document does a quite inadequate job of that.

I'm not sure I agree with this claim.  I think I understand what you
are saying but I'm not sure I think the document strikes the wrong
balance here.  I'd appreciate input from others besides Eric as I
suspect the two of us would quickly spin on this issue.

    Eric> At an even higher level, I also find myself pretty puzzled
    Eric> by the putative purpose of this document. (1) It's destined
    Eric> for informational (2) it says that it doesn't levy
    Eric> requirements on WGs and yet (3) it's represented as the
    Eric> opinion of the IETF (see S 1.1.) and (4) uses RFC 2119
    Eric> normative language. This seems odd. 

I think the use of RFC 2119 languague is consistent with a lot of
informational documents I've reviewed for the IESG.

Section 1.1 is a new section and I may have gotten it wrong.  I
certainly don't know that we have agreement to that text; we
definitely need to discuss that section.

However if section 1.1 claims that there is an IETF consensus behind
this document then I didn't say what I intended to say and would
appreciate help saying it more clearly.  What I intended to say (and
hope to achieve) is that the IETF has consensus that working on authentication systems that meet these requirements is a useful step.

I'd appreciate comments both on whether we're trying to do that with
this document and on  whether I successfully say that in section 1.1.

    Eric> I don't agree that this
    Eric> document has the consensus of the IETF (it doesn't have
    Eric> mine) and don't think it should be represented as such. 

I believe that section 1.1 will need to be explicitly included in an
ietf last call and that section 1.1 is not a true statement until such
a last call succeeds.

    Eric> I've
    Eric> got no problem with it being published and represented as
    Eric> Sam Hartman's opinion.

If I just wanted to publish my opinion I'd long ago have written a
blong entry or published an independent submission.  If we (meaning
the community, probably not you and I) cannot reach agreement I may
well submit the resulting draft to the rfc editor (obviously without
section 1.1).  However I think the document will be far more valuable
if we can get to a point where something like section 1.1 is
appropriate.

Date: Sat, 24 Nov 2007 19:46:53 -0800
From: Eric Rescorla <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re: [Ietf-http-auth] Submitted draft 06
Cc: [email-masked]

$Id: draft-hartman-webauth-phishing-06-rev.txt,v 1.1 2007/11/25 03:43:56 ekr Exp $

Sam,

I've just finished reading draft-hartman-webauth-phishing-06-rev.
There are some areas in which it's improved, but generally
it suffers from most of the same deficiencies I identified in 
my review of version -05.

In particular (but not exhaustively):

- The coverage of the literature is still grossly deficient.
  Seriously, there has been a lot of work on phishing resistant
  authentication mechanisms and having a document which doesn't credit
  any of it (a) isn't very useful and (b) looks bad.  I appreciate
  this isn't an academic paper, but that doesn't mean it's OK to
  appear to neglect all the prior work.

- The document still focuses on cryptographic mutual authentication
  mechanisms. Given that there are mechanisms (e.g., PwdHash) which
  provide substantial phishing resistance without modifying the server
  and that the mutual auth mechanisms do, rejecting them without even
  discussing them (see S 4.3) seems quite inappropriate.

- The document mentions ZKPP/PAKE systems (twice) but somehow omits
  TLS-PSK. I understand that there are technical reasons why
  one might prefer ZKPPs--though TLS-PSK is an enormous improvement
  over the current systems--but you need to explain it, not just
  assert it.

At a higher level, if you're going to levy requirements,
you need to actually explain what they are, not just levy
them. This document does a quite inadequate job of that.

At an even higher level, I also find myself pretty puzzled by the
putative purpose of this document. (1) It's destined for informational
(2) it says that it doesn't levy requirements on WGs and yet (3) it's
represented as the opinion of the IETF (see S 1.1.) and (4) uses RFC
2119 normative language. This seems odd. I don't agree that this
document has the consensus of the IETF (it doesn't have mine) and
don't think it should be represented as such. I've got no problem with
it being published and represented as Sam Hartman's opinion.

Reviewing the diffs it seems that this version principally adds some
explanatory text, but the problem is that much of the text needs
rewriting. So, no, I don't really think this is headed in the right
direction.  Or rather, the magnitude of the vector is so small it's
hard to tell if it's in the right direction.

-Ekr

From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Sun, 18 Nov 2007 22:44:44 -0500
Subject: [Ietf-http-auth] Submitted draft 06

Hi.

I've submitted draft 06.

This includes changes up through the threat model.  I may not have
addressed all comments; I still need to finish making the first pass
through the entire document and then go back over reviewer comments.

However I'd appreciate it if you would review the changes I've made
and see if you think I'm heading ithe right direction.  If so, please
let me know.  If not, please explain why not.

Thanks,

--Sam

Resent-From: Christian Vogt <[email-masked]>
Resent-To: [email-masked]
Resent-Date: Fri, 16 Nov 2007 11:39:20 +0200
Resent-Message-Id: <[email-masked]>
Resent-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666
Date: Thu, 15 Nov 2007 17:22:45 +0200
From: Christian Vogt <[email-masked]>
To: Eliot Lear <[email-masked]>
Cc: Gen-ART Mailing List <[email-masked]>, [email-masked]
Subject: [Ietf-http-auth] Re: draft-hartman-webauth-phishing Section 3.1

Hi Eliot -

I think we are actually on the same page regarding section 3.1, and this
is just a terminology question.  What you consider "private" is the
personal data desired by the attacker, whereas I was considering this to
be the user's username and password.

>>    Mechanisms attackers use to accomplish this include links with a
>>    misleading name or URI, which they may distribute in emails;
>>    attacks against DNS; and man-in-the-middle attacks against a TLS
>>    handshake.  The former two attacks allow the attacker to pass
>>    authentication because the victim user can be tricked into
>>    accepting the attacker's certificate.  The latter attack will
>>    typically create a warning on the victim user's side, but many
>>    users cannot make informed decisions on how to respond to such a
>>    warning, making them inclined to accept the bogus certificate.
> 
> I do like this text, with the exception that I would replace "cannot
> make informed decisions" with "do not make informed decisions".  And
> indeed you have hit the nail on the head here IMHO.

Yes, that replacement makes sense.

Alright, take care,
- Christian

Date: Thu, 08 Nov 2007 15:57:26 +0100
From: Eliot Lear <[email-masked]>
To: Christian Vogt <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-http-auth] draft-hartman-webauth-phishing Section 3.1

Hello Christian,

Some time ago, you had sent Sam text regarding
draft-hartman-webauth-phishing, Section 3.1.  I understand this may have
been part of a GenArt review (thank you for taking the time).  As I am
the instigator of some of that text (and quite honestly I don't recall
which part - too many cobwebs upstairs), let me see if we can go through
your comments.

Starting with this:

> Alright, I see that the intent of section 3.1 is actually to describe
> capabilities that an attacker will *always* have, i.e., even in case it
> does not know (and cannot acquire) a username/password from a victim
> user.  Maybe you can clarify this by changing the latter part of paragraph
> 2 of section 3.1 like this:
>   
>    OLD
>
>                                                      However the
>    attacker probably could not replicate the account summary page until
>    the attacker learned the user name and password because the attacker
>    would not know what accounts to list or approximate balances that
>    will look convincing to a user.  Of course attackers may know some
>    personal information about a user.  Websites that want to rely on
>    attackers not knowing certain information need to maintain the
>    privacy of that information.
>
>    NEW
>
>                                                      However the
>    attacker probably could not replicate the account summary page
>    until the attacker learned the user name and password because the
>    attacker would not know what accounts to list or approximate
>    balances that will look convincing to a user.  Preventing the
>    attacker from acquiring a victim's user name and password would thus
>    make it impossible for an attacker to spoof a user interface that
>    shows such individual data.
> What I did is replacing the last two existing sentences with a new
> one.  Would you agree?

I believe the intent here is to say that whatever private data a web
site maintains, REGARDLESS OF THE FORM OF THAT DATA, need to go to great
pains to keep that information private.  The idea in this paragraph is
that it should be difficult for a phisher to reproduce even an
authentic-looking web page to the user.  Put another way, the site
should prove itself to the user.  And so the private data may be account
numbers and approximate value of those accounts or holdings.  And so I
don't believe the proposed changes above would be appropriate in this case.

HOWEVER...

> Here is some text that you could take to replace the currently last
> sentence in paragraph 1 of section 3.1.  If you wish, feel free to
> copy and paste:
>    Mechanisms attackers use to accomplish this include links with a
>    misleading name or URI, which they may distribute in emails;
>    attacks against DNS; and man-in-the-middle attacks against a TLS
>    handshake.  The former two attacks allow the attacker to pass
>    authentication because the victim user can be tricked into
>    accepting the attacker's certificate.  The latter attack will
>    typically create a warning on the victim user's side, but many
>    users cannot make informed decisions on how to respond to such a
>    warning, making them inclined to accept the bogus certificate.

I do like this text, with the exception that I would replace "cannot
make informed decisions" with "do not make informed decisions".  And
indeed you have hit the nail on the head here IMHO.

Regards,

Eliot

From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Wed, 07 Nov 2007 10:38:09 -0500
Subject: [Ietf-http-auth] Proposals for review

--=-=-=

I've been quiet because I've been considering the review comments,
doing some additional literature review based on Eric's comments and
working on other projects.

I had previously looked at the papers Eric cited, although especially
in the case of "The Emperor's New Security Indicators," I had not
integrated what's really an important paper for this work.  I was well
aware that the UI suggestions I'm making may not work and depend on
finding a way to get people to take advantage of them in practice.
That's not reflected in the current document at all.

I still disagree with Eric that the references section of this draft
should be a survey of the literature, but I do agree that citations
need to be added and that the document needs significant rewording not
to overstate the value of speculative claims and to make it clear
assumptions that are necessary for the system to work.

For a variety of reasons I've started a pass from the beginning of the
document going through and rewording the text.  Once I'm done with
that, I'll make a pass through all the open reviews and propose
changes.

I've made it through the introduction and a good chunk of the threat
model.  I'd appreciate review of these proposed changes so far.
More to follow.

--=-=-=
Content-Type: text/html
Content-Disposition: inline;
	filename=draft-hartman-webauth-phishing-from--05.diff.html
Content-Description: Diff of webauth phishing 05 to 06a

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 
<!-- Generated by rfcdiff 1.26: rfcdiff draft-hartman-webauth-phishing-05.txt draft-hartman-webauth-phishing.txt --> 
<!-- <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional" > -->
<!-- System: Linux live 2.6.18-4-amd64 #1 SMP Mon Mar 26 11:36:53 CEST 2007 x86_64 GNU/Linux --> 
<!-- Using awk: /usr/bin/gawk: GNU Awk 3.1.5 --> 
<!-- Using diff: /usr/bin/diff: diff (GNU diffutils) 2.8.1 --> 
<!-- Using wdiff: /usr/bin/wdiff: GNU wdiff 0.5 --> 
<html> 
<head> 
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> 
  <meta http-equiv="Content-Style-Type" content="text/css" /> 
  <title>Diff: draft-hartman-webauth-phishing-05.txt - draft-hartman-webauth-phishing.txt</title> 
  <style type="text/css"> 
    body    { margin: 0.4ex; margin-right: auto; } 
    tr      { } 
    td      { white-space: pre; font-family: monospace; vertical-align: top; font-size: 9pt;} 
    th      { font-size: 11pt; } 
    .small  { font-size: 7pt; font-style: italic; font-family: Verdana, Helvetica, sans-serif; } 
    .left   { background-color: #EEE; } 
    .right  { background-color: #FFF; } 
    .diff   { background-color: #CCF; } 
    .lblock { background-color: #BFB; } 
    .rblock { background-color: #FF8; } 
    .insert { background-color: #8FF; } 
    .delete { background-color: #ACF; } 
    .void   { background-color: #FFB; } 
    .cont   { background-color: #EEE; } 
    .linebr { background-color: #AAA; } 
    .lineno { color: red; background-color: #FFF; font-size: 8pt; text-align: right; padding: 0 2px; } 
    .elipsis{ background-color: #AAA; } 
    .left .cont { background-color: #DDD; } 
    .right .cont { background-color: #EEE; } 
    .lblock .cont { background-color: #9D9; } 
    .rblock .cont { background-color: #DD6; } 
    .insert .cont { background-color: #0DD; } 
    .delete .cont { background-color: #8AD; } 
  </style> 
</head> 
<body > 
  <table border="0" cellpadding="0" cellspacing="0"> 
  <tr bgcolor="orange"><th></th><th>&nbsp;draft-hartman-webauth-phishing-05.txt&nbsp;</th><th> </th><th>&nbsp;draft-hartman-webauth-phishing.txt&nbsp;</th><th></th></tr> 
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">Network Working Group                                         S. Hartman</td><td> </td><td class="right">Network Working Group                                         S. Hartman</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">Internet-Draft                                                       MIT</td><td> </td><td class="right">Internet-Draft                                                       MIT</td><td class="lineno" valign="top"></td></tr>
      <tr><td><a name="diff0001" /></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">Intended status: Informational                             <span class="delete">July 25,</span> 2007</td><td> </td><td class="rblock">Intended status: Informational                          <span class="insert">November 7,</span> 2007</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">Expires: <span class="delete">January 26,</span> 2008</td><td> </td><td class="rblock">Expires: <span class="insert">May 10,</span> 2008</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">       Requirements for Web Authentication Resistant to Phishing</td><td> </td><td class="right">       Requirements for Web Authentication Resistant to Phishing</td><td class="lineno" valign="top"></td></tr>
      <tr><td><a name="diff0002" /></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">                 draft-hartman-webauth-phishing-0<span class="delete">5</span>.txt</td><td> </td><td class="rblock">                 draft-hartman-webauth-phishing-0<span class="insert">6a</span>.txt</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">Status of this Memo</td><td> </td><td class="right">Status of this Memo</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   By submitting this Internet-Draft, each author represents that any</td><td> </td><td class="right">   By submitting this Internet-Draft, each author represents that any</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   applicable patent or other IPR claims of which he or she is aware</td><td> </td><td class="right">   applicable patent or other IPR claims of which he or she is aware</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   have been or will be disclosed, and any of which he or she becomes</td><td> </td><td class="right">   have been or will be disclosed, and any of which he or she becomes</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   aware will be disclosed, in accordance with Section 6 of BCP 79.</td><td> </td><td class="right">   aware will be disclosed, in accordance with Section 6 of BCP 79.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   Internet-Drafts are working documents of the Internet Engineering</td><td> </td><td class="right">   Internet-Drafts are working documents of the Internet Engineering</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   Task Force (IETF), its areas, and its working groups.  Note that</td><td> </td><td class="right">   Task Force (IETF), its areas, and its working groups.  Note that</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr bgcolor="gray" ><td></td><th><a name="part-l2" /><small>skipping to change at</small><em> page 1, line 34</em></th><th> </th><th><a name="part-r2" /><small>skipping to change at</small><em> page 1, line 34</em></th><td></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   and may be updated, replaced, or obsoleted by other documents at any</td><td> </td><td class="right">   and may be updated, replaced, or obsoleted by other documents at any</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   time.  It is inappropriate to use Internet-Drafts as reference</td><td> </td><td class="right">   time.  It is inappropriate to use Internet-Drafts as reference</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   material or to cite them other than as "work in progress."</td><td> </td><td class="right">   material or to cite them other than as "work in progress."</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   The list of current Internet-Drafts can be accessed at</td><td> </td><td class="right">   The list of current Internet-Drafts can be accessed at</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   http://www.ietf.org/ietf/1id-abstracts.txt.</td><td> </td><td class="right">   http://www.ietf.org/ietf/1id-abstracts.txt.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   The list of Internet-Draft Shadow Directories can be accessed at</td><td> </td><td class="right">   The list of Internet-Draft Shadow Directories can be accessed at</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   http://www.ietf.org/shadow.html.</td><td> </td><td class="right">   http://www.ietf.org/shadow.html.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td><a name="diff0003" /></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   This Internet-Draft will expire on <span class="delete">January 26</span>, 2008.</td><td> </td><td class="rblock">   This Internet-Draft will expire on <span class="insert">May 10</span>, 2008.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">Copyright Notice</td><td> </td><td class="right">Copyright Notice</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   Copyright (C) The IETF Trust (2007).</td><td> </td><td class="right">   Copyright (C) The IETF Trust (2007).</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">Abstract</td><td> </td><td class="right">Abstract</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   This memo proposes requirements for protocols between web identity</td><td> </td><td class="right">   This memo proposes requirements for protocols between web identity</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   providers and users and for requirements for protocols between</td><td> </td><td class="right">   providers and users and for requirements for protocols between</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   identity providers and relying parties.  These requirements minimize</td><td> </td><td class="right">   identity providers and relying parties.  These requirements minimize</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr bgcolor="gray" ><td></td><th><a name="part-l3" /><small>skipping to change at</small><em> page 2, line 24</em></th><th> </th><th><a name="part-r3" /><small>skipping to change at</small><em> page 2, line 24</em></th><td></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   as passwords that can be used to impersonate the user to third</td><td> </td><td class="right">   as passwords that can be used to impersonate the user to third</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   parties.  Browsers should perform mutual authentication and flag</td><td> </td><td class="right">   parties.  Browsers should perform mutual authentication and flag</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   situations when the target website is not authorized to accept the</td><td> </td><td class="right">   situations when the target website is not authorized to accept the</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   identity being offered as this is a strong indication of fraud.</td><td> </td><td class="right">   identity being offered as this is a strong indication of fraud.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   These requirements may serve as a basis for requirements for</td><td> </td><td class="right">   These requirements may serve as a basis for requirements for</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   preventing fraud in environments other than the web.</td><td> </td><td class="right">   preventing fraud in environments other than the web.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">Table of Contents</td><td> </td><td class="right">Table of Contents</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3</td><td> </td><td class="right">   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3</td><td class="lineno" valign="top"></td></tr>
      <tr><td><a name="diff0004" /></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock">     <span class="insert">1.1.  Purpose of this Memo . . . . . . . . . . . . . . . . . . .  4</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">     1.2.  Passwords and Interface  . . . . . . . . . . . . . . . . .  4</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   2.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  5</td><td> </td><td class="right">   2.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  5</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   3.  Threat Model . . . . . . . . . . . . . . . . . . . . . . . . .  6</td><td> </td><td class="right">   3.  Threat Model . . . . . . . . . . . . . . . . . . . . . . . . .  6</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">     3.1.  Capabilities of Attackers  . . . . . . . . . . . . . . . .  6</td><td> </td><td class="right">     3.1.  Capabilities of Attackers  . . . . . . . . . . . . . . . .  6</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">     3.2.  Attacks of Interest  . . . . . . . . . . . . . . . . . . .  7</td><td> </td><td class="right">     3.2.  Attacks of Interest  . . . . . . . . . . . . . . . . . . .  7</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   4.  Requirements for Preventing Phishing . . . . . . . . . . . . .  9</td><td> </td><td class="right">   4.  Requirements for Preventing Phishing . . . . . . . . . . . . .  9</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">     4.1.  Support for Passwords and OTher Methods  . . . . . . . . .  9</td><td> </td><td class="right">     4.1.  Support for Passwords and OTher Methods  . . . . . . . . .  9</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">     4.2.  Trusted UI . . . . . . . . . . . . . . . . . . . . . . . . 10</td><td> </td><td class="right">     4.2.  Trusted UI . . . . . . . . . . . . . . . . . . . . . . . . 10</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">     4.3.  No Password Equivelents  . . . . . . . . . . . . . . . . . 10</td><td> </td><td class="right">     4.3.  No Password Equivelents  . . . . . . . . . . . . . . . . . 10</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">     4.4.  Mutual Authentication  . . . . . . . . . . . . . . . . . . 11</td><td> </td><td class="right">     4.4.  Mutual Authentication  . . . . . . . . . . . . . . . . . . 11</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">     4.5.  Authentication Tied to Resulting Page  . . . . . . . . . . 11</td><td> </td><td class="right">     4.5.  Authentication Tied to Resulting Page  . . . . . . . . . . 11</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr bgcolor="gray" ><td></td><th><a name="part-l4" /><small>skipping to change at</small><em> page 2, line 45</em></th><th> </th><th><a name="part-r4" /><small>skipping to change at</small><em> page 2, line 47</em></th><td></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">     4.7.  Protecting Enrollment  . . . . . . . . . . . . . . . . . . 13</td><td> </td><td class="right">     4.7.  Protecting Enrollment  . . . . . . . . . . . . . . . . . . 13</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   5.  Is it the right Server?  . . . . . . . . . . . . . . . . . . . 14</td><td> </td><td class="right">   5.  Is it the right Server?  . . . . . . . . . . . . . . . . . . . 14</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   6.  Iana Considerations  . . . . . . . . . . . . . . . . . . . . . 15</td><td> </td><td class="right">   6.  Iana Considerations  . . . . . . . . . . . . . . . . . . . . . 15</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16</td><td> </td><td class="right">   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17</td><td> </td><td class="right">   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19</td><td> </td><td class="right">   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 19</td><td> </td><td class="right">     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 19</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">     9.2.  Informative References . . . . . . . . . . . . . . . . . . 19</td><td> </td><td class="right">     9.2.  Informative References . . . . . . . . . . . . . . . . . . 19</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   Appendix A.  Trusted UI Mechanisms . . . . . . . . . . . . . . . . 20</td><td> </td><td class="right">   Appendix A.  Trusted UI Mechanisms . . . . . . . . . . . . . . . . 20</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   Appendix B.  Change History  . . . . . . . . . . . . . . . . . . . 21</td><td> </td><td class="right">   Appendix B.  Change History  . . . . . . . . . . . . . . . . . . . 21</td><td class="lineno" valign="top"></td></tr>
      <tr><td><a name="diff0005" /></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">     B.1.  Changes since <span class="delete">02</span> . . . . . . . . . . . . . . . . . . . . . 21</td><td> </td><td class="rblock">     B.1.  Changes since <span class="insert">05</span> . . . . . . . . . . . . . . . . . . . . . 21</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">     B.2.  Changes since 01 . . . . . . . . . . . . . . . . . . . . . 21</td><td> </td><td class="rblock">     B.2.  Changes since <span class="insert">02 . . . . . . . . . . . . . . . . . . . . . 21</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . <span class="delete">22</span></td><td> </td><td class="rblock"><span class="insert">     B.3.  Changes since</span> 01 . . . . . . . . . . . . . . . . . . . . . 21</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   Intellectual Property and Copyright Statements . . . . . . . . . . <span class="delete">23</span></td><td> </td><td class="rblock">   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . <span class="insert">23</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock">   Intellectual Property and Copyright Statements . . . . . . . . . . <span class="insert">24</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">1.  Introduction</td><td> </td><td class="right">1.  Introduction</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   Typically, web sites ask users to send a user name and password in</td><td> </td><td class="right">   Typically, web sites ask users to send a user name and password in</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   order to log in and authenticate their identity to the website.  The</td><td> </td><td class="right">   order to log in and authenticate their identity to the website.  The</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   user name and plaintext password are often sent over a TLS [RFC4346]</td><td> </td><td class="right">   user name and plaintext password are often sent over a TLS [RFC4346]</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   encrypted connection.  As a result of this, the server learns the</td><td> </td><td class="right">   encrypted connection.  As a result of this, the server learns the</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   password and can pretend to be the user to any other system where the</td><td> </td><td class="right">   password and can pretend to be the user to any other system where the</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   user has used the same user name and password.  The security of</td><td> </td><td class="right">   user has used the same user name and password.  The security of</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   passwords over TLS depends on making sure that the password is sent</td><td> </td><td class="right">   passwords over TLS depends on making sure that the password is sent</td><td class="lineno" valign="top"></td></tr>
      <tr><td><a name="diff0006" /></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   to the right, trusted server.  <span class="delete">TLS</span> implementations typically confirm</td><td> </td><td class="rblock">   to the right, trusted server.  <span class="insert">HTTPs [RFC2818]</span> implementations</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   that the name entered by the user in the URL corresponds to the</td><td> </td><td class="rblock">   typically confirm that the name entered by the user in the URL</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   <span class="delete">certificate as described in [RFC2818].</span></td><td> </td><td class="rblock">   corresponds to the <span class="insert">certificate.</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   One serious security threat on the web today is phishing.  Phishing</td><td> </td><td class="right">   One serious security threat on the web today is phishing.  Phishing</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   is a form of fraud where an attacker convinces a user to provide</td><td> </td><td class="right">   is a form of fraud where an attacker convinces a user to provide</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   confidential information to the attacker believing they are providing</td><td> </td><td class="right">   confidential information to the attacker believing they are providing</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   the information to a party they trust with that information.  For</td><td> </td><td class="right">   the information to a party they trust with that information.  For</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   example, an email claiming to be from a user's bank may direct the</td><td> </td><td class="right">   example, an email claiming to be from a user's bank may direct the</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   user to go to a website and verify account information.  The attacker</td><td> </td><td class="right">   user to go to a website and verify account information.  The attacker</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   captures the user name and password and potentially other sensitive</td><td> </td><td class="right">   captures the user name and password and potentially other sensitive</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   information.  Domain names that look like target websites, links in</td><td> </td><td class="right">   information.  Domain names that look like target websites, links in</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   email, and many other factors contribute to phishers' ability to</td><td> </td><td class="right">   email, and many other factors contribute to phishers' ability to</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   convince users to trust them.</td><td> </td><td class="right">   convince users to trust them.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td><a name="diff0007" /></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock">   <span class="insert">Typically the user names and password are not directly valuable to</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   the phisher.  However they can be used to access resources of value.</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   For example a bank password may permit money transfer or access to</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   information useful in identity theft.</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock">                                                                         </td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   It is useful to distinguish two targets of phishing.  Sometimes</td><td> </td><td class="right">   It is useful to distinguish two targets of phishing.  Sometimes</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   phishing is targeting web authentication credentials such as user</td><td> </td><td class="right">   phishing is targeting web authentication credentials such as user</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   name and password.  Sometimes phishing is targeting other</td><td> </td><td class="right">   name and password.  Sometimes phishing is targeting other</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   confidential information, such as bank account numbers.  This memo</td><td> </td><td class="right">   confidential information, such as bank account numbers.  This memo</td><td class="lineno" valign="top"></td></tr>
      <tr><td><a name="diff0008" /></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   presents requirements that significantly reduce the effectiveness of</td><td> </td><td class="rblock">   presents requirements that <span class="insert">can be part of a solution to</span> significantly</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   the first category of phishing: <span class="delete">these requirements guarantee</span> that</td><td> </td><td class="rblock">   reduce the effectiveness of the first category of phishing: <span class="insert">provided</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   even if the user authenticates to the wrong server, that server</td><td> </td><td class="rblock">   that <span class="insert">a user uses an authentication mechanism that meets these</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   cannot impersonate the user to a third party.  However, to combat</td><td> </td><td class="rblock"><span class="insert">   requirements,</span> even if the user authenticates to the wrong server,</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   phishing targeted at other confidential information, the best we <span class="delete">can</span></td><td> </td><td class="rblock">   that server cannot impersonate the user to a third party.  However,</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   do is help the user detect fraud before they release confidential</td><td> </td><td class="rblock">   to combat phishing targeted at other confidential information, the</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   information.</td><td> </td><td class="rblock">   best we <span class="insert">know how to</span> do is help the user detect fraud before they</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock">   release confidential information.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   The approach taken by this memo is to handle these two types of</td><td> </td><td class="right">   The approach taken by this memo is to handle these two types of</td><td class="lineno" valign="top"></td></tr>
      <tr><td><a name="diff0009" /></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   phishing differently.  <span class="delete">Users are</span> given <span class="delete">some trusted mechanism to</span></td><td> </td><td class="rblock">   phishing differently.  <span class="insert">The user is</span> given <span class="insert">new authentication</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete">   determine whether they are typing their password into a secure</span></td><td> </td><td class="rblock"><span class="insert">   mechanisms.</span>  If the user <span class="insert">uses these mechanisms,they</span> have strong</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete">   component that will authenticate them to the server or whether they</span></td><td> </td><td class="rblock">   assurances that their password has not been disclosed and that the</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete">   are typing their password into an HTML form that will send their</span></td><td> </td><td class="rblock">   ensuing data returned from the server was generated by a party that</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete">   password to the server.</span>  If the user <span class="delete">types a password into the</span></td><td> </td><td class="rblock">   either knows their password or who is authenticated by an identity</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete">   trusted component, they</span> have strong assurances that their password</td><td> </td><td class="rblock">   provider who knows their password.  The server can then use</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   has not been disclosed and that the ensuing data returned from the</td><td> </td><td class="rblock">   confidential information known to the user and server to enhance the</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   server was generated by a party that either knows their password or</td><td> </td><td class="rblock">   user's trust in its identity beyond what is available given the</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   who is authenticated by an identity provider who knows their</td><td> </td><td class="rblock">   social engineering attacks against TLS server authentication.  If a</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   password.  The server can then use confidential information known to</td><td> </td><td class="rblock">   user <span class="insert">authenticates to</span> the wrong server but discovers this before they</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   the user and server to enhance the user's trust in its identity</td><td> </td><td class="rblock">   give that server any other confidential information, then there</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   beyond what is available given the social engineering attacks against</td><td> </td><td class="rblock">   exposure is very limited.  <span class="insert">The success of this solution depends</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   TLS server authentication.  If a user <span class="delete">enters their password into</span> the</td><td> </td><td class="rblock"><span class="insert">   heavily on whether the user uses the new authentication mechanisms;</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   wrong server but discovers this before they give that server any</td><td> </td><td class="rblock"><span class="insert">   designing ways for users to tell if they are using the authentication</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   other confidential information, then there exposure is very limited.</td><td> </td><td class="rblock"><span class="insert">   mechanisms and encouraging users to use these mechanisms will be</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   critical to achieving any security benefit from these requirements.</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   The requirements presented in this memo are intended to be useful to</td><td> </td><td class="right">   The requirements presented in this memo are intended to be useful to</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   browser designers, designers of other HTTP applications and designers</td><td> </td><td class="right">   browser designers, designers of other HTTP applications and designers</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   of future HTTP authentication mechanisms.</td><td> </td><td class="right">   of future HTTP authentication mechanisms.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td><a name="diff0010" /></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">1.1.  Purpose of this Memo</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"></span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   In publishing this memo, the IETF recommends the development of web</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   authentication mechanisms that meet the requirements outlined in</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   Section 4.  It is hoped that developing these mechanisms will prove a</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   useful step in fighting phishing.  However this memo does not</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   restrict work either in the IETF or any other organization.  In</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   particular, new authentication efforts are not bound to meet the</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   requirements posed in this memo unless the charter for those efforts</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   chooses to make these binding requirements.  Less formally, the IETF</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   presents this memo as an option to pursue while acknowledging that</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   there may be other promising paths both now and in the future.</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"></span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">1.2.  Passwords and Interface</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"></span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   There are two related concepts: the user interface of passwords and</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   plaintext password protocols.  A plaintext password protocol is a</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   protocol where the server receives credentials sufficient to</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   impersonate a user to third parties.  A password interface provides a</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   user experience where a user types a password into any computer,</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   including one they have never used before and that is sufficient to</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   authenticate.  The requirements in this memo require support for</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   password user interfaces as one option for authentication.  The</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   requirements of this memo are incompatible with plaintext password</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   protocols.</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock">                                                                         </td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">2.  Requirements notation</td><td> </td><td class="right">2.  Requirements notation</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",</td><td> </td><td class="right">   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this</td><td> </td><td class="right">   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   document are to be interpreted as described in [RFC2119].</td><td> </td><td class="right">   document are to be interpreted as described in [RFC2119].</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">3.  Threat Model</td><td> </td><td class="right">3.  Threat Model</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   This section describes the assumed capabilities of phishers,</td><td> </td><td class="right">   This section describes the assumed capabilities of phishers,</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   describes assumptions about web security and describes what</td><td> </td><td class="right">   describes assumptions about web security and describes what</td><td class="lineno" valign="top"></td></tr>
      <tr><td><a name="diff0011" /></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   vulnerabilities exist.</td><td> </td><td class="rblock">   vulnerabilities exist.  <span class="insert">Human factors issues contribute significantly</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   to these vulnerabilities.  For example, security information</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   dialogues in web browsers can provide information on the subject of a</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   certificate.  However, users rarely examine this information, so an</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   attacker could be successful even if examining the security dialogue</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   would show an attack.  This threat model is intended to include these</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   sorts of attacks and so it is broader than the technical threats</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   against protocols.</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   We assume that the implementations of authentication systems can be</td><td> </td><td class="right">   We assume that the implementations of authentication systems can be</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   trusted sufficiently to meet their design objectives.  This does not</td><td> </td><td class="right">   trusted sufficiently to meet their design objectives.  This does not</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   mean that the entire local system and browser need to be trusted.</td><td> </td><td class="right">   mean that the entire local system and browser need to be trusted.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   However if there is a component that has access to users' passwords,</td><td> </td><td class="right">   However if there is a component that has access to users' passwords,</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   that component needs to be secure enough to be trusted not to divulge</td><td> </td><td class="right">   that component needs to be secure enough to be trusted not to divulge</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   passwords to attackers.  Similarly in a system that used smart cards,</td><td> </td><td class="right">   passwords to attackers.  Similarly in a system that used smart cards,</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   the smart cards would need to be trusted not to give attackers access</td><td> </td><td class="right">   the smart cards would need to be trusted not to give attackers access</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   to private keys or other authentication material.  Designing</td><td> </td><td class="right">   to private keys or other authentication material.  Designing</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   implementations to limit the size and complexity of the most trusted</td><td> </td><td class="right">   implementations to limit the size and complexity of the most trusted</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr bgcolor="gray" ><td></td><th><a name="part-l5" /><small>skipping to change at</small><em> page 6, line 47</em></th><th> </th><th><a name="part-r5" /><small>skipping to change at</small><em> page 7, line 5</em></th><td></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   different code points.</td><td> </td><td class="right">   different code points.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">3.1.  Capabilities of Attackers</td><td> </td><td class="right">3.1.  Capabilities of Attackers</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   We assume attackers can convince the user to go to a website of their</td><td> </td><td class="right">   We assume attackers can convince the user to go to a website of their</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   choosing.  Since the attacker controls the web site and since the</td><td> </td><td class="right">   choosing.  Since the attacker controls the web site and since the</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   user chose to go to the website the TLS certificate will verify and</td><td> </td><td class="right">   user chose to go to the website the TLS certificate will verify and</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   the website will appear to be secure.  The certificate will typically</td><td> </td><td class="right">   the website will appear to be secure.  The certificate will typically</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   not be issued to the entity the user thinks they are communicating</td><td> </td><td class="right">   not be issued to the entity the user thinks they are communicating</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   with, but as discussed above, the user will not notice this.</td><td> </td><td class="right">   with, but as discussed above, the user will not notice this.</td><td class="lineno" valign="top"></td></tr>
      <tr><td><a name="diff0012" /></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   Mechanisms attackers use to accomplish this include links <span class="delete">where the</span></td><td> </td><td class="rblock">   Mechanisms attackers use to accomplish this include links with <span class="insert">a</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete">   link name and URI target are misleading; email</span> with <span class="delete">links; DNS</span></td><td> </td><td class="rblock"><span class="insert">   misleading name or URI, which they may distribute in emails; attacks</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete">   attacks;</span> and <span class="delete">on-path network attacks.</span></td><td> </td><td class="rblock"><span class="insert">   against DNS;</span> and <span class="insert">man-in-the-middle attacks against a TLS handshake.</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   The former two attacks allow the attacker to pass authentication</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   because the victim user can be tricked into accepting the attacker's</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   certificate.  The latter attack will typically create a warning on</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   the victim user's side, but many users cannot make informed decisions</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   on how to respond to such a warning, making them inclined to accept</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   the bogus certificate.</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   The attacker can convincingly replicate any part of the UI of the</td><td> </td><td class="right">   The attacker can convincingly replicate any part of the UI of the</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   website being spoofed.  The attacker can also spoof trust markers</td><td> </td><td class="right">   website being spoofed.  The attacker can also spoof trust markers</td><td class="lineno" valign="top"></td></tr>
      <tr><td><a name="diff0013" /></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   such as the security lock, URL bar and other parts of the browser <span class="delete">UI.</span></td><td> </td><td class="rblock">   such as the security lock, URL bar and other parts of the browser <span class="insert">UI</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   There is one limitation to the attacker's ability to replicate UI.</td><td> </td><td class="rblock"><span class="insert">   sufficiently that a significant class of users will not treat the</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   The attacker cannot replicate a UI that depends on information the</td><td> </td><td class="rblock"><span class="insert">   spoofed security indicators as a problem.</span>  There is one limitation to</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   attacker does not know.  For example, an attacker could generally</td><td> </td><td class="rblock">   the attacker's ability to replicate UI.  The attacker cannot</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   replicate the UI of a banking site's login page.  However the</td><td> </td><td class="rblock">   replicate a UI that depends on information the attacker does not</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   attacker probably could not replicate the account summary page until</td><td> </td><td class="rblock">   know.  For example, an attacker could generally replicate the UI of a</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   the attacker learned the user name and password because the attacker</td><td> </td><td class="rblock">   banking site's login page.  However the attacker probably could not</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   would not know what accounts to list or approximate balances that</td><td> </td><td class="rblock">   replicate the account summary page until the attacker learned the</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   will look convincing to a user.  Of course attackers may know some</td><td> </td><td class="rblock">   user name and password because the attacker would not know what</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   personal information about a user.  Websites that want to rely on</td><td> </td><td class="rblock">   accounts to list or approximate balances that will look convincing to</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   attackers not knowing certain information need to maintain the</td><td> </td><td class="rblock">   a user.  Of course attackers may know some personal information about</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   privacy of that information.</td><td> </td><td class="rblock">   a user.  Websites that want to rely on attackers not knowing certain</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock">   information need to maintain the privacy of that information.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   The attacker can convince the user to do anything with the phishing</td><td> </td><td class="right">   The attacker can convince the user to do anything with the phishing</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   site that they would do with the real target site.  As a consequence,</td><td> </td><td class="right">   site that they would do with the real target site.  As a consequence,</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   when passwords are used, if we want to avoid the user giving the</td><td> </td><td class="right">   when passwords are used, if we want to avoid the user giving the</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   attacker their password, the web site must prove that it has an</td><td> </td><td class="right">   attacker their password, the web site must prove that it has an</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   established authentic relationship with the user without requiring a</td><td> </td><td class="right">   established authentic relationship with the user without requiring a</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   static password to do so, and in a way that cannot be visually</td><td> </td><td class="right">   static password to do so, and in a way that cannot be visually</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   mimicked so as to trick a user.  One approach could be to transition</td><td> </td><td class="right">   mimicked so as to trick a user.  One approach could be to transition</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   to a solution where the user could not give the real target site</td><td> </td><td class="right">   to a solution where the user could not give the real target site</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   their password if they are using a new mechanism.  Instead they will</td><td> </td><td class="right">   their password if they are using a new mechanism.  Instead they will</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr bgcolor="gray" ><td></td><th><a name="part-l6" /><small>skipping to change at</small><em> page 16, line 14</em></th><th> </th><th><a name="part-r6" /><small>skipping to change at</small><em> page 16, line 14</em></th><td></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">7.  Acknowledgments</td><td> </td><td class="right">7.  Acknowledgments</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   I'd like to thank Nicolas Williams, Matt Knopp and David Blumenthal</td><td> </td><td class="right">   I'd like to thank Nicolas Williams, Matt Knopp and David Blumenthal</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   for helping me walk through these requirements and make sure that if</td><td> </td><td class="right">   for helping me walk through these requirements and make sure that if</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   a solution met them it would actually protect against the real world</td><td> </td><td class="right">   a solution met them it would actually protect against the real world</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   attacks consumers of our technology are facing.  I was particularly</td><td> </td><td class="right">   attacks consumers of our technology are facing.  I was particularly</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   focusing on attacks that financial institutions are seeing and their</td><td> </td><td class="right">   focusing on attacks that financial institutions are seeing and their</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   help with this was greatly appreciated.</td><td> </td><td class="right">   help with this was greatly appreciated.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td><a name="diff0014" /></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">   I'd like to thank Eric Rescorla and <span class="delete">b</span>en Laurie for their significant</td><td> </td><td class="rblock">   I'd like to thank Eric Rescorla and <span class="insert">B</span>en Laurie for their significant</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   comments on this draft.</td><td> </td><td class="right">   comments on this draft.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   Eliot Lear provided many last call comments and helped work through</td><td> </td><td class="right">   Eliot Lear provided many last call comments and helped work through</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   several long standing issues with the document.</td><td> </td><td class="right">   several long standing issues with the document.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td><a name="diff0015" /></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock">   <span class="insert">Christian Vogt provided text and review comments.</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock">                                                                         </td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">8.  Security Considerations</td><td> </td><td class="right">8.  Security Considerations</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   This memo discusses the security of web authentication and how to</td><td> </td><td class="right">   This memo discusses the security of web authentication and how to</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   minimize the risk of phishing in web authentication systems.  This</td><td> </td><td class="right">   minimize the risk of phishing in web authentication systems.  This</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   section discusses the security of the overall system and discusses</td><td> </td><td class="right">   section discusses the security of the overall system and discusses</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   how components of the system that are not directly within the scope</td><td> </td><td class="right">   how components of the system that are not directly within the scope</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   of this document affect the security of web transactions.  This</td><td> </td><td class="right">   of this document affect the security of web transactions.  This</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   section also discusses residual risks that remain even when the</td><td> </td><td class="right">   section also discusses residual risks that remain even when the</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   requirements proposed here are implemented.</td><td> </td><td class="right">   requirements proposed here are implemented.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr bgcolor="gray" ><td></td><th><a name="part-l7" /><small>skipping to change at</small><em> page 21, line 7</em></th><th> </th><th><a name="part-r7" /><small>skipping to change at</small><em> page 21, line 7</em></th><td></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   community has extensive research in designing UIs to display</td><td> </td><td class="right">   community has extensive research in designing UIs to display</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   classified, compartmentalized information.  It is critical that these</td><td> </td><td class="right">   classified, compartmentalized information.  It is critical that these</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   UIs be able to label information and that these labels not be</td><td> </td><td class="right">   UIs be able to label information and that these labels not be</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   spoofable.</td><td> </td><td class="right">   spoofable.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   See Section 5 for another case where confidential information in a UI</td><td> </td><td class="right">   See Section 5 for another case where confidential information in a UI</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">   can be used to build trust.</td><td> </td><td class="right">   can be used to build trust.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">Appendix B.  Change History</td><td> </td><td class="right">Appendix B.  Change History</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td><a name="diff0016" /></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">B.1.  Changes since 02</td><td> </td><td class="rblock">B.1.  Changes since <span class="insert">05</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"></span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      Clarified introduction to distinguish what happens at the TLS</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      layer and what at the HTTP layer.  Discuss motivation of phishing</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      more.</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"></span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      In the introduction, restate claims to be more accurate.  These</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      requirements are useful if users actually use the authentication</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      mechanisms; convincing them to do so and making it obvious whether</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      they are is a significant risk.  Also, we may give them the</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      theoretical information necessary to detect fraud, but whether</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      they act on that is open.</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"></span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      Add a purpose of this memo section.  Whatever text ends up there</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      after community discussion needs to be called out in the last</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      call.</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"></span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      Add a section calling out the difference between plaintext</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      password protocols and password interface.  This needs to be</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      worked into the rest of the document.</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"></span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      Update the threat model.  Significant hopefully clarifying</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      changes.</span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"></span></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">B.2.  Changes since</span> 02</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">      Updated discussion of TLS authentication to point out that it does</td><td> </td><td class="right">      Updated discussion of TLS authentication to point out that it does</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">      meet the requirement of mutual authentication.</td><td> </td><td class="right">      meet the requirement of mutual authentication.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">      Added pointer to HTTP TLS channel bindings work</td><td> </td><td class="right">      Added pointer to HTTP TLS channel bindings work</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td><a name="diff0017" /></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="lblock">B.<span class="delete">2</span>.  Changes since 01</td><td> </td><td class="rblock">B.<span class="insert">3</span>.  Changes since 01</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">      Updated threat model to give examples of attacks that are in scope</td><td> </td><td class="right">      Updated threat model to give examples of attacks that are in scope</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">      and to more clearly discuss host security based on comments from</td><td> </td><td class="right">      and to more clearly discuss host security based on comments from</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">      Chris Drake.</td><td> </td><td class="right">      Chris Drake.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">      Clarify attacks of interest to be consistent with the</td><td> </td><td class="right">      Clarify attacks of interest to be consistent with the</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">      introduction.</td><td> </td><td class="right">      introduction.</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">      Fix ups regarding one-time passwords.  I'm not sure that OTPs can</td><td> </td><td class="right">      Fix ups regarding one-time passwords.  I'm not sure that OTPs can</td><td class="lineno" valign="top"></td></tr>
      <tr><td class="lineno" valign="top"></td><td class="left">      meet all the requirements but clean things up where they clearly</td><td> </td><td class="right">      meet all the requirements but clean things up where they clearly</td><td class="lineno" valign="top"></td></tr>

     <tr><td></td><td class="left"></td><td> </td><td class="right"></td><td></td></tr>
     <tr bgcolor="gray"><th colspan="5" align="center"><a name="end">&nbsp;End of changes.&nbsp;</a></th></tr>
     <tr><td colspan="5" align="center" class="small"><br/>This html diff was produced by rfcdiff 1.26, available from <a href="http://www.levkowetz.com/ietf/tools/rfcdiff/" >http://www.levkowetz.com/ietf/tools/rfcdiff/</a> </td></tr>
   </table>
   </body>
   </html>

--=-=-=--