Also see the user workflows and components.
Contents
LDAP Demo
We would like to have an memorable and interactive demo on a fully-free system ready by October, 2015 or January, 2016.
- memorable
The demo needs to showcase an interesting arrangement or combination of technologies that the FreedomBox supports.
- interactive
- The audience can participate with and operate on the running system.
- fully-free
- The system will be created from fully-free components, at the software, firmware, and hardware level:
- software
- The system will use only the Debian-main archive.
- firmware
The system will not include any binary blobs in any drivers, and none will be needed to use the fully functional system. See GNU linux-libre.
- hardware
The system will use freely-designed hardware, that which the four fundamental software freedoms can be applied to.
Making it Memorable
To be memorable, the demo should do something that no demo has done before. Right now, in June 2015, the FreedomBox project is pretty close to accomplishing something completely new: making PGP-based client certificate authentication easy.
To do this, the server needs to be able to:
1. identify specific users in an HTTP-session based on PGP keys, 2. authorize or deny specific users in an HTTP-session based on a centralized service authorization system, and, 3. configure the available services and authorized users in a centralized service configuration system.
To do this, the client needs to be able to:
1. log in to the server with a client certificate.
If the server and client can do those things, we've made HTTP client certificates possible, but not easy. To make HTTP client certificates easy, (1) the server must be able to provide clients with SSL Client Certificates based on their PGP keys, and (2) the client must be able to import the SSL Client Certificate from the server.
Since the SSL client certificate is self-validating, the client can verify that the server isn't deceiving it (the client certificate must refer back to the client's original PGP key). Otherwise, this doesn't affect the standard PGP trust-model at all: in the standard PGP threat-model, anyone can already create a key for anybody, anyway.
Making it Interactive
To be interactive, users need to be able to log into the system and use the service. Users should be able to interact with one another, like in a chatroom.
If we were to make a presentation where Debian Developers, or anyone in the strongly trusted set of PGP keys, could automatically log into a service as themselves and communicate, that'd be pretty memorable. We could do that through a few services, like Jabber (ejabberd server and jwchat web UI), ownCloud, ikiwiki, or others.
To do this, each service on the box must use the client certificate's user identifier as the user's service id, and must defer to the box's centralized authorization layer to determine whether that user can access that service or not.
Getting from Here to There
To be ready for the demo, the system must import the keys of pre-authorized users, those users must download and install their PGP-SSL-client-certificate from the server, available over the demo's LAN. Users will then connect to the server, be automatically logged in through their client certificate, and access any of the available services.
Capabilities
At a high level, the server and client need to be able to perform these duties.
Server
Client Certificate Identification (Authentication)
Client Authorization
Administrative Service Access Control Layer (ACL)
PGP Key Generation
PGP SSL Client Certificate Generation
Client
Client Certificate Identification
The UI sucks, but any standard desktop browser can already import a client certificate and use it to authorize to a server, including:
- Firefox/Debian Ice Weasel/GNU Ice Cat - Chrome - Internet Explorer
Client Certificate Keyring Import
To make Client Certificate Identification easy, we should release an extension that handles importing and trusting the user's client certificate for the user.
Necessary Tools & Services
We need these items for the demo, but they do not yet exist.
Apache Client Certificate Identification
Apache will read the SSL client certificate id to supply the necessary Client Certificate Identification (Authentication).
LDAP Authorization
LDAP will manage client authorization to allow or deny the client access to the service. See the wiki's notes for further details.
Plinth Centralized Service ACL
Plinth will handle user-service access (authorization).
Plinth PGP-Key and PGP-SSL-Client-Certificate Creation
Plinth will manage PGP Key Generation and PGP SSL Client Certificate Generation. When a user without a client certificate connects to the server, they'll be directed to the key generation tools
The PGP key generation tools should be disabled during the demo because they could easily overwhelm the server.
Client Certificate Keyring Import Extension
A Firefox extension will manage Client Certificate Keyring Import.
Additional Interactive Services
To round out the demo, we should add more services that users can experiment with. Right now, we have Jabber (JWChat and ejabberd) and file hosting (ownCloud). Those are good, but more would be good.
Intro |
Information |
Support |
Contribute |
Reports |
Promote |
|
|
|
|||||
|
|
|
HELP & DISCUSSIONS: Discussion Forum - Matrix - Mailing List - #freedombox irc.debian.org | CONTACT Foundation | JOIN Project
Next call: Sunday, March 24 at 17:00 UTC
This page is copyright its contributors and is licensed under the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.