Provisioning arrangements for secnet - consultation

[Ian Jackson]

Ian Jackson writes ("Provisioning arrangements for secnet - consultation"):
> I am starting by collecting requirements `user stories' [1].  I will
> reply to this message with a couple of my own.  Please do likewise,
> posting to sgo-software-discuss.

User story: Key rollover

 Ian is running secnet and has been using the new provisioning
 arrangements for 6 months or so.  Ian does nothing.

 Ian's secnet instances decide that Ian's keys are rather old.  His
 secnet nodes automatically generate new keypars, automatically
 re-enrol them in the relevant vpn(s), and automatically start using
 them.

 The new keys are automatically distributed throughout all the
 relevant vpn(s).  Ian's peer nodes pick up the new keys
 automatically.

 After a suitable period, the old keys are de-provisioned, and
 automatically de-authorised.  Now, any attacker who has compromised
 one of the old keys has no ability to do anything bad.

 There is no interruption to service.

User story: Algorithm upgrade

 Some time later, a version of secnet is released which support a new
 ECC-based public key algorithm suite.

 Ian upgrades one of his nodes, xenophobe, with `dpkg -i'.  He does
 nothing else.

 xenophobe's secnet tools generate a new ECDSA keypair, and enrol it
 in the SGO VPN.  The new ECDSA keypair is distributed to all the
 sites on the SGO VPN that support it, and to Ian's other secnet
 nodes.

 Ian's un-upgraded nodes keep using the old RSA keys and keep working.

 But Clare has also upgraded secnet on her laptop (which was earlier
 enrolled as a mobile node with xenophobe).  Clare does nothing else.

 Clare's laptop receives the new ECDSA keypair and starts using the
 new ECC cryptography when talking to xenophobe.

 Despite the fact that both Clare's laptop, and xenophobe, still have
 RSA keys, an attacker who compromises those RSA keys (or the
 corresponding DH group) is unable to attack the traffic between
 Clare's laptop and xenophobe.

User story: Algorithm retirement

 Five years later: almost everyone has upgraded.  A new version of
 secnet is released which no longer generates RSA keys by default.

 New installations are not compatible with un-upgraded sites, but do
 not have to generate or distribute RSA keys.

 Ten years later: RSA support is removed from secnet.  As sites are
 upgraded, they lose the ability to communicate with un-upgraded
 sites.  The RSA keys are dropped from the provisioning databases,
 within the key rollover period if not before.

 All of this happens without secnet node administrators having to do
 anything other than install the new version of secnet.

-- 
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.