|
|
|
# 
|
|
|
|
|
|
|
|
----
|
|
|
|
|
|
|
|
[Fenrir](Fenrir)'s aim is to provide a single, efficient and extremely flexible protocol to manage authentication, authorization and encryption in [federated](Federated_vs_Distributed) environments.
|
|
|
|
|
|
|
|
It mimics a lot SCTP or QUIC in terms of transport features, with both reliable and unreliable transmission, but it also includes encryption, [federated](Federated_vs_Distributed) authentication, and a lot of other features, such as cross-domain single sign-on.
|
|
|
|
|
|
|
|
Its aim is to replace SSL/TLS, Kerberos, OAuth and basically any other encryption or authentication scheme.
|
|
|
|
|
|
|
|
While I was at it, I decided to implement a recent Forward Error Correction library, and release it. project:[libraptorq](https://www.fenrirproject.org/Luker/libRaptorQ/wikis/home) will be used in the Fenrir Project
|
|
|
|
|
|
|
|
You can follow its development here and on **[the Fenrir blog](https://www.fenrirproject.org/blog)**
|
|
|
|
|
|
|
|
It does NOT use TLS for encryption, and doesn't use the bulky X.509 certificates. The trust of the system is derived from DNSSEC, which is used to get all the information and the public keys.
|
|
|
|
|
|
|
|
Advanced features for account management will be included, such as per-device account management, and user authorization.
|
|
|
|
|
|
|
|
The whole protocol is designed and developed by me, [Luca Fulchir](Luca_Fulchir), an Italian university student.
|
|
|
|
|
|
|
|
If you need to contact me, just got to **#fenrirproject** on FreeNode (IRC), use the forum or [contact me](Contacts) directly. If you need it, my gpg key id is: **D42DDF0A** (I change it every year)
|
|
|
|
Full fingerprint: **AB35 E45F 5CA5 E35B 8B55 818F 0157 D133 D42D DF0A**
|
|
|
|
|
|
|
|
## When ?
|
|
|
|
|
|
|
|
I'm still developing it all. Things can be complex, and I am finishing University.
|
|
|
|
|
|
|
|
The library is being developed [here](https://www.fenrirproject.org/Fenrir/libFenrir).
|
|
|
|
|
|
|
|
It is still incomplete, but I am working towards a demo for now.
|
|
|
|
|
|
|
|
Since I have to graduate in December, I'll better have something ready for then, though ;)
|
|
|
|
|
|
|
|
## Why?
|
|
|
|
|
|
|
|
The development of this project seemed necessary due to the [Current Auth schemes](Current_Auth_Schemes) status and the [Requirements](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.
|
|
|
|
|
|
|
|
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 learned [what I was searching for](Requirements) with full details, I had a better view of the various qualities of an authentication protocol and I learned to [hate OAuth](OAuth Hate) 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](Federated_vs_Distributed) . 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 [Featues](Features) page for a list.
|
|
|
|
|
|
|
|
There is also a quick [Comparison](Comparison) page if you just want to have a quick look at how it stacks up to other protocols.
|
|
|
|
|
|
|
|
## How?
|
|
|
|
|
|
|
|
See the [History](History) to know a little of how the Fenrir protocol was designed.
|
|
|
|
|
|
|
|
This protocol will be UDP-based, much like Google is doing with their [QUIC](QUIC) protocol
|
|
|
|
In fact, a lot of 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. If it was not for the inclusion of a new authentication/authorization/cryptography mechanism, Fenrir would be too similar to google's QUIC.
|
|
|
|
|
|
|
|
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 3 roles:
|
|
|
|
* Authentication Server
|
|
|
|
* Service Server
|
|
|
|
* Client
|
|
|
|
|
|
|
|
The names should be self-explanatory, they are the same as in Kerberos, and their function is the same, too:
|
|
|
|
|
|
|
|
### 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.
|
|
|
|
|
|
|
|
### Service Server
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
### Client
|
|
|
|
|
|
|
|
Your computer, or program. It will connect to the Authentication server to negotiate the access and crypto stuff and then communicate directly with a Service Server.
|
|
|
|
|
|
|
|
### More details
|
|
|
|
|
|
|
|
You can find more details in the authentication mechanism on the [[Fenrir_Details]] page, and then have a look at the [[Packet_Structure]].
|
|
|
|
|
|
|
|
If you are interested in the low level details, you can look at the following pages:
|
|
|
|
* [DNSSEC Details](DNSSEC_Details): details of the data in the DNSSEC query/response.
|
|
|
|
* [Auth_Details](Auth_Details): details on the connection establishment.
|
|
|
|
* [Federation Details](Federation_Details): details on the federated details.
|
|
|
|
|
|
|
|
## How can I contribute?
|
|
|
|
|
|
|
|
Right now, please just analyze, think, comment, and ask questions. I'm still waiting for people's opinion on the protocol and design choices in general.
|
|
|
|
|
|
|
|
The [library code](https://www.fenrirproject.org/Fenrir/libFenrir) is public, yet unfinished.
|
|
|
|
|
|
|
|
To start coding, please look at the [Development](Development) page.
|
|
|
|
|
|
|
|
Some people might think that there will be problems with software patents. [My position](Software_Patents) on how to deal with those cases is already well defined.
|
|
|
|
|
