Subject: [saag] JavaScript for authentication

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Jul 2012 13:50:11 +0300

Disclaimer: I am not actively participating in the W3C Web Cryptography working group http://www.w3.org/2012/webcrypto/ for some reasons that are outside the scope of this discussion and therefore I do not know their latest development.

Having said that I believe it would be wrong to ignore that these activities are going on when we talk about securing authentication on the Web (in particular when the browser community seems to be willing to deploy these mechanisms and when the concepts are familiar to the application developers). (Note: the Web technologies are also used by smart phone apps -not just for use with Web pages).

I don't want to create the impression that JavaScript will solve all the problems that had been raised in discussion on this list. There is a larger picture, which includes (at least):

#1 Problems with the PKI as used in the Web
(We had briefly spoken about this also at the Paris IAB technical plenary, see http://www.ietf.org/proceedings/83/technical-plenary.html. There is lots of work in the IETF here and there but I do not see the direction where this is going.)
 
#2 Form-based authentication emerged because of the way the lower layer security mechanisms weren't found attractive for many application developers (see a short discussion about this topic in http://tools.ietf.org/html/draft-tschofenig-secure-the-web-03).

#3 The initial authentication needs to be carried across the entire protocol session. Proposals like TLS-OBC seem to be a potential forward. 

#4 Sharing of long-term credentials to allow one site to access protected information of another site

#5 Lack of authentication mechanisms with higher level of security. This includes mechanisms that build on better identity proofing (which is expensive) and multi-factor authentication (which is also expensive since it raises the bar of what you need to possess). The problem there is really the cost of deployment. 

 #6 Data breaches of backend databases
It seems that we see an increase in the last few years but I am not sure whether this is just a side-effect of more transparency due to data breach notification laws all over the place. In general, it would of course be good not to store plaintext passwords (or to have your software be vulnerable to SQL injection attacks) but we will for sure see these types of incidents and information will leak since sites tend to collect more and more information about their customers. I am not sure what is worse - your password gets stolen, your credit card, or your medical records. In any case it is bad. 

(I am sure that some of you could come up with other mechanisms as well.) 

Needless to say that one solution doesn't solve all these problems. The JavaScript CryptAPI can really only help with item #2. #4 is being solved by OAuth. The situation of #6 could (theoretically) be improved by using different credentials and / or in combination of a WebSSO solution. 

I have gotten the impression that many people in the Web community believe that we need to move to WebSSO solutions in order to 
a) reduce the number of sites that run their own authentication infrastructure. The assumption seems to be that fewer (but bigger) players will have more expertise and incentives to secure their authentication infrastructure,  
and 
b) the economies of scale will allow them to introduce authentication mechanisms, stronger credential types, and better identity proofing schemes. 

If you want to read a nice writeup of these types of thoughts then have a look at the NSTIC program, see http://www.nist.gov/nstic/. 

Interestingly, we are moving to those systems already for a while although much slower than some of us had expected and in a different way than initially envisioned. When I started looking at that work in the SAML days everyone was excited about sharing your authentication information with other Web sites (exactly for the single-sign-on experience). Today, we see more a focus on data sharing because the Web with the mashups had required that Web sites focus on a very specific task. try to do that well and get other functions done by other sites. Typically, the data they need is protected (has also to-do with privacy) and therefore requires a security mechanism to be in place to allow secure data sharing (and the consent of the user prior to the sharing). This is where OAuth comes into the picture and sharing of the authentication information is really only an add-on to that. 

On the other hand, these WebSSO and data sharing solutions have various drawbacks as well. In general they require some additional "stuff" beyond the technical protocol exchanges between the relying party and the identity provider for various reasons, including security, privacy, business models, and the lack of interoperability at the application layer.  

Hence, instead of being excited about writing specifications for yet another authentication mechanisms or to find out how to stuff existing authentication frameworks into HTTP I suggest to 
* find out how the bigger picture looks like and what the relationships between the different pieces are, (this may require a one-or two-day workshop) 
* work with the W3C on their CryptoAPI to make sure that it is indeed covering users cases people in the IETF care about (*), and 
* tackle some of the problems listed above. 

Ciao
Hannes

(*) I could imagine that some folks on this list may even want to work on some JavaScript libraries for their favorite authentication protocol so that the Web community does not get it wrong. (Running code and all that...)

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Jul 2012 12:36:17 +0100

On a meta-point, I disagree with you that JS is important
to the argument here. JS is an important language, but not
very relevant for this argument, which I take as being "how
to do better web authentication."

If there are language specific parts to that argument I'd
be interested in knowing what those are. Can you help with
that?

The w3c stuff is of course good, and will hopefully allow
for better implementation of crypto things in JS, so I'm
not against what you're trying to do, but puzzled that you
see JS as a critical part of the discussion.

A few more nitty comments below, but the question above is
my main point here.

On 07/17/2012 11:50 AM, Hannes Tschofenig wrote:
> #2 Form-based authentication emerged because of the way the lower layer security mechanisms weren't found attractive 

I agree. IMO, we ought aim for something that works for both HTTP and
above (e.g. forms). And I think the route to get there, in an IETF
context, is to do HTTP first, then people doing forms can copy that
scheme if its good.

> #3 The initial authentication needs to be carried across the entire protocol session. Proposals like TLS-OBC seem to be a potential forward. 

Right. And/or replicating the OBC trick at the HTTP layer.

> #6 Data breaches of backend databases

This, IMO, is something we have to address. WebSSO and GSS are
not relevant for that part of the work. Replacing password
verifiers with public keys would work if we can do it well
enough. That is not something your average JS developer is
gonna be able to do. (We've failed at it for years;-) So again,
the route to take for me is to figure it out in HTTP first
but so's it can be copied above HTTP.

Cheers,
S.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Jul 2012 15:35:53 +0300

Hi Stephen, 

> see JS as a critical part of the discussion.

Ok. Here is the relationship as I see it. 

If the W3C manages to standardize the API extensions that allow us to access keying material (and potentially offer some of the cryptographic primitives to JavaScript, which would be useful for performance reasons) then service providers can build their authentication protocols as they need them (in JavaScript). They can (at any time!!!) change those mechanisms to offer something better for their users (if the need arises). I cannot stress the importance of this too much because the time it takes to roll out new mechanisms (or even a minor improvement) takes forever with the current software distribution model. 

I hope I was able to explain the power of mobile code properly.
 
> context, is to do HTTP first, then people doing forms can copy that

I believe the right layer isn't HTTP but rather somewhere above it. 

> Right. And/or replicating the OBC trick at the HTTP layer.

Correct. 

> but so's it can be copied above HTTP.

WebSSO should would help if you believe in the idea that fewer big players take better care of your security.

What could help any developer on the Web is to provide libraries that do the complex stuff for them. So, in this case someone with clue would write a good JavaScript authentication protocol library. We have seen this happening, as Yaron mentioned, with JQuery in the UI area. 

There are also other ideas on how to improve the situation. If you look at the recent work in the 3GPP on standardizing software development and security processes  or the idea of regulators to introduce mandatory audits, seals, certification, etc. 

Ciao
Hannes

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Jul 2012 14:09:50 +0100

> I hope I was able to explain the power of mobile code properly.

Ok, so your argument is about downloaded code and not JS
in particular.

I'm not sure I see the huge architectural change though,
seems more like a matter of degree, given that I downloaded
linux, (updated frequently), and firefox and chrome (also
updated frequently). And as far as I know, most JS is not
really per-site, but rather sites re-use bits of JS code
and/or libraries they've gotten elsewhere.

S.

PS: I should probably admit I'm also a happy noscript user,
so I could just be missing some JS stuff:-)

---

From: Sam Hartman <[email-masked]>
Date: Tue, 17 Jul 2012 10:39:36 -0400

I'm with Hannes. There is a huge architectural difference between
allowing the site to control what code you run and allowing the platform
to control what code you run.
The issue is not the frequency of your Firefox updates, but whether site
x can depend on you having a particular update. If site x controls what
code you're running, then they can have much higher confidence you have
a particular feature.
That's true regardless of whether the code ultimately is written by site
x or imported from somewhere else.

There are practical reasons that make this far more true for JS than for
anything else.  I might except that the architectural issue is
site-controlled vs platform-controlled and JS vs other mobile code is a
matter of degree. However the degree is so important that I don't think
the argument worth having.

While I think this web architecture makes it far easier to push out new
mechanisms, I'll note that it has huge security drawbacks as
well. Running your authentication mechanism from a dubiously-trusted
code source has disadvantages.

My current thinking is that JS allows us to make new mechanisms
deployable. They won't actually give us much in the way of security
because we can't actually trust them, but they won't make things
particularly worse than they are today.  If we do it right, I think we
can eventually get security benefits as those same mechanisms make their
way into the platform.  There are many unsolved problems in all this,
especially including the UX issues.

I don't have the energy to build a consensus behind this in the IETF;
I'm happy to write code and if we ever get it working standardize later.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Jul 2012 16:39:33 +0100

> code you're running, then they can have much higher confidence you have

Ok, I can buy that as an architectural difference given that
90+% of clients will run anyone's code.

> site-controlled vs platform-controlled 

Yep. I like that characterisation.

> and JS vs other mobile code is a

Don't get that. Do you mean JS is so ubiquitous that its
ok as shorthand for site-controlled vs platform-controlled?
If so, I didn't get it when Hannes assumed it and am not
sure its really a good shorthand.

> code source has disadvantages.

Right.

S.

---

From: Chris Palmer <[email-masked]>
Date: Tue, 17 Jul 2012 10:13:43 -0700

I am having a hard time following this discussion, because I can't
imagine how JavaScript crypto will help solve the problems. (I do
believe in and understand the problems Hannes raised, of course.) Can
someone (Hannes?) provide a sketch of an example of what a JavaScript
crypto-based solution to the authentication problem would look like?
And explain how this solution will be better than what is currently
available (or at least what is currently possible)?

For example, say a server delivers a blob of JS to the client.
Transmission is over TLS, of course (otherwise, the blob contains code
written by the attacker). The blob uses the browser's support for the
JS crypto APIs to query the browser's database of public/private key
pairs for the server's origin (creating a new pair if none exists, and
registering the public key with the server). Then the JS code proves
to the server that the client has ownership of the private key, thus
authenticating the user transparently and without having to store any
sensitive data (like a poorly hashed password) on the server. Yay!

But, couldn't we get pretty much the same thing client certificates,
possibly with TLS-OBC or some other scheme? Is it better than TLS-SRP?

And then there are all the problems — dealbreakers, AFAICT — raised by
Ptacek and Lawson.

That said, I *can* imagine a way to not need TLS: re-define the web
origin concept by making it the origin be the keypair used to sign the
JS blob. (This is how Android separates code origins, for example.)
Then you could do all security in JS, and presumably somebody would
write The Good Library That Does It Right. But re-defining the web
origin concept is a major undertaking, especially since we finally
defined it (RFC 6454). And especially since in the short and medium
terms, most web sites would find themselves in a default "unsigned"
origin, together with all the others...

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Jul 2012 21:20:39 +0300

Hi Stephen, 

> and/or libraries they've gotten elsewhere.

There is more to that. 

Of course there has always been the possibility to download a native application to your device. I am, however, focusing here on how to accomplish interoperability: I would like to pick a random web browser in two years and connect to a Website of my choice, my identity provider,  and it should be able to run an authentication protocol that this IdP offers with my browser (if I provide my consent). 

This is the way how the location integration into the browser works today for nearly all location-based applications today.   

The difference to the way we had done our standardization work is best illustrated with an example from the RAI area. 

In the RAI area we have been working on SIP for a long, long time and standardized extensions like hell. That took a long time and didn't actually lead to great interoperability (for various reasons, as Jonathan Rosenberg described quite nicely at the Prague IAB technical plenary, see http://www.ietf.org/proceedings/80/slides/plenaryt-5.pdf).

The same is true for XMPP. Lots of standardization was going on in the IETF and in the XSF to reach some level of interoperability between an XMPP client and XMPP servers.  

Now, it turns out that you can also accomplish interoperability in a different way: instead of standardizing every protocol exchange and every protocol element you can as well standardize a language, JavaScript, that is capable enough to build any of these real-time protocol (and many more). 

Of course this language has to provide "extensions" (call them APIs) to connect to hardware (such as microphone, camera, GPS module, ...) so that it can do all the stuff a native application can do but just in an interoperable way. 

Consequently, now we have Websites that send JavaScript to your browser that happens to implement real-time protocols and some folks had for fun replicated SIP, XMPP and other protocols in JavaScript to illustrate it's power. 

I hope that this is a better description. 

Ciao
Hannes

---

From: Sam Hartman <[email-masked]>
Date: Tue, 17 Jul 2012 14:27:17 -0400

>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:

    >> the argument worth having.

    Stephen> Don't get that. Do you mean JS is so ubiquitous that its

No, I mean that JS is the site-controlled solution that works well in
practice.  It's more reliable than Java or Flash or other
site-controlled approaches.  If someone says they're moving to a
site-controlled approach I have less confidence it will actually work
than if they say they are moving to something implemented in JS.  Note
that even with JS there are significant versioning issues. However
everyone has JS.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Jul 2012 21:04:11 +0100

> In the RAI area we have been working on SIP for a long, long time and standardized extensions like hell. That took a long time and didn't actually lead to great interoperability (for various reason…

Yeah. Now that was ironic.

So, ok, its about site-controlled as Sam nicely put it.

I guess that brings us back to Chris' question as to how
that might be done securely.

S.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Jul 2012 14:13:21 -0700

> that might be done securely.

I'm not sure that "that" is that well-defined. What do you believe the
problem statement is here?

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Jul 2012 22:55:59 +0100

> problem statement is here?

Its obviously the inverse of the threat model:-)

S

---

From: Derek Atkins <[email-masked]>
Date: Wed, 18 Jul 2012 09:52:54 -0400

> Its obviously the inverse of the threat model:-)

... which is?

(Yes, I'm being rhetorical here, but I think we do need to be explicit
about what the threat model is in order to have an explicit problem
statement)

There are obvious benefits to a site-controlled approach.  There are
also obvious benefits to a platform-controlled approach.  The benefits
of each are somewhat different, and the drawbacks to each are
different.  Are they necessarily disjoint?

> S

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Ben Laurie <[email-masked]>
Date: Wed, 18 Jul 2012 17:01:39 +0100

> * tackle some of the problems listed above.

On tackling the problems above, I should mention two things:

1. Certificate Transparency - happy to provide more links, but an
overview: http://www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf.
TL;DNR: keep an append-only, public, verifiable log of all certs
issued and use this to detect mis-issuance. CT is s.t. the log does
not have to be trusted.

2. Authentication - the real problem with passwords is not so much
that they are passwords, but that it is completely impossible to
follow the recommended policies (different password for each site,
don't write them down) without assistance. Nigori
(http://www.links.org/files/nigori/) provides a way to store your
passwords centrally without having to trust the store (there's a theme
here). There have been several studies that show that everything we
try to replace passwords with is less good - so why fight it? Why not
fix the underlying problem? Also, of course, once you have such a
central store it is easy to store things like private keys in it
instead of passwords...

---

From: Ben Laurie <[email-masked]>
Date: Wed, 18 Jul 2012 17:03:15 +0100

> available (or at least what is currently possible)?

http://www.browserauth.net/?

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Jul 2012 14:11:37 +0100

>> Its obviously the inverse of the threat model:-)

Sorry, mine was just a flippant take on the "ask for
problem statement"/"ask for threat model" way in which
we mess with folks' heads sometimes.

> different.  Are they necessarily disjoint?

I'd be interested in that analysis too but won't have
time to do it myself.

S.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 23 Jul 2012 21:27:50 -0700

Sorry for jumping in late; I was on vacation...

> sensitive data (like a poorly hashed password) on the server. Yay!

That's a simplified version of what we do for authentication at OneID.
It seems to work pretty well, even with existing JavaScript capabilities
and using local storage for keys and such.
> possibly with TLS-OBC or some other scheme? Is it better than TLS-SRP?

One way I look at it is that a more device-centric authentication scheme
needs to have a really responsive key revocation model.  Yes, that can
be done with certificates but another way is for the JavaScript to be
authenticating in conjunction with (using the term loosely) an IdP that
can confirm validity of the endpoint in real time. JavaScript also gives
us the opportunity to encrypt and decrypt user attributes at the
endpoint, making the "IdP" virtually free of sensitive data in the clear.
> And then there are all the problems — dealbreakers, AFAICT — raised by
Can you give a more specific citation to these?

But one the subject of problems, one of the trickier ones is to ensure
the user is running authentic JavaScript. Getting the code via TLS is a
must, of course, but makes the server(s) sourcing the code a very
attractive attack target.

-Jim

---

From: Chris Palmer <[email-masked]>
Date: Tue, 24 Jul 2012 11:14:05 -0700

> endpoint, making the "IdP" virtually free of sensitive data in the clear.

When the credentials are asymmetric keypairs, credential liveness
checking is possible without the liveness checker needing to have any
sensitive data in the clear. (See e.g. OCSP.) So I still don't see how
JavaScript crypto is strictly better than some alternatives.

> Can you give a more specific citation to these?

http://www.matasano.com/articles/javascript-cryptography/

http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/

> attractive attack target.

Web servers hosting important applications are always attractive
targets. Using TLS does not necessarily make them more attractive.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 24 Jul 2012 17:39:08 -0700

> targets. Using TLS does not necessarily make them more attractive.

Yes, of course.  I didn't mean to say it quite that way.

Thanks for the citations.

-Jim