Subject: [http-auth] The Mutual Auth Draft

From: Yaron Sheffer <[email-masked]>
Date: Wed, 15 Dec 2010 15:52:20 +0200

I must admit I haven't read the draft in depth yet, but I think it's 
definitely a good direction.

However I believe it is missing one crucial (and difficult) component: 
the user interface. The draft implicitly assumes the same user interface 
is HTTP Basic/Digest auth: an ugly browser-based dialog. The draft 
claims to "modernize" HTTP authentication, and this is an area in dire 
need of modernization. Many people on this list expressed the opinion 
that a branded login page is a MUST requirement for adoption. I believe 
this draft (or possibly an associated draft, so we can keep the UI even 
if we change the crypto) should address this requirement.

This can take the form of:

- Specification of a *very* minimal subset of HTML, with a URL included 
in the protocol so that the server can provide its own login page.
- Or even specification of the actual HTML, with the server allowed to 
tweak it using CSS stylesheets.

Either of these should assume that the channel is under an attacker's 
control, and it should be impossible to fool the user into posting 
credentials outside the protected channel created by the protocol. Note 
that submitting another site's credentials in NOT a problem when using 
such mutual auth schemes.

Feel free to bash me if this is too naive for real-world use.

And a nit: the draft provide examples for URLs of pages to display when 
authentication fails etc. I don't understand why these are HTTP rather 
than HTTPS.

Thanks,
Yaron

> Message: 4
> Date: Tue, 14 Dec 2010 14:52:45 -0700
> From: Peter Saint-Andre<[email-masked]>
> Subject: Re: [http-auth] HTTP authentication: the next generation
> To: Tim<[email-masked]>
> Cc: "[email-masked]"<[email-masked]>
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset="utf-8"
>
> On 12/14/10 2:48 PM, Tim wrote:
>>> What's the "draft Mutual standard"?
>> http://www.rcis.aist.go.jp/special/MutualAuth/
> Given that this is an IETF discussion list, I think the more appropriate
> link is:
>
> http://tools.ietf.org/html/draft-oiwa-http-mutualauth-08
>
> But the more general website provides some helpful background
> information, too.
>
> Peter
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Dec 2010 16:28:56 +0200

It could be in a separate draft, but there's still a lot of interaction between them.  For example, the drawing in section 2.2 might change to something like the below. Then we can have a customized login form that looks something like this:

<horrid_ascii_art>
--------------------------------------------------
|                         | Browser panel        |
|         AUTH            |  (app designers      |
|         ICON            | Userid:              |
|         GOES            |    ____________      |
|         HERE            |                      |
|                         | Password:            |
|                         |     ______________   |
|                         |                      |
|                         | Realm: a realm       |
|-------------------------+----------------------|
|                                                |
| Some buttons and links for joining and for     |
| password remediation, or "about" page.         |
|-------------------------+----------------------|
</horrid_ascii_art>

I have no idea if this will appease the web application designers.

Anyway, the new diagram might look like this.

          Client                                 Server
            |                                      |
            |  ---- (1) normal request --------->  |
        GET / HTTP/1.1                             |
            |                                      |
            |  <------------------ (2) 401-B0 ---  |
            |            401 Authentication Required
            |            WWW-Authenticate: Mutual realm="a realm"
            |                                      |
        GET /authicon_a%20realm HTTP/1.1           |
            |                                      |
            |  <---------------------- 200 ------  |
            |                                      |
        GET /auth_link_bar.html HTTP/1.1           |
            |                                      |
            |  <---------------------- 200 ------  |
            |                                      |
   [user,   |                                      |
    pass]-->|                                      |
            |  ---- (3) req-A1 ----------------->  |

        GET / HTTP/1.1                             |
        Authorization: Mutual user="john",         |--> [user DB]
                       wa="...", ...               |<-- [user info]
            |                                      |
            |  <------------------ (4) 401-B1 ---  |
            |            401 Authentication Required
            |            WWW-Authenticate: Mutual sid=..., wb="...", ...

            |                                      |
        [compute] (5) compute session secret   [compute]
            |                                      |
            |                                      |
            |  ---- (6) req-A3 ----------------->  |
        GET / HTTP/1.1                             |--> [verify (6)]
        Authorization: Mutual sid=...,             |<-- OK
                       oa="...", ...               |
            |                                      |
            |  <------------------ (7) 200-B4 ---  |
   [verify  |            200 OK                    |
     (7)]<--|            Authentication-Info: Mutual ob="..."
            |                                      |
            v                                      v

On Dec 15, 2010, at 3:52 PM, Yaron Sheffer wrote:

> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
> 
> Scanned by Check Point Total Security Gateway.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Dec 2010 15:39:52 +0100

On 15.12.2010 14:52, Yaron Sheffer wrote:
> ...
> ...

I think anything that restricts the designers will be a problem.

Why not full HTML? That shouldn't be a problem, as long as there's a 
simple way to get the required information for non-HTML clients.

Best regards, Julian

---

From: Tim <[email-masked]>
Date: Wed, 15 Dec 2010 08:38:28 -0800

> However I believe it is missing one crucial (and difficult)
> component: the user interface. 

As I mentioned in the previous thread, this problem can potentially be
addressed by the standardized XMLHttpRequest interface.  My
proof-of-concept implementation is here:
  http://vsecurity.com/download/tools/fbha-poc_0.1.zip

(I don't blame you for not reading that very long discussion =)

It is a self-contained Python web server.  I did it this way to
minimize configuration overhead in trying out the sample.  In summary,
using XMLHttpRequest, we can have a full blown HTML form which
utilizes the browser's implementation of HTTP auth.

> Either of these should assume that the channel is under an
> attacker's control, and it should be impossible to fool the user
> into posting credentials outside the protected channel created by
> the protocol. Note that submitting another site's credentials in NOT
> a problem when using such mutual auth schemes.

So this is a real problem.  Unlike just about any other authentication
mechanism out there, the Mutual auth proposal attempts to address the
very real problem of phishing.  So, in theory, even if a user doesn't
bother to look at the domain name, their credentials can be protected
when they log in to the wrong HTTPS site.

However, I think this feature disappears if HTML forms are used to
submit HTTP credentials.  Then again, if an attacker could lure a user
to the wrong site, how hard would it be for an attacker to pop up a
DIV layer which looks exactly like the browser-based login form?  Most
likely this would work great.  Preventing targeted social engineering
like this is incredibly difficult.  I think Mutual auth is a great
start, but more is needed to really address it in the general case.

tim

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Dec 2010 17:52:16 +0100

On 15.12.2010 17:27, Yaron Sheffer wrote:
> Because you don't want to allow all the extra baggage that goes with
> HTML, such as JavaScript or ActiveX.
>
> Also: I'm sure you know about it more than I do, but if the attacker
> (phisher) has complete control of the HTML form, can't they set it up so
> that the password is posted to the wrong URL?

People currently have full control over the HTML in their login pages 
(when using cookie-based logins), so I'm not sure what the problem is. 
They are not going to give this up unless you have a convincing argument 
why they need to.

I believe what's needed is a way to works well both in browsers (as in 
UAs that do HTML), and outside browsers (such as for machine-to-machine 
communication). To get there, an authentication scheme should allow 
sending whatever HTML people think is needed, but it would also need a 
way for non-HTML clients to figure out how to "fill in the form" and 
proceed.

Best regards, Julian

PS: previous work here: 
<http://tools.ietf.org/html/draft-broyer-http-cookie-auth-00>

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 15 Dec 2010 18:27:58 +0200

Thanks,
     Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 15 Dec 2010 21:05:52 +0200

See inline...

     Yaron

On 12/15/2010 06:52 PM, Julian Reschke wrote:
> They are not going to give this up unless you have a convincing 
> argument why they need to.
>
Those "people" who have full control over the HTML are the "good" Web 
site developers. But I am worried about the other people who might 
control the same content: man-in-the-middle phishers. The login page is 
displayed when the client is not yet authenticated (of course), and when 
mutual auth is used, the *server* is not yet authenticated as well. 
That's the catch. The idea I'm playing with is that with restricted 
HTML, you can present a branded login page, but still avoid phishing 
attacks in this scenario.
> UAs that do HTML), and outside browsers (such as for 
> machine-to-machine communication). To get there, an authentication 
> scheme should allow sending whatever HTML people think is needed, but 
> it would also need a way for non-HTML clients to figure out how to 
> "fill in the form" and proceed.
I fully agree.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Dec 2010 22:51:35 +0200

> utilizes the browser's implementation of HTTP auth.

OK. Installed it. I must be missing something, but what prevents a phisher from creating a website that looks exactly like that, but passes the password in the clear to his own malicious server?

---

From: Dave Raggett <[email-masked]>
Date: Wed, 15 Dec 2010 21:16:40 +0000

Another idea is for the website to display a branded page that provides
an explanation, e.g. of the need to sign in, but which doesn't include a
form (this could be enforced by the browser along with a suppression of
any web page scripts). The website also presents a machine interpretable
description that the browser interprets to provide the UI for users to
select which id they want to sign in with, see:

See http://www.mozilla.com/en-US/firefox/accountmanager/

This opens the path to users never having to create or to type per site
passwords. These are instead created by the browser according to the
interface published by the website. If this caught on we could
eventually say goodbye to memorable but weak passwords, and hello to
strong but impossible to remember secret keys. The new key could be
protected with the site's public key or simply passed via TLS.

A further possibility is to replace secret keys with anonymous
credentials and zero knowledge proofs when it is sufficient to securely
prove membership or a group and/or some other attributes. I have a demo
of this using a Firefox extension developed together with IBM Zurich and
hope to make this available within a few weeks time.

Of course there are plenty of details to be worked through, but I am
hoping there is interest in examining fresh ideas. If I am right the
Mozilla Labs work could point the way to a middle ground where websites
retain a degree of control over the signing in experience, and in
exchange get much stronger authentication and browser support for secure
privacy enhancing technologies.

-- 
 Dave Raggett <[email-masked]> http://www.w3.org/People/Raggett

---

From: Tim <[email-masked]>
Date: Wed, 15 Dec 2010 13:19:49 -0800

> OK. Installed it. I must be missing something, but what prevents a
> phisher from creating a website that looks exactly like that, but
> passes the password in the clear to his own malicious server?

Nothing.  Just like nothing prevents a phisher right now from popping
up a DIV layer which looks exactly like a browser login form. Visual
phishing tricks are alive and well[1] in many ways still, as are
certain same-origin bypasses that are arguably even worse[2].

I think something like Mutual auth would cover a few specific attack
scenarios and would allow users who care to protect themselves by:

  * logging in once and caching passwords, which could be sent
    directly via Mutual auth in future sessions

  * simply browsing to the protected site area which initiates the
    browser pop-up instead of using the HTML form

But I think in general, if users are vulnerable to SSL/TLS
man-in-the-middle attacks, they are probably susceptible no matter
what you do, given current browser implementations.

Now, stepping back, if we truly wanted to say that authentication
should not be based in HTML forms, then we need to ditch the idea
of customization completely.  This involves changing user and
developer behavior, which is hard.

Moving the login fields up next to the URL bar, as suggested by the
Mutual auth folks, might be a solid benefit to security, by mitigating
the fake popup problem I mention, but it isn't yet clear what other
tricks might be possible.  (Note that in the past, browsers have
commonly had vulnerabilities where HTML content could overlay
URL/status bars, though most of these have probably been fixed.)

Finally, note that regardless of whether or not you agree with my
approach to using XMLHttpRequest objects with HTML log in forms, the
capability *already exists* in JavaScript enabled browsers.  If web
developers could be convinced to use any HTTP authentication scheme
(which I think is a good idea), they will be tempted to use the one I
outline.

tim

1. http://en.wikipedia.org/wiki/Clickjacking

2. http://en.wikipedia.org/wiki/DNS_rebinding

---

From: Tim <[email-masked]>
Date: Wed, 15 Dec 2010 13:37:57 -0800

After sending that last email, I did a little more pondering on this.
I came up with this idea months back, and maybe it's even in my paper,
but it's been a while since I put brainpower into this.

Anyway, the proof-of-concept app I have right now just gives you a
typical 200 response code web page for the login form.  If browser
implementations were less naive with 401 codes, we could do better and
accomplish a reasonable tradeoff between user interface and phishing
prevention.

Right now, when web servers send a 401, the 401 does typically have 
some kind of page content.  However, browsers currently ignore this up
front and prompt the user with the ugly, annoying, spoofable popup
window.  If users click "cancel", they then see the content of the
401, which is usually an error message.

If instead, browsers saw the 401 and associated headers and used this
to present the login fields near the URL (as the Mutual auth folks
propose) and then also show the 401's page content, then web
developers can provide a much better experience while still
encouraging users to log in via their browser.  

For instance, if a web page read:

  Please log in to our wonderful web application using the login form in
  your browser window above.  If you are using a legacy browser, click
  *here* to log in.

If a user clicks "here", a bit of JavaScript could drop down a login
form for them to use the XMLHttpRequest trick.

tim

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Dec 2010 23:03:26 +0100

> 401, which is usually an error message.

Um, that depends on the auth scheme, I believe. If you use one the UA 
doesn't know (yet), and do not include any it does, it should display 
the page content directly.

Best regards, Julian

---

From: Tim <[email-masked]>
Date: Wed, 15 Dec 2010 14:14:10 -0800

> Um, that depends on the auth scheme, I believe. If you use one the
> UA doesn't know (yet), and do not include any it does, it should
> display the page content directly.

Well, sure, if it doesn't know the auth scheme, it will ignore it.
But if it does recognize it, it pops up a window.  Is there an auth
scheme and common user agent combination combination you know of that
doesn't do this?

It's been a while since I looked, but I believe when I did read about
401s in various RFCs, there was nothing there that would prevent the
behavior I propose (of displaying page content along with the prompt).
It's just an implementation detail... an important one for adoption.

tim

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Dec 2010 23:31:04 +0100

> It's just an implementation detail... an important one for adoption.

Yes.

I was just pointing out that a *new* scheme (such as Thomas Broyer's 
cookie scheme) could rely on the response body to be displayed.

Best regards, Julian

---

From: Tim <[email-masked]>
Date: Wed, 15 Dec 2010 14:46:48 -0800

> cookie scheme) could rely on the response body to be displayed.

Ok, I see.  I've looked at that before I have a lot of problems with
that proposal.  For one, as I've mentioned and provided links to
before, cookies are utterly broken in both the RFCs and the actual
implementations[1].  This is even outside of a security context.
Within the security context, there are a lot of problematic defaults
that I describe in my paper.

Besides my loathing for using cookies as a part of authentication,
this proposal, while just a preliminary idea, has some major issues
to overcome due to it's cross-layer interaction.  For instance, if a
UA tries to access a protected GIF image and hasn't yet authenticated
to the realm, what happens?  GIF images don't generally have HTML
forms in them.  Same goes for Flash, movies, etc.

My proposed approach to the problem relies on HTML and HTML-like
content to supply the pretty user interface in the specific (typical)
case of a login form, but still supplies all of the machinery needed
to handle authentication in the other cases (UAs that don't do
HTML/JavaScript, non-HTML content).  If browsers do continue to insist
on not displaying 401 content, then it's still possible to login with
both HTML forms and with simpler UAs, it's just not as convenient.

thanks,
tim

1. http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 15 Dec 2010 16:24:07 -0800

> attacks in this scenario.

+1

Hence my (and others) comments about outside-window support in the chrome.  I'm in favor of restricting what can be put in the login chrome sufficiently that the user is assured they know exactly what they are sending over the wire and where they are sending it to.  IMO if we settle for any lower standard then we aren't actually solving the problem.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Thomas Maslen <[email-masked]>
Date: Thu, 16 Dec 2010 00:28:25 +0000

Per Julian's following message this may be moot, but for the record:

[...]
> scheme and common user agent combination combination you know of that

"WWW-Authenticate: Negotiate" (SPNEGO using Kerberos) in at least:

    Chrome
    Firefox et al
    Internet Explorer
    Safari

When the user has Kerberos credentials, and the browser has been configured
to allow SSO to the relevant HTTP server, this gives transparent SSO (look Ma,
no popups).

Also "WWW-Authenticate: NTLM) in at least:

    Firefox et al
    Internet Explorer
    (probably others too, I haven't checked)

With these auth schemes, if you do see an authentication popup it often means
that something went wrong, e.g. the client browser / OS wasn't configured as
expected.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 15 Dec 2010 16:41:58 -0800

> what you do, given current browser implementations.

Not if the http-auth is bonded to the TLS channel.  Then the http-auch could detect the MITM and fail.  The new, incompatible Microsoft extensions to Negotiate do this.  

With channel bonding, you *could* base your trust of the TLS channel entirely on a properly-implemented mutual auth at the http layer and solve all the problems with the 100+ pre-trusted CAs.  I know one Microsoft developer who is considering if the CA warnings from the TLS negotiation in IE can be postponed until after the HTTP-Negotiate handshake is complete so they can be suppressed if they aren't relevant.

This is what I mean when I say that channel bonding is necessary for anything we do at the HTTP layer to be a significant improvement over the status quo.  

The only alternative would be some kind of security layer in http (which would make TLS unnecessary).

> developer behavior, which is hard.

+1, but I think it's necessary.  See other email.

Fallback to a current style login form is clearly unavoidable for now.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 15 Dec 2010 17:04:40 -0800

> to allow SSO to the relevant HTTP server, this gives transparent SSO (look Ma,

It's somewhat version and configuration dependent, but sometimes you will get a popup to acquire Kerberos credentials instead of a basic-auth prompt.  It doesn't look as different as I'd like but it is different.

Firefox 3.6.10 on MacOS 10.6.4 does this if you have not tickets for a specific example.

> that something went wrong, e.g. the client browser / OS wasn't configured as

As someone noted, we won't ever get a single root Kerberos realm for the same reasons we won't ever have a single root X.509 CA.  It works reasonably well within an enterprise, modulo the channel bonding issues in my other email.

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 16 Dec 2010 10:37:01 +0900

Dear Yaron,

> However I believe it is missing one crucial (and difficult) component: the user
> interface. The draft implicitly assumes the same user interface is HTTP
> Basic/Digest auth: an ugly browser-based dialog. The draft claims to "modernize"
> HTTP authentication, and this is an area in dire need of modernization. Many
> people on this list expressed the opinion that a branded login page is a MUST
> requirement for adoption. I believe this draft (or possibly an associated draft,
> so we can keep the UI even if we change the crypto) should address this
> requirement.

Actually, I intend that the GUI browser interfaces will be changed.
Optional-WWW-Authenticate and Authentication-Control headers will
be better implemented over some kind of non-modal (non dialog) UI interface.
To protect passwords from eavesdropping and phishing, UIs for different schemes
(at least for schemes with considerably different security strength) should be
distinguishable, and it should be protected from HTML-level UI forging.

Could you see "Slide 7" of my presentation in last Maastricht appsopen?
  https://staff.aist.go.jp/y.oiwa/publications/MutualAuth-IETF78-AppsOpen.pdf
We have implemented this new UI in our Firefox-based test browser.
  https://www.rcis.aist.go.jp/special/MutualAuth/trial-en.html
We also have one picture of our UI proposal in the page above.
# I've prepared new 3.6-based implementations several times, but at every bad
# timing Mozilla guys release a new revision...

However, I also agree that we should not enforce almost any restriction for
browser designers about their UI choices.  And, at the same time, UI is very
important for security protocols.  In my draft I've very carefully written
minimum UI requirements as a part of security requirements.  How do you think we
the IETF guys and IETF RFCs/drafts should work on UI issues?  I also have one
unpublished draft in preparation for UI requirements of our draft (which is
informally referred to by the submitted draft).

-- 
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[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Tim <[email-masked]>
Date: Wed, 15 Dec 2010 17:46:42 -0800

Hi Henry,

> Not if the http-auth is bonded to the TLS channel.  Then the http-auch could detect the MITM and fail.  The new, incompatible Microsoft extensions to Negotiate do this.  

The problem is, given the current poor state of browser UIs, a
downgrade attack is unavoidable.  Sure, binding HTTP auth to TLS in
some way as you describe in Negotiate (or with Mutual) prevents
phishing, but only if it is used.  Users have no choice in the matter,
nor are they even told what form of auth is being used.  My paper
highlights this point in one of the sections.

Users are currently trained to use systems which are very spoofable.
Before *any* benefits against phishing can be realized, users have to
get used to not using bad interfaces.  New, hard-to-spoof interfaces
need to be available for a long time before the populace will forget
that the old interfaces even existed.

> Fallback to a current style login form is clearly unavoidable for now.

Yeah, I think you are right on both points.  As my follow up email
indicated, I revisited this and proposed a transition plan.  Perhaps
more coherently:

Step 1
======
Ask major browser vendors *really nicely* to change their UIs to move
the popup to a location that is unmistakably part of the browser.  The
UI should give users enough information about the authentication
mechanism (basic vs digest vs mutual vs negotiate vs ...) and ideally,
cache information about what authentication schemes have been used in
the past, warning about insecure ones.  (This is also mentioned
briefly in my paper.  It is along the lines of the SSL/TLS downgrade
attacks which preciptated [1].)

Initially, browser page bodies may need to display a generic but
helpful message indicating that users can log in with the new UI
widget above, etc.  Note that this change brings about security
benefits to HTTP authentication right now even if nothing else is
done.  This doesn't require any changes to standards, AFAIK, though
some kind of official recommendations may help effect change.

Step 2
======
Next, once users are used to doing HTTP authentication in the safe UI,
browsers should also begin to display the 401 page's content during
this prompt.  This allows for backward compatible user interfaces right
now, while still allowing browser password managers to immediately
take over the login process.  These UI change doesn't require any
change in standards, either.

Step 3
======
Web developers who are already using HTTP authentication could opt to
start putting XMLHttpRequest login forms into their 401 pages.  Most
probably won't, because they won't know about this capability.  Others
who are extra concerned about security won't bother either, since this
makes phishing against users easier.  

Step 4
======
Web development frameworks can incorporate HTTP authentication into
traditional session management while still allowing for HTML login
forms, if developers want to turn them on.  For most developers, such
a switch over could be made as easy as a server configuration change
and perhaps a blob of canned JavaScript.

...

Now, this is great and all, but no developers are actually going to
switch to these better interfaces and protocols until HTTP
authentication is as easy to implement as form+cookie auth.  Web
development frameworks won't bother to make it easy for them to use
HTTP authentication until all of the necessary pieces are in place.

The biggest standards piece that is missing here is a server-initiated
session termination.  A log out button can easily be added to 
browser UIs, but right now people are not used to logging out in the
browser.  They are used to clicking a Logout link in the page.  I
don't see any reason why HTTP basic, digest and any other HTTP
authentication mechanism should not have a way for a server to ask a
client to forget credentials.  This really is a major sticking point
for developers, and one of the big reasons HTTP auth was abandoned
years ago.

This feature could be added only to a newer, more secure HTTP
authentication protocol, or we could retrofit Basic and Digest.  I
would prefer to retrofit, since Basic and Digest are already out there
and it may make transitioning to better authentication easier for
developers.  Then again, maybe it will be hard to convince browser
vendors to fix up their Basic and Digest implementations.

Feedback welcome,
tim

PS- sorry for the huge email.

1. http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-hodges-strict-transport-sec

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 15 Dec 2010 18:39:56 -0800

OK, I *think* you and I are mostly on the same page.  (Nits in-line below.)

Anyone else want to comment, or is this a starting point for getting more concrete?

On Dec 15, 2010, at 5:46 PM, Tim wrote:

> phishing, but only if it is used.  

I'm assuming the scope of this group's charter is primarily a new authentication method to be use in the existing http authenticate headers.  I don't personally care (ATM) if it's a new one, or a new sub-option of Negotiate.

I think whatever http-auth we propose should fail if channel binding fails.  Period.  That's only spoof-able if you also support legacy/fallback methods which are spoof-able.  I assume that's what you were getting at.

> Users have no choice in the matter,
> nor are they even told what form of auth is being used.  

The situation isn't that simple.  If X.509 client certs are required the users get a fairly distinctive query, but the interface is ugly and doesn't necessarily tell the user what they need to know.  Most browsers can handle fallback to basic auth (or a login page) if the user doesn't have the right credentials to support Negotiate, but the user doesn't know the fallback options exist until they have refused to provide a Kerberos username/password.

The situation is really confusing and incoherent.

> My paper

Agreed, but I'd like to see some consensus on the kind and level of information that should be shown first.  

While basic/digest/negotiate/X.509/... is part of what it should translate into, I think what a user should care about is what kind of information/credential is being sent, and how reusable/forwardable it is.  

*I* may not care if a web site gets an X.509 client cert that unambiguously identifies me in the real world, but someone else may only be willing to provide a zero-knowledge proof that they are authorized.  Someone else may have a username/password they are willing to send over because they plan to change it in 5 minutes and it doesn't work with anything else important.

> and perhaps a blob of canned JavaScript.

It's actually way easier to develop against the built-in authentication methods (Basic/Digest/Negotiate) since there is no UI to develop.  You just have to pick up the authenticated identity afterward.  Given reasonable alternatives, I think this may be easy.

> vendors to fix up their Basic and Digest implementations.

I like the work you've done.  I think it makes sense to ask browser vendors to retrofit our proposed UI improvements.  

I also think we need to focus on specifying, functionally, what an authentication UI must expose, what it must make available, and how recognizably distinct from any web page it must be.

> PS- sorry for the huge email.

Is it any worse than mine?

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 16 Dec 2010 08:09:52 +0200

Hi Dave,

with many people using more than one device, the use of "long" 
credentials requires a standard way of synchronizing such credentials 
across disparate browsers (and non-browsers?) from different vendors. In 
this respect it is no different from client certificates. Does such a 
synchronization standard exist?

OTOH, using short memorable passwords with SRP/EKE or the AIST crypto 
algorithm does not have this limitation. It does have other issues of 
course.

Thanks,
     Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 16 Dec 2010 08:31:21 +0200

Hi Yukata,

starting from your last point, I would expect W3C to have more UI 
expertise than we at the IETF have. Luckily some of them are on this 
list, so we can have a joint discussion.

Regarding your specific proposal. From slide 7, I gather that you want 
BOTH the username/password entry and the login indication to be from 
dedicated areas in the browser.

I agree that the login indication (and logout button) should be from the 
"browser chrome", as it has been called on this list. But I think the 
actual username/password entry cannot be from the chrome, because it is 
not at the center of the user's attention. In other words, if the main 
window says "Today, due to technical problems, we are using a different 
server to validate your identity. Please enter your password here: 
_______", the user will just go ahead an do it. So unless we have 
educated the user really well (of which I am skeptical), MITM phishing 
is still easy.

The alternative I am looking for will allow the site to embed the 
username/password entry fields within the actual HTML, while preventing 
the site from adding additional fields, having images overlap the 
fields, reducing the field sizes beyond a certain minimum etc.

Thanks,
     Yaron

---

From: Dave Raggett <[email-masked]>
Date: Thu, 16 Dec 2010 07:11:21 +0000

> synchronization standard exist?

I agree that this is needed and am not personally aware of an
appropriate standard. Mozilla Labs has its solution of course, and this
could form a starting point for discussions, and judging from their
precedent is likely to cover more than just synchronising credentials,
see the Mozilla Weave Sync effort:

  https://mozillalabs.com/sync/

I would like to see the user's data held in an encrypted form with only
the user holding the key, i.e. the data never leaves the browser in an
unencrypted form and the synchronization server is unable to decrypt it.
This is practical if the user is required to enter a pass phrase to
unlock his or her credentials at the beginning of each browser session
(along with a means to log off explicitly or after a period of user
inactivity).

p.s. this approach is also being looked into for distributed social
networking where the data is held by users on their own devices and the
network used only for presence and transfer of encrypted content.

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 16 Dec 2010 16:45:27 +0900

Hi Yaron,

Thank you for the comments.

On 2010/12/16 15:31, Yaron Sheffer wrote:

> starting from your last point, I would expect W3C to have more UI expertise than
> we at the IETF have. Luckily some of them are on this list, so we can have a
> joint discussion.

Hmm, that makes sense.  I'd really like to have a way to discuss security/UI
relation issues under a quite good coordination and cooperation.

(quotations order below has been swapped)

> username/password entry fields within the actual HTML, while preventing the site
> from adding additional fields, having images overlap the fields, reducing the
> field sizes beyond a certain minimum etc.

This form of authentication is very easily forged, unfortunately.
We can make imitated simple password field by plain HTMLs.
The users must be able to find out which field is secure from the UI design alone.

# If it were opposite (i.e. plain password entry form cannot be rich enough to
imitate the secure mutual auth form), it would make security sense... but it
would be non-sense in usability.

And this will also not solve the problem which you've shown below.

> Regarding your specific proposal. From slide 7, I gather that you want BOTH the
> username/password entry and the login indication to be from dedicated areas in
> the browser.
> 
> "browser chrome", as it has been called on this list. But I think the actual
> username/password entry cannot be from the chrome, because it is not at the
> center of the user's attention. In other words, if the main window says "Today,
> due to technical problems, we are using a different server to validate your
> identity. Please enter your password here: _______", the user will just go ahead
> an do it. So unless we have educated the user really well (of which I am
> skeptical), MITM phishing is still easy.

It is true, but this kind of phishing is not able to be solved in any
password-based authentications, as long as some way for plain-text password
entry is allowed in somewhere.
# In other words, we can not prevent any kind of phishing in the way saying
# "Yes, we are partner of WhatEver Inc., believe us, so please enter
#  WhatEver Inc.'s password here!" by technology alone.
The same will hold for any password-based authentication, e.g. for TLS-SRP.

However, at least in our way, we can prevent any phishing with the same UI
experience as the original one.  Users can aware that there is something
unexpected happening, which is very important for preventing casual loss of
passwords.  Also, we've reduced the required user education as low as possible,
as "this input field is secure, others may not so and be careful".

Of course, our example UI is not ideal for user experiences, but we're at least
demonstrating what we should be done in the UI (or W3C, or browser vendors)
side, as a requirements from the protocol (or IETF) side.  Any better UI
proposal is welcome for us.  As far as the security requirements are met, we are
not strongly one-ideaed on the current UI.  And also I'd like to leave
browser vendors a space for introducing their own cute UI, e.g. integration with
Mozilla's Identity Managers :-)

One possibility might be:
  the buttons to be three-stated, no login, login-requested, and logged-in.
  When the button is pressed in login-requested state, the browser will
  enable SOME KIND OF secure user interface for asking username and password,
  in the way it will interact the user's attention.
  The current pop-up is no-good, because it can be imitated by either
  Basic auth or Form/CSS/Javascript combination.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 16 Dec 2010 10:40:03 +0200

> and perhaps a blob of canned JavaScript.

Step 10
=======
(after the new UI has become somewhat ubiquitous)
Browser vendors make the browsers show a warning screen whenever there's a password field in the form. This will force web application developers to:
 (a) Switch to the new UI (good!), or
 (b) Live with the warning screen (users won't like that), or
 (c) Change to passwords in the clear (bad - that's the one security signal that users actually look for), or
 (d) Use some fancy javascript to make a text field that looks like a password field (with dots) but the browser doesn't recognize it as such.

Hopefully, the effort for (a) will be lower than for (d).
This is not just "let's force the designers to do the right thing". By then it should be considered bad and even suspicious to have a password field in the web page.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 16 Dec 2010 11:36:25 +0200

Now I've read the draft, and I have a comment.

There is no justification given for why we do or do not .need the pwd-hash field, that has a default and recommended value of "none". This is kind of scary, because it looks like security that is off by default.

I assume that this is done to facilitate support for passwords that are stored as hashes, so that the server doesn't even have access to the real password.

However, most password storage systems follow the UNIX model, and store salted hashes of passwords (i.e. 0x9e7a342b+MD5(0x9e7a342b|password) is stored).

To work with this, I suggest the following:
- add to the pwd-hash description in section 4.1 a new value "salted-md5" (is "salted-sha1" and/or "salted-sha256" also needed?)
- add to message 401-B1 in section 4.4 a new field "salt", which is a hex-fixed-number

I think this would make this integrate better with existing systems.

Yoav

---

From: Marsh Ray <[email-masked]>
Date: Thu, 16 Dec 2010 16:01:17 -0600

> be better implemented over some kind of non-modal (non dialog) UI interface.

I think it's a great design.

> distinguishable, and it should be protected from HTML-level UI forging.

How about having just one mode? "The secure one."

"Degrees of insecurity" are very difficult concepts to communicate, even 
between experts. I think they're impossible to describe to users.

> browser designers about their UI choices.

They won't listen anyway. :-)

> And, at the same time, UI is very
> important for security protocols.

Yes, to the extent that security involves a user.

It's a little UI control with big consequences.

- Marsh

---

From: Yutaka OIWA <[email-masked]>
Date: Mon, 20 Dec 2010 23:32:30 +0900

Dear Yoav,

First of all, thank you very much for your comment.

> I assume that this is done to facilitate support for passwords that are stored as hashes, so that the server doesn't even have access to the real password.

Yes to your assumption, and in fact "none" is the security-wise, RECOMMENDED
value (Sec 14.4 of our draft) except for backward compatibility requirements.
Among other values, Digest-MD5 was trivial to add as it was included in RFC
2617, and we found some library instances (e.g. PEAR for PHP) which use
plain-hashed passwords in the user DB.  It was also simple and clear enough to
add it.

> I think this would make this integrate better with existing systems.

We also thought about that once in the past, and my past decision at that time
was not to include it for a security reason.  However, I have no strong
insistence on this choice, and as far as the whole system security (please see
the long description below) and the usability get together, I would accept the
people's final decision.

There are several issues about this, among which one is very critical.
To securely use this pwd-hash facility, the hashed password MUST NOT be known to
any people other than the user and the server administrator (see the third
sentence, clause 2, Sec. 14.4 of my draft).  If it is known by a rogue person,
he can use that hash to authenticate himself as a victim user, without knowing
the real plaintext password.  However, for a long time, both /etc/passwd and
.htpasswd were stored with a world-readable (0644) permission, and many systems
required (or still require) that setting.  This contradicts with the security
requirement.  I felt that the security consideration section will become too
confused and obfuscated if this facility is added.

# For example, many Unix Web servers read .htpasswd file with either www-data or
nobody user privilege, which requires the file to be world-readable when it is
owned by normal users (or root).

Digest-MD5 password hashes are directly useful for authentication in the very
similar way, and thus those *must have been* stored in a secure way.
Non-salted hashes are usually considered by people not secure enough to make it
public, and I see this in the real world (at least it seems not be used in a
place where the hash will be explicitly made public), but people may doubt about
this observation.

# I personally afraid that some Digest-MD5 hashes, if there are any, are stored
world-readable in the real world...

Other less-critical issues are:
  * It may reveal the non-existence of user IDs to attackers
    unless really carefully implemented and deployed,
    which usually seems impossible.
  * It depends on some de-facto-standard technologies
    which are not standardized and have many minor variants.
    There are too many ways for hashing passwords with salts.
  * The most simple design (adding a salt to 401-B1) only works with algorithms
    in which the req-A1 message does not depend on the password.
    This may limit the future extension of the protocol.

If people want, I will publish my unfinished draft about this salted-hash
facility, just for a reference.  It also has a support for future algorithms
that have req-A1 messages depending on user passwords.