| Network Working Group | P. Hallam-Baker |
| Internet-Draft | Comodo Group Inc. |
| Intended status: Informational | April 10, 2018 |
| Expires: October 12, 2018 |
Mathematical Mesh: Application Profiles
draft-hallambaker-mesh-app-01
The use of the Mathematical Mesh to manage cryptographic keys for use with Mail and SSH is described. The format of the application profiles is described with examples.
This document is also available online at http://prismproof.org/Documents/draft-hallambaker-mesh-app.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 October 12, 2018.
Copyright (c) 2018 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. 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.
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 related specifications are described in the Mesh Architecture specification [draft-hallambaker-mesh-architecture]
No terms of art are defined.
The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer] .
(Pull piece from Mesh Reference to here)
Catalog profiles are used to synchronize encrypted data sets across devices. The catalog data model is restricted so as to permit a common set of management tools to be used to access and maintain profiles containing different types of data (bookmarks, credentials, contacts, etc.). Catalogs do not contain per device data. A catalog may not be shared with every device in the user?s profile but all the data in a catalog is available to all the devices with which it is shared.
The management operations supported are:
Each catalog entry SHOULD contain exactly one timestamp field of time Added, Updated or Deleted. If present, the timestamp entries and the entry identifiers are used to merge catalog profiles that have been updated separately leading to an inconsistent state.
Applications SHOULD specify a timestamp field on every entry unless it is known that update inconsistency cannot occur. For example, when initially populating a catalog.
Alice creates a new bookmarks profile which is shared between her laptop and her phone. The initial profile is empty:
{
"BookmarkProfilePrivate": {
"Entries": []}}
Figure 1
Alice adds a bookmark entry to her profile on the browser on her laptop:
{
"BookmarkProfilePrivate": {
"Entries": [{
"Added": "2018-04-10T23:16:06Z",
"Title": "First Site",
"Uri": "http://example.com/"}]}}
Figure 2
Later, Alice is attempting to connect to a site on her phone but has no network connection. She decides to bookmark the site instead.
{
"BookmarkProfilePrivate": {
"Entries": [{
"Added": "2018-04-11T00:50:44Z",
"Title": "Second Site",
"Uri": "https://example.com/"}]}}
Figure 3
At this point, the profiles on Alice's two devices are out of sync. When the phone is finally able to connect to the network, the profiles are merged:
{
"BookmarkProfilePrivate": {
"Entries": [{
"Added": "2018-04-10T23:16:06Z",
"Title": "First Site",
"Uri": "http://example.com/"},
{
"Added": "2018-04-11T00:50:44Z",
"Title": "Second Site",
"Uri": "https://example.com/"}]}}
Figure 4
A credentials catalog contains access credentials, typically usernames and passwords, for a set of network resources such as Web sites that do not support the use of Mesh device profile data for authentication.
Mesh/Credential enabled applications SHOULD offer to generate strong passwords for the user if the AutoGenerate field is set to true in the credential profile. Since the use of automatically generated passwords is likely to be inconvenient for users unless all the applications on all the devices they might use support Mesh/Credential profiles, applications MUST NOT automatically generate passwords unless the user has affirmatively indicated that they want to use them.
Further Work: Credential entries MAY specify that the credential is restricted to use with certain protocols (Web browsing, SFTP, etc.) and/or certain authentication mechanisms but the precise means of identifying both is not currently defined.
{
"CredentialProfilePrivate": {
"AutoGenerate": true,
"Entries": [{
"Sites": ["luggage.example.net"],
"Username": "Alice",
"Password": "12345"},
{
"Label": ["Linux"],
"Sites": ["host.example.net"],
"Username": "BitAlice",
"Password": "password",
"Protocol": "ssh"}],
"NeverAsk": ["secure.example.com",
"bank.example.com"]}}
Figure 5
A bookmarks catalog contains a collection of bookmarks that have been saved for later use. While the ability share bookmarks between groups of users has obvious advantages, at present, the implementation and specification are only written with the use of a single user have been considered.
A bookmark entry contains the URI of the target and a title. If the book mark entry is a HTML resource, the title is taken from the <title> element in the document header. If network and storage resources permit, catalog entries MAY include a favicon value for easy identification.
Further Work: Bookmark entries MAY contain details describing the security properties of the connection to protect against downgrade attack. For example, information from HTTP strict security [RFC6797] and key pinning headers [RFC7460] .
tbs
A contacts catalog contains a collection of contacts. The ContactEntry object contains the usual fields for describing the person or organization the entry refers to, and means of contact (Internet, Postal).
One significant deviation from existing formats is that the fact that people change names (e.g. marriage) is captured and that means of contact MAY be scoped to a particular organization.
{
"ContactProfilePrivate": {
"Entries": [{
"Personals": [{
"First": "Alice"}],
"Internets": [{
"Uri": "mailto:alice@example.com"}]},
{
"Personals": [{
"First": "Bob"}],
"Internets": [{
"Uri": "mailto:bob@example.com"}]}]}}
Figure 6
It is generally acknowledged that representation of calendar information is a ?difficult? problem. Since it is the author?s experience that such problems almost invariably arise from an attempt to make use of an inadequate data model, the format for exchange of calendar information is currently undefined.
Further Work: Two major causes of difficulty are the use of local time zones and daylight savings, the definition of which are capricious at best. When a recurring meeting is specified it is vital that the time zone in which the meeting is to recur is specified explicitly. Attempts to normalize meetings to a single time zone will inevitably fail when the definition of time changes between the time the meeting is called and the meeting is held.
Another major limitation in existing formats is the lack of understanding that when the user travels, at least some part of their context for scheduling also changes. It should be possible to integrate all parts of the user?s schedule to offer alerts and reminders appropriate to their current location.
Mesh Mail profiles serve two distinct purposes:
The Secure Shell (SSH) transport layer protocol [RFC4253] is widely used as a mechanism for securing access to remote hosts. In addition to providing a terminal connection to a remote host, SSH also supports file transfer and remote access (VPN) functionality. It is also used to provide remote procedure call (RPC) capabilities in applications such as Git.
While SSH permits a high level of security to be achieved, achieving a high security configuration requires a considerable degree of attention to detail. Numerous ?how to? guides found on the Internet advise the user to engage in many unsafe practices. These include:
Using a single private key for authentication for every machine to be used as a client.
Emailing a copy of the authentication key to yourself to transfer it to a new machine. (Alternatively use of insecure FTP, copying the data to /temp, etc.)
Of equal concern was the fact that none of the guides mentioned any form of maintenance activity such as deleting authentication keys for a decommissioned device or performing a rekey operation in the case that a device is compromised.
Configuring SSH securely is a non-trivial task because SSH is the tool through which the administrator will be connecting to secure their system. This is a bootstrap problem: It is easy to solve the problem of SSH configuration once we have SSH configured for use. To enable SSH access to a machine without creating an insecure path first is not a trivial matter.
A Mesh/SSH profile contains three sets of information:
Catalogues are application profiles that consist of a set of related information (contacts, passwords, bookmarks) but do not contain any cryptographic private keys or device specific data. These restrictions allow management of these profiles to be simplified.
The following objects are common to multiple profiles.
Base class for all application profiles that are tied to an account profile
Base class for catalog entries, contains base information on which catalog operations are performed.
Typed content.
Profile for recording access credentials for Web sites and other projects. Currently this is limited to usernames and passwords but could expand to include other credential forms.
Stores usernames and passwords. There are no public fields.
[No fields]
Private part of the profile.
Username password entry for a single site
Profile for recording Web site bookmarks and related information.
Stores Web site bookmarks in a hierarchical
[No fields]
Private part of the profile.
Bookmark entry for a single site
Profile for recording user contact information
Stores Web site bookmarks in a hierarchical
[No fields]
Private part of the profile.
Contact entry
Personal name structure.
Contact address.
Internet contact address
Postal or geographic address.
Contact entry for a single person
Contact entry for a single organization
Stores usernames and passwords. There are no public fields.
[No fields]
Private part of the profile.
Describes network access credentials
Profiles that describe mail user agent configuration
Public profile describes mail receipt policy. Private describes Sending policy
Contains public device description
[No fields]
Describes a mail account configuration
Private profile contains connection settings for the inbound and outbound mail server(s) and cryptographic private keys. Public profile may contain security policy information for the sender.
Private data specific to the device
[No fields]
Profiles that describe SSH user agent configuration
Application profile for SSH. This is an initial cut of the profile and will need revision. In particular, a sysadmin with a very large number of hosts they are accessing will need some means of avoiding combinatorial explosion.
[No fields]
Contains public device description
Private portion or profile.
Describe a host connected to the SSH profile. This is a machine that the user will access using the credential.
Private data specific to the device
Your name could appear here.
[This is just a sketch for the present.]
[TBS list out all the code points that require an IANA registration]
| [draft-hallambaker-mesh-architecture] | Hallam-Baker, P., "Mathematical Mesh: Architecture", Internet-Draft draft-hallambaker-mesh-architecture-04, September 2017. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC4253] | Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006. |
| [RFC6797] | Hodges, J., Jackson, C. and A. Barth, "HTTP Strict Transport Security (HSTS)", RFC 6797, DOI 10.17487/RFC6797, November 2012. |
| [RFC7460] | Chandramouli, M., Claise, B., Schoening, B., Quittek, J. and T. Dietz, "Monitoring and Control MIB for Power and Energy", RFC 7460, DOI 10.17487/RFC7460, March 2015. |
| [draft-hallambaker-mesh-developer] | Hallam-Baker, P., "Mathematical Mesh: Reference Implementation", Internet-Draft draft-hallambaker-mesh-developer-05, September 2017. |