Differences between revisions 1 and 2
Revision 1 as of 2015-06-28 20:20:09
Size: 6019
Editor: ?NickDaly
Comment: Created page.
Revision 2 as of 2015-06-28 21:45:05
Size: 11755
Editor: ?NickDaly
Comment: Added workflows
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
= LDAP Demo Notes = = LDAP Demo =
Line 14: Line 14:
= Making it Memorable = == Making it Memorable ==
Line 32: Line 32:
= Making it Interactive = == Making it Interactive ==
Line 40: Line 40:
= Getting from Here to There = == Getting from Here to There ==
Line 44: Line 44:
== Capabilities == === Capabilities ===
Line 48: Line 48:
=== 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 ====
==== 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 =====
Line 70: Line 70:
==== Client Certificate Keyring Import ==== ===== Client Certificate Keyring Import =====
Line 74: Line 74:
== Necessary Tools & Services == === Necessary Tools & Services ===
Line 78: Line 78:
=== Apache Client Certificate Identification === ==== Apache Client Certificate Identification ====
Line 82: Line 82:
=== LDAP Authorization === ==== LDAP Authorization ====
Line 86: Line 86:
=== Plinth Centralized Service ACL === ==== Plinth Centralized Service ACL ====
Line 90: Line 90:
=== Plinth PGP-Key and PGP-SSL-Client-Certificate Creation === ==== Plinth PGP-Key and PGP-SSL-Client-Certificate Creation ====
Line 96: Line 96:
=== Client Certificate Keyring Import Extension === ==== Client Certificate Keyring Import Extension ====
Line 100: Line 100:
=== Additional Interactive Services === ==== Additional Interactive Services ====
Line 103: Line 103:

= Workflows =

== Goals ==

The FreedomBox is both a system that provides services for others and a router that protects its user's communications.

=== As a Server ===

(By default)

 1. Users can connect to their FreedomBox's services with client certificates:
   1. On their desktop's browser.
   2. On their mobile device.
 2. Administrators can selectively authorize (local and remote) users for services hosted on the box.

=== As a Router ===

(By default)

1. Communications that don't have to leave the box, won't.
2. The box will route all external connections through privacy-enhancing and anonymizing tools.

== Configured User Sends FBX a Service Request ==

{{{
  +-------------+ +-------------+
  | User Agent | | Service |
  | | | |
  | |<-----+ |
  | | 6 | |
  | | | |
  +----------+--+ +-------------+
           1 | ^
             | | 5
             | +-------------+-------------+
             | | Web Server | LDAP |
             +-------->| 2,3 -+> |
                       | | |
                       | <+- 4 |
                       | | |
                       +-------------+-------------+
}}}

 1. Browser sends request to FBX.
 1. Web server receives request, authenticates user's key id. Web server 401s user if no key.
 1. Web server requests LDAP authorizes user's key.
 1. LDAP informs web server of its decision. Web server 403s user if LDAP doesn't authorize.
 1. Having been authenticated and authorized, web server passes request on to service.
 1. Service processes request, using key id as user id and replies to user.

== Configuring New Users ==

{{{
  +-------------+ +-------------+
  | User Agent | | Hello |
  | | | |
  | |<-----+ |
  | | 4 | |
  | | | |
  +----------+--+ +-------------+
           1 | ^
             | | 3
             | +-------------+-------------+
             | | Web Server | LDAP |
             +-------->| -+> |
                       | 2 | |
                       | <+- |
                       | | |
                       +-------------+-------------+
}}}

 1. User requests ''Hello service''.
 1. Web server checks with LDAP to see if user without key (Nobody) is authorized for Hello right now.
 1. The Hello service begins by de-authorizing Nobody*, then it creates a PGP key, signs it with the box's key, and fully trusts the key. That key is then exported as an SSL certificate.
 1. The user-agent receives the key and the SSL certificate. It installs the certificate into the local store. The user can now access the system per the [[#Configured User Sends FBX a Service Request|Configured User Sends FBX a Service Request]] workflow.

== Box-to-Box Service Location Updates ==

{{{
  +--------------+
  | Freedombuddy |
  | | 3
  | |<------------+
  | | |
  | | |
  +----------+---+ |
           1 | |
             | 2 |
             | +-------+------+
             | | FreedomBuddy |
             +-------->| |
                       | |
                       | |
                       | |
                       +--------------+
}}}

 1. A sends location request to B's ''FBuddy service''.
 1. B replies with updated locations to A's FBuddy.
 1. A records updates.

== Key Exchange / Introduction Process Between Users ==

{{{
  +-------------+ +--------------+
  | User Agent +-------->| FreedomBuddy |
  | | 1 | 2 |
  | | | |
  | |<--------+ |
  | | 3 | |
  +-------------+ +--------------+
}}}

 1. User A sends identity and service locations in a self-signed statement to User B.
 1. User B verifies signed statement. Imports identity and service locations if all is well.
 1. User B replies to destination A just defined to inform A of identity and (optionally) provide A services.

== Teaching Client About Box's Services ==

== FBX-App Connecting to Box's Services ==

== User Telling FBX-App to Connect to Local Box's Services ==

== User Telling FBX-App to Connect to Remote Box's Services ==

== Enabling New Service ==

 1. User selects service-to-enable in ''Plinth''.
 1. User selects authorized client-users from pool of known users.
   1. User can select or enter new key ids when authorizing users.
 1. Nobody (users without client certificate ids) denied access by default.
 1. User is presented with any absolutely necessary configuration options.
   1. If service has any required configuration options, service should be patched to function without those options and prompt the user when the user accesses the service for the first time?
 1. Service is enabled.

== Footnotes ==

* This step generates cryptographic keys and consumes lots of entropy (effectively a non-renewable resource on a plugserver), so the Hello service should not be enabled for more users than necessary.

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.

Workflows

Goals

The FreedomBox is both a system that provides services for others and a router that protects its user's communications.

As a Server

(By default)

  1. Users can connect to their FreedomBox's services with client certificates:

    1. On their desktop's browser.
    2. On their mobile device.
  2. Administrators can selectively authorize (local and remote) users for services hosted on the box.

As a Router

(By default)

1. Communications that don't have to leave the box, won't. 2. The box will route all external connections through privacy-enhancing and anonymizing tools.

Configured User Sends FBX a Service Request

  +-------------+      +-------------+
  | User Agent  |      | Service     |
  |             |      |             |
  |             |<-----+             |
  |             |    6 |             |
  |             |      |             |
  +----------+--+      +-------------+
           1 |                 ^
             |                 | 5
             |         +-------------+-------------+
             |         | Web Server  | LDAP        |
             +-------->|        2,3 -+>            |
                       |             |             |
                       |            <+- 4          |
                       |             |             |
                       +-------------+-------------+
  1. Browser sends request to FBX.
  2. Web server receives request, authenticates user's key id. Web server 401s user if no key.
  3. Web server requests LDAP authorizes user's key.
  4. LDAP informs web server of its decision. Web server 403s user if LDAP doesn't authorize.
  5. Having been authenticated and authorized, web server passes request on to service.
  6. Service processes request, using key id as user id and replies to user.

Configuring New Users

  +-------------+      +-------------+
  | User Agent  |      | Hello       |
  |             |      |             |
  |             |<-----+             |
  |             |    4 |             |
  |             |      |             |
  +----------+--+      +-------------+
           1 |                 ^
             |                 | 3
             |         +-------------+-------------+
             |         | Web Server  | LDAP        |
             +-------->|            -+>            |
                       |          2  |             |
                       |            <+-            |
                       |             |             |
                       +-------------+-------------+
  1. User requests Hello service.

  2. Web server checks with LDAP to see if user without key (Nobody) is authorized for Hello right now.
  3. The Hello service begins by de-authorizing Nobody*, then it creates a PGP key, signs it with the box's key, and fully trusts the key. That key is then exported as an SSL certificate.
  4. The user-agent receives the key and the SSL certificate. It installs the certificate into the local store. The user can now access the system per the Configured User Sends FBX a Service Request workflow.

Box-to-Box Service Location Updates

  +--------------+
  | Freedombuddy |
  |              |  3
  |              |<------------+
  |              |             |
  |              |             |
  +----------+---+             |
           1 |                 |
             |               2 |
             |         +-------+------+
             |         | FreedomBuddy |
             +-------->|              |
                       |              |
                       |              |
                       |              |
                       +--------------+
  1. A sends location request to B's FBuddy service.

  2. B replies with updated locations to A's FBuddy.
  3. A records updates.

Key Exchange / Introduction Process Between Users

  +-------------+         +--------------+
  | User Agent  +-------->| FreedomBuddy |
  |             | 1       | 2            |
  |             |         |              |
  |             |<--------+              |
  |             | 3       |              |
  +-------------+         +--------------+
  1. User A sends identity and service locations in a self-signed statement to User B.
  2. User B verifies signed statement. Imports identity and service locations if all is well.
  3. User B replies to destination A just defined to inform A of identity and (optionally) provide A services.

Teaching Client About Box's Services

FBX-App Connecting to Box's Services

User Telling FBX-App to Connect to Local Box's Services

User Telling FBX-App to Connect to Remote Box's Services

Enabling New Service

  1. User selects service-to-enable in Plinth.

  2. User selects authorized client-users from pool of known users.
    1. User can select or enter new key ids when authorizing users.
  3. Nobody (users without client certificate ids) denied access by default.
  4. User is presented with any absolutely necessary configuration options.
    1. If service has any required configuration options, service should be patched to function without those options and prompt the user when the user accesses the service for the first time?
  5. Service is enabled.

Footnotes

* This step generates cryptographic keys and consumes lots of entropy (effectively a non-renewable resource on a plugserver), so the Hello service should not be enabled for more users than necessary.