Subject: [http-auth] BoF goals

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 08 Jul 2011 09:51:45 -0600

And now a word from your sponsor... :)

I think it would be productive to chat about the goals of this BoF.

As I see it, the primary and perhaps only goal is to come to a common
understanding of the problem space so we can figure out if we might be
able to scope important and realistic work in the future. The goal is
not to discuss the technical details of Technology X or the relative
merits of Technology X and Technology Y. It makes little sense to have
presentations along the lines of "I can fix this with Technology Z" if
we don't yet know what "this" is.

Therefore, I'd like to see discussion about topics like these:

- real-world problems with existing HTTP authentication methods,
important features that such methods don't provide, etc.

- lessons learned from non-HTTP authentication mechanisms (e.g., SASL)
and how they might apply to the web

- pain points currently being experienced those who use and deploy
different kinds of web-based applications (as Jeff Hodges points out,
"the web" consists of many different kinds of applications)

- challenges to adoption of whatever new HTTP authentication method we
might develop (e.g., mobile devices), types of web applications that
might become early adopters (e.g., online payment systems), etc.

- what's the killer app for improved HTTP authentication methods?

Feel free to add to the foregoing list so we make sure that we're asking
the right questions.

And if you are able to make a presentation that will help us all clarify
the problem, then by all means please contact the chairs.

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 08 Jul 2011 18:09:02 +0200

> important features that such methods don't provide, etc.

Web sites want to style the password entry screen.

Web sites want to provide a "logout" button.

> might become early adopters (e.g., online payment systems), etc.

Broken UA behavior when they get challenges for both new and old 
authentication schemes.

> - what's the killer app for improved HTTP authentication methods?

For me: integrate what web sites do today, thus form-based 
authentication with cookies, so that sites can use the same 
authentication for browsers and programmatic clients. (-> 
<http://tools.ietf.org/html/draft-broyer-http-cookie-auth-00>)

> ...

Best regards, Julian

---

From: Tim <[email-masked]>
Date: Sun, 10 Jul 2011 16:36:18 -0700

> Web sites want to style the password entry screen.

Yes, with the caveat that: by providing a customizable login screen,
you almost certainly leave your users open to phishing.  

Ideally, a new protocol should allow for both customizable login
screens for sites that don't care about phishing, and "chrome"-based
ones that behave somewhat like current HTTP auth ones do.  The
techniques I've described in the past allow for this.

> Web sites want to provide a "logout" button.

Yes, definitely.

> Broken UA behavior when they get challenges for both new and old

Yes!  Downgrade attacks seem to be possible on nearly every
TLS-related standard that comes out (STARTTLS, HTTP/HTTPS sslstrip
attacks, etc).  I'm not sure why so many standards efforts haven't
bothered to address this most important security aspect of backward
compatibility.

> <http://tools.ietf.org/html/draft-broyer-http-cookie-auth-00>)

Instead of trying to throw good time and money after bad, I'd
personnally prefer us:

- Provide guidance for popular web frameworks how to track user
  sessions just like they are tracked today within their APIs.  That
  is, make it easy for J2EE, .NET, PHP, etc, frameworks to provide
  better authentication "under the hood" without changing anything on
  web developers and users.

- Work with browser vendors to get the new protocol implemented
  correctly with full features in all of them.  Provide testing tools
  and other ways to minimize the implementation effort.  

Too many good standards don't get adopted, and I think it is in large
part to a lack of follow-through in these areas.

tim

---

From: Yoav Nir <[email-masked]>
Date: Mon, 11 Jul 2011 07:10:30 +0300

> techniques I've described in the past allow for this.

I don't agree that you can't have both. Today, if I explicitly enter the URL for a site with Basic Auth, I still see the previous site or a blank screen behind a dialog box that says "To view this page, you must log in to area "www.example.com" on www.example.com:80 and asks for my name and password.

It may be enough that the username and password fields are in a special place that's not accessible to the web designer, as long as the web designer can do whatever HTML will allow on the canvas. I don't believe that Google have to have the gmail login on the right side of the canvas. As long as they can make a "corporate" page, it's OK if the text fields are somewhere else. Something like the MutualAuth demo on Firefox could work for getting both customizability and security.

These are, of course, only my guesses. I wish we could hear from web designers whether this would be acceptable.

---

From: Yutaka OIWA <[email-masked]>
Date: Mon, 11 Jul 2011 19:00:58 +0900

> It may be enough that the username and password fields are in a special place that's not accessible to the web designer, as long as the web designer can do whatever HTML will allow on the canvas. I…

+1

I think there are actually two aspects of needs for UI customizability
in log-on screen: visual design and functionality.

For visual design, I believe that Web designers can (or, will have to)
give up the "current" design for future, if we have either a good
reason or a better alternative; the latter will be a win-win solution
if possible. The set of our MutualAuth UI proposal and demo is one of
(visually-ugly, quickly-made) proposals for possible future (*0),
leaving Web designers to customize whatever in canvas.
Another support for this direction is that browser vendors are
currently trying to take ID management in their hands, using
password/ID managers and browser-frame automatic handling; that will
anyway take away from Web designers their control of visual designs.
If they find some point of compromise, it can be applied to future
HTTP-based secure authentications, too.

On the other hand, I think that functionalities are unforgivable
requirements for the Web system designers.  They can't cope with
current modal (locking) design of authentication behavior (*1), they
really require log-out and timeout for visitors' security, they may
need centralized log-in/log-out page for user accounting, and most of
them need guest user support, etc. etc.  I want and am going to
investigate the precise set of such requirements, hopefully with all
of IETF protocol designers, browser designers and Web designers.  A
partial answer of mine is included in our draft as an "HTTP auth
control header", and I really appreciate to have feedbacks on that
section of the draft (*2).

*0: We hope browser designers in future for inventing more beautiful
visual design in their products :-)
*1: HTTP spec does not strictly require such semantics, though.
*2: No cryptographic knowledge is required to read that section! :-) :-)

Yutaka

---

From: Dave Raggett <[email-masked]>
Date: Mon, 11 Jul 2011 14:10:58 +0100

We should aim to remove the need for users to type their user name and 
password into web page forms altogether. At the same time we should 
include anti-phishing measures such as mutual authentication, and 
privacy friendly authentication based upon zero knowledge proofs. It is 
unclear that this needs to be integrated as part of HTTP or layered 
above.  I am involved in work on experimenting with these ideas as part 
of the Eurpean "webinos" project, see http://webinos.org

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

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Jul 2011 11:44:19 -0500

>> you almost certainly leave your users open to phishing.

I believe it should be possible to provide some customization, but the
key is to make sure that users do NOT type passwords into a field that
is available to an untrusted element (downloaded script, script
embedded in the HTML, or a remote service).  This kinda means that any
would-be echo-off text input fields (or even echo-on password fields)
need to be in the browser chrome, and that we need to educate users to
not enter any text into non-chrome echo-off fields (we can ban such
fields, but scripts could still emulate them).

My proposal[0] is for a DOM "login" button.  Sites could be allowed to
prompt for a username, though this has unpalatable (to me) privacy
implications that I could live with if it were the price of having
decent web authentication.

[0] http://www.w3.org/2011/identity-ws/slides/Williams.pdf

Nico
--

---

From: Tim <[email-masked]>
Date: Wed, 13 Jul 2011 08:22:01 -0700

> fields, but scripts could still emulate them).

Yeah, whatever it is, it needs to be visually very distinguishable
from anything one can generate in HTML.  It also needs to make the
origin you are authenticating to very prominent.

> decent web authentication.

HTTP authentication + XmlHttpRequest already allows for fully
customizable login pages[1] (assuming a standards-compliant browser) and
of course safer authentication via the browser chrome.  (Assuming we
can convince browser developers to improve the UI elements.)  I don't
*like* fully customizable login pages, but many businesses will simply
require them for some time, until security people convince them to
switch to something safe.  To be realistic, there are many sites that
accept passwords and simply don't need to worry about phishing.

In any case, all of the flexibility we could want is already available
through the standards-based techniques I've described in the past.
This approach is fully compatible with both complex UAs (browsers) and
simple UAs (web crawlers, scripts, etc).  All that is left on the
standards side is to use an HTTP authentication mechanism that
provides good mutual authentication and a standard way for
server-initiated logout.

tim

1. http://vsecurity.com/download/tools/fbha-poc_0.1.zip

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 Jul 2011 15:49:42 +0100

AD hat off:

The main problem I see with which we might try to help
is the need for servers to store databases of passwords
that inevitably leak out sometimes.

So I'd like to see us develop something that gets rid of
passwords entirely if possible.

I also think its pointless to develop something that
won't really be deployed and used.

A similar, but not identical, goal might be to reduce the
overall number of passwords, but I'd be fairly skeptical
of SSO approaches with a password for the initial auth.

S.

---

From: Nico Williams <[email-masked]>
Date: Fri, 15 Jul 2011 21:18:13 -0500

> that inevitably leak out sometimes.

And credit card numbers.  And all sorts of personal information...

I don't think this is a fully solvable problem.  Using memory-hard
PBKDFs (e.g., scrypt) and augmented ZKPPs would mean that only
password verifiers could leak, and those would be relatively hard to
attack, and leakage relatively easy to mitigate.

For things like credit personal information that's not needed when the
user is not logged in one option is to store it encrypted in a
user-agent-side key that the site doesn't know and let the user-agent
decrypt and send the plaintext to the service as necessary.  (This is
an interesting use for JS crypto APIs in the browser.)

> passwords entirely if possible.

Agreed.  I don't think we're going to get there in one day.  Augmented
ZKPPs are very tempting, even if that means that password verifiers
can get stolen (see comments above).  Federated authentication methods
where *initial* authentication (i.e., at the IdP) uses augmented ZKPPs
would be even better.  User certs present cert/device management
headaches, but if we can address them then user certs would work too
(I'm afraid that the use of online CAs or SACRED-type protocols will
be part of the end-result user cert mgmt solution).

> won't really be deployed and used.

For some proposals we can tell if that's likely.  For others it will
be harder to tell.  Also, something that can work on the Internet and
the enterprise would have a higher probability of success.  (This is
why I'm proposing a pluggable solution, because I don't think we can
produce one authentication solution that will have a high likelihood
of wide adoption in all these case.)

> of SSO approaches with a password for the initial auth.

See comments above and below about user certs.

Anyone proposing the use of user certs needs to make some convincing
arguments about why user certs will not devolve into an SSO approach
"with a password for the initial auth"  :)

It helps to think of PKIX w/ OCSP (or online CAs issuing short-lived
certs) as a PK-based ticketing system, not unlike a PK-version of
Kerberos.  It is possible to bridge multiple authentication mechanisms
by looking at them this way.  In fact, there's two or three kerberized
online CA solutions available, (kca, kx509, and Heimdal's version of
kx509).  And Kerberos can use PKIX for initial auth, via PKINIT.

Another way to phrase the question: will browsers or the platforms
they integrate well with, resort to these bridging solutions?  If so,
then what's the advantage of locking us into a PKIX (but not-PKI)
solution?  Yes, the fact that bridging authentication methods is
possible means that the choice of one method doesn't preclude use of
any others, but forcing people who have one infrastructure deployed to
deploy another is going to have significant costs (this has been one
the main arguments for pluggable authentication).

Nico
--