Skip to content

F
Fenrir_Project

Home

Last edited by Luker
Page history

Fenrir_Logo

Please donate! More money means more time spent on the project!
Donate Donate

Fenrir's aim is to provide a single, efficient and extremely flexible protocol to manage authentication, authorization and encryption in federated environments.

Fenrir is a from-scratch rewrite of transport, authentication, authorization and encryption protocols. The result is an efficient, flexible protocol whose aims are the security and the simplification of both developers' work and the user experience with security.

You can follow news on the development here and on the Fenrir blog

The protocol can handle unicast, Multicast, ordered, unordered, reliable and unreliable transmission, or any combination, with multiple data streams per connection. The federated authentication included grants the interoperability between servers, and introduces the concept of authorization lattice where we can order multiple privilege levels. Finally the whole project does not rely on the certificate authority model, so no X.509 certificates are needed: the keys are derived from DNSSEC.

Check the comparison page for a quick glance.

The whole protocol is designed and developed by Luca Fulchir.

If you need to contact me, just got to #fenrirproject on FreeNode (IRC), use the forum or contact me directly.
If you need it, my gpg key id is: B11CD823BA278C85
Full fingerprint: 7393 DAD2 55BE B575 1DBD A04A B11C D823 BA27 8C85

When ?

Developing is under way. A kickstarter campaign will start as soon as I can get a demo working.

The library is being developed here.

It is still incomplete, Currently the plugin infrastructure works, handshake works, but authentication and flow control are not done yet.

I am not getting paid for this, so the project is progressing slowly. I'd like to make it my work, so if you are interested or have suggestions on it, feel free to write me at luker at fenrirproject.org

Why?

The development of this project seemed necessary due to the Current Auth schemes status and the Requirements that people are normally searching in an authentication protocol.

I was searching for a new protocol to use in other small projects, I obviously wanted something standard, but with as many features and security as possible.

Transport-wise, If a developers wants to handle multiple streams of data, it has to do it by setting up multiple protocol stacks. This is almost as complex as creating a new protocol, so why reinvent the wheel every time, each time differently?

While searching for the right protocol, I worked on a small implementation of OAuth (v1 and v2) for a university class. On this experience I understood what I was searching for with full details, I had a better view of the various qualities of an authentication protocol and I learned to hate OAuth with a passion.

With these premises I looked better for a little-known protocol or something that met my needs, and I could find none. Fenrir is thus the logical conclusion of my learning and searching: a protocol capable of handling cryptography like SSL/TLS, but with much better support for authentication, authorization and federation . Since I was building a new protocol from scratch, I decided to make it very flexible and to integrate all kinds of stuff, you can check the Comparison page if you just want to have a quick look at how it stacks up to other protocols.

How?

For an technical overview of the protocol read this paper that summarizes the design of the protocol.

For an in-depth analysis of the protocol choices, my master thesis (~80 pages) should give you enough to think about.

This protocol will be UDP-based, much like Google is doing with their QUIC protocol In fact, some ideas were taken from both SCTP and QUIC, so we have a full-featured transport protocol that handles cryptography and authentication in a new way.

The transport layer was redesigned It can now handle Multicast, unicast, reliable, unreliable, ordered, unordered, bytestream and datagream streams. In a single connection and less than 30 bytes. Aside from the transport features, the main objective of Fenrir are cryptography and user management.

To better separate the players in our protocol, we define 4 roles:

  • Authentication Server
  • Service
  • Application
  • Client Manager

The names should be self-explanatory, they are similar to the Kerberos ones, and their function is the same, too.

Separating the 4 roles lets us handle everything that is related to security, authentication and authorization so that the application developers will be able to work completely ignoring things like authentication, authorization, passwords, tokens, encryption, and so on.

Authentication Server

This is obviously the server that will do the authentication and manage the user. This is in constant contact with its Service Servers, to communicate them of new client connections. Ideally there will be one authentication server per domain, and all the services and clients will interact with this for authentication.

Thanks to a couple of tricks, the authentication server will not be able to impersonate its clients on any service.

Service

This is your application server. It may be an HTTP server or anything else. It's in constant communication with the Authentication Server and should NOT have access to the client credentials. This means no user password management either. If your authentication server gets hacked, the data in the services is safe. If your service get hacked, nobody has to change passwords!

Application

The application that the user wants to use (browser/mail client, whatever). The developers of this applications will not have to do anything for authentication, or user management. things will get simpler and more flexible.

Client Manager

The manager for your authentications/authorizations. It will connect to the Authentication server to negotiate the access and crypto stuff to let the application communicate directly with a Service.

This will handle all the security details, so that the application does not need to know anything about handshakes, token, or other authentication stuff.

Ideally one of this will run on every device/user. The authentication server will have a complete view of which devices accessed which service, so that the user will be able to check where its accounts have been used, and even block a whole device without changing many passwords.

More details

If you are interested in the low level details, you can look at the following pages:

For anything more, contact me, I'll be happy to explain.

How can I contribute?

In the next few months the code will change a lot. If the Kickstarter campaign is successful enough, I will hire more developers, so check the status of the campaign if you are interested.
A Patreon page has been be set up, too. -- There are no sponsor yet! Want to be a sponsor? Write a mail!

The library code is public, yet unfinished.

To start coding, please look at the Development page.

Some people might think that there will be problems with software patents.
They are not a problem for me.