This is an old revision of the document!
New America Foundation - Contractor Agreement #32-OTIUSAID2013 “NAF5”
Section 1: Work to be Performed (Scope of Work)
<BOOKMARK:R1>R1. Complete multi-SID support to serval routing engine and network layer.
servald id enter pin <PIN> which unlocks any SID identities protected by that PIN. If the SID already has a remote route, then the SID is not announced, but if no remote route exists, then the SID is announced as routable to this node. Returns the list of identities unlocked by that pin, and whether each is announced or already has a remote route.
<BOOKMARK:R3>R3. Implement SID roaming handshake procedure with
servald id announce <SID>.
servald id relinquish pin <PIN|SID>, which releases the specified identities, and removes those identities from the local routing table.
<BOOKMARK:R5>R5. Add ability to store tags (which could be IEMI/IMSIs) in keyring entries.
servald id list [<TAG|SID>] that lists all unlocked identities, or only those unlocked identities with a supplied SID or tag (which could be the IEMI/IMSI).
<BOOKMARK:R7>R7. Extend test suite to cover the above.
The following implementation decisions were made during the course of the contract.
. The R2
keyring PIN enter and relinquish commands only affect entry PINS
not keyring PINs
. A running daemon can have at most one keyring PIN, which is set by the command-line option when started and cannot be relinquished while running.
<BOOKMARK:N2>N2. The daemon uses one SID as its main identity for its entire lifetime. All other SIDs are treated as secondary identities.
the daemon automatically unlocks all PIN-less identities it can find in the keyring on start-up, as well as any whose PINs are supplied on the command line
if there are none, the daemon creates a PIN-less one automatically and stores it in the keyring (for re-use in future sessions)
the daemon chooses the first unlocked, start-up SID as its main identity
the daemon does not allow its main identity to be relinquished (locked)
<BOOKMARK:N3>N3. Identity hand-over is only performed when a running daemon is requested to unlock an identity, and in no other occasions. In particular:
identity hand-over is not performed when a daemon starts up, to try to gain custody of its initial identities, so if two daemons are started with shared unlocked identities in their keyrings, there will be a routing conflict on those identities;
identity hand-over is not performed opportunistically (eg, at regular intervals), so a network merge between subnets which each had the same identity present will produce a routing conflict on that identity.
Summary of work performed to date;
73342a9 - R1, Announce fake links in the routing table to secondary identities.
ae7e120 - R2, Pass a pin to servald to unlock an identity from the keyring.
ef7351b - R4, Relinquish identities based on either the entry pin or SID.
0c1c767 - R1, automatically claim the route to an identity with an existing route when all possible routes disappear.
b8ec568 - R3, When a SID is unlocked, but is a route already exists, automatically trigger a request / challenge / response handshake with the existing instance of this SID so it can be unlocked and routable locally.
c3b4d68 - R5, Read / Write / and search new key type for storing tag name / value pairs.
4e543f7 - R6, Implement id list command to list identities currently unlocked in the running daemon. Allow filtering by tag name / value pairs.