Subject: [http-auth] re-call for IETF http-auth BoF

From: Yutaka OIWA <[email-masked]>
Date: Mon, 06 Jun 2011 02:06:38 +0900

Dear all at http-auth mailing list,
(Cc: Peter, Sean, Harry, and related mailing lists subscribers)

following the discussions in the Prague http-auth Bar-BoF in March,
and the W3C Identity in Browser workshop in the last month, now I
would like to re-call the formation of BoF for http-auth in IETF.  The
workshop was really hot and enjoying, and there were so many useful
inputs to both Web community and IETF, I believe.  Some materials
presented and discussed there are available at
<http://www.w3.org/2011/identity-ws/>.

# Harry, are the *output* materials of the workshop already available to public?

Currently I'm preparing a start-up version of problem statement document and
proposed BoF agenda.  However, very unfortunately, the last week I had a
severe fever heat and could not work well (I'm really sorry about that).
I'm going to submit them to the list within two days, and if possible
comments to the last version of the agenda proposal, available at
<http://www.ietf.org/mail-archive/web/http-auth/current/msg00770.html>,
are welcome.  I'm currently working based on that.

Thanks,

Yutaka

-- 
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: "Harry Halpin" <[email-masked]>
Date: Sun, 5 Jun 2011 22:32:44 +0100 (BST)

> # Harry, are the *output* materials ofn the workshop already available to
> public?
>

The workshop already links to all papers and slides on the website. There
will be a final report released in about 2 weeks. The
[email-masked] will be list I use to get input to the draft final
report, to join email "subscribe" in subject line to
[email-masked]. From my memory there was interest in
MutualAuth, primarily from the financial industry and banks, who really
did seem to want it. The browser vendors were of course skeptical of
anything in chrome, but other discussions such as Dirk Balfanz's do to
auth in the OS layer could provide an alternative.

[1] http://www.w3.org/2011/identity-ws/

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 6 Jun 2011 11:30:48 +0300

Hi Yutaka, 

it is definitely a good idea to get ourselves organized to continue our work in securing the Web. 

For me, the main questions are: 

 * What is the biggest problem? 
    You, for example, point to the usage of forms for user authentication in Web pages in the agenda proposal.
    The NSTIC fans seem to believe that passwords are the problem to begin with.  

 * What solution approach is most promising? (or multiple approaches)
     You seem to suggest to standardize a strong-password based authentication mechanism in http://tools.ietf.org/html/draft-oiwa-http-mutualauth-05
     NSTIC fans seem to believe that the approach is towards stronger credentials (non-password-based) and the usage of federated log-ins. 
     Again others believe that we will never agree on a single authentication protocol and hence we need a framework that allows passwords to be plugged in dynamically.
     Browser vendors are interested, as you may recall from the Identity in the Browser discussion, in standardizing username/password form indications  so that the user does not need to type their username & password too often into forms - but the browser does it instead. 

 * How do we motivate the different stakeholders to implement and deploy our favorite solutions? (There is also the usability issue for the user.)
    Whatever you come up with changes are needed on the client, and on the server side. That requires a lot of cooperation.

Ciao
Hannes

On Jun 5, 2011, at 8:06 PM, Yutaka OIWA wrote:

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Yutaka OIWA <[email-masked]>
Date: Tue, 07 Jun 2011 00:32:44 +0900

Dear Hannes,

thank you for good questions.

Hannes Tschofenig <[email-masked]> writes:

>     You, for example, point to the usage of forms for user
>     authentication in Web pages in the agenda proposal.  The NSTIC
>     fans seem to believe that passwords are the problem to begin
>     with.

IMO, the main point is the lack of the protection for the
authentication credentials, and the lack of the mutual agreement and
assurance about authentication results.

For the first point, in current technology, the passwords are almost
used as a naked token (including the Digest authentication), which is
too weak in current computation environment; there are no protection
against steal by the communicated peer, no protection against
forwarding, etc. I understand that there will be no single solution to
solve the all problem, for example some high-secure applications such
as NSTIC or corporate-value banking needs cryptographic strong
credentials.  But, at the same time, passwords are the only tokens
which can be easily portable by human without help of mechanical
storages.  Both current federated ID management and cloud-based
password management, or even issuing/managing client certificates
online are relying on the password authentication in some form as a
starting point.  It is still worth to improve security of initial
password authentication with those stories.

For the second point, in many high-value applications the security
(privacy) of the user-submitted data is equally or even more important
as/than the integrity of client authorization (I do NOT mean that the
latter is unimportant :-).  Strong mutual authentication is a
important key for this.  Virtually all authentication technologies
which are currently available to Web are weak in this aspect,
including TLS client certificate authentication.  I believe that even
for non-password-based authentication this is important to be fixed.
I currently do not have a proposal for those non-password stories, but
we should really work on this, I believe.

As I mentioned and promised in the previous Bar-BoF, my proposal can
(and will) be separated to a core mutual authentication framework and
a specific algorithm for password-based authentication.  I welcome to
use the framework part for mutually securing other types of
authentications (if algorithmically applicable) as well as password
authentications.  It can also potentially provide shared keys for
channel-binding for higher-layer applications.

The third point, not mentioned earlier, is that all kinds of current
authentication methods, both password- and non-password-based, are 
just hard to use compared to Form-based authentication.
I'm also working on this "applicability" problem and proposing a solution.

>      You seem to suggest to standardize a strong-password based
>      authentication mechanism in
>      http://tools.ietf.org/html/draft-oiwa-http-mutualauth-05 NSTIC
>      fans seem to believe that the approach is towards stronger
>      credentials (non-password-based) and the usage of federated
>      log-ins.  Again others believe that we will never agree on a
>      single authentication protocol and hence we need a framework
>      that allows passwords to be plugged in dynamically.  Browser
>      vendors are interested, as you may recall from the Identity in
>      the Browser discussion, in standardizing username/password form
>      indications so that the user does not need to type their
>      username & password too often into forms - but the browser does
>      it instead.

I believe we need multiple approaches, depending on the nature of each
specific application.  In my opinion, password authentication and
(better) certificate/private-key authentication are needed as starting
points.  I don't believe that current TLS client cert auth is the
perfect solution for the latter, however.  I also would like to see
how they can be integrated with federated authentication mechanisms.
Pluggable approaches need a little-bit careful consideration about the
mutual influences of plug-ins against total security, but my proposal
is actually going in that way in some aspects, as mentioned above.

# I really want to see someone proposing a draft fixing the
# certificate-based authentication to be more secure and useful :-)

In my personal opinion, browser-assisted fill-ins are in a different
layer, which means that we like to have both at the same time in the
future.  To easily use my proposed technology we need a good password
managers, and to make the browser-stored password secure in all time,
(I believe) we need a good underlying protocol e.g. for mutual
assurance and portability.

My personal intention to proposing BoF and a working group (if people
agrees) is to solve the whole problems, not only our proposed ones.
Currently I only have our draft to count on, but I really don't want
to finish by standardizing ours only.

# How should I write an agenda (or a proposed charter) in this situation?
# "Start-then-recharter" approach will work?

I don't know, however, how much extent of those can be worked on by
our proposed group within next several seasons.  I hope as much as
possible :-)

>  * How do we motivate the different stakeholders to implement and
>  deploy our favorite solutions? (There is also the usability issue
>  for the user.)

>     Whatever you come up with changes are needed on the client, and
>     on the server side. That requires a lot of cooperation.

This was (is) one of the most hard points for us (I believe not only
for our group :-).  But, for ensuring mutual authentication integrity,
we need at some point to change both peers anyway.

For the "technical" usability/deployability problem of the RFC 2617
HTTP authentication, we're actually proposing a solution for that.
For gradual transition, our current proposal can be parallel-served
with existing form-based authentication framework for transition
periods.  We also keep trying to keep contact with browser vendors, of
course.

---

From: Tim <[email-masked]>
Date: Mon, 6 Jun 2011 10:02:56 -0700

Hi everyone,

I'm coming out of lurking-mode to offer some opinions on this.

>      Browser vendors are interested, as you may recall from the Identity in the Browser discussion, in standardizing username/password form indications  so that the user does not need to type their…

In general authentication theory terms, using passwords is relying on
"something you know" (SYK) whereas certificates rely on "something you
have" (SYH).  By moving toward password management in the browser, you
turn something you know into something you have.  

The SYH solutions are very attractive from a security perspective and
from a usability perspective.  If it were sufficiently standardized,
browsers can use certificates or random passwords for each site and
users don't have to worry about it. (Of course once we move to a SYH
password model, then what is the point in using passwords at all
again?)

However, SYK will always have a place in the world.  There are many
situations where users simply want to be able to type in something
they've memorized.  Passwords will never go away completely for this
reason.  Add into that the fact that far more average users understand
username/password systems than certificates, and you will have a hard
time convincing the world to switch off of passwords even in
applications that would work prefectly well with SYH.

To me, the best way forward is to offer seemless integration of SYH
and SYK systems, both allowing for federated authentication and all of
the advanced features everyone seems to want these days.  If you
convince application developers and browser vendors to switch to such
a framework, then you also eliminate some barriers to entry for
switching some sites and users to switch away from passwords (or at
least user-chosen passwords).  

As a first step to this proposed master plan, the new SYK model must
be more secure than what we are using now, in order to convince people
to move away from web forms to the new system.  Protecting against
phishing attacks, which are rampant these days, is one great way to do
that.

tim

---

From: Nico Williams <[email-masked]>
Date: Mon, 6 Jun 2011 16:22:35 -0500

> turn something you know into something you have.

Well, I wouldn't call that "general authentication theory" :)

Passwords are either something you know, or something you have, or
even both.  Because let's face it: users can (and do!) write passwords
down, and as soon as they are written down they become "something you
have".

Also, password managers typically have a master password, so, what's,
uh the deal?

It strikes me as silly to say that passwords are something you know,
as if users might never write them down.  Indeed, nowadays some
security experts urge users to write their passwords down as a way to
enable stronger passwords -- not a bad idea, IMO.

A bigger problem with passwords as something you have is the need to
carry them.  If they're in a browser password manager, well, we need a
way to export (and import) the thing.  Also, there's no way to
securely use a password manager on an untrusted system (or, for that
matter, to securely use a password on an untrusted system).

In other words, this is hardly the biggest problem we have.

The biggest problems we have, IMO, are:

 - local security (malware)
 - the lack of strong authentication protocols on the web
 - the lack of mutual authentication (TLS server certs don't cut it)

I'd be perfectly happy with passwords if we had ZKPPs or strengthened
password protocols.  But we don't.  DIGEST doesn't cut it, and we have
not much else on the web, not with mutual authentication anyways.

> password model, then what is the point in using passwords at all

Passwords do have the benefit that they work everywhere.  Smartcards
requre that they be carried around.

Fortunately users now have powerful computers with them at all times
(i.e., mobile phones).  Unfortunately these are powerful computers,
with all attendant local security problems.  (Also, not everyone
carries their phones with them at all times.  My daughter certainly
doesn't, for example.  So we need to be careful here.)

> applications that would work prefectly well with SYH.

One could always used passwords to authenticate to an online CA or
keystore (think SACRED).

> least user-chosen passwords).

I proposed an authentication framework (based on existing ones) two
weeks ago.  It turns out that even when there's no fundamental
objections to a proposal (or even any objections at all), the fact is
that it's hard to get momentum going for any real solutions if those
would require either significant investment or just significant
re-thinking, or any sort of leap-of-faith.  (For example, in my
proposal there's a leap-of-faith that not only will mutual
authentication help, but that it's feasible to have such a thing on an
Internet scale.  I don't have proof either way -- it's just a
conjecture, though many of us believe that it is correct, but that may
not be enough.  For another example, I believe my proposal is
relatively simple to implement, but I've to convince others of this,
and that, for the moment, seems difficult.  This is not a complaint --
it is an illustration of the difficulty in achieving change here.
Lots of smart people have been working on these problems for many
years, and yet we're still more or less stuck with mid-90s technology
-- it's not for want of effort or good ideas, but that momentum is
difficult to change.)

> phishing attacks, which are rampant these days, is one great way to do

How would you protect against phishing attacks via a new
authentication system?  I'm serious.  I believe it's possible to
improve the situation significantly that way, and I have my reasons,
but I want to hear yours.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 6 Jun 2011 16:44:51 -0500

>    The NSTIC fans seem to believe that passwords are the problem to begin with.

You know from the workshop that my view is that web authentication
should be pluggable with respect to authentication mechanisms.

Passwords are a HUGE problem if you must type them at untrusted
entities.  (Such as: kiosks, hotel business center desktops, other
people's laptops, or even pretty much any computer, given the current
state of local security on user desktops and, soon, if not already,
mobiles.  But also: untrusted web page forms -- the fact that TLS
server certs are used, when they are, is not enough.)

>     Browser vendors are interested, as you may recall from the Identity in the Browser discussion, in standardizing username/password form indications  so that the user does not need to type their…

My proposal:

http://www.w3.org/2011/identity-ws/slides/Williams.pdf
http://www.ietf.org/id/draft-williams-rest-gss-00.txt
http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_16.pdf

>    Whatever you come up with changes are needed on the client, and on the server side. That requires a lot of cooperation.

I'm trying...  I'm looking for: people who will want to implement one
aspect or another of REST-GSS because it successfully addresses
immediate problems for them (this would be, mostly, non-browser
HTTP-based applications and the server side of those).  I'm also
trying other angles.

But my approaches may be all wrong.  So I too want to hear your
opinions on how to get momentum going.

One possibility is to build consensus in the IETF and push the W3C
from there.  I'm not sure that's wise.  I think the best approach, for
now, is to demo solutions.  Since all solutions pretty much require
new UIs (and JavaScript APIs) in the browsers, we need to start by
implementing demos in the browsers themselves, now.

Finally, the incipient JavaScript crypto APIs will be successful in
that they will be widely popular.  They will not solve the real
problems because either users will still be typing secrets at
untrusted interfaces (scripts used by untrusted pages) or because
there will be no simple way to control access to cryptographic
material in software or hardware tokens/smartcards.  But I'm afraid
that the appearance of success will be enough to staunch progress in
any other areas, so it may be a now-or-never situation for any
alternatives other than JavaScript crypto APIs.

Nico
--

---

From: Tim <[email-masked]>
Date: Mon, 6 Jun 2011 15:11:03 -0700

I don't necessarily disagree with many of the things you mentioend
(that i've cut).

> requre that they be carried around.

This is the point I was trying to get at.  Until the typical user has
a brain implant to handle digital signatures, there will be a place
for methods of authentication that don't require hardware. (And even then...)

> doesn't, for example.  So we need to be careful here.)

Yes, I think the case for SYH is becoming more and more strong with
the way portable devices are going, but there's just so much legacy...

> -- it's not for want of effort or good ideas, but that momentum is

Agreed.  One of the problems is that there are so many proposals.  I
can't keep up with them all.  I live and breathe web security, but I
don't have time to read up on all of the new stuff until a customer
actually implements something and I'm asked to test it.

For the average developer, figuring out which to use is just as
difficult, if not more difficult.  

In my experience, new technologies are most commonly adopted because
they fill a need and they have a low implementation cost, not because
they are the best all-around solution.  Understanding how a technology
works is part of the implementation cost.  If you put out the most
secure, most feature rich, and most efficient protocol possible, it
probably won't be adopted if it isn't super easy to understand,
implement, etc. 

For a guy like me, who spends most of his time in the trenches, it
seems like the best approach is to have a firm idea of where you want
to go with your framework, but release it in small digestable pieces.
For instance, authentication protocols that can be used in very
specific scenarios (e.g. one that replaces basic/digest auth, another
that improves on client certificates, etc).

> but I want to hear yours.

Well, we've discussed this in the past, and agreed essentially that:

0. We must assume that users will fail to validate the trust of the
   domain they are visiting (definition of typical phishing attack)

1. Authentication must be conducted outside of the web page, since
   that will be attacker-controlled.  Proposals have been to include
   it in the browser "chrome", but OS-level authentication could work
   as well.  It is essential that whatever is selected as a GUI widget
   must not be easily spoofable through fancy web features.

2. In the case of password authentication, the server must prove it
   knows the password as well.  This is what HTTP Mutual can
   accomplish, though other protocols can accomplish it as well (TLS
   SRP?) 

Note that this doesn't eliminate all phishing attack vectors.  An
attacker could still phish someone by convincing them to hand out their
personal information outside of an authenticated session.  

Is there something I'm missing?

tim

---

From: Marsh Ray <[email-masked]>
Date: Mon, 06 Jun 2011 17:33:41 -0500

On 06/06/2011 04:44 PM, Nico Williams wrote:
>  But I'm afraid

Don't worry about it, they're not going to work even that well.

They wouldn't have stopped the government of Tunisia from MitMing 
Facebook and inserting Javascript to modify the behavior of the page. 
They wouldn't have stopped the government of Syria from using a BlueCoat 
to perform SSL MitM on Facebook with a bogus self-signed cert either.

Both governments were arresting and shooting their citizens and hacking 
their Facebook credentials. Interestingly, Tunisia controls a trusted 
root CA but didn't bother to use it. Syria doesn't control a widely 
trusted CA, but doesn't seem to need it either.

Sooner or later, people will tire of security theater. We can just try 
to have the best options available when they do.

- Marsh

---

From: Nico Williams <[email-masked]>
Date: Mon, 6 Jun 2011 18:30:26 -0500

> difficult, if not more difficult.

We have fundamentally the following choices:

 - new TLS auth methods (but... how to upgrade existing TLS firmware, ...?)
 - new HTTP auth methods (but... how to upgrade the many HTTP stacks?)

 - new HTTP redirect-based authentication methods (with all the
problems those entail)

 - new auth methods based on TLS user (and server?) certs, such as
downloading keys and certs via SACRED, getting short-lived certs from
onine CAs (to which one authenticates via, say, a password-based
method), or via registration of random self-signed certs (where one
uses a password-based method, say, to authenticate in the cert
registration protocol)

 - application-layer auth methods

 - ?? (out-of-band authentication?)

My proposal is to do authentication at the application layer.  In most
other Internet protocols that's _exactly_ what we do: authentication
at the application layer.  What we can't do is transport protection at
the application layer (for practical reasons as well as because of
existing investments in TLS concentrators, etcetera) -- so enter
channel binding (see RFCs 5056 and 5929).

> probably won't be adopted if it isn't super easy to understand,

I believe application-layer authentication can fulfill this because no
changes are required to the existing TLS and HTTP stacks.

> that improves on client certificates, etc).

What if the authentication mechanisms exist, but you're only just
awaiting for a way to use them in this one class of applications?

>   domain they are visiting (definition of typical phishing attack)

Yes!

This means that whatever authentication method you use to authenticate
the user MUST also authenticate the server.  And, because we'll have
TLS around forever, we must have channel binding of authentication to
the TLS channel.

>   must not be easily spoofable through fancy web features.

Yes!

See Sam Hartman's presentation from the W3C workshop two weeks ago.

>   accomplish, though other protocols can accomplish it as well (TLS

Yes!  This is really just a restatement of the mutual authentication
requirement that you implied above.

> personal information outside of an authenticated session.

Phishing attacks depend on the fact that humans are susceptible to
cons.  We can't prevent people for falling to cons.  HOWEVER, we may
be able to make some (not all) classes of phishing and MITM attacks
much harder, or impossible -- I believe that we can.

> Is there something I'm missing?

Channel binding :)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 6 Jun 2011 18:32:45 -0500

> Don't worry about it, they're not going to work even that well.

I know they won't work.  That's not my fear.  My fear is that they
will seem to be enough of an improvement over the current mess that we
declare victory and go home, leaving us with a serious failure.

> They wouldn't have stopped the government of Tunisia from MitMing Facebook
> and inserting Javascript to modify the behavior of the page. They wouldn't
> have stopped the government of Syria from using a BlueCoat to perform SSL
> MitM on Facebook with a bogus self-signed cert either.

Right.

> their Facebook credentials. Interestingly, Tunisia controls a trusted root
> CA but didn't bother to use it. Syria doesn't control a widely trusted CA,
> but doesn't seem to need it either.
>
> Sooner or later, people will tire of security theater. We can just try to
> have the best options available when they do.

Having them available means having implementations and deployments of
code done.  That's also the hardest part.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Jun 2011 01:20:25 +0100

Hiya,

> Don't worry about it, they're not going to work even that well.

Just trying to understand this. Why won't what work well?
(Compared to Tom, Dick and Harry each doing the same thing
in their own favourite way?)

Seriously - I think it'll be useful to know/document the
limitations of this approach of developing a standard
JS crypto API.

S.

---

From: Nico Williams <[email-masked]>
Date: Mon, 6 Jun 2011 20:33:36 -0500

> in their own favourite way?)

People are already using JavaScript crypto algorithm implementations.
A crypto library implemented by the browsers themselves will at least
get the crypto algorithms right and perform better.  On the other
hand, a JS crypto API cannot prevent misuse of cryptographic
algorithms, nor can it do about the fact that it will be used from
untrusted scripts.  Regarding that last point, suppose a JS crypto API
included a PKCS#11-like interface to access a "token" (a smartcard,
effectively, either in the browser chrome, or an actual, hardware
smartcard)...  with such a thing one could prevent untrusted scripts
from reading secret keys, but not from _using_ them because the
browser will not have enough context to explain what's happening to
the user, nor will the user be able to decide for themselves whether
they should or should not allow a given script to use a given key.

But a JS crypto API can be delivered relatively quickly, and thus it
will seem like an accomplishment.  It might be a while before
consensus develops that indeed, a JS crypto API wasn't much of a
solution.

> limitations of this approach of developing a standard

See above.

I said as much at the W3C workshop two weeks ago.  The minutes, last I
looked, record the fact that there was consensus for adding such APIs,
not that there was loud grumbling about their dangers.

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Mon, 06 Jun 2011 21:16:50 -0500

> Just trying to understand this. Why won't what work well?

Well you can probably make the math more efficient. You could certainly 
improve on the crypto handling ability of a language like Javascript 
which has neither secure memory overwrite nor constant time comparison 
operations.

But is there any plausible attack scenario where crypto in the web page 
adds meaningful security?

I don't think so. Either:

A. TLS is correctly securing the connection, in which case you could 
just as easily ship the plaintext to the server, or

B. TLS is not present or ineffective, in which case it's the attacker 
who controls what script is running in the page to such an extent that 
it's not even worth discussing distinctions in the degree of the 
compromise. I.e., pwned.

> limitations of this approach of developing a standard

Anything done in client-side script happens only at the pleasure of an 
adversary who can break the security of the page (i.e. source or inject 
even the smallest fragment in the origin context of the site).

Therefore, client-side script is powerless to add real security.

This is not academic, obviously script injection is common in the real 
world. Some of the most common types of malware inject script into pages 
for the purpose of relaying login credentials (of course they could do 
almost anything since they are running binary code in the browser, it 
just happens that injecting script is the easiest way to do it).

- Marsh

---

From: Nico Williams <[email-masked]>
Date: Mon, 6 Jun 2011 21:30:34 -0500

On Mon, Jun 6, 2011 at 9:16 PM, Marsh Ray <[email-masked]> wrote:
> improve on the crypto handling ability of a language like Javascript which
> has neither secure memory overwrite nor constant time comparison operations.
>
> But is there any plausible attack scenario where crypto in the web page adds
> meaningful security?
>
> A. TLS is correctly securing the connection, in which case you could just as
> easily ship the plaintext to the server, or
>
> B. TLS is not present or ineffective, in which case it's the attacker who
> controls what script is running in the page to such an extent that it's not
> even worth discussing distinctions in the degree of the compromise. I.e.,
> pwned.

Exactly.  There is, however, a third possibility: code signing.  That
is, we could have a script (and, for that matter, HTML document)
signing mechanism, then browsers could trust signed code even if not
delivered over TLS.

Note though: I'm not advocating code signing.  On the web code changes
much too often, for one.  But the biggest problem is that you'd have
to make sure that there's no leakage of untrusted bits into a page
such that trusted code could be subverted to perform actions that it
should not.  Web pages nowadays consist of a great many objects that
have to be fethced via HTTP -- this means that code signature
verification for all of them would be akin to using HTTP/1.0 (i.e.,
not pipelining) and TLS w/o session resumption, in that an asymmetric
crypto operation would be required for each object.  That's a lot of
asymmetric crypto!!

In short, I don't think code signing on the web is a terribly
practical idea, except, maybe, for generally stable libraries.

There's also a fourth possibility: that crypto APIs will be used to
access PKCS#11-like tokens (soft or hardware).  But the browser, and
therefore the user, will never know what a script means to do when
using a given key, which means that we couldn't gain much security
from this fourth possibility.

We're left with the two options that Marsh stated, and which more than
one of us explained at the W3C workshop (these are obvious problems),
which means that JS crypto will add no security.

Nico
--

---

From: Yutaka OIWA <[email-masked]>
Date: Wed, 08 Jun 2011 19:20:42 +0900

Dear all,

> are welcome.  I'm currently working based on that.

I put a pre-draft version of problem statement on
<http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF80/http-auth/AdditionalMaterials/DraftProblemStatement>.
I tried to be as neutral to specific technologies as possible, but we may still
update this to reflect more comments on the Bar-BoF and IIB as possible.

We will wrap this as a I-D format in a few days, but I'd like to reflect your
suggestions and comments as much as possible.  Please either send your comments
here, or personal mails to me are also welcome.

Thank you,

Yutaka

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 09 Jun 2011 23:31:55 +0900

Dear all,

Regarding http-auth, I finally updated the proposed BoF agenda.
The text is appended to this mail.

A "draft" of the problem statement document, referred to by the agenda,
is currently available at
<http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF80/http-auth/AdditionalMaterials/DraftProblemStatement>.
We're currently preparing an Internet-Draft formatted version.

Comments for both documents are really welcome and appreciated.

Cheers,

---------
Description:

The current authentication methods used in the Web system are prone to
various serious vulnerabilities, including password eavesdropping,
password stealing, session hijack, and phishing.  Currently, the HTTP
core protocol only provides basic plaintext password authentication
and MD5-based hashed password authentication, both of which are
insecure against eavesdropping and password dictionary attack.  There
are some other authentication protocols which integrate with existing
authentication frameworks such as GSS and SASL, but these were not
widely accepted outside the area where the frameworks are already
used. TLS, which is the underlying transport of HTTPS, provides client
certificate-based authentication but that has some but not massive use
cases, mainly due to deployment and usability problems.

Also, both current HTTP authentications and TLS client authentication
lack several control features, which makes modern Web applications
hard to deploy.  For example, both authentication mechanisms do not
have ability to dissolve authentication association (log-out) from the
server side, nor ability to directly accept a guest (unauthenticated)
user in the same URL as those for authenticated users.  These lack of
features make people tends to use HTML forms for authentication, which
are by nature insecure against eavesdropping and Phishing attacks.

Furthermore, although TLS has a almost-mandatory server authentication
feature, it in the real world did not completely prevent impersonation
attacks. To mitigate this, we should consider introduction of
techniques which let users know by themselves whether the accessed
server matches with their intentions, without relying on central
authority or careful attentions of users.

These problems should be solved as soon as possible to mitigate the
impact of Web authentication-related frauds to the Internet users.
However, to solve this problem, the resulting technologies should be
carefully designed so that these will be well deployable to the
real-world applications.  Without this, we will end up with inventing
one more useless technology,  which is obviously unfortunate.

Recently we have several new proposals for securing Web/HTTP
authentications.  In addition, we also have several proposed
technologies in surrounding areas, such as delegated authorization
(e.g.  OAuth) or delegated authentication (OpenID). Combining those
technologies with such secure authentication, with careful
consideration about security binding, should contribute to the whole
Web security improvements.

Additionally, the work of the HTTPBIS working group is about to finish,
and it will require some maintenance works for the HTTP existing
authentication mechanism, at least the registrations to IANA.

The purpose of the proposed BoF is to pursue creation of IETF working
groups on various HTTP authentication issues.  The possible topics of
the future working group may include some of the following topics:

 * Introduction of much more secure authentication mechanisms as
   extensions to the HTTP, considering use with Web and non-Web
   accesses.  These technologies should protect users from being
   stolen their authentication by malicious eavesdropper or phishers,
   or being impersonated by man-in-the-middle attacks, or forged
   authentication result by malicious servers.

 * Introduction of technologies which will enable more sophisticated
  use of HTTP authentication from recent Web applications.

 * Introduction of better secure authentication mechanisms which can be
   used with non-Web HTTP accesses with existing authentication
   frameworks. ("non-Web" here includes HTTP accesses made from
   scripting code running inside Web browsers.)

 * Introduction of proper channel-binding technologies to HTTP
   authentication layer, which can be combined with higher-layer
   authentication/authorization mechanisms.

 * Research on the secure and more easily usable ways of (possibly
   mutual) Web/HTML authentications using several kinds of
   authentication credentials, and required protocol-side support for
   them.

 * Maintenance of existing HTTP authentication extensions (other than
   Basic and Digest), either checking its httpbis-conformance or making
   it historic.

 * Proposing addition of the above authentication schemes to the IANA
   registry as proposed by httpbis new HTTP 1.1 specification.

The working group should be careful about the impact of the introduced
security mechanisms to privacy issues, as strong authentication
sometimes conflicts with people's privacy concerns.

Both BoF and possible future working group expect well coordination
with W3C's effort on the related topics.  It shall also be in
coordination with related IETF working groups, including websec, abfab
and oauth.

BoF proposed agenda:

 * Discussions on HTTP authentication problem statement

 * Discussions for working group activity scope

 * Discussions for working group schedules
  (including handling of "research items")

Logistical informations:

BoF Chairs: TBD
BOF Proponents: Harry Halpin, Yutaka OIWA, ... (TBD)
People expected: 50
Length of session: 90min
Conflicts to avoid: Working Groups in the APP and SEC areas
WebEX: no
Responsible AD: Peter Saint-Andre (tentative)
Goal: to pursue creation of IETF working groups
Drafts:  http://tools.ietf.org/html/draft-oiwa-http-mutualauth-08; more to be added
Mailing List: HTTP http-auth mailing list
Mailing List Archive: http://www.ietf.org/mail-archive/web/http-auth/
--------

---

From: Julian Reschke <[email-masked]>
Date: Thu, 09 Jun 2011 16:40:50 +0200

On 2011-06-09 16:31, Yutaka OIWA wrote:
> ...
> ...

That's kind of misleading; the core HTTP protocol doesn't define any 
concrete authentication schemes at all; it just offers a framework 
(header fields, status codes etc).

 > ...
> ...

I believe you need to add HTTPbis.

Best regards, Julian

---

From: Yutaka OIWA <[email-masked]>
Date: Fri, 10 Jun 2011 11:22:53 +0900

I forgot to send a reply to the mailing list, so forwarding for your
reference...
Sorry for inconvenience.

---------- Forwarded message ----------
From: Yutaka OIWA <[email-masked]>
Date: 2011/6/10
Subject: Re: [http-auth] re-call for IETF http-auth BoF
To: Julian Reschke <[email-masked]>

Dear Julian:

2011/6/9 Julian Reschke <[email-masked]>:
> concrete authentication schemes at all; it just offers a framework (header
> fields, status codes etc).

Thank you for comment.  My intention was RFC 2616+2617 as a core,
but the view of your comment seems to be more clear.

> I believe you need to add HTTPbis.

Yes, I'm sorry.

Yutaka

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 11 Jun 2011 17:53:38 -0400

I have a different proposal. Lets take the high value authentication use
cases out of the browser completely.

Back in 1993 when Digest was designed, a Web browser could be written in
about ten thousand lines of code. Today a modern browser has a code
footprint that is larger than the memory plus pagefile of machine I used to
work on at CERN.

The modern browser is contaminated with plugins and active code. The worst
disservice that Netscape did to the Web was when they added Javascript to
Navigator unilaterally. Once a program conflates code and data it is never
going to be possible to make it secure.

The alternative would be to have a mini-browser whose sole purpose was to be
used to confirm high value transactions. This could be on the same machine
as the browser or a totally different machine such as a mobile phone.

If we start small with an application whose sole purpose is security we have
a good chance of getting some secure implementations.

This type of approach is not going to be acceptable for every possible
application or for every user. But the same is true of smart-cards, tokens
and the like.

So imagine that we had such a capability (I have a draft, I am just working
on getting preliminary feedback), what would we want HTTP authentication to
look like?

At that point what I would want most from the browser is to be able to
authenticate the browser and the machine it is running on in a manner that
is secure and robust. Cookies try to do this but again the implementation
was shoddy.

Where I think this conversation tends to go off the rails is when people get
the idea that the problem is the lack of an authentication protocol or an
authentication framework API. We have both of them, we have cartloads of
both of them.

The other point where I think the conversation went into a dead end was five
years ago when people started to sniff out the possibility of a something
that turned out to be Facebook. All those people who were wittering on about
'Identity' were not trying to solve the problem of how users authenticate or
manage attributes they were trying to solve the problem of how they could
win the spot in the industry that Facebook now occupies.

The missing like here in my view is the account identifier and the mechanism
by which it is mapped to a service.

The market has already decided that the federated account identifier for
Internet login will look like an email address. So Alice is going to be
something like [email-masked].

The problem with the current authentication infrastructure is that Alice now
has hundreds of accounts under that account name being maintained all over
the Web and example.com really has no control over how they are used.

One side effect of that lack of control is the type of idiocy I encountered
trying to report a bug in Visual Studio yesterday. First I had to register
to create a Windows Live ID. Which was irritating since I already have
registered several products with Microsoft. But never mind. So I register
for that and then I am told that I have to register my Windows Live account
again and verify my email a second time. Plus give all the same personal
details again.

Now the reason that Microsoft ended up in that situation is quite easy to
see. They have a bunch of divisions run as silos and one does not exchange
information with another. But they do have management degrees coming down
from the top telling one division to use another's dog food.

If my [email-masked] accounts were all managed by gmail.com there would be
no need for any callback mechanism whatsoever. Nor would there have been any
need for the Windows Live account or the crazy register then register all
over again.

If we could accept the simple idea that use of an authentication account
should work the exact same way as use of an email account, this type of
problem can be eliminated.

You don't expect to be able to use gmail.com for email unless gmail.com has
a Web server. So why do people try to write protocols that are designed to
allow people to use gmail.com for authentication when gmail.com is not
involved in the running of the authentication service in question?

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 12 Jun 2011 17:18:11 +0100

> I believe you need to add HTTPbis.

+1.

I would also add Kitten.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 14 Jun 2011 16:59:54 +1200

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

>what would we want HTTP authentication to look like?

I have a suggestion for what it shouldn't look like: Any method that hands 
over the password (or a password-equivalent like a password in hashed form) as 
current browsers do should be banned outright, and anyone who implements 
hand-over-the-password should killed and eaten to prevent them from passing on 
the genes.

The only permitted auth.form should be a dynamic, cryptographic mutual auth. 
that authenticates both the client and the server.  There are endless designs 
for this sort of thing around so the precise form isn't too important, as long 
as it's not hand-over-the-password.

Peter.

---

From: Nico Williams <[email-masked]>
Date: Tue, 14 Jun 2011 11:17:02 -0500

+1.

> as it's not hand-over-the-password.

+1, particularly with regard to mutual authentication.  It's important
to understand that we need mutual authentication using something other
than the TLS server cert PKI for authenticating the server.

Some aspects of the designs are important.

For example:

 - Is this to be done in TLS?  HTTP?  Or at the application-layer?

IMO: TLS is too low a layer to do authentication in, and doing it in
HTTP would require retrofitting too many HTTP stacks.  Doing it at the
application layer has a number of advantages.

 - Shall we have just one authentication mechanism?

IMO: We can't pick a universal authentication mechanism that will work
for everyone, but if it helps get momentum I'd be happy to specify
something where we start with one mechanism but nothing prevents us
from adding others later.

Here's an example showing how to use SCRAM (a successor to DIGEST-MD5,
thus not terribly interesting, but pretend for a second that this is a
ZKPP) at the application layer and in a RESTful way:

C->S: HTTP/1.1 POST /rest-gss-login
      Host: A.example
      Content-Type: application/rest-gss-login
      Content-Length: nnn

      SCRAM-SHA-1,,MIC
      n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL

S->C: HTTP/1.1 201
      Location http://A.example/rest-gss-session-9d0af5f680d4ff46
      Content-Type: application/rest-gss-login
      Content-Length: nnn

      C
      r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
      s=QSXCR+Q6sek8bf92,i=4096

C->S: HTTP/1.1 POST /rest-gss-session-9d0af5f680d4ff46
      Host: A.example
      Content-Type: application/rest-gss-login
      Content-Length: nnn

      c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
      p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=

S->C: HTTP/1.1 200
      Content-Type: application/rest-gss-login
      Content-Length: nnn

      A
      v=rmF9pqV8S7suAoZWja4dJRkFsKQ=

Does that work for you?

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Jun 2011 17:36:14 +0100

This is about http auth (and I'm glad to see the discussion) but can we keep it to just that list? 
Ta.
S

On 14 Jun 2011, at 17:17, Nico Williams <[email-masked]> wrote:

> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Nico Williams <[email-masked]>
Date: Tue, 14 Jun 2011 11:48:20 -0500

> This is about http auth (and I'm glad to see the discussion) but can we keep it to just that list?

The two lists I'm cc'ing now are appropriate for this.  It wasn't
obvious that websec might not be appropriate, though it should have
been obvious that saag wasn't -- my MUA hides dups from me, so it's
all too easy to hit reply-all.

Nico
--

---

From: Yutaka OIWA <[email-masked]>
Date: Wed, 15 Jun 2011 07:46:33 +0900

>> hand-over-the-password should killed and eaten to prevent them from passing on

+1, although the original statement is a bit too strong in wording for me :-)

> application layer has a number of advantages.

IMO, I agree that TLS is too low.
However, although the application layer use-case exists,
I believe that for general use cases HTTP-auth layer is more appropriate,
because the trust relationship becomes much simpler.

Backward-compatibility is important, and all intermediates *should* and
*in most cases will* work well with new http authentication
that completely complies with existing HTTP auth framework design.
All they've needed is just forward auth-related headers to the origin server.
We've done some experiment around my proposal,
and it worked quite well with all existing stacks,
including proxies, "SSL accelerators" and load balancers.
(Yes, we've carefully designed the protocol so that it can work in this way.)
Do you need some more detail on it?

Required code modification is almost the same magnitude in both cases,
because we need to change the client, and to add some server-side thing.
we can keep all other intermediates as it is.
Some client-side change is necessary in both cases to make mutual
authentication trustful and unforgeable.
In server-side, http-layer authentication can be implemented in either
in the server or in the application.

---

From: Nico Williams <[email-masked]>
Date: Tue, 14 Jun 2011 18:47:13 -0500

> +1, although the original statement is a bit too strong in wording for me :-)

Why?

> because the trust relationship becomes much simpler.

Can you explain what you mean by "the trust relationship becomes much simpler"?

> that completely complies with existing HTTP auth framework design.

Compatibility with existing installed base of HTTP stacks is a huge
plus.  Application-layer authentication can be implemented using CGI
on the server-side, if you want the lowest common denominator, and
practically every HTTP server has CGI support (even IIS!).  This is a
critical feature.

> All they've needed is just forward auth-related headers to the origin server.

Application-layer authentication also works whether there's proxies in
the path or not.  It is end-to-end because it is implemented by the
application-layer end-points.  This is also a critical feature.

> because we need to change the client, and to add some server-side thing.

With application-layer authentication one could make a CGI reference
implementation that can be trivially installed and used on the vast
majority of existing servers.  With HTTP-layer authentication one must
modify the HTTP servers that one uses.  That's a huge difference in
favor of application-layer authentication.  Sure, CGI isn't great, but
fast CGI is quite decent, and the important thing is to get deployment
momentum -- optimization for each HTTP server can come later.

> in the server or in the application.

The same is true for application-layer authentication, oddly enough.
There is a bit of a dualism between HTTP- and application-layer
authentication as long as the HTTP stacks expose enough
request/response header interfaces to the application.

On the client-side this duality is more complete than on the
server-side.  There's no reason that the HTTP stack couldn't implement
application-layer authentication, and there's no reason that the
application couldn't implement HTTP-layer authentication.  However,
there's no way to implement HTTP-layer authentication with CGI, and
that's a big issue.

There are other reasons to want application-layer authentication.  For
example, the application-layer authentication process need not reveal
any information about what resources the client wishes to access
unless the client tries to access a protected resource before
authenticating, whereas with HTTP-layer authentication the client must
access a harmless resource to get the same effect.  This is another
case where the duality of HTTP- and application-layer authentication
is not complete.

But let's say that the semantics and implementation and deployment
considerations authentication at either layer are fully equivalent to
those of authentication at the other layer...  Then why shouldn't we
just flip a coin to pick which layer to add authentication to?  It is
precisely because the duality mentioned above is not complete that we
have good reasons to pick one layer or the other.

Nico
--

---

From: Yutaka OIWA <[email-masked]>
Date: Wed, 15 Jun 2011 16:48:10 +0900

Dear Nico,

Thank you for very prompt comment.

>> +1, although the original statement is a bit too strong in wording for me :-)

Oh, just don't mind it in any technical way.
I just didn't prefer the wording like killing or eating people or technologies
and I have hesitated to put just "+1" with such things :-)
Another factor possibly in my mind at that moment were that I personally expect
the future transition to be more gradually, and I imagine the transition in some
form of "gradually cease to exist", rather than "stop and go another way".
Except for those trivial points, I agree that we should let people move to
technologies not relying to handing over the "reusable raw authentication
tokens", (including passwords, Digest password hashes, private keys and other
tokens) to authenticators.

> Can you explain what you mean by "the trust relationship becomes much simpler"?

OK.  I'll be happy if you can treat the following comments as possible
improvements proposal rather than critics.

I like your proposal very much, especially for using it for replacing current
authentications for internal communications initiated by script-based Web
applications. It seems to be well designed, have enough flexibility (including
introduction of mutually-authenticating underlying mechanisms) and useful
semantics.  You've mentioned in the draft that it can be implemented by client
scripts, although browser support is preferred, and it can really improve the
security of such applications.  Maybe this is one of the reasons why Sam Hartman
proposed abfab WG for possible discussion place.

However, I have a concern in directly using it for improving the security of Web
pages, e.g. against Phishing, which is the assumed use case of our proposal.
But before entering to the main topic, I want firstly to discuss some web-page
security model.

The current model of Web page security is top-to-down hierarchal model. The
topmost page, for which the address bar displays its location, must be secure:
it must be careful not to refer any malicious external contents including
images, applets and scripts, and all forms in that page must post to "trustful"
servers. Not to have any XSS vulnerability is needless to say.  And,
importantly, this is the *necessary and sufficient* requirements for that page.
 As top-to-down, each scripts and other contents included from that page has the
same requirements as necessary and sufficient conditions, too.  Assuming this,
all that users have to do is to think about whether the first page is trustful
or not. And it is almost what they can do at most, with existence of client-side
scripting.  Phishing pages make this top trust checking difficult for users.

Web-page mutual authentication will ensure the trust of this top page in effect.
Carefully reading our draft, you may find that the user-agents are allowed to
accept only new authentication requested by the top-most pages and ignore
others, and the result from the top-page authentication must be displayed.
Authentication algorithms are limited to those which provide equally-or-more
cryptographically secure authentication, it provides mandatory binding to the
originating host to prevent any forwarding, and authentication always happens
within the same top-page URL and nothing else, as usual http auth does. These
conditions are enough for browsers to trust authentication for the "whole"
displayed page, when the above security model is assumed.

In this perspective, your proposal seems to be currently too generic and too
flexible for this specific purpose. Initiating authentication from the
application layer makes more involvement of application-level contents,
including iframe, XMLHTTP and others. The browser must be careful not to display
any authentication results from any contents which are included by Phishing
servers, or from authentication requests forwarded to genuine servers.  Also,
the GSS-REST login process involves several URLs, which brings it complicates to
the security model and possible exploit points.

To this purpose, if we're going to use your GSS-REST proposal for securing
Web pages, I think we need to carefully define some subset "profile" which we
can trust for this specific purpose, and do analysis of it against the security
model.  For example, it should limit the underlying GSS mechanisms to use, it
should limit what resource can request new authentication to users, which set
of URLs can be accepted for GSS-login, and in which set of URLs the created
session URL can be, and for which resource the corresponding authentication
result will be shown in UI.  I found some good phrases in your security
considerations section, but I think we need even more.

I cannot judge whether this kind of restrictions increase or reduce the value of
your proposal, because it sacrifices its good properties of flexibility a lot
and introduces more complexities. If you're interested to go in this way, I'll
be happy in collaboration to discuss what properties are really required for
such a "profile".

> those of authentication at the other layer...

I agree that HTTP auth and application auth have some duality in general.
Also, with above restricted "profile", I agree that those two approaches are, in
some sense, in duality.  I personally think, at this moment, both proposals have
some non-overwraping good use cases and is worth to go on both of them, rather
than choosing one.

I'd like, at this moment, firstly to investigate to define what kind of abstract
properties are required for web authentications, considering for several use
cases. The short-term goal of mine is to improve our problem statement document
to discuss at Quebec and further.

---

From: Nico Williams <[email-masked]>
Date: Wed, 15 Jun 2011 03:49:05 -0500

> proposed abfab WG for possible discussion place.

I don't recall Sam proposing that.

As for my comment about scripts, it was in reference to demonstration:
by having authentication at the application layer it's trivial to
demonstrate the protocol without platform nor browser integration (if
we have JS crypto).  But I don't believe in trusted scripts, so the
script comment is limited to demonstration.

> But before entering to the main topic, I want firstly to discuss some web-page

Do you agree that to defeat phishing (a subset of phishing anyways) we
need: mutual authentication and channel binding?

If not, what else do you think we need?  Or what do we need instead?

> importantly, this is the *necessary and sufficient* requirements for that page.

I don't agree that that is necessary and sufficient.

Consider a phishing attack where a user is directed to a domain that
is confusable with one that the user trusts.  And imagine that the
malicious domain's servers have valid server certificates.  The
requirements you list above will not help the user detect such
malicious services.

Moreover, external contents, including scripts, is definitely allowed
to be referred to from pages -- it certainly happens all the time

> scripting.  Phishing pages make this top trust checking difficult for users.

I don't think external content is at the root of phishing.

> Web-page mutual authentication will ensure the trust of this top page in effect.

OK, so you agree that mutual authentication is part of this.

> others, and the result from the top-page authentication must be displayed.

I don't find that at all.  What makes you believe that's the case?

And in any case, the problem is bound to be the same for HTTP-layer
authentication -- after all, HTTP can't possibly know that some
resource you're fetching is related to some other resource you've
already fetched.  The application has to be in charge of deciding when
authentication is required, and the application has to use
authentication whenever it's advisable.

A browser should use authentication for a page and all contents
referenced from it once the user initiated a login.  If a secure page
references external contents then the user agent has to be able to
authenticate the services offering that content.  There's no way that
HTTP can automatically do this for the user agent.

> cryptographically secure authentication, it provides mandatory binding to the

Equal to or more than... what?

> displayed page, when the above security model is assumed.

Remember too that HTTP is used for things that aren't web pages, that
aren't HTML.

> the security model and possible exploit points.

No, I think you've misunderstood.  My proposal is just a protocol,
browser UI elements (but only for browsers), and XMLHttpRequest
extensions.  The browser will have to get the UI elements right,
particularly in the case of frames.  Clearly frames and clickjacking
complicate the situation _for the browser_, but not for the
authentication _protocol_.  The URLs used by REST-GSS are not visible
to the user; they complicate nothing.

> considerations section, but I think we need even more.

I just started on it.  The Security Considerations section, and the
section on UIs needs more work, clearly.  But there's nothing here
that's going to be particularly different than for HTTP-layer
authentication.  Or perhaps you can show me how you'd handle these
problems in HTTP without addressing them in the application (I don't
think you can, but maybe I'm simply not creative enough to see what
should be obvious to me).

> be happy in collaboration to discuss what properties are really required for

Thanks.  I think this is a sort of collaboration already, since we're
actually going through these issues.

> some non-overwraping good use cases and is worth to go on both of them, rather

I'd like to see more about those use cases for which only HTTP-layer
authentication works well or at all.

> to discuss at Quebec and further.

Let's keep a few things clear too.  There's properties of the
authentication _protocol_, and properties of the _UIs_ (and APIs).  We
must address both, but they are not the same thing.

Here's a start:

0) We need to distinguish between "secure page" as in "we used TLS"
and "secure page" as in "we're logged in (and we used TLS)".  For this
we'll need new terminology.

1) Required properties of authentication protocols:

1a) mutual authentication;
1b) channel binding (because TLS is here to stay);
1c) must have a notion of login session.

2) Desired properties for authentication protocols:

2a) support for enterprise and Internet-scale authentication mechanisms;
2b) federation.

3) Required properties for _browser UIs_:

3a) must have a non-confusable trust path (e.g., browser chrome,
secure attention sequences, particularly when full-screen apps are
involved);
3b) must make clear to the user what page elements are authenticated
OR must not mix authenticated and non-authenticated contents (this
principle addresses the iframe issue, for example);
3c) non-external content references from logged in pages must be
obtained using the same logged in session;
3d) external content references from logged in pages either must be
disallowed or must require some clue from the page origin as to what
to do with them (authenticate? use TLS and here's the external
references' servers' TLS certs?);
3e) the UI must allow the user to distinguish between "secure" as in
"used TLS with server certs" and "secure" as in "logged in (and used
TLS)";
3f) the UI must allow the user to see the authenticated names of the
user and service.

4) Required properties for JavaScript APIs:

4a) the user agent must not expose all or any of the names of the
user's credentials to the calling script;
4b) the user agent must not allow the calling script to authenticate
to a different server than the one to which the authentication
messages are ostensibly being sent, otherwise the script could abuse
the user's credentials to login by proxy to other sites and gain
control of those new sessions;
4c) ...

What have I missed?  (Keep in mind it's the middle of the night for
me, so I'm sure I missed quite a few things.)  Most of the above I
either referred to explicitly in my presentation and I-D, or obliquely
for lack of time.

Thanks for you comments, particularly for elaborating on your trust
issue.  I don't believe the trust issue is germane to the
authentication protocol, but it is germane to how the user agent uses
authentication, and to the user agent UIs.

Nico
--

---

From: "KIHARA, Boku" <[email-masked]>
Date: Wed, 15 Jun 2011 18:44:37 +0900

+1.

To make the goal clear, let's list what kind of authentication methods
should be avoided. One item is methods that hand over passwords,
mentioned by Peter. Let me add methods whose UI can be imitated and
the result can be forged by malicious sites. Like a padlock icon that
insists the session is secured by TLS inside content area, Is a _secure_
authentication method inside content area truly reliable?

* a method that hands over a password (or a password-equivalent)
* a method whose UI can be imitated by malicious sites.

Of course there might be more items, please append.

# Peter, sorry for missing Ccs.

--
KIHARA, Boku

---

From: Nico Williams <[email-masked]>
Date: Wed, 15 Jun 2011 09:17:26 -0500

> * a method whose UI can be imitated by malicious sites.

The protocol and UI are not that closely related.  I can't think of
any method that satisfies the first requirement that couldn't have a
secure UI.

Nico
--

---

From: Yutaka OIWA <[email-masked]>
Date: Wed, 15 Jun 2011 23:24:58 +0900

Dear Nico, (I'm sorry to you for duplicated posting as I forgot Cc)

I think that my point was not correctly explained to you.
I'm very sorry that my phrasing are understood in very opposite way.

> need: mutual authentication and channel binding?

Yes, at least it is required.

> requirements you list above will not help the user detect such

You're correct, but my intention was different.

I guess you agree that Phishing is very different kinds of attack compared to
XSS, CSRF, SQL injection and many others.
Server admins and programmers can and must prevent XSS, CSRF, SQL injection
and others, but they cannot prevent Phishers from creating the Phishing site.
This is the first point.

Then, to prevent Phishing users, not the server owners, must notice that
Phishing is on going in some way.  Currently users must be very careful,
and mutual authentication can take this part. this is the second point.

Then, the third point is: the users must have to check only the validity of
the topmost page.  And all others are server's responsibility to correctly
refer all external information which requires.  In this way, my requirement
list is "what servers must do" and "what servers can do at most".
My intent for the "sufficient" was: means "all what they ought to do".

> to be referred to from pages -- it certainly happens all the time

Yes, and if they are correctly referred to by the topmost page,
it is OK for users.
In anyway, the top-most page must be correctly written,
as users cannot check all subrequests the page has made.

> I don't think external content is at the root of phishing.

I didn't said it...

> OK, so you agree that mutual authentication is part of this.

Yes.

> I don't find that at all.  What makes you believe that's the case?

Please see almost the last of section 8 "Decision procedure for client",
the paragraph starting from "The client software SHOULD...".
There is a special mention for interactive clients, which treats
sub-requests in a different way than the topmost document.

> HTTP can automatically do this for the user agent.

This is related to the second next question possibly...

> Equal to or more than... what?

...Than the currently-defined crypto algorithm.

> Remember too that HTTP is used for things that aren't web pages, that

Yes, and it is actually used in two very different ways.
One case is for subrequests, which are effectively part of the "Web page"
and it will typically require the same authentication (or none) as the topmost
page.  For this kind of contents, which is the first main target of
our proposal,
works quite well with our design, as it works for existing HTTP authentications.

The second use case is for application-issued requests (aka XMLHTTP request),
which has very application-specific semantics for authentication.
In this cases, it is better applications (in browser case, typically scripts
which is in or referred to by the topmost document) will determine how
they authenticate with resources.  For such purpose GSS-REST is really good,
OAuth also, and some people tends to use custom auth/authz
implementation by their own.  Our proposal, technically speaking,
can be used as an underlying protocol, but our design and requirements
for browsers are not considering this well, as this is not our main target.
And in this case, Phishing is not a main target for preventing
(the application typically knows which server to connect), but mutual
authentication
still gives a slight improvement for security, such as against transport-level
or TLS-level (such as a false certificate) attacks.

Another variant of the second case is completely non-Web applications
which uses HTTP as just underlying transport for various reasons
(simplicity, sharing code with the above second case, etc.)
I appreciate requests for supporting non-browser use cases, and I
really do it as a second target.
And it is actually much more trivial than supporting browsers.

> to the user; they complicate nothing.

Yes.  I have actually no doubt for the "a protocol" and "XMLHttpRequest" part.
My concern is only on the UI element part, which must be really
carefully designed
to prevent misunderstanding by users.

I think we do not need too much details on the some questions below, as
I believe that I can understand, mostly agree on your point and go productively.
so skipping...

> authentication works well or at all.

Technically we can tunnel both protocols into another layer by
defining too-restrictive hard-coded rules (because what you're doing
in apps-layer is actually in HTTP request, so we can easily exchange the
role of body and headers), but I think we certainly need such restrictions
to work well.

One point we are in disagreement on this is possibly that you're estimating
cost of introducing http-layer auth extension too expensive.
Of course, adding new request method (e.g. GET, POST etc.) or new
tunneling protocol (Upgrade:) is extremely extensive, because we really
have to upgrade all servers and all intermediates.
On the contrary, adding new authentication does not change all request
binary structure and thus it should go though all existing intermediates.
At least ours can be used with all intermediates which can pass
Digest authentication. We actually did field experiments in a part of
Yahoo! Japan web systems, which has a complex internal structures
with intermediate proxies and accelerators, and it worked quite well.

Adding auth protocol to the servers is modularized in most
production-level Web servers, and also many language platforms
(e.g. PHP) actually support passing authentication requests
transparently to the apps layer so that application framework
can handle authentication. If application are relying on the such platform-
or server-provided authentication, ours can be introduced
to the server-side with almost no cost.
For general cases we need to change some framework
part to adopt new authentication, but the cost is comparable
to change some framework for new apps-layer authentication.

Now I love to go to the next step...

> must address both, but they are not the same thing.

Let's go :-)

> secure attention sequences, particularly when full-screen apps are

Agreed to this point.

> principle addresses the iframe issue, for example);

Hmm, I can doubt this.  In our application story, the top-most page
must be authenticated, but the subrequests can be done
in either ways.  If the top-most page is correctly written
(it is the server's responsibility), it refers all HTTPS sub-contents
not user-autheticated, and if we can either trust CAs
or have "LockCA" feature of Strict Transport Security, the security
will not be broken.

Currently, HTTP auth _does not_ require all-or-nothing, and HTTPS
_does_ require all-or-nothing which make some people irritating :-)
Actually, it can be in either design and people can decide.

# My personal feeling for the mixed contents on HTTPS is
# "not acceptable" for hard contents (e.g. scripts, HTML and style-sheets)
# but "acceptable" for just images if they need.

This is also related to the next two issues.

> references' servers' TLS certs?);

So, to this part, actually we can have several designs.

One important point here is that, even for the applications
which needs those strong properties and does it correctly,
loosening these rules 3b-3d to non-mandatory
will not sacrifice the security of such applications.
Even without these they can make it secure by themselves.
And loosening these rules will certainly benefit some other applications.
(On the contrary, for example, allowing non-mutual authentication
to use the same secure UI (which violates (or whatever worse)
3a, 3e and 0) will make secure application a "victim" of forged
Phishing attacks.)

And loosening these rules will certainly benefit some other applications.
So there will be a design choice.

For 3d), I agree that we need to provide some additional clues for them
so that the pages can use these if wanted, even when we do't let it mandatory.)

> "used TLS with server certs" and "secure" as in "logged in (and used

Yes.

> 3f) the UI must allow the user to see the authenticated names of the

For the user yes, and in federation case also for the service.

# But, if this includes script-initiated request cases, it is *not always* true:
they can implement more complicated access patterns like
OAuth-like delegation, or using temporarily-generated id/credential
pair to authenticate to third-party resource servers.
In such case showing such internal authentication ID might be
inappropriate, although mutual authentication is still very useful.

For "4) Required properties for JavaScript APIs", sorry I don't have
enough concrete idea at this point.

> authentication, and to the user agent UIs.

Thank you very much, too.  Your comments and summarization
really help my understanding becoming much clearer.

---

From: Yutaka OIWA <[email-masked]>
Date: Wed, 15 Jun 2011 23:32:32 +0900

> any method that satisfies the first requirement that couldn't have a

How about a simple form-field extension which
encrypts some password with timed challenges?

OK, but your point suggests the following rephrasing:

 * a UI which can be imitated by malicious sites.

Although they are not closely related, but we cannot completely
ignore the UI issues . I think that protocol designs
should, in some extent, consider how such UI is to be provided
(especially when and how they are kicked in). How about it?

---

From: Nico Williams <[email-masked]>
Date: Wed, 15 Jun 2011 09:35:41 -0500

> (especially when and how they are kicked in). How about it?

I think what you want is to say that the user agent must implement a
secure UI, or that it must integrate with the platform's secure UIs,
if any.  The UI is quite distinct from the authentication protocol.

I agree that a UI that cannot be imitated is a good and desirable
thing, but as long as full-screen applications are allowed you'll need
a secure attention sequence instead.

Nico
--

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 17 Jun 2011 20:38:45 +1200

>Some aspects of the designs are important.

Definitely.  Before we launch into the inevitable bikeshedding, I think we
should set out what it is we're documenting/specifying (since this is copied
across several lists, it's a bit hard to see what the target/goal is).  Is it
a new crypto mutual-auth mechanism?  A recommendation to use crypto mutual
auth?  Is it for browsers/HTTP, or general use?  Is it a MUST for a protocol,
or a BCP, or an informational RFC?  If we're going to go into UI issues then
it's probably going to be an informational RFC, which won't have much effect
on browser behaviour, while if it's a crytpto mutual-auth protocol for HTTP
that'll become a MUST (I hope so!) then we're not really going to be able to
lay out requirements for UI design.

>Shall we have just one authentication mechanism?

*If* the idea is to specify a new auth mechanism and *if* it's for browsers
and similar devices, I'd just say "Use EAP with X", it's been studied and
spec'd to death, there's lots of implementations, it's pretty simple to do,
etc.

>at the application layer and in a RESTful way:

I would really, *really* prefer to not invent another auth mechanism.  There'd
have to be a pretty strong argument to not use what we've already got.  I
happen to like EAP because it's simple, already spec'd out for lots of things
(including cellphones via SIMs and other non-browser devices), and you can
just say "use this", as long as "this" is profiled a bit to be something more
specific than "any EAP mechanism you feel like".

Peter.

---

From: Nico Williams <[email-masked]>
Date: Fri, 17 Jun 2011 10:25:25 -0500

> spec'd to death, there's lots of implementations, it's pretty simple to do,

CHeck out what ABFAB WG is doing then!  ;)

(Hint: they're making a GSS-API security mechanism based on EAP.  Now,
if only there were a way to use that well in HTTP.)

> specific than "any EAP mechanism you feel like".

Ah, but I'm not proposing that we invent any new mechanisms.  Mind
you, I'd not mind more mechanism choices, but I'm not proposing new
ones.  I'm proposing a way to use the set of mechanisms we have in
HTTP without modifying HTTP nor TLS.

Nico
--

---

From: Josh Howlett <[email-masked]>
Date: Fri, 17 Jun 2011 16:11:40 +0000

>CHeck out what ABFAB WG is doing then!  ;)

Just by way of information for Peter's benefit, we have an ABFAB
implementation -- and we've demonstrated ABFAB-based EAP authentication
with Firefox and Apache by leveraging their existing support for the HTTP
Negotiate scheme.

I also agree with Peter's argument, although there are other benefits to
EAP that he doesn't mention. It supports a diverse range of authentication
methods, which means that deployers are not required to use a particular
type of credential - they can use whatever type of credential best suits
their needs.

In addition, with EAP Pass-Through the web server does not need to
understand the credential technology being presented by the user; the web
server can be entirely agnostic with respect to the credential technology
being used by EAP (modulo some basic security properties that enable GSS
magic to happen).

>HTTP without modifying HTTP nor TLS.

Nico's proposal definitely adds significant value to EAP (ABFAB) based
authentication, relative to transport-bound Negotiate. I would like to see
GSS REST happen.

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 25 Jun 2011 15:43:00 -0400

> hand-over-the-password should killed and eaten to prevent them from passing

Take a look at the following draft:
https://tools.ietf.org/html/draft-hallambaker-owcp-00

The basic idea is that putting SecurID type schemes on an iPhone is using a
Deep Blue to play pong.

This is orthogonal in that it is really about replacing the two factor
scheme. But a really good backup for two factor could allow us to address
some of the issues with single factor.

For example, browser generates a strong public keypair, uses same to
authenticate to an 'account management service'. This stores single factor
passwords on behalf of the user. Really big ones, like 128 bit worth of
password.

If that type of scheme is used for the 90% of accounts that don't matter to
me (no really, I don't care who uses my NYT account, only they care) we can
reserve the second factor scheme to the accounts and the transactions where
it really matters.

> as it's not hand-over-the-password.

Agree completely. But that is not the problem that is blocking us here. The
central issue is how to get deployment and that is hard.

If we could maybe get a toehold on this problem by getting a free
replacement for second factor out there that is also better, we can maybe
get a critical mass we can leverage.

-- 
Website: http://hallambaker.com/

---

From: Thomas Fossati <[email-masked]>
Date: Sat, 25 Jun 2011 10:59:07 +0200

> application layer has a number of advantages.

I've tried to figure out how to get something similar to your REST GSS -- which I like -- at the HTTP level and, yes, you need to hammer HTTP clients a bit to teach them how to do the challange-response on a specially crafted cookie, but then it seems you can switch from stateless to stateful HTTP (and viceversa) quite robustly.

Still there's the related bootstrap problem to solve, i.e. the authentication phase and implied key agreement.  

In this respect I've only been able to sketch a TLS-based mechanism, with a) explicit HTTP redirection, or b) a-priori knowledge of the authentication URI via .well-known or DNS-SD, which then uses RFC 5705 to feed both parties with the needed crypto material.

Anyway, I still have hazy thoughts about the whole matter, basically from an architectural standpoint, i.e. about where (which layer) the secure state management component must be placed.

My unanswered (taboo?) question being: would the core HTTP protocol benefit from introducing secure state handling capabilities ?  Or should HTTP remain stateless ?

---

From: Nico Williams <[email-masked]>
Date: Sat, 25 Jun 2011 23:42:15 -0500

> I've tried to figure out how to get something similar to your REST GSS -- which I like -- at the HTTP level and, yes, you need to hammer HTTP clients a bit to teach them how to do the challange-res…

I think the main benefit of doing this at the app-layer is that the
server-side can be portably implemented as FastCGI and instantly be
available on 90+% of servers.  I've started implementing in FCGI,
incidentally, and I believe I can implement all of REST-GSS this way.

Another major benefit of being able to use FastCGI is that you
automatically get privilege separation!  You can run the app, the web
server, and the REST-GSS FastCGI all under different user accounts,
with different access, privileges, ...

The POST/DELETE/GET can be implemented as a FastCGI responder, the MIC
validation as a FastCGI authorizer, and the servers' MICs can be
computed and added by a FastCGI filter.

On the client-side the situation is not as convenient regardless of
whether authentication is *in* HTTP or *above* HTTP: the apps, the
browsers, the XMLHttpRequest API -- all need extending, and all need
deploying.  At best you can save having to extend the HTTP libraries,
but in the browser that's not much of a savings, I bet, and even then,
people will prefer that HTTP libraries to just implement REST-GSS (as
opposed to having to use a separate library in addition).

> Still there's the related bootstrap problem to solve, i.e. the authentication phase and implied key agreement.

That's what the GSS mechanisms do for you!  That's the beauty of this:
you're reusing an existing security framework that has just the right
semantics: you get to authenticate an initiator (client user) to an
acceptor (service) , and preferably also the acceptor to the
initiator, and you get to do per-request/response integrity protection
(MIC tokens) without having to have ordered message delivery.

There's several GSS mechanisms available now, and it's relatively easy
to add new ones (see RFC5802).  A ZKPP mechanism would be great.  A
federated ZKPP mechanism would be even better!

> My unanswered (taboo?) question being: would the core HTTP protocol benefit from introducing secure state handling capabilities ?  Or should HTTP remain stateless ?

I like keeping things that are meant to be stateless stateless.
Implementations of HTTP that don't handle DIGEST or HTTP/Negotiate
would have a hard time adjusting, for example.

Also, if we do this *in* HTTP then we have the problem that the HTTP
method and URI are not specific to the authentication facility -- they
are real, and thus they are sent, initially, without having
authenticated the service to the user.  That's a problem, though maybe
it's not a big deal (I'm not sure).

Nico
--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 27 Jun 2011 14:44:38 -0700

> hand-over-the-password should killed and eaten to prevent them from passing on 

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