BOXP Network Model

From BOXP

Contents 1 Basics 2 User identification 2.1 User names and domains 2.2 Who will receive the authority 2.3 Currently defined ranges and domains 2.4 Authentication

Basics

The main function of BOXP is secure transportation of data packets. These packets are handled by higher level protocols.

BOXP is a decentralized, peer-to-peer protocol. It is also not tied to TCP or IP. The senders and recipients of the packets are identified by unique numeric IDs. This leads to many advantages, but also leads to a number of problems, which this document is to solve.

User identification

As said above, users are identified by numeric IDs. The need to keep these IDs unique and authenticatable creates a need for identification authorities.

Each range of the IDs is served by a specific authority. The list of these authorities is maintained by IONH and can be received from user #1 (root). This is the only function of root. There will be probably up to 10 sessions of root running in different places of the world simultaneously. They will have fixed IPs and/or DNS, and this will be the only inevitable use of IP in BOXP.

User names and domains

The numeric IDs are convenient for programs, but less convenient for humans. So each user ID will also have a user name mapped to it. A user name can consist only of alphanumeric characters and underscore.

But the authorities can, and most new authorities will already come with their user base. So, to prevent collisions of names from different authorities, each of them will receive a domain name. (Think of top level domains in DNS)

The user name will thus be in form user.domain. If there is no domain given, .u should be assumed (see below).

One domain can cover multiple ID ranges, but a single range can not be covered by multiple domains. In contrast to DNS, the commercialization of the user names will be forbidden.

Subdomains can be operated by users in the domain, if the TLD permits it. The authority must not allow inaproriate use of subdomains, e.g. for spambot spawning.

Who will receive the authority

Except very few special cases, the authority will be given to existing projects with a large user base willing to join the BOXP network, so that their users can continue using the service without re-registering.

Currently defined ranges and domains

• .u Users (e.g. homo sapiens). Should be assumed by default if no domain is given. Can not have subdomains.

  Range: 1000 to 10^8-1

  Maintained by IONH (Currently VeryPositive)

• .c Companies and other organizations. Subdomains allowed.

  Range: 10^8 -- 2*10^8-1

  Maintained by IONH (Currently not operating)

• .s Services (e.g. content services, bots, supernodes, chat servers). Each service must have a human or corporate owner. Subdomains allowed.

  Range 2*10^8 -- 3*10^8-1

  Maintained by IONH (Currently VeryPositive)

• .d Devices. Should the BOXP-supporting devices be produced, they will receive a permanent ID in this domain.

  Range 3*10^8 -- 4*10^8-1

  Theoretical proposal.

Authentication

The users in the network are authenticated by the certificates. A certificate is a combination of user's ID, full username, current session's ID, a public key and optional information about the user, signed by the public key of the domain authority. The public key of authority is itself extracted from a certificate signed by higher level authority. The certificates of TLD are signed by the root. Any BOXP implementation must have a list of root public keys hard-coded.

A certificate of any user should be publically available to any other user of the network. It also should be sent as a first packet before starting communication with a user. All other packets sent to user must be then signed by this public key. They also should be encrypted by the recipients public key.

A new certificate is issued per every session. Each user has a password at the authority. When starting a new session, the client generates a new key pair. It then sends a hash of the password and the newly-generated public key to the authority, encrypted by its public key. If no problems are encountered, the client receives his certificate which can be used for further communication. The private key is never sent anywhere. The clients also should not write the key to the hard drive and must discard the key after the session is over.