Network Working Group P. Hallam-Baker Internet-Draft April 4, 2019 Intended status: Informational Expires: October 6, 2019 Mathematical Mesh Part VII: Security Considerations draft-hallambaker-mesh-security-00 Abstract 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. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-security.html [1] . Status of This Memo 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 October 6, 2019. Copyright Notice Copyright (c) 2019 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 Hallam-Baker Expires October 6, 2019 [Page 1] Internet-Draft Mathematical Mesh Reference April 2019 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Related Specifications . . . . . . . . . . . . . . . . . 5 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 5 2.5. Shared Classes . . . . . . . . . . . . . . . . . . . . . 5 2.5.1. Structure: PublicKey . . . . . . . . . . . . . . . . 5 2.6. Mesh Profile Objects . . . . . . . . . . . . . . . . . . 6 2.6.1. Structure: Profile . . . . . . . . . . . . . . . . . 6 2.6.2. Keyset Classes . . . . . . . . . . . . . . . . . . . 6 2.6.3. Structure: EscrowedKeySet . . . . . . . . . . . . . . 6 2.6.4. Profile Classes . . . . . . . . . . . . . . . . . . . 6 2.6.5. Structure: ProfileMaster . . . . . . . . . . . . . . 6 2.6.6. Structure: ProfileDevice . . . . . . . . . . . . . . 7 2.6.7. Structure: ProfileApplication . . . . . . . . . . . . 7 2.6.8. Structure: ProfileMesh . . . . . . . . . . . . . . . 7 2.6.9. Structure: ProfileMeshDevicePublic . . . . . . . . . 8 2.6.10. Structure: ProfileMeshDevicePrivate . . . . . . . . . 8 2.6.11. Structure: DeviceRecryptionKey . . . . . . . . . . . 8 2.7. Common Structures . . . . . . . . . . . . . . . . . . . . 8 2.7.1. Structure: Permission . . . . . . . . . . . . . . . . 8 2.7.2. Structure: Contact . . . . . . . . . . . . . . . . . 9 2.7.3. Structure: Role . . . . . . . . . . . . . . . . . . . 10 2.7.4. Structure: Address . . . . . . . . . . . . . . . . . 10 2.7.5. Structure: Location . . . . . . . . . . . . . . . . . 10 2.7.6. Structure: Reference . . . . . . . . . . . . . . . . 11 2.8. Catalog Entries . . . . . . . . . . . . . . . . . . . . . 11 2.8.1. Structure: CatalogEntry . . . . . . . . . . . . . . . 11 2.8.2. Structure: CatalogEntryDevice . . . . . . . . . . . . 11 2.8.3. Structure: CatalogEntryCredential . . . . . . . . . . 11 2.8.4. Structure: CatalogEntryNetwork . . . . . . . . . . . 12 2.8.5. Structure: CatalogEntryContact . . . . . . . . . . . 12 2.8.6. Structure: CatalogEntryContactRecryption . . . . . . 13 2.8.7. Structure: CatalogEntryBookmark . . . . . . . . . . . 13 2.8.8. Structure: CatalogEntryTask . . . . . . . . . . . . . 13 2.8.9. Structure: Task . . . . . . . . . . . . . . . . . . . 13 2.8.10. Structure: CatalogEntryApplication . . . . . . . . . 14 2.8.11. Structure: CatalogEntryApplicationEntry . . . . . . . 15 2.8.12. Structure: CatalogEntryApplicationRecryption . . . . 15 2.8.13. Structure: CatalogEntryApplicationSSH . . . . . . . . 15 Hallam-Baker Expires October 6, 2019 [Page 2] Internet-Draft Mathematical Mesh Reference April 2019 2.8.14. Structure: CatalogEntryApplicationMail . . . . . . . 15 2.8.15. Structure: CatalogEntryApplicationNetwork . . . . . . 15 2.9. Messages . . . . . . . . . . . . . . . . . . . . . . . . 15 2.9.1. Structure: MeshMessage . . . . . . . . . . . . . . . 15 2.9.2. Structure: MeshMessageComplete . . . . . . . . . . . 15 2.9.3. Structure: MessageConnectionRequest . . . . . . . . . 16 2.9.4. Structure: MessageConnectionPIN . . . . . . . . . . . 16 2.9.5. Structure: MessageContactRequest . . . . . . . . . . 17 2.9.6. Structure: MessageConfirmationRequest . . . . . . . . 17 2.9.7. Structure: MessageConfirmationResponse . . . . . . . 17 2.9.8. Structure: MessageTaskRequest . . . . . . . . . . . . 17 3. Mesh Portal Service Reference . . . . . . . . . . . . . . . . 17 3.1. Request Messages . . . . . . . . . . . . . . . . . . . . 18 3.1.1. Message: MeshRequest . . . . . . . . . . . . . . . . 18 3.2. Response Messages . . . . . . . . . . . . . . . . . . . . 18 3.2.1. Message: MeshResponse . . . . . . . . . . . . . . . . 18 3.3. Imported Objects . . . . . . . . . . . . . . . . . . . . 18 3.4. Common Structures . . . . . . . . . . . . . . . . . . . . 18 3.4.1. Structure: KeyValue . . . . . . . . . . . . . . . . . 18 3.4.2. Structure: SearchConstraints . . . . . . . . . . . . 19 3.5. Transaction: Hello . . . . . . . . . . . . . . . . . . . 19 3.6. Transaction: ValidateAccount . . . . . . . . . . . . . . 19 3.6.1. Message: ValidateRequest . . . . . . . . . . . . . . 20 3.6.2. Message: ValidateResponse . . . . . . . . . . . . . . 20 3.7. Transaction: CreateAccount . . . . . . . . . . . . . . . 21 3.7.1. Message: CreateRequest . . . . . . . . . . . . . . . 21 3.7.2. Message: CreateResponse . . . . . . . . . . . . . . . 21 3.8. Transaction: DeleteAccount . . . . . . . . . . . . . . . 21 3.8.1. Message: DeleteRequest . . . . . . . . . . . . . . . 22 3.8.2. Message: DeleteResponse . . . . . . . . . . . . . . . 22 3.9. Transaction: Get . . . . . . . . . . . . . . . . . . . . 22 3.9.1. Message: GetRequest . . . . . . . . . . . . . . . . . 22 3.9.2. Message: GetResponse . . . . . . . . . . . . . . . . 23 3.10. Transaction: Publish . . . . . . . . . . . . . . . . . . 23 3.10.1. Message: PublishRequest . . . . . . . . . . . . . . 23 3.10.2. Message: PublishResponse . . . . . . . . . . . . . . 24 3.11. Transaction: Status . . . . . . . . . . . . . . . . . . . 24 3.11.1. Message: StatusRequest . . . . . . . . . . . . . . . 24 3.11.2. Message: StatusResponse . . . . . . . . . . . . . . 24 3.12. Transaction: ConnectStart . . . . . . . . . . . . . . . . 25 3.12.1. Message: ConnectStartRequest . . . . . . . . . . . . 25 3.12.2. Message: ConnectStartResponse . . . . . . . . . . . 25 3.13. Transaction: ConnectStatus . . . . . . . . . . . . . . . 25 3.13.1. Message: ConnectStatusRequest . . . . . . . . . . . 26 3.13.2. Message: ConnectStatusResponse . . . . . . . . . . . 26 3.14. Transaction: ConnectPending . . . . . . . . . . . . . . . 26 3.14.1. Message: ConnectPendingRequest . . . . . . . . . . . 26 3.14.2. Message: ConnectPendingResponse . . . . . . . . . . 27 Hallam-Baker Expires October 6, 2019 [Page 3] Internet-Draft Mathematical Mesh Reference April 2019 3.15. Transaction: ConnectComplete . . . . . . . . . . . . . . 27 3.15.1. Message: ConnectCompleteRequest . . . . . . . . . . 27 3.15.2. Message: ConnectCompleteResponse . . . . . . . . . . 27 3.16. Transaction: Transfer . . . . . . . . . . . . . . . . . . 28 3.16.1. Message: TransferRequest . . . . . . . . . . . . . . 28 3.16.2. Message: TransferResponse . . . . . . . . . . . . . 28 4. Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.1. Data . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.2. Credentials . . . . . . . . . . . . . . . . . . . . . . . 29 4.3. Reputation . . . . . . . . . . . . . . . . . . . . . . . 29 4.3.1. Outbound Messaging Abuse () . . . . . . . . . . . . . 29 5. Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 29 5.1.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . 29 5.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 29 5.3. Availability . . . . . . . . . . . . . . . . . . . . . . 29 5.3.1. Data loss . . . . . . . . . . . . . . . . . . . . . . 29 5.3.2. Partial data survivability . . . . . . . . . . . . . 29 5.4. Inbound Messaging Abuse (Spam) . . . . . . . . . . . . . 29 6. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1. End point Compromise . . . . . . . . . . . . . . . . . . 29 6.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. Controls . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.1. Cryptographic . . . . . . . . . . . . . . . . . . . . . . 30 7.1.1. Triple lock . . . . . . . . . . . . . . . . . . . . . 30 7.1.2. Key Protection . . . . . . . . . . . . . . . . . . . 30 7.1.3. Key and Nonce Generation . . . . . . . . . . . . . . 31 7.1.4. Key Escrow and Recovery . . . . . . . . . . . . . . . 31 7.1.5. Profile Verification . . . . . . . . . . . . . . . . 31 7.1.6. Identity Validation . . . . . . . . . . . . . . . . . 31 7.1.7. Trust Broker Accountability . . . . . . . . . . . . . 31 7.2. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . 31 7.2.1. Ingress Control . . . . . . . . . . . . . . . . . . . 31 7.2.2. Egress Control . . . . . . . . . . . . . . . . . . . 32 7.2.3. Security Signal . . . . . . . . . . . . . . . . . . . 32 7.2.4. Accountability . . . . . . . . . . . . . . . . . . . 32 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . 33 11.2. Informative References . . . . . . . . . . . . . . . . . 33 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33 Hallam-Baker Expires October 6, 2019 [Page 4] Internet-Draft Mathematical Mesh Reference April 2019 1. Introduction 2. Definitions 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. 2.1. 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] . 2.2. Defined Terms The terms of art used in this document are described in the Mesh Architecture Guide [draft-hallambaker-mesh-architecture] . 2.3. Related Specifications The architecture of the Mathematical Mesh is described in the Mesh Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh documentation set and related specifications are described in this document. 2.4. Implementation Status The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer] . 2.5. Shared Classes The following classes are used as common elements in Mesh profile specifications.a 2.5.1. Structure: PublicKey The PublicKey class is used to describe public key pairs and trust assertions associated with a public key. UDF: String (Optional) UDF fingerprint of the public key parameters/ X509Certificate: Binary (Optional) List of X.509 Certificates X509Chain: Binary [0..Many] X.509 Certificate chain. X509CSR: Binary (Optional) X.509 Certificate Signing Request. Hallam-Baker Expires October 6, 2019 [Page 5] Internet-Draft Mathematical Mesh Reference April 2019 2.6. Mesh Profile Objects Base class for all Mesh Profile objects. 2.6.1. Structure: Profile Parent class from which all profile types are derived Names: String [0..Many] 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. Updated: DateTime (Optional) The time instant the profile was last modified. NotaryToken: String (Optional) A Uniform Notary Token providing evidence that a signature was performed after the notary token was created. 2.6.2. Keyset Classes 2.6.3. Structure: EscrowedKeySet A set of escrowed keys. [No fields] 2.6.4. Profile Classes 2.6.5. Structure: ProfileMaster Inherits: Profile Describes the long term parameters associated with a personal profile. This profile MUST be signed by MasterSignatureKey: PublicKey (Optional) The root of trust for the Personal PKI, the public key of the PMSK is presented as a self- signed X.509v3 certificate with Certificate Signing use enabled. The PMSK is used to sign certificates for the PMEK, POSK and PKEK keys. MasterEscrowKeys: PublicKey [0..Many] A Personal Profile MAY contain one or more PMEK keys to enable escrow of private keys used for stored data. Hallam-Baker Expires October 6, 2019 [Page 6] Internet-Draft Mathematical Mesh Reference April 2019 OnlineSignatureKeys: PublicKey [0..Many] A Personal profile contains at least one OSK which is used to sign device administration application profiles. 2.6.6. Structure: ProfileDevice Inherits: Profile Describes a mesh device. This profile MUST be signed by the DeviceSignatureKey Description: String (Optional) Description of the device DeviceSignatureKey: PublicKey (Optional) Key used to sign certificates for the DAK and DEK. The fingerprint of the DSK is the UniqueID of the Device Profile DeviceAuthenticationKey: PublicKey (Optional) Key used to authenticate requests made by the device. DeviceEncryptionKey: PublicKey (Optional) Key used to pass encrypted data to the device such as a DeviceUseEntry 2.6.7. Structure: ProfileApplication Inherits: Profile Contains the public description of a Mesh application. [No fields] 2.6.8. Structure: ProfileMesh Inherits: ProfileApplication Contains the binding of a device to a MasterProfile. Each device has a separate profile which MUST be signed by an OnlineSignatureKey Account: String (Optional) Account address. MasterProfile: DareMessage (Optional) Master profile of the account being registered. AccountEncryptionKey: PublicKey (Optional) Key used to encrypt data under this profile Hallam-Baker Expires October 6, 2019 [Page 7] Internet-Draft Mathematical Mesh Reference April 2019 2.6.9. Structure: ProfileMeshDevicePublic Inherits: ProfileApplication Inherits: ProfileApplication DeviceProfile: DareMessage (Optional) Device profile of the device making the request. Permissions: Permission [0..Many] List of the permissions that the device has been granted. 2.6.10. Structure: ProfileMeshDevicePrivate Inherits: ProfileApplication Inherits: ProfileApplication Permissions: Permission [0..Many] List of the permissions that the device has been granted. ProfileNonce: Binary (Optional) Random nonce used to mask the fingerprint of the profile UDF. ProfileWitness: Binary (Optional) Witness value calculated over the ProfileNonce and profile UDF 2.6.11. Structure: DeviceRecryptionKey UDF: String (Optional) The fingerprint of the encryption key RecryptionKey: PublicKey (Optional) The recryption key DeviceRecryptionKeyEncrypted: DareMessage (Optional) The decryption key encrypted under the user's device key. 2.7. Common Structures 2.7.1. Structure: Permission Name: String (Optional) Name: String (Optional) Role: String (Optional) Role: String (Optional) Hallam-Baker Expires October 6, 2019 [Page 8] Internet-Draft Mathematical Mesh Reference April 2019 Capabilities: DareMessage (Optional) Keys or key contributions enabling the operation to be performed 2.7.2. Structure: Contact Identifier: String (Optional) Identifier: String (Optional) Account: String (Optional) Account: String (Optional) FullName: String (Optional) FullName: String (Optional) Title: String (Optional) Title: String (Optional) First: String (Optional) First: String (Optional) Middle: String (Optional) Middle: String (Optional) Last: String (Optional) Last: String (Optional) Suffix: String (Optional) Suffix: String (Optional) Labels: String [0..Many] Labels: String [0..Many] Addresses: Address [0..Many] Addresses: Address [0..Many] Locations: Location [0..Many] Locations: Location [0..Many] Hallam-Baker Expires October 6, 2019 [Page 9] Internet-Draft Mathematical Mesh Reference April 2019 Roles: Role [0..Many] 2.7.3. Structure: Role CompanyName: String (Optional) CompanyName: String (Optional) Addresses: Address [0..Many] Addresses: Address [0..Many] Locations: Location [0..Many] 2.7.4. Structure: Address URI: String (Optional) URI: String (Optional) Labels: String [0..Many] 2.7.5. Structure: Location Appartment: String (Optional) Appartment: String (Optional) Street: String (Optional) Street: String (Optional) District: String (Optional) District: String (Optional) Locality: String (Optional) Locality: String (Optional) County: String (Optional) County: String (Optional) Postcode: String (Optional) Postcode: String (Optional) Hallam-Baker Expires October 6, 2019 [Page 10] Internet-Draft Mathematical Mesh Reference April 2019 Country: String (Optional) 2.7.6. Structure: Reference MessageID: String (Optional) The received message to which this is a response ResponseID: String (Optional) Message that was generated in response to the original (optional). Relationship: String (Optional) The relationship type. This can be Read, Unread, Accept, Reject. 2.8. Catalog Entries 2.8.1. Structure: CatalogEntry [No fields] 2.8.2. Structure: CatalogEntryDevice Inherits: CatalogEntry Public device entry, indexed under the device ID Account: String (Optional) The Account to which this entry binds this device. UDF: String (Optional) UDF of the signature key AuthUDF: String (Optional) UDF of the authentication ID ProfileMeshDevicePublicSigned: DareMessage (Optional) The device profile ProfileMeshDevicePrivateEncrypted: DareMessage (Optional) The device profile DeviceRecryptionKeys: DeviceRecryptionKey [0..Many] Decryption key entries. 2.8.3. Structure: CatalogEntryCredential Inherits: CatalogEntry Inherits: CatalogEntry Protocol: String (Optional) Hallam-Baker Expires October 6, 2019 [Page 11] Internet-Draft Mathematical Mesh Reference April 2019 Protocol: String (Optional) Service: String (Optional) Service: String (Optional) Username: String (Optional) Username: String (Optional) Password: String (Optional) 2.8.4. Structure: CatalogEntryNetwork Inherits: CatalogEntry Inherits: CatalogEntry Protocol: String (Optional) Protocol: String (Optional) Service: String (Optional) Service: String (Optional) Username: String (Optional) Username: String (Optional) Password: String (Optional) 2.8.5. Structure: CatalogEntryContact Inherits: CatalogEntry Inherits: CatalogEntry Key: String (Optional) Unique key. Permissions: Permission [0..Many] List of the permissions that the contact has been granted. Contact: DareMessage (Optional) The (signed) contact data. Hallam-Baker Expires October 6, 2019 [Page 12] Internet-Draft Mathematical Mesh Reference April 2019 2.8.6. Structure: CatalogEntryContactRecryption Inherits: CatalogEntryContact [No fields] 2.8.7. Structure: CatalogEntryBookmark Inherits: CatalogEntry Inherits: CatalogEntry Uri: String (Optional) Uri: String (Optional) Title: String (Optional) Title: String (Optional) Path: String (Optional) 2.8.8. Structure: CatalogEntryTask Inherits: CatalogEntry Inherits: CatalogEntry Task: DareMessage (Optional) Task: DareMessage (Optional) Key: String (Optional) Unique key. 2.8.9. Structure: Task Key: String (Optional) Unique key. Start: DateTime (Optional) Start: DateTime (Optional) Finish: DateTime (Optional) Finish: DateTime (Optional) StartTravel: String (Optional) Hallam-Baker Expires October 6, 2019 [Page 13] Internet-Draft Mathematical Mesh Reference April 2019 StartTravel: String (Optional) FinishTravel: String (Optional) FinishTravel: String (Optional) TimeZone: String (Optional) TimeZone: String (Optional) Title: String (Optional) Title: String (Optional) Description: String (Optional) Description: String (Optional) Location: String (Optional) Location: String (Optional) Trigger: String [0..Many] Trigger: String [0..Many] Conference: String [0..Many] Conference: String [0..Many] Repeat: String (Optional) Repeat: String (Optional) Busy: Boolean (Optional) 2.8.10. Structure: CatalogEntryApplication Inherits: CatalogEntry Inherits: CatalogEntry Key: String (Optional) Hallam-Baker Expires October 6, 2019 [Page 14] Internet-Draft Mathematical Mesh Reference April 2019 2.8.11. Structure: CatalogEntryApplicationEntry [No fields] 2.8.12. Structure: CatalogEntryApplicationRecryption [No fields] 2.8.13. Structure: CatalogEntryApplicationSSH [No fields] 2.8.14. Structure: CatalogEntryApplicationMail [No fields] 2.8.15. Structure: CatalogEntryApplicationNetwork [No fields] 2.9. Messages 2.9.1. Structure: MeshMessage MessageID: String (Optional) MessageID: String (Optional) Sender: String (Optional) Sender: String (Optional) Recipient: String (Optional) Recipient: String (Optional) References: Reference [0..Many] 2.9.2. Structure: MeshMessageComplete Inherits: MeshMessage [No fields] Hallam-Baker Expires October 6, 2019 [Page 15] Internet-Draft Mathematical Mesh Reference April 2019 2.9.3. Structure: MessageConnectionRequest Inherits: MeshMessage Inherits: MeshMessage Account: String (Optional) Account: String (Optional) DeviceProfile: DareMessage (Optional) Device profile of the device making the request. ClientNonce: Binary (Optional) ClientNonce: Binary (Optional) ServerNonce: Binary (Optional) ServerNonce: Binary (Optional) Witness: String (Optional) Witness: String (Optional) PinID: String (Optional) Pin identifier used to identify a PIN authenticated request. 2.9.4. Structure: MessageConnectionPIN Inherits: MeshMessage Inherits: MeshMessage Account: String (Optional) Account: String (Optional) Expires: DateTime (Optional) Expires: DateTime (Optional) PIN: String (Optional) Hallam-Baker Expires October 6, 2019 [Page 16] Internet-Draft Mathematical Mesh Reference April 2019 2.9.5. Structure: MessageContactRequest Inherits: MeshMessage Inherits: MeshMessage Contact: DareMessage (Optional) The contact data. 2.9.6. Structure: MessageConfirmationRequest Inherits: MeshMessage Inherits: MeshMessage Text: String (Optional) 2.9.7. Structure: MessageConfirmationResponse Inherits: MeshMessage Inherits: MeshMessage ResponseID: String (Optional) ResponseID: String (Optional) Accept: Boolean (Optional) 2.9.8. Structure: MessageTaskRequest Inherits: MeshMessage [No fields] 3. Mesh Portal Service Reference HTTP Well Known Service Prefix: /.well-known/mmm 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. Hallam-Baker Expires October 6, 2019 [Page 17] Internet-Draft Mathematical Mesh Reference April 2019 3.1. Request Messages 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. 3.1.1. Message: MeshRequest Base class for all request messages. Portal: String (Optional) Name of the Mesh Portal Service to which the request is directed. 3.2. Response Messages 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. 3.2.1. Message: MeshResponse Base class for all response messages. Contains only the status code and status description fields. [No fields] 3.3. Imported Objects The Mesh Service protocol makes use of JSON objects defined in the JOSE Signatgure and Encryption specifications. 3.4. Common Structures The following common structures are used in the protocol messages: 3.4.1. Structure: KeyValue Describes a Key/Value structure used to make queries for records matching one or more selection criteria. Key: String (Optional) The data retrieval key. Value: String (Optional) The data value to match. Hallam-Baker Expires October 6, 2019 [Page 18] Internet-Draft Mathematical Mesh Reference April 2019 3.4.2. Structure: SearchConstraints 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. NotBefore: DateTime (Optional) Only data published on or after the specified time instant is requested. Before: DateTime (Optional) Only data published before the specified time instant is requested. This excludes data published at the specified time instant. MaxEntries: Integer (Optional) Maximum number of data entries to return. MaxBytes: Integer (Optional) Maximum number of data bytes to return. PageKey: String (Optional) 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. 3.5. Transaction: Hello Request: HelloRequest Request: HelloRequest Response: HelloResponse 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. 3.6. Transaction: ValidateAccount Request: ValidateRequest Request: ValidateRequest Response: ValidateResponse Hallam-Baker Expires October 6, 2019 [Page 19] Internet-Draft Mathematical Mesh Reference April 2019 Request validation of a proposed name for a new account. For validation of a user's account name during profile creation. 3.6.1. Message: ValidateRequest Inherits: MeshRequest Describes the proposed account properties. Currently, these are limited to the account name but could be extended in future versions of the protocol. Account: String (Optional) Account name requested Reserve: Boolean (Optional) If true, request a reservation for the specified account name. Note that the service is not obliged to honor reservation requests. Language: String [0..Many] List of ISO language codes in order of preference. For creating explanatory text. 3.6.2. Message: ValidateResponse Inherits: MeshResponse 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. Valid: Boolean (Optional) If true, the specified account identifier is acceptable. If false, the account identifier is rejected. Minimum: Integer (Optional) Specifies the minimum length of an account name. Maximum: Integer (Optional) Specifies the maximum length of an account name. InvalidCharacters: String (Optional) A list of characters that the service does not accept in account names. The list of characters Hallam-Baker Expires October 6, 2019 [Page 20] Internet-Draft Mathematical Mesh Reference April 2019 MAY not be exhaustive but SHOULD include any illegal characters in the proposed account name. Reason: String (Optional) Text explaining the reason an account name was rejected. 3.7. Transaction: CreateAccount Request: CreateRequest Request: CreateRequest Response: CreateResponse 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. 3.7.1. Message: CreateRequest Request creation of a new portal account. The request specifies the requested account identifier and the Mesh profile to be associated with the account. Inherits: MeshRequest Inherits: MeshRequest Account: String (Optional) Account identifier requested. 3.7.2. Message: CreateResponse Inherits: MeshResponse Reports the success or failure of a Create transaction. [No fields] 3.8. Transaction: DeleteAccount Request: DeleteRequest Request: DeleteRequest Response: DeleteResponse Hallam-Baker Expires October 6, 2019 [Page 21] Internet-Draft Mathematical Mesh Reference April 2019 Request deletion of a portal account. Deletes a portal account but not the underlying profile. Once registered, profiles are permanent. 3.8.1. Message: DeleteRequest Request deletion of a new portal account. The request specifies the requested account identifier. Inherits: MeshRequest Inherits: MeshRequest Account: String (Optional) Account identifier to be deleted. 3.8.2. Message: DeleteResponse Inherits: MeshResponse Reports the success or failure of a Delete transaction. [No fields] 3.9. Transaction: Get Request: GetRequest Request: GetRequest Response: GetResponse Search for data in the mesh that matches a set of properties described by a sequence of key/value pairs. 3.9.1. Message: GetRequest Describes the Portal or Mesh data to be retreived. Inherits: MeshRequest Inherits: MeshRequest Identifier: String (Optional) Lookup by profile ID Account: String (Optional) Lookup by Account ID Hallam-Baker Expires October 6, 2019 [Page 22] Internet-Draft Mathematical Mesh Reference April 2019 KeyValues: KeyValue [0..Many] List of KeyValue pairs specifying the conditions to be met SearchConstraints: SearchConstraints (Optional) Constrain the search to a specific time interval and/or limit the number and/or total size of data records returned. Multiple: Boolean (Optional) If true return multiple responses if available Full: Boolean (Optional) 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. 3.9.2. Message: GetResponse 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. Inherits: MeshResponse Inherits: MeshResponse DataItems: DataItem [0..Many] List of mesh data records matching the request. PageKey: String (Optional) 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. 3.10. Transaction: Publish Request: PublishRequest Request: PublishRequest Response: PublishResponse Publish a profile or key escrow entry to the mesh. 3.10.1. Message: PublishRequest Requests publication of the specified Mesh entry. Inherits: MeshRequest Hallam-Baker Expires October 6, 2019 [Page 23] Internet-Draft Mathematical Mesh Reference April 2019 [No fields] 3.10.2. Message: PublishResponse Reports the success or failure of a Publish transaction. Inherits: MeshResponse [No fields] 3.11. Transaction: Status Request: StatusRequest Request: StatusRequest Response: StatusResponse 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] 3.11.1. Message: StatusRequest Inherits: MeshRequest Initiates a status transaction. [No fields] 3.11.2. Message: StatusResponse Reports the success or failure of a Status transaction. Inherits: MeshResponse Inherits: MeshResponse LastWriteTime: DateTime (Optional) Time that the last write update was made to the Mesh LastCheckpointTime: DateTime (Optional) Time that the last Mesh checkpoint was calculated. Hallam-Baker Expires October 6, 2019 [Page 24] Internet-Draft Mathematical Mesh Reference April 2019 NextCheckpointTime: DateTime (Optional) Time at which the next Mesh checkpoint should be calculated. CheckpointValue: String (Optional) Last checkpoint value. 3.12. Transaction: ConnectStart Request: ConnectStartRequest Request: ConnectStartRequest Response: ConnectStartResponse Request connection of a new device to a mesh profile 3.12.1. Message: ConnectStartRequest Inherits: MeshRequest Initial device connection request. SignedRequest: SignedConnectionRequest (Optional) Device connection request signed by thesignature key of the device requesting connection. AccountID: String (Optional) Account identifier of account to which the device is requesting connection. 3.12.2. Message: ConnectStartResponse Reports the success or failure of a ConnectStart transaction. Inherits: MeshRequest [No fields] 3.13. Transaction: ConnectStatus Request: ConnectStatusRequest Request: ConnectStatusRequest Response: ConnectStatusResponse Request status of pending connection request of a new device to a mesh profile Hallam-Baker Expires October 6, 2019 [Page 25] Internet-Draft Mathematical Mesh Reference April 2019 3.13.1. Message: ConnectStatusRequest Inherits: MeshRequest Request status information for a pending request posted previously. AccountID: String (Optional) Account identifier for which pending connection information is requested. DeviceID: String (Optional) Device identifier of device requesting status information. 3.13.2. Message: ConnectStatusResponse Reports the success or failure of a ConnectStatus transaction. Inherits: MeshRequest Inherits: MeshRequest Result: SignedConnectionResult (Optional) The signed ConnectionResult object. 3.14. Transaction: ConnectPending Request: ConnectPendingRequest Request: ConnectPendingRequest Response: ConnectPendingResponse Request a list of pending requests for an administration profile. 3.14.1. Message: ConnectPendingRequest Inherits: MeshRequest Specify the criteria for pending requests. AccountID: String (Optional) The account identifier of the account for which pending connection requests are requested. SearchConstraints: SearchConstraints (Optional) Constrain the search to a specific time interval and/or limit the number and/or total size of data records returned. Hallam-Baker Expires October 6, 2019 [Page 26] Internet-Draft Mathematical Mesh Reference April 2019 3.14.2. Message: ConnectPendingResponse Reports the success or failure of a ConnectPending transaction. Inherits: MeshRequest Inherits: MeshRequest Pending: SignedConnectionRequest [0..Many] A list of pending requests satisfying the criteria set out in the request. PageKey: String (Optional) 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. 3.15. Transaction: ConnectComplete Request: ConnectCompleteRequest Request: ConnectCompleteRequest Response: ConnectCompleteResponse Post response to a pending connection request. 3.15.1. Message: ConnectCompleteRequest Reports the success or failure of a ConnectComplete transaction. Inherits: MeshRequest Inherits: MeshRequest Result: SignedConnectionResult (Optional) The connection result to be posted to the portal. The result MUST be signed by a valid administration key for the Mesh profile. AccountID: String (Optional) The account identifier to which the connection result is posted. 3.15.2. Message: ConnectCompleteResponse Inherits: MeshRequest Reports the success or failure of a ConnectComplete transaction. [No fields] Hallam-Baker Expires October 6, 2019 [Page 27] Internet-Draft Mathematical Mesh Reference April 2019 3.16. Transaction: Transfer Request: TransferRequest Request: TransferRequest Response: TransferResponse Perform a bulk transfer of the log between the specified transaction identifiers. Requires appropriate authorization [Not currently implemented] 3.16.1. Message: TransferRequest Request a bulk transfer of the log between the specified transaction identifiers. Requires appropriate authorization Inherits: MeshRequest Inherits: MeshRequest SearchConstraints: SearchConstraints (Optional) Constrain the search to a specific time interval and/or limit the number and/or total size of data records returned. 3.16.2. Message: TransferResponse Inherits: MeshResponse Reports the success or failure of a Transfer transaction. If successful, contains the list of Mesh records to be transferred. DataItems: DataItem [0..Many] List of mesh data records matching the request. PageKey: String (Optional) 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. 4. Assets 4.1. Data Hallam-Baker Expires October 6, 2019 [Page 28] Internet-Draft Mathematical Mesh Reference April 2019 4.2. Credentials 4.3. Reputation 4.3.1. Outbound Messaging Abuse () 5. Risks 5.1. Confidentiality Is a regulatory requirement GDPR/HIPPA 5.1.1. Privacy Stronger requirement, given data but with restrictions on use Unintended use within an organization may put it in default GDPR HIPPA 5.2. Integrity Modification of data enables control breaches 5.3. Availability 5.3.1. Data loss Loss of the pictures of the kids at 5 5.3.2. Partial data survivability Where they buried Aunt Agatha's jewelry but not where they buried Aunt Agatha. 5.4. Inbound Messaging Abuse (Spam) 6. Threats 6.1. End point Compromise 6.2. Hallam-Baker Expires October 6, 2019 [Page 29] Internet-Draft Mathematical Mesh Reference April 2019 7. Controls 7.1. Cryptographic 7.1.1. Triple lock 7.1.1.1. Transport Security Traffic analysis protection 7.1.1.2. Message Security Access control Authentication / Integrity 7.1.1.3. Data Level Security Data Confidentiality Non-Repudiation 7.1.2. Key Protection 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. 7.1.2.1. Windows Use encrypted key store Preferably use BitLocker 7.1.2.2. OSX Use Key Ring 7.1.2.3. iOS Use ??? 7.1.2.4. Linux Use the DBUS mechanism Hallam-Baker Expires October 6, 2019 [Page 30] Internet-Draft Mathematical Mesh Reference April 2019 7.1.2.5. Android Hope and prayers. 7.1.3. Key and Nonce Generation Use strong mechanisms as described in RFC??? Use of key co-generation as described in part 8 is advised 7.1.4. Key Escrow and Recovery 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. 7.1.5. Profile Verification 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. 7.1.6. Identity Validation See the separate document on the trust model 7.1.7. Trust Broker Accountability Cert transparency type techniques 7.2. Mesh Messaging 7.2.1. Ingress Control 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. Hallam-Baker Expires October 6, 2019 [Page 31] Internet-Draft Mathematical Mesh Reference April 2019 7.2.2. Egress Control Some applications may require egress control For example, classified environments Mail too stupid to send 7.2.3. Security Signal 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 7.2.3.1. Brand If messages are being sent on behalf of a corporate entity, this should be signaled to both sender and receiver Sender ? remind them that they are speaking on behalf of another party Receiver ? establish who is speaking by the familiar technique. 7.2.4. Accountability Authentication and consequences 8. Security Considerations This document comprises the security considerations for the use and implementation of the Mathematical Mesh. 9. IANA Considerations All the IANA considerations for the Mesh documents are specified in this document 10. Acknowledgements Hallam-Baker Expires October 6, 2019 [Page 32] Internet-Draft Mathematical Mesh Reference April 2019 11. References 11.1. Normative References [draft-hallambaker-mesh-architecture] Hallam-Baker, P., "Mathematical Mesh Part I: Architecture Guide", draft-hallambaker-mesh-architecture-06 (work in progress), August 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. 11.2. Informative References [draft-hallambaker-mesh-developer] Hallam-Baker, P., "Mathematical Mesh: Reference Implementation", draft-hallambaker-mesh-developer-07 (work in progress), April 2018. 11.3. URIs [1] http://mathmesh.com/Documents/draft-hallambaker-mesh- security.html Author's Address Phillip Hallam-Baker Email: phill@hallambaker.com Hallam-Baker Expires October 6, 2019 [Page 33]