Current Auth schemes
Here we will take a look at what we can do with the current authentication and encryption schemes.
Please keep in mind our Requirements when reading this page.
Encryption
For obvious reasons we won't take into consideration tunnelling solutions like VPNS or IPSEC.
They are all difficult to set up (from a user point of view) and this just isn't the right use-case for a VPN.
Here we are left with few choices:
SSL- TLS
- DTLS
The fun part is that all these options are not so different one from the other.
TLS is an evolution of SSL, and DTLS is TLS over UDP (very simplified, ok, but you got it).
So there actually is no choice in the matter, which is why attacks like BEAST or CRIME had such a huge impact and made everyone so afraid.
The good news is that these protocols have been thoroughly tested and are considered enough secure by all the experts.
And if you need just the encryption, these are perfectly fine.
But what are the differences?
SSL
SSL is the older one, from version 1.0, 2.0 (both unused and insecure) to 3.0 (insecure, still used).
This protocol supports encryption with a single X.509 certificate, and user identification. Multiple authentication schemes are supported, so passwords or certificates are fine.
As wikipedia puts it, TLS 1.0 is actually better, but its still widely used.
One of the main drawbacks of SSL (aside from the many security problems)is that it does not play nicely with virtual hosts -- that is, trying to have multiple certificates for different domains on the same listening port. Just use TLS.
This protocol has recently been deprecated and is being phased out in favour of TLS
TLS
As the evolution of SSL, it has better key-derivation functions, supports virtual hosts, and has a better general security.
Attacks are recently starting to target TLS, too (POODLE), but the protocol per se seems secure (now).
Still, we have 3 versions of it (1.0, 1.1 and 1.2), and the browser support for the last ones is pretty bad (getting better) :(
DTLS
This is the version used for datagram-oriented connections (as the name implies).
The versions here are the same as in the TLS, and the security is the same.
Over the years some encryption algorithms have been found to be weak or broken, and it's the job of the programmer or the system administrator to know which are the good ones and which are not.
Auth problems
Note that although all these protocols can manage users, those apis are rarely left accessible by an application server to the application.
That is a possible problem with Fenrir, too: its flexibility should encourage application servers to expose the right api calls, but at the moment no naming or API convention is up for that, so we are risking API naming incompatibilities, although applications are usually written for a specific application server, or follow de facto standards (see HTTP webservers).
QUIC & Curvecp & MinimaLT
There area actually some protocols that deserve a page on their own, CurveCP and QUIC.
CurveCP is a nice alternative, but it has (IMHO) some inefficiencies. Doesn't do much for authentication (like TLS, &co) and gives the user a TCP-like stream (no messages/multiple streams like Fenrir).
The author of CurveCP also participated on an other protocol, MinimaLT. You might want to check it out, it has interesting proposals, but is too tightly tied with a single ECC algorithm.
Authentication
Here we group together identification, authorization, accounting and all the stuff you can do on a user.
The most common possibilities right now are:
- SSL/TLS
- OAuth
- Kerberos
- OpenID
SSL/TLS
We already discussed about this. It works, but the main problem is that you can only authenticate before the connection takes place.
And not all application servers then expose apis to get the user id or login.
OAuth
Well, I'm not a fan of this one. Inefficient, with lots of places to screw up your implementation, totally incompatible with other implementations, useless application identification etc...
Still, it can be used. It provides both user identification and (somewhat) authorization. But you need an HTTP client/server on both endpoints.
OpenID-Connect is an authentication protocol and standardization layer on top of OAuth2. An authentication protocol on top of an authentication protocol. I think it tells enough of the story of this protocol framework
Kerberos
Most of you surely know this one, it's a safe and tested (version 5 at least...), standard and federated authentication protocol.
But it requires the client and the server to have synchronized clocks. Which is difficult or impossible on the Internet, and the protocol to synchronize clocks itself is rarely secure.
The good thing is that it's one of the first big token-based protocols, and it made a big and clear distinction between authentication server, service and client. Used in Active Directory.
OpenID
This one is just for user identification.
It's a nice, HTTP-based federated authentication protocol, and the only thing that you need is a url for a webpage.
There are lots of implementation, it's not very efficient, but widely used.
The best combo
Right now the best way to do authentication for your application seems to be TLS + OAuth.
Again, I'm not a huge fan of it, but assuming you have a cryptographer near you that will explain you why your OAuth implementation is hackable, it's usable.
TLS + OAuth means only one reliable connection, having to deal with the HTTP protocol, maintaining passwords and token security, without federation support.
Of course, Fenrir is supposed to solve this mess and half-done protocols and fuse them together :)