Skip to content

Home · Changes

Page history
Main page authored by Luker's avatar Luker
Hide whitespace changes
Inline Side-by-side
home.md
View page @ af413cff
......@@ -4,26 +4,23 @@
**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.
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.
Its aim is to replace SSL/TLS, Kerberos, OAuth and basically any other encryption or authentication scheme.
You can follow news on the development here and on **[the Fenrir blog](https://www.fenrirproject.org/blog)**
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
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](https://www.fenrirproject.org/Fenrir/Fenrir_Project/wikis/Federation_Details#introducing-the-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](X.509) certificates are needed: the keys are derived from DNSSEC.
You can follow its development here and on **[the Fenrir blog](https://www.fenrirproject.org/blog)**
Check the [comparison](Comparison) page for a quick glance.
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.
The whole protocol is designed and developed by [Luca Fulchir](Luca_Fulchir).
If you need to contact me, just got to **#fenrirproject** on FreeNode (IRC), use the forum or [contact me](Development#contacts) directly. If you need it, my gpg key id is: **F61F6137** (I change it every year)
Full fingerprint: **95EB 6FA4 03D7 29A7 13C2 FC9F F85A DA1C F61F 6137**
## When ?
Developing is under way. A kickstarter campaign will start soon.
Developing is under way. A kickstarter campaign will start at the end of this week.
I have finished University and am trying to make this project my work.
The library is being developed [here](https://www.fenrirproject.org/Fenrir/libFenrir).
......@@ -36,7 +33,9 @@ The development of this project seemed necessary due to the [Current Auth scheme
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.
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](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.
......@@ -46,42 +45,52 @@ There is also a quick [Comparison](Comparison) page if you just want to have a q
For an technical overview of the protocol read this
[paper](https://www.fenrirproject.org/Fenrir/Fenrir_Project/uploads/504146146b8bbd21e0b1d4c40957c825/paper.pdf)
that tracks the design of the protocol.
that summarizes the design of the protocol.
For an in-depth analysis of the protocol choices, my [master thesis](https://www.fenrirproject.org/Fenrir/Thesis/wikis/home) should give you enough to think about.
For an in-depth analysis of the protocol choices, my [master thesis](https://www.fenrirproject.org/Fenrir/Thesis/wikis/home) (~80 pages) should give you enough to think about.
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.
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](Packet_Structure) 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 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:
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.
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 Server
### 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 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 want to use (browser/mail client, whatever).
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 and then communicate directly with a Service Server.
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
You can find more details in the authentication mechanism on the [Fenrir Details](Fenrir_Details) page, and then have a look at the [packet structure](Packet_Structure).
......@@ -93,7 +102,7 @@ If you are interested in the low level details, you can look at the following pa
## How can I contribute?
For now, I am only looking for comments on theory and design. Around April the code should be a bit more stable, and you might want to look at the code and start contributing. If the Kickstarter campaign is successful enough, I will hire more developers, so check the status of the campaign if you are interested.
In the next few months the code will change a lot, It will take up until around May for it to stabilize a bit. If the Kickstarter campaign is successful enough, I will hire more developers, so check the status of the campaign if you are interested.
The [library code](https://www.fenrirproject.org/Fenrir/libFenrir) is public, yet unfinished.
......@@ -101,3 +110,4 @@ 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.
----
\ No newline at end of file