Internet-Draft Mathematical Mesh: SSH Application September 2016
Hallam-Baker Expires 23 March 2017 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-hallambaker-mesh-app-ssh-00
Published:
Intended Status:
Informational
Expires:
Author:
P. M. Hallam-Baker
Comodo Group Inc.

Mathematical Mesh: SSH Application

Abstract

The use of the Mathematical Mesh to manage OpenSSH Keys is described.

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 http://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 23 March 2017.

Table of Contents

1. Introduction

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

The Mathematical Mesh provides an infrastructure for single touch administration of all the devices a user has connected to their Mesh profile. Managing SSH configuration with the Mesh guides the user towards use of a maximally secure configuration. Once the configuration is achieved, it is maintained automatically.

2. Definitions

[Please note that due to work in progress to support the new RFC format etc, some of the formatting features are not currently working as they should. These will be fixed in a future version.]

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].

The Mathematical Mesh [draft-hallambaker-mesh-architecture-01] [draft-hallambaker-mesh-reference-02]

Is..

2.3. Terminology

The following terms are used as terms of art in this document with the meaning specified below:

3. User Experience

Alice is a user of three machines, X, Y and Z. Machines X and Y are configured with monitors and keyboards enabling their use as an SSH client. Machine Z is to be configured as a headless machine (no monitor). When finished, Alice wants to be able to connect to machines X, Y or Z from machine X or Y.

Since SSH is a tool principally used on UNIX based systems and machines configured to provide similar behavior, this guide assumes machines X, Y and Z are all UNIX systems when describing the files to be modified. When used on a Windows machine, the Mesh tools configure the equivalent Windows files.

3.1. Initial profile creation

If this is the first time Alice has used the Mesh, she creates a personal profile for herself on machine X:

X> meshman /personal alice@mesh.prismproof.org

3.2. Configuring SSH for machine X

To configure SSH on machine X, Alice adds it to her profile.

X> meshman /ssh

Note that the meshman tool only performs the

At this point, Alice has a new private key that is unique to machine X and the corresponding public key has been added to her profile

3.3. Configuring SSH for machine Y

To configure the second machine, Alice first requests adding it to her profile:

Y>

This request must be accepted on machine X:

X>

Alice now adds the SSH profile to machine Y:

Y> meshman /ssh

At this point machines X and Y both have a unique private key and both the corresponding public keys have been added to the authorized key files on Y. The authorized key file on X will be updated by a mesh profile manager running periodically.

3.4. Configuring SSH for machine Z

Configuration of machine Z begins in exactly the same way as for machine Y. The only difference is that when she creates the SSH profile for the device, she requests it be a host only profile:

Z> meshman /ssh /host

3.6. Future directions

3.6.1. Native Mesh support in SSH

The chief weakness in this user experience is that the machines cannot update themselves automatically or even know when an update is required. The only approach that is available is for the host devices to periodically poll the Mesh portal and request updates for the registered profiles.

This delay can be avoided if the SSH protocol and implementations were updated to support direct use of Mesh profiles. This allows a client to push the updated profile data to the server when making the connection attempt.

3.6.2. Update Daemon

Native support allows the process of adding devices to be automated but does not guarantee timely processing of deletion requests. It also requires action by third parties who may not be interested in providing Mesh support.

A better approach would be to run a daemon on each machine that could receive update notifications from the portal whenever a significant event (profile addition/deletion) had occurred.

3.6.3. Batched Connection Requests

The existing management tools require a device to be connected to a profile before use of applications are enabled on the device.

3.6.4. Enhanced administration

While this approach is functional, it does not meet the requirement for complete mediation of the log in request. While the system administrator has the ability to permit or deny remote access capabilities to a user, these are the only options that the administration tools currently supported by most SSH configurations provide. The administrator cannot control the types of credentials used by specific users.

The Mesh could be employed to permit a closer level of control. Storing the user's profile fingerprint in the password database (/etc/passwd or /etc/shadow) would allow every application and system utility to refer to a single root of trust for authenticating every credential presented by a user.

4. Application Profile

5. Acknowledgements

6. Implementation Status

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 6982. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.

According to RFC 6982, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

6.1. Reference Implementation

Organization: Comodo Group Inc.

Implementer: Phillip Hallam-Baker

Maturity: Experimental Prototype

This implementation was used to produce the reference section and all the examples in this document. Since the conversion of specification to code is automatic, there is a high degree of assurance that the reference implementation is consistent with this document.

6.1.1. Coverage:

The draft-xx branch describes the code used to create version xx of this document.

The main current limitations are that the code only supports RSA key pairs and for ease of development the server does not persist keys across sessions. Nor does the implementation currently support the HTTP payload authentication and encryption layer or make use of TLS. These could be easily fixed.

The client and server are implemented as libraries that may be called from a multi-protocol server. A standalone server will be provided in a future release.

Only the JSON encoding is currently implemented. The JSON-B, JSON-C, ASN.1 and TLS Schema implementations are all supported by the code generation tool but not currently implemented as the build tool bindings for those encodings have not yet been finalized or documented.

The key restrictions for TLS key exchange have not yet been implemented.

The code has only been tested on Windows 10 but passed compatibility testing for both Mono and dotNetCore 10 run times which should in theory permit use on Linux and OSX platforms.

6.1.2. Licensing

The code is released under an MIT License

Source code is available from GitHub at https://github.com/hallambaker/LURK-PHB

6.1.3. Implementation Experience

The implementation and specification documentation were developed in Visual Studio using the PHB Build Tools suite.

6.1.4. Contact Info

Contact Phillip Hallam-Baker phill@hallambaker.com

7. Security Considerations

[This is just a sketch for the present.]

8. IANA Considerations

[TBS list out all the code points that require an IANA registration]

9. Normative References

[draft-hallambaker-mesh-architecture-01]
"[Reference Not Found!]".
[draft-hallambaker-mesh-reference-02]
"[Reference Not Found!]".
[RFC4253]
Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, , <https://www.rfc-editor.org/rfc/rfc4253>.

Author's Address

Phillip Hallam-Baker
Comodo Group Inc.