Architecture

Everybody is familiar with the usual client-server architecture, and you might have figured out the “authentication server”-“service”-“client” model in Kerberos and OAuth.

Fenrir further splits the roles, simplifying the work each application has to do and increasing the overall security.

But first, let’s have a small recap of the “old” models.

Client-Server

This is simple:

Your application contacts the service it wants to contact, and you are done. Except this turns out to be an overall complicated model: each application now has to reimplement all authentication features, each server has to reimplement its own user database, reimplement security features…

But we have shared libraries, so this didn’t seems like a lot of work.

Still, the big problem is that not all application are well designed, or offer you control over the various features of the underlying protocols. For example, very few let you decide how you want to authenticate. In the end the only usable method is username and password. For every application, for every service.

This is why I ended up having a gpg-encrypted file with around a hundred passwords…

Kerberos-like

So someone though: let’s fix this mess!

Let’s separate the user database from the service, and let’s make it so the user doesn’t have to input the passphrase every time!

So Kerberos was born. I won’t discuss here the limitations of kerberos, and why it has not taken more traction (there are a lot of them, both good and bad), so let’s focus on what it looks like:

Not only kerberos uses this model, and there are a lot of variations, but the main idea is to split the authentication from the application and from the service.

So now when your application wants to authenticate somewhere, it only needs to know where to authenticate. The “Manager” will perform handshakes and data exchange with the authentication server, and will give back a token to the application. The application can now contact the service, and provide the token as proof of being the right user.

The good part of Kerberos-like

• We have taken work away from the application! It doesn’t have to know a lot about handshakes (less things can go wrong)
• We have taken the user database away from the service! If the service gets broken into, the user database and passwords won’t be compromised!
• Authentication servers can talk to each other, so you can use your username also on services not in your domain (the so called federation).

The bad of being kerberos-like

• Kerberos needs clock synchronization. The client and server clocks can NOT be more than 5 minutes apart. This is a big deal for the internet.
• The service still needs to somehow verify the token, which contains signed information from the authentication service. See OAuth to know how much this can fail. But if done right (kerberos) it’s ok.
• The application still gets the token, has to keep it safe, refresh it every some time (tokens do expire)… we have not taken away the management of user authorization
• It is a layer above the transport, meaning it’s independent, so a lot of servers just don’t bother implementing it.

But Those are not bad drawbacks, and that’s why kerberos is still used a lot today (think Active Directory from Microsoft)

OAuth

Then came the era of the web. Everything needs to be on the web.

So someone thought: let’s bring a kerberos-like infrastructure to the web! …and an hideous monster was born. I know, technically Fenrir could be seen as a monster (huge, talking wolf?), but we are talking about blobfish level of ugliness here.

I have kind of a personal hate toward OAuth, in both of its versions (version 2 is the worst, btw), but let’s see what they did:

This is only the theory behind OAuth, or merely its potential. In practice the actual model is a client-server one, and all advantages are lost.

Following the picture, you see that it looks a lot like the kerberos model, but the differences are subtle. First of all, each passage between application, browser and service is handled with HTTP, and redirects. It’s a normal HTTP(S) redirect. I have to write HTTP(S) because all the specifications put this little thing, TLS, as optional. Guess what happens if you don’t use it?…

The first thing you might notice is that in the kerberos model the authentication server and the service where two distinct entities, while here I have blurred the difference. The reason for this is that since everything is handled by HTTP, and thus web pages, everyone just implements the authentication pages in the same code as their services, and serves them with the same webserver. This is not technically bad, but we have introduced the authentication service complexity to separate the user database from the service, so why can we bundle everything together again? Oh, but you are supposed to keep things separate! Go look at what every application does, even enterprise ones.

Your application can not open the authentication server page by itself. Well, technically there’s nothing stopping you from doing so (read: half of mobile apps), but you have to use the user’s browser. Why? Because its safe. I mean, it’s not like they have a huge plugin infrastructure, browsers surely don’t have to parse different versions of atrocius XML, right? WhatCouldPossiblyGoWrong?

Of course, even with a safe browser, there are things like transparent windows that can be put on top of the browser, stealing the user password (again, lots of mobile apps did this some years ago).

Anyway, now we go to our browser, log in, and we get redirected to our application Oh, nice, now my application needs a webserver! So much for simplicity.

Finally, our application gets the token from that last redirect, and can use that to identify itself to the service. In theory the application can cache the token, and does not have to ask for the user password again.

This still sounds somehow good, except for the atrocious number of ways to do this (OAuth2 was declassified from protocol to framework for this), and for the fact that no one uses a different 2nd server. No password-database/service separation.

And mobile applications load their own browser to avoid dealing with user browsers annoyances, or to avoid the need for webservers.

So we have a big infrastructure that shows promise, but gets cut down to the old client-server model. All that complexity for nothing.

And it’s not even portable. To the point where you need to rewrite a part of the authentication for each service you want to log into.

I am still baffled every time I see this framework around

The Fenrir Way

Ok, the OAuth part might have been longer than necessary, but I wanted to show at least the tip of the iceberg of what can go wrong.

In Fenrir, we are back to a Kerberos-like model, but it’s a simplified one:

There are subtle differences that mean a lot:

• The application never has to hold on to a token. It only receives a connection id and the encryption keys. Only the “Manager” holds the authentication information. The only thing the application has to remember (and ask to the user) is with which user name to login.
• There is no clock synchronization. This adds one more check between the Service and the Authentication Server, but avoids a lot of problems (especially in embedded systems, where clock is always at 1970…)
• The service does not have to verify anything anymore. When a client authenticates successfully, it will receive a message from the authentication server saying that a new client, with a certain connection id and some encryption key is connecting. And that’s it. Even the Service got simpler
• Since the Manager still has a connection to the various authentication servers, it can decide to drop the connection, in case you want to be sure that an application is not misbehaving (do you really trust all that stuff on your phone?)
• Each authentication server can control one (or multiple) domain(s). The federation is still intact, so when you authenticate to an other domain, that authentication service will check your token with your own authentication server to be sure it’s really you.

Plus a new, shiny introduction: The Authorization Lattice

Authorization Lattice

Until now, each session was associated to a username, and that was it.

What would happen if we were to tie each session also to the device, to the application and to the user authorization? And what if all of this didn’t require any big change in the application’s code? Or difficulty in managing all the authorizations from the user perspective?

That is Fenrir.

But first, you need to know what an authorization is, and what an authorization lattice is. No big deal, a single image and you’ll understand it:

An authorization in this case is what the user can do with his/her session. The symbol at the top represents all authorization that is, you can do everything. Then you go down, ‘till you reach bottom, the no authorizations point.

Now, things should start making sense. Each session is identified by its token. Each token represents the user, works only on that device, and represents a single authorization.

Tokens are also kinda special. They can be restricted (but not given more scope). This means that the Manager on your device might have a token for a service with “write” permission. But let’s say you don’t trust that much an application running on your device. You can just give the application a “read” authorization, without additional messages to get the right token from the authentication service.

Your application doesn’t need to be designed to handle all of this. The Manager will. Again, your application only receives the encryption keys, nothing more.

The lattice will be transferred between the Manager and the Authentication Aervers, and is tied to a specific service, but it is also limited in size to 64 nodes, so less then 3kb (2 packets).

Of course, the Lattice is an advanced feature for paranoid users (like me?). You are not forced to understand it or use it, but having it introduces a hell of a lot of possibilities.

Imagine being able to transfer a token to a friend, but limiting that token to read access, and then deleting his access after some time, ‘cause you trust him, but not too much… Or being completely secure in checking your bank account on your phone, because it only has read access, and can’t do anything else. Could you do it before? Now you can :)

There are a lot of little things that this model lets you do, especially in controlling what your not-so-trusted applications are doing. Now you have the basic information on how Fenrir works and why, and a general idea of where the project is headed.

-Luker