[SECNET] Provisioning and configuration - proposal

[Ian Jackson]

Please comment on this draft.


Proposed new provisioning arrangements
======================================

Problems I aim to solve:

 * New sites added to the SGO VPN are not reachable from other sites
   without an update campaign (which will generally never complete).

 * Arrangements for adding mobile nodes are ad hoc (and in my case
   involve clone-and-hack of existing configs).

 * Setting up a new VPN is far too hard.

 * Existing provisioning arrangements are unsuitable for use with
   mobile phones as clients.

 * Public key rollover is so hard that no-one has ever done it.


Model / assumptions
===================

Each instance of the provisioning arrangements manages a single
vpn consisting of
 - a set of fixed (non-mobile) sites with well-know DNS
   names, connected by a complete mesh of pairwise links
 - a set of mobile sites, each with a small subset of the
   fixed sites providing routing ("routing sites") and with
   an address chosen from one of those ("home site")
 - a subset of the non-mobile sites are trusted to give
   out enrolment information

Some fixed sites have delegated setup control: the site master admin
delegates address and vpn namespace to unprivileged users.

The admin of a mobile site has (possibly delegated) control over the
configuration of each of its fixed sites.  Packets between a mobile
site and fixed sites which are not routing for it, go via the mobile
site's home (and that home can interfere with them because it sees the
plaintext).

By default the arrangements assume that they "own" the secnet they are
configuring, but mixed arrangements (where secnet configuration from a
provisioner is combined with information from othere sources) will be
possible.

Each fixed site corresponds to a "location" (in make-secnet-sites
terms).  A mobile site's location is its home site's location.

Each site trusts the vpn coordinator to do enrolment of other sites;
any more fine-grained access control is done via controls on the
within-vpn IP addresses.


New design priciple - splitting public keys
===========================================

We split public keys from the sites' configuration information.

Peer public keys will be managed by secnet itself.  They will be
stored in /var somewhere.  During key setup, each side (the relying
end) will advertise what public keys it will accept.  The proving end
will choose one that it has the private key for.  (During a key setup,
each end plays both the relying and proving end in two instances of
this subprotocol.)

After key exchange, if the relying end had an out-of-date set, this
will be updated with a new set specified by the proving end
(effectively, authentication-chained from the just-done key setup).
The updated public key set is made immediately effective at the
relying end, without a secnet restart.

To do key rollover, a proving end will first add a new public key to
its acceptable set (and the corresponding private key to its store of
private keys).  After a suitable expiry period, the old key will be
removed.  (The expiry period should be chosen so that it is not likely
that the proving end will be rewound by a restore from backups to
before the new key was added.)  Private keys are retained
indefinitely.

During all protocols, public key sets are treated as a unit (like a
DNS RRset).  Each public key set has a 64-bit wrapping serial number,
which is formally like a DNS zone serial number but is usually a
64-bit time_t.  A public key set may be empty, which is distinct from
a not having the set recorded at all.

sites files will gain the ability to list multiple public keys of
multiple algorithms and also to specify the serial number.

When a sites file is converted to a secnet configuration and
installed, the public key material in it overwrites the operational
configuration iff the serial is more recent.


New design priciple - coordinator site(s)
=========================================

A designated set of sites are the "coordinator" sites.  Each of them
is trusted by everyone else for entrolment.  No-one else needs to know
how they manage this.

Coordinator sites advertise the sites file in two versions: one is the
"recent" version and contains all public key updates exchanged in-band
wwith peers.  One is the "config" version and is updated only when
something else changes.  The "recent" version contains within it an
annotation giving the hash of the "config" version.

During key exchange with a coordinator site, each peer is told the
hash of the current "config" version.  If it is different to the
peer's (maybe, the config hash in the peer's file, if applicable), the
peer is sent a copy of the "recent" file.  The receiving site then
reruns make-secnet-sites and restarts.

When a new site is set up, it gets a copy of the "recent" version,
which means it has the most up to date public key set.

In our implementation, one site for each vpn is the coordinator site.
It maintains (perhaps via userv delegation) the master sites file.

Updates to the master site file involve restarting secnet everywhere.
There is some limit placed (in our implementation, in the userv
service, and also in each site) on the frequency of this.

The identity of the coordinator site is specified in the sites file
itself.


Enrollment pack, and enrollment tools
=====================================

We invent a new kind of thing I am calling an "enrollment pack".
This contains:
 - vpn-level configuration information
 - a copy of the sites file to be used
 - a private key used for bootstrapping

There will be new scripts to generate and consume these.

The "consume" script will be able to do everything necessary to get
secnet working on the vpn member site.  It will optionally allow for
human review or application of local policy.


Mobile site
===========

Mobile sites need to use a variant configuration, which talks directly
only to their routing sites and directs all the "leftover" space to
their home site.

This variant configuration will be generated on their home site, as a
sites file.  This sites file will be derived from the main sites file.
>From the point of view of the mobile site, its home site is its
coordiator.

Some mobile sites want to track the address ranges used by the various
fixed sites, others not.  This is selected as a configuration option
on their home.


Implemetation on a mobile phone
===============================

The enrollment pack can be fed to a phone somehow.

A limited reimplementation of make-secnet-sites will be provided to
convert the sites file to a secnet configuration and public key store.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.