-
Notifications
You must be signed in to change notification settings - Fork 7
Fujinet Id identity server proposal by Roger Sen
This is a draft with the proposal of a Fujinet-Id identity manager, by Roger Sen.
Fujinet-ID is a simple identity management solution designed for low end 8 bit systems.
It's main benefits are:
- Allows 8 bit clients to generate multiple public identities and use them simultaneously.
- 8 bit client is able to identify itself to Third Party Servers (TPS) securely without revealing its private identities.
It's main drawbacks are:
- Single point of failure (Fujinet-ID server). Can be mitigated with HA solution for the Fujinet-ID server.
- Fujinet-ID requires a secret. In case of secret being stolen, all Fujinet-ID tickets are revoked.
- Third Party Servers (TPS) need to be trustful, otherwise they can use client ticket in a pass the ticket attack. This can be mitigate with (a) short TTL (b) registration of TPS to access Fujinet-Id server and (c) one time use tickets (to be implemented).
- All the communications requires TLS (among Fujinet-Id, TPS and 8 bit clients)
Let's start with some definitions:
Fujinet-Id server is the software in charge of generate public identities and verify tickets.
Third Party servers are any kind servers developed to make use of Fujinet-Id server.
A ticket is a token used to identify a user retrieving it's identity (public name)
A user is someone that wants to be identified in the system via an identity.
The identity of an user is represented with a public name. A user can have multiple identities (public names) simultaneously.
A public name has the format following format: username!tripcode. For each public name, there's always a private name with the format: username#password. The username is the same in the public and private names.
tripcode is generated by the Fujinet-Id server from the password submitted by the user in the private name.
Fujinet-Id server in its simplest form executes this process:
private name public name
(username#password). ────────────────⊕─────────────────► (username!tripcode)
▲
│
SERVERKEY
SERVERKEY is a secret stored in Fujinet-Id used to generate the tripcode of the public name from the password of the private name.
The transformation function is deterministic (same input always generates same output if SERVERKEY is the same) and non reversible (from a public name it's not possible to obtain the private name)
The Fujinet-Id system places no limitation on the generation of multiple public names and allows users to have multiple identities. Because the username part of the public/private name is not changed is possible that johnsmith!qwerty1 is a different user than johnsmith!asdfgh2. Not to confuse identities it's key that any application that shows public names should do it in full (username!tripcode) and not only username.
Tickets are temporary tokens used by the TPS to retrieve the public name from Fujinet-Id.
Every public name/private name can have multiple tickets, with different TTL that will be shared to the TPS for identification. Once the TPS receives a ticket from the 8 bit client, it will check with the Fujinet-ID to obtain the public name.
- Ticket is requested by a Fujinet identity management application to the Fujinet-Id server with it's private name (and optionally a Time to Live - TTL)
- Fujinet-Id server generates public name and token. It stores the public name and token in it's database and sends the token back to FN 8bit computer.
- Fujinet local device stores the token internally.
- The client application running in Fujinet retrieves the list of tokens in Fujinet device and asks the user which one wants to use.
- The client application sends the tocken to the TPS that...
- ...proceeds to forward it to Fujinet-Id.
- If token is valid, Fujinet-Id returns the public name to the TPS who uses the name and forwards the ok to the client application in Fujinet.
- If the token is not valid, Fujinet-Id returns an error to the TPS who informs of the error to the client application running in the 8 bit client.
- The Fujinet identity management application sends the token and the private name to the Fujinet-Id
- Fujinet-Id checks for token validity and removes it from the system.
- Fujinet identity management application can remove it from Fujinet internals.
- The Fujinet identity management application sends the private name to the Fujinet-Id
- Fujinet-Id proceeds to remove all tokens associated to the private identity from Fujinet-Id.
The tuple (public name, token) with only active tokens. Non active or revoked tokens cannot be accessed, so it's possible that an existing public name in a TPS is no longer in Fujinet-Id.
They only store public names needed to identify the users.
They store a list of active, non revoked tokens to be selected when an applications wants to share it with the TPS.
This data and the actions to generate a token and revoke it are to be managed by Fujinet identity management application running in the 8 bit computer with access to Fujinet device token storage area.
What are the failure scenarios?
If Fujinet-Id is down no new keys can be generated, nor third party servers cannot verify Tickets.
Will the user have only 1 private key, so we need 1 app per platform to generate them?
User can generate as many private keys (called private names) as they desire. Each one will generate 1 public name per private name. Every public key will have one or more tickets that will be shared to the TPS for identification.
What is a private name
A combination of a username (whatever you decide to have, you can have multiple ones) plus a passwd separated by a #: #
A password is text string that should be relatively easy to remember, such as: columbus-did-not-discover-america.It-was-always-there
My private name would be: rogersm!columbus-did-not-discover-america.It-was-always-there
What if they lose it?
If they lose the private name # there's nothing that can be done.
Can it be copied between FN devices? E.g I have A2, Coco, c64, atari and a BBC beeb, how do I ensure only 1 "identity"?
The private name used to generate a public name and tickets is a simple string. They can be copied between different devices.
Does each app that needs to have login have separate keys?
This is something pending to be defined depending on the capabilities of FN. From a security perspective, FujiNet should only store the tickets, and reveal them to the 8 bit applications via an API (so in the app the user can select between multiple tickets for identification). Ideally no public name, nor private name shoul be stored in FN, except if it's possible to limit who has access to them (only the user or an specific app, but never third party apps)
How do we repudiate? e.g accidentally commit my key to a repo.
Tickets can be revoked at any time by the 8 bit client.