When it comes to secure authentication, the web
is in a much worse shape than email. But that's
not due to email; it is the web that habitually
ignores all the advances that are used everywhere
else! Since the web is important, we want to extend
HTTP with SASL, the general framework that works so
well for almost all the other protocols.
You have heard us complain about the lack of security and identity support on websites. The reason has perhaps been gradual progress without a clear direction. This is why projects like our InternetWide Architecture, with explicit design, can make a leap forward.
Authentication at the TLS or HTTP levels is the best option, because it eliminates the context of JavaScript, that also runs code from arbitrary sources. Also, application developers are not necessarily security experts.
HTTP however, is still recovering from the original authentication with weak methods. Some have overruled it in JavaScript, where some aspects of the weakness of passwords could be compensated by guiding users towards slightly better passwords. But once in JavaScript, the chances of stronger security mechanisms (like SCRAM) is gone.
We can complain all we like, but the InternetWide Architecture intends to untie such knots. So here we go.
SASL can Connect Everything
We propose to introduce SASL into HTTP. SASL is already part of many everyday protocols, such as IMAP, SMTP, POP3, LDAP, XMPP, AMQP and countless other -- even low-profile chat with IRC uses SASL!
SASL is a little more difficult to get into than a simple password, but that is due to its strengths:
- SASL can be built into any protocol
- SASL can carry any authentication algorithm
The specification shows this in the following ASCII-art drawing:
SMTP LDAP XMPP Other protocols ...
\ | | /
\ | | /
SASL abstraction layer
/ | | \
/ | | \
EXTERNAL GSSAPI PLAIN Other mechanisms ...
Think of SASL as standardised piping; the protocol side defines what hooks and bolts are needed to mount it, and the mechanism side defines an inner lining for the piping to which mechanisms can be matched for easy passing.
Genericity towards protocols means that not every protocol developer needs to invent a mechanism for user names and passwords; instead he can grab on SASL library and pass the messages through his protocols. For web applications this is evey simpler; web applications run on top of a protocol, and the SASL can be implemented at the HTTP and TLS layers and served to the application through environment variables.
Genericity towards authentication mechanisms means that new ones can be incorporated silently, without knowledge to the application programmer. The plethora of independently developed applications have been holding back the deployment of better schemes, which is why the web is still rife with password authentication, in spite of all security advise discrediting it.
Today, every application programmer starts off with a simple system based on passwords "just to get started" but never finds the time to move away from it -- there are always more pressing concerns in the application. This is precisely why it is a good reason to separate the concerns and simply follow the security offered by the HTTP and TLS layers.
SASL mechanisms are identified by standardised names. The requirements of a corporation might call for GS2-KRB5-PLUS or SAML20, but these are difficult and it is a hard call convincing application developers to support it. When authentication is handled at the HTTP and TLS layers, the dependency on a wide variety of application developers is gone; it is more realistic to convince parties producing generic software, such as web servers and web middleware.
Towards mechanisms, SASL defines how they can pass messages back and forth. This is not of influence on a design of HTTP SASL.
Towards protocols, SASL defines what kind of messages they should pass. It is up to the protocol how to fit this into the rest of the protocol flow. This is what needs to be handled by an HTTP embedding of SASL.
Introducing SASL for HTTP
Given these properties, we though it would be a good idea to introduce HTTP SASL in the most general manner possible, that is, as a specification for the Internet Engineering Task Force.
We are currently trying out these ideas by coding them into a proof of concept, and supporting it in other software:
- A browser plugin that answers to HTTP SASL challenges, cleverly incorporating a desktop application to enable controlled access to local authentication infrastructure such as Kerberos;
- An Apache module that will implement not just HTTP SASL, but also the other aspects of our identity model;
- A demo servlet that runs its demonstration as part of a Java Tomcat webserver and that responds with HTTP SASL authentication requests;
- WSGI middleware that demonstrates how HTTP SASL can be a layer that can mount on any WSGI service;
- Docker demos for these components will likely follow too; for now, FireFox with SASL can be tried; the Apache modules also aim to incorporate SASL.
Not all this work is done, and there is certainly a lot more that can be done. This is an open source project, and you are welcome to join our ranks if you would like to see this evolve!
The pleasant thing is that it all works in HTTP headers, so:
- No mixing of credentials and dynamically loaded extensions and advertisements in the same name space;
- Application programmers need not concern themselves with authentication;
- Authentication mechanisms can be configured by website administrators;
- A growth path for ever-improving security has been plotted.
Diving In: Message Flows
For those who are interested in seeing the technology working, this section gives an example of the message flow of HTTP SASL. Others are welcome to skip ahead for a last surprise.
When a website is asked for a protected page, it will ask for authentication with a special status code 401 (for proxy access that would be 407, same story but different names). Stripped down to the bare essentials, we get
HTTP/1.1 401 Unauthorized
WWW-Authenticate: SASL
realm="members only"
mech="SCRAM-SHA-256 SCRAM-SHA-256-PLUS
SCRAM-SHA-1 SCRAM-SHA-1-PLUS
GS2-KRB5-PLUS GS2-KRB5"
(This post adds spacing and line breaks for readability)
From the looks of it, this is a very secure server! And why not, given that the SASL mechanisms are available and all behave the same? And so, this server offers SCRAM-* mechanisms, a tick-tock pattern where both client and server prove knowledge of the password, and GS2-KRB5 which is a very pleasant Kerberos single-signon authentication. The variants with -PLUS provide additional channel binding, to ensure that authentication is specific to the current HTTPS connection.
The client sees this and decides it has a few options to choose from. Since the mechanism names are standard, it can recognise them and pick out the ones it supports. Perhaps the user also added constraints.
Let's say the user has no setup with single sign-on, so it will have to be a password. SCRAM is a pretty good way of doing that if you have to, so that is selected. There are variants based on the SHA-1 and SHA-256 hashes, of which the latter is more secure. And if the browser gives access to TLS information, it is even possible to incorporate that; the browser therefore selects SCRAM-SHA-256-PLUS.
This mechanism is initiated by the client, so the first message already does something active:
Authorization: SASL
realm="members only"
mech="SCRAM-SHA-256-PLUS"
c2s=[n,,n=user,r=rOprNGfwEbeRWgbNEkqO]
(Square brackets denote base64-encoded content)
We can see the choice of authentication being made with SASL, we can see the mech having been reduced to a single option, and the realm being repeated for the server's reference. Then there is the client-to-server parameter named c2s holding things specific to the mechanism. It doesn't matter what that means exactly; the general idea is that it is taken care of by the SASL mechanism and not a concern to HTTP SASL.
The server checks with its SCRAM mechanism implementation, which decideds to go for another round and so the server sends an update:
HTTP/1.1 401 Unauthorized
WWW-Authentication: SASL
s2c=[r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxF
Ilj)hNlF$k0,s=W22ZaJ0SNY7soEsUEjb6gQ==,
i=4096]
s2s=[xxxxx]
The parameter s2c, as you probably guessed, means server-to-client. The other parameter s2s may be a bit of a surprise; it contains server state that must be replicated by the client in continued messages. This is a requirement for all HTTP authentication mechanisms, and it helps to keep the server lenient.
The client makes an effort to continue the computation. The fact that it takes a few tick-tocks is precisely what the SCRAM mechanism prescribes, and it is necessary in all SASL protocols to allow the number of exchanges needed before the mechanism can come to a conclusion. So the client scratches its head, thinks hard about its password and decides
Authorization: SASL
c2s=[c=biws,r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2Ra
TCAfuxFIlj)hNlF$k0,p=dHzbZapWIk4jUhN+Ute9
ytag9zjfMHgsqmmiz7AndVQ=]
s2s=[xxxxx]
The c2s is funny as always; in a PLAIN mechanism this sort of message would hold a readable password, but such replayable credentials are what we hope to avoid by using SCRAM instead. The s2s bounces back the literal text had from the server, as required. This seems to put the server in a good mood, and it finally decides on
HTTP/1.1 200 OK
WWW-Authentication: SASL
s2c=[v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsj
l95G4=]
s2s=[zzz]
A redirect would also be an option, allowing client judgement.
The server is happy, and the s2c part is the final step to also make the client happy. If that is the case, the positive response can be used for client access to the website.
The fact that an s2s parameter is included in the positive response may come unexpected, but it is very useful. This s2s parameter is the client's hold on future access to the members only realm. For the remainder of our session, or if ever the server wants us to authenticate to the members only realm, we can respond by simply including the following header in the request:
Authorization: SASL
realm="members only"
s2s=[zzz]
The server still has an option to refuse this and forcing us into a new authentication round. One reason for this could be that a session timed out. If that happens, another round of SCRAM would be started. Or perhaps the users understands that it need not type passwords all the time, and better setup Kerberos.
Microsoft Friendly
We don't talk about Microsoft a lot in the world of open source and open protocols. Still, it is good to know that the HTTP SASL mechanism is very useful to that group of users.
Corporate domains often use Active Directory which is a fixed combination of Kerberos with LDAP and a few other protocols. Users in those domains have tickets that they can use in all Kerberos applications. (There are independent Kerberos stacks for Windows too, of course.)
The HTTP SASL mechanism allows better integration of Kerberos with the web than the current option, HTTP Negotiate. This option is considered only moderately secure. Specifically the option GS2-KRB5-PLUS can help to improve the security of access to web sites based on single sign-on. This is an often-heard requirement.
We probably will not develop dedicated plugins for the Windows platforms, but others might. The best economic model is sharing work once it has been done, so we hope to find one or two back on open source platforms, as a sign of gratitude to solving this big problem.
Passwords are back?!?
SASL supports password authentication. But don't take our support for SASL the wrong way -- passwords are detrimental to online security and must go as soon as possible. But this will not be an instant change, and a transition path that can support old and good habits at the same time allows each user to change at their own pace. HTTP SASL offers precisely that option, and precisely where it hurts most.
Current HTTP authentication is beyond hope: It has always been poor, the responsibility is dispersed over many incompatible home-grown code pieces, and so it is unmanageable -- and it is not changing a bit. Or have you encountered the HTTP headers for SCRAM authentication in the wild? It was published in 2010, so by now it should be commonplace, right? But we are waiting for application developers to pick it up. And every application that does move to a better mechanism is outcrowded by ten new applications that begin all over and re-invent the worst mechanism way "for now" and get away with it -- because everyone is still doing it so poorly.
Separation of authentication from application can free us from waiting for application developers to introduce better security. And it is in everybody's interest because it assigns the most suitable programmers to each task. And what we really need to move forward is an authentication approach that can grow with time and the individual maturity of their users.
Gold and Silver Paths
We consider the use of SASL as the "silver path" towards the InternetWide Mission and that certainly includes its use in HTTP. The use of a browser extension makes it possible for any user to step up to the system. In addition, native messaging allows for access to credentials on the desktop, such as password managers and today's Kerberos session.
We believe that the "golden path" for the InternetWide Architecture continues to be
TLS-KDH
with SASL mechanism EXTERNAL to fetch identities.
The addition of
KXOVER
allows connections everywhere. The reason that we say this path is better is manyfold:
- TLS-KDH protects against Quantum Computers;
- Kerberos is a single sign-on system; the user will benefit with simpler security;
- Kerberos is an promising combination with mobile platforms, such as smart phones;
- The TLS-KDH protocol authenticates hundreds to tens of thousands times faster than public-key based TLS;
- once established, realm crossover (KXOVER) can hold for weeks, effectively caching the crossover connection;
- Kerberos tickets can cache information for improved efficiency.
We do still have work to do; TLS-KDH is not a formal specification yet, and still underway in TLS stacks; KXOVER is being implemented to make it more scalable than the proof of concept; KXOVER waits for consensus about public-key algorithms for key agreement that protect against Quanum Computing.
Go Top