| Internet-Draft | Mathematical Mesh Reference | March 2020 |
| Hallam-Baker | Expires 10 September 2020 | [Page] |
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data.¶
[Note to Readers]¶
Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.¶
This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-security.html.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 10 September 2020.¶
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
This section presents the related specifications and standard, the terms that are used as terms of art within the documents and the terms used as requirements language.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
The terms of art used in this document are described in the Mesh Architecture Guide [draft-hallambaker-mesh-architecture].¶
The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer].¶
Classes that are derived from an assertion.¶
Parent class from which all assertion classes are derived¶
Fingerprints of index terms for profile retrieval. The use of the fingerprint of the name rather than the name itself is a precaution against enumeration attacks and other forms of abuse.¶
The time instant the profile was last modified.¶
A Uniform Notary Token providing evidence that a signature was performed after the notary token was created.¶
Parent class from which all condition classes are derived.¶
[No fields]¶
Abstract classes from which the Profile, Activation and Connection classes are derrived.¶
Parent class from which all profile classes are derived¶
The permanent signature key used to sign the profile itself. The UDF of the key is used as the permanent object identifier of the profile. Thus, by definition, the KeySignature value of a Profile does not change under any circumstance. The only case in which a¶
A Personal profile contains at least one OSK which is used to sign device administration application profiles.¶
Contains the private activation information for a Mesh application running on a specific device¶
Base class for cataloged Mesh data.¶
[No fields]¶
A Mesh profile does not have activation or connection classes associated with it.¶
It might be more consistent to represent administation devices as activations on the ProfileMesh class though.¶
Describes the long term parameters associated with a personal profile.¶
Describes a mesh device.¶
[No fields]¶
List of the permissions that the device has been granted.¶
The signature key for use of the device under the profile¶
The encryption key for use of the device under the profile¶
The authentication key for use of the device under the profile¶
Public device entry, indexed under the device ID¶
UDF of the signature key of the device in the Mesh¶
The Mesh profile¶
UDF of the signature key of the device¶
The device profile¶
The public assertion demonstrating connection of the Device to the Mesh¶
The activations of the device within the Mesh¶
The accounts that this device is connected to¶
Account assertion. This is signed by the service hosting the account.¶
Service address(es).¶
Master profile of the account being registered.¶
Key used to encrypt data under this profile¶
Key used to authenticate requests made by the device.¶
The list of service identifiers.¶
List of the permissions that the device has been granted.¶
The signature key for use of the device under the profile¶
The encryption key for use of the device under the profile¶
The authentication key for use of the device under the profile¶
Contains the Account information for an account with a CatalogedDevice.¶
UDF of the account profile¶
The account profile¶
The connection of this device to the account¶
The activation data for this device to the account¶
[No fields]¶
Describes a group. Note that while a group is created by one person who becomes its first administrator, control of the group may pass to other administrators over time.¶
Describes the connection of a member to a group.¶
Profile of a Mesh Service¶
Key used to authenticate service connections.¶
[No fields]¶
[No fields]¶
Classes describing data used in cataloged data.¶
The Mesh Account Connection - the main event really¶
Unique key.¶
If true, this catalog entry is for the user who created the catalog. To be valid, such an entry MUST be signed by an administration key for the Mesh profile containing the account to which the catalog belongs.¶
Unique key.¶
List of the permissions that the contact has been granted.¶
The (signed) contact data.¶
[No fields]¶
[No fields]¶
[No fields]¶
[No fields]¶
[No fields]¶
Connection request message. This message contains the information¶
Connection request message generated by a service on receipt of a valid MessageConnectionRequestClient¶
Respond to RequestConnection message to grant or refuse the connection request.¶
[No fields]¶
[No fields]¶
[No fields]¶
Every Mesh Portal Service transaction consists of exactly one request followed by exactly one response. Mesh Service transactions MAY cause modification of the data stored in the Mesh Portal or the Mesh itself but do not cause changes to the connection state. The protocol itself is thus idempotent. There is no set sequence in which operations are required to be performed. It is not necessary to perform a Hello transaction prior to a ValidateAccount, Publish or any other transaction.¶
A Mesh Portal Service request consists of a payload object that inherits from the MeshRequest class. When using the HTTP binding, the request MUST specify the portal DNS address in the HTTP Host field.¶
Base class for all request messages.¶
Name of the Mesh Portal Service to which the request is directed.¶
A Mesh Portal Service response consists of a payload object that inherits from the MeshResponse class. When using the HTTP binding, the response SHOULD report the Status response code in the HTTP response message. However the response code returned in the payload object MUST always be considered authoritative.¶
Base class for all response messages. Contains only the status code and status description fields.¶
[No fields]¶
The Mesh Service protocol makes use of JSON objects defined in the JOSE Signatgure and Encryption specifications.¶
The following common structures are used in the protocol messages:¶
Describes a Key/Value structure used to make queries for records matching one or more selection criteria.¶
Specifies constraints to be applied to a search result. These allow a client to limit the number of records returned, the quantity of data returned, the earliest and latest data returned, etc.¶
Only data published on or after the specified time instant is requested.¶
Only data published before the specified time instant is requested. This excludes data published at the specified time instant.¶
Maximum number of data entries to return.¶
Maximum number of data bytes to return.¶
Specifies a page key returned in a previous search operation in which the number of responses exceeded the specified bounds.¶
When a page key is specified, all the other search parameters except for MaxEntries and MaxBytes are ignored and the service returns the next set of data responding to the earlier query.¶
Report service and version information.¶
The Hello transaction provides a means of determining which protocol versions, message encodings and transport protocols are supported by the service.¶
Request validation of a proposed name for a new account.¶
For validation of a user's account name during profile creation.¶
Describes the proposed account properties. Currently, these are limited to the account name but could be extended in future versions of the protocol.¶
Account name requested¶
If true, request a reservation for the specified account name. Note that the service is not obliged to honor reservation requests.¶
List of ISO language codes in order of preference. For creating explanatory text.¶
States whether the proposed account properties are acceptable and (optional) returns an indication of what properties are valid.¶
Note that receiving a 'Valid' responseto a Validate Request does not guarantee creation of the account. In addition to the possibility that the account namecould be requested by another user between the Validate and Create transactions, a portal service MAY perform more stringent validation criteria when an account is actually being created. For example, checking with the authoritative list of current accounts rather than a cached copy.¶
If true, the specified account identifier is acceptable. If false, the account identifier is rejected.¶
Specifies the minimum length of an account name.¶
Specifies the maximum length of an account name.¶
A list of characters that the service does not accept in account names. The list of characters MAY not be exhaustive but SHOULD include any illegal characters in the proposed account name.¶
Text explaining the reason an account name was rejected.¶
Request creation of a new portal account.¶
Unlike a profile, a mesh account is specific to a particular Mesh portal. A mesh account must be created and accepted before a profile can be published.¶
Request creation of a new portal account. The request specifies the requested account identifier and the Mesh profile to be associated with the account.¶
Reports the success or failure of a Create transaction.¶
[No fields]¶
Request deletion of a portal account.¶
Deletes a portal account but not the underlying profile. Once registered, profiles are permanent.¶
Request deletion of a new portal account. The request specifies the requested account identifier.¶
Reports the success or failure of a Delete transaction.¶
[No fields]¶
Search for data in the mesh that matches a set of properties described by a sequence of key/value pairs.¶
Describes the Portal or Mesh data to be retreived.¶
Lookup by profile ID¶
Lookup by Account ID¶
List of KeyValue pairs specifying the conditions to be met¶
Constrain the search to a specific time interval and/or limit the number and/or total size of data records returned.¶
If true return multiple responses if available¶
If true, the client requests that the full Mesh data record be returned containing both the Mesh entry itself and the Mesh metadata that allows the date and time of the publication of the Mesh entry to be verified.¶
Reports the success or failure of a Get transaction. If a Mesh entry matching the specified profile is found, containsthe list of entries matching the request.¶
List of mesh data records matching the request.¶
If non-null, indicates that the number and/or size of the data records returned exceeds either the SearchConstraints specified in the request or internal server limits.¶
Publish a profile or key escrow entry to the mesh.¶
Requests publication of the specified Mesh entry.¶
[No fields]¶
Reports the success or failure of a Publish transaction.¶
[No fields]¶
Request the current status of the mesh as seen by the portal to which it is directed.¶
The response to the status request contains the last signed checkpoint and proof chains for each of the peer portals that have been checkpointed.¶
[Not currently implemented]¶
Initiates a status transaction.¶
[No fields]¶
Reports the success or failure of a Status transaction.¶
Time that the last write update was made to the Mesh¶
Time that the last Mesh checkpoint was calculated.¶
Time at which the next Mesh checkpoint should be calculated.¶
Last checkpoint value.¶
Request connection of a new device to a mesh profile¶
Initial device connection request.¶
Reports the success or failure of a ConnectStart transaction.¶
[No fields]¶
Request status of pending connection request of a new device to a mesh profile¶
Request status information for a pending request posted previously.¶
Reports the success or failure of a ConnectStatus transaction.¶
Request a list of pending requests for an administration profile.¶
Specify the criteria for pending requests.¶
Reports the success or failure of a ConnectPending transaction.¶
A list of pending requests satisfying the criteria set out in the request.¶
If non-null, indicates that the number and/or size of the data records returned exceeds either the SearchConstraints specified in the request or internal server limits.¶
Post response to a pending connection request.¶
Reports the success or failure of a ConnectComplete transaction.¶
Reports the success or failure of a ConnectComplete transaction.¶
[No fields]¶
Perform a bulk transfer of the log between the specified transaction identifiers. Requires appropriate authorization¶
[Not currently implemented]¶
Request a bulk transfer of the log between the specified transaction identifiers. Requires appropriate authorization¶
Reports the success or failure of a Transfer transaction. If successful, contains the list of Mesh records to be transferred.¶
Is a regulatory requirement GDPR/HIPPA¶
Where they buried Aunt Agatha's jewelry but not where they buried Aunt Agatha.¶
Traffic analysis protection¶
Access control¶
Authentication / Integrity¶
Data Confidentiality¶
Non-Repudiation¶
Use of platform provided facilities to bind private keys in the Device profile to the device is highly desirable. Ideally, private keys should be protected against extraction by hardware techniques presenting a high degree of resistance.¶
Use strong mechanisms as described in RFC???¶
Use of key co-generation as described in part 8 is advised¶
Master profile keys should be escrowed¶
Escrow strategies for DARE should take account of the fact that users may want some but not all their data assets to survive them.¶
Check that the device credential has been signed by an administration device and that the administration device was properly authorized by the master profile.¶
Device catalog MUST be signed by the admin device.¶
Future ? provide protection against rollback attacks.¶
See the separate document on the trust model¶
Cert transparency type techniques¶
Every message is subject to access control¶
Mesh Services should perform abuse filtering on inbound mail¶
Mesh Services MUST apply user specified ingress control as specified in their contacts catalog.¶
Some applications may require egress control¶
For example, classified environments¶
Mail too stupid to send¶
Confirmation messages requiring payments¶
Need Accountability¶
Need to know the source of the accountability assertions¶
Should be distinguished from sender controlled part of a message¶
Authentication and consequences¶
This document comprises the security considerations for the use and implementation of the Mathematical Mesh.¶
All the IANA considerations for the Mesh documents are specified in this document¶
A list of people who have contributed to the design of the Mesh is presented in [draft-hallambaker-mesh-architecture].¶