The use-case diagram essentially lists the functionality required of the OpenDNSSEC software (this functionality is expanded in the associated requirements document). By and large (a) the use-cases are fairly simple and (b) the actions are largely automatic, requiring little input from the user. For these reasons, rather than detail a step-by-step procedure for each use-case (as is usual in such documents), only a broad description of the function is given.
Two sets of use-cases are given, one for each phase of the project.
Phase 1 - Zone Files
The following diagrams show the use-cases covered by this phase:
Actors are external entities involved in the system – they are not part of it. The following entities have been referenced in the use-cases:
The parent of the zone under consideration. It is included in these use cases because the action of editing the file may require changes to the NS and glue records in the parent.
Signed Zone File
The output of the process, and what is ultimately loaded into the nameserver.
Many actions are automated and are triggered by the passage of time. The Timer represents the system clock initiating an action.
Trust Anchor Location
Introduction of a new KSK into a zone requires that a corresponding trust anchor be published somewhere. This actor represents that location, whatever it is (e.g. parent zone, trust anchor repository etc.).
(Un)signed Zone File
The input zone file. If signed, DNSSEC information is stripped off before processing.
The person (or persons) responsible for managing the data in the zone.
The person (or persons) responsible for the security of the zone.
(Note that the roles of Zone Manager and Security Manager may well be filled by the same person.)
Scheduled KSK Rollover
Initiated by the timer, this use-case is concerned with replacing the existing key-signing key with a new one. As described in RFC 4631, the process involves the introduction of a new key, parallel running, and the withdrawal of the old key.
The system keeps track of when keys were introduced into the zone and how long they have been there. The determination of when to initiate a key rollover is based on this data and the parameters defining the zone policies.
The output is an updated signed zone file. Also output is a trust anchor for the new KSK.
Emergency KSK Rollover
Initiated by the security manager if a key compromise is suspected, the process forces a roll-over of the current KSK. In practice, it can be achieved by marking the current KSK as retired then following the process for scheduled KSK rollovers.
Scheduled ZSK Rollover
Like the scheduled KSK rollover, this use-case automatically rolls a zone-signing key based on time and zone policies. Like the KSK rollover, introduction of a new ZSK will lead to an updated signed zone file. Unlike the KSK case, there is no updated trust anchor.
Emergency ZSK Rollover
Initiated by the security manager if a key compromise is suspected, the process forces a roll-over of the current ZSK. In practice, it can be achieved by marking the current ZSK as retired then following the process for scheduled ZSK rollovers.
Edit Key Policies
Key policies – which determine how DNSSEC in the zone operates, e.g the lifetimes of keys and signatures, how often the zone is re-signed, etc – are expressed as a set of parameters. The OpenDNSSEC solution must have a way whereby these parameters can be modified.
Keys will be stored in a key store. Although keys could be generated as needed, some sites may have a requirement for redundancy, i.e. duplicate key stores in separated locations. As such, it may be simpler to pre-generate all keys for the lifetime of the key store.
Delete Keys from Key Store
Keys that have been used and have expired may be deleted from the key store. The system should allow the security manager to do this.
Change Key Store
In the event that a key store is implemented in hardware (e.g. a hardware security module, HSM), there must be some way of coping with the end of life event of the hardware. Either there must be a way of moving existing keys to the new key store, or there must be a way of transitioning between the two.
DNSSEC requires that signatures have a fixed lifetime, which in turn means that the zone needs periodic re-signing.
There may be circumstances where the zone manage may want to trigger an emergency re-signing (e.g. if the scheduled re-signing job has failed for some reason). The system must allow them to do this. The use-case is marked as an extension of the scheduled re-signing, since both perform the same actions, only the method of invocation is different.
Edit Zone File
Although OpenDNSSEC is concerned with DNSSEC, the zone file will have non-DNSSEC related changes applied to it. The solution must allow this and allow the updated zone file to be signed.