idnits 2.17.1 draft-hallambaker-mesh-app-ssh-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 18, 2017) is 2444 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Informational August 18, 2017 5 Expires: February 19, 2018 7 Mathematical Mesh: SSH Application 8 draft-hallambaker-mesh-app-ssh-01 10 Abstract 12 Mesh/SSH 14 The use of the Mathematical Mesh to manage OpenSSH Keys is described. 16 This document is also available online at 17 http://prismproof.org/Documents/draft-hallambaker-mesh-app-ssh.html . 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 19, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2.2. Related Specifications . . . . . . . . . . . . . . . . . 3 57 2.3. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3 58 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 4 59 3. User Experience . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Initial profile creation . . . . . . . . . . . . . . . . 4 61 3.2. Configuring SSH for machine X . . . . . . . . . . . . . . 4 62 3.3. Configuring SSH for machine Y . . . . . . . . . . . . . . 4 63 3.4. Configuring SSH for machine Z . . . . . . . . . . . . . . 5 64 3.5. Deleting a Device . . . . . . . . . . . . . . . . . . . . 5 65 3.6. Future directions . . . . . . . . . . . . . . . . . . . . 5 66 3.6.1. Native Mesh support in SSH . . . . . . . . . . . . . 5 67 3.6.2. Update Daemon . . . . . . . . . . . . . . . . . . . . 5 68 3.6.3. Batched Connection Requests . . . . . . . . . . . . . 6 69 3.6.4. Enhanced administration . . . . . . . . . . . . . . . 6 70 4. Platform Bindings . . . . . . . . . . . . . . . . . . . . . . 6 71 4.1. OpenSSH Files . . . . . . . . . . . . . . . . . . . . . . 6 72 5. Application Profile . . . . . . . . . . . . . . . . . . . . . 6 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 78 9.2. Informative References . . . . . . . . . . . . . . . . . 7 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 81 1. Introduction 83 The Secure Shell (SSH) transport layer protocol [!RFC4253] is widely 84 used as a mechanism for securing access to remote hosts. In addition 85 to providing a terminal connection to a remote host, SSH also 86 supports file transfer and remote access (VPN) functionality. It is 87 also used to provide remote procedure call (RPC) capabilities in 88 applications such as Git. 90 While SSH permits a high level of security to be achieved, achieving 91 a high security configuration requires a considerable degree of 92 attention to detail. Numerous ?how to? guides found on the Internet 93 advise the user to engage in many unsafe practices. These include: 95 Using a single private key for authentication for every machine to be 96 used as a client. 98 Emailing a copy of the authentication key to yourself to transfer it 99 to a new machine. (Alternatively use of insecure FTP, copying the 100 data to /temp, etc.) 102 Of equal concern was the fact that none of the guides mentioned any 103 form of maintenance activity such as deleting authentication keys for 104 a decommissioned device or performing a rekey operation in the case 105 that a device is compromised. 107 Configuring SSH securely is a non-trivial task because SSH is the 108 tool through which the administrator will be connecting to secure 109 their system. This is a bootstrap problem: It is easy to solve the 110 problem of SSH configuration once we have SSH configured for use. To 111 enable SSH access to a 113 The Mathematical Mesh provides an infrastructure for single touch 114 administration of all the devices a user has connected to their Mesh 115 profile. Managing SSH configuration with the Mesh guides the user 116 towards use of a maximally secure configuration. Once the 117 configuration is achieved, it is maintained automatically. 119 2. Definitions 121 This section presents the related specifications and standard, the 122 terms that are used as terms of art within the documents and the 123 terms used as requirements language. 125 2.1. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119] [RFC2119] . 131 2.2. Related Specifications 133 The related specifications are described in the Mesh Architecture 134 specification [draft-hallambaker-mesh-architecture] 135 [draft-hallambaker-mesh-architecture] 137 2.3. Defined Terms 139 No terms of art are defined. 141 2.4. Implementation Status 143 The implementation status of the reference code base is described in 144 the companion document [draft-hallambaker-mesh-developer] 145 [draft-hallambaker-mesh-developer] . 147 3. User Experience 149 Alice is a user of three machines, X, Y and Z. Machines X and Y are 150 configured with monitors and keyboards enabling their use as an SSH 151 client. Machine Z is to be configured as a headless machine (no 152 monitor). When finished, Alice wants to be able to connect to 153 machines X, Y or Z from machine X or Y. 155 Since SSH is a tool principally used on UNIX based systems and 156 machines configured to provide similar behavior, this guide assumes 157 machines X, Y and Z are all UNIX systems when describing the files to 158 be modified. When used on a Windows machine, the Mesh tools 159 configure the equivalent Windows files. 161 3.1. Initial profile creation 163 If this is the first time Alice has used the Mesh, she creates a 164 personal profile for herself on machine X: 166 X> meshman /personal alice@mesh.prismproof.org 168 3.2. Configuring SSH for machine X 170 To configure SSH on machine X, Alice adds it to her profile. 172 X> meshman /ssh 174 Note that the meshman tool only performs the 176 At this point, Alice has a new private key that is unique to machine 177 X and the corresponding public key has been added to her profile 179 3.3. Configuring SSH for machine Y 181 To configure the second machine, Alice first requests adding it to 182 her profile: 184 Y> 186 This request must be accepted on machine X: 188 X> 189 Alice now adds the SSH profile to machine Y: 191 Y> meshman /ssh 193 At this point machines X and Y both have a unique private key and 194 both the corresponding public keys have been added to the authorized 195 key files on Y. The authorized key file on X will be updated by a 196 mesh profile manager running periodically. 198 3.4. Configuring SSH for machine Z 200 Configuration of machine Z begins in exactly the same way as for 201 machine Y. The only difference is that when she creates the SSH 202 profile for the device, she requests it be a host only profile: 204 Z> meshman /ssh /host 206 3.5. Deleting a Device 208 3.6. Future directions 210 3.6.1. Native Mesh support in SSH 212 The chief weakness in this user experience is that the machines 213 cannot update themselves automatically or even know when an update is 214 required. The only approach that is available is for the host 215 devices to periodically poll the Mesh portal and request updates for 216 the registered profiles. 218 This delay can be avoided if the SSH protocol and implementations 219 were updated to support direct use of Mesh profiles. This allows a 220 client to push the updated profile data to the server when making the 221 connection attempt. 223 3.6.2. Update Daemon 225 Native support allows the process of adding devices to be automated 226 but does not guarantee timely processing of deletion requests. It 227 also requires action by third parties who may not be interested in 228 providing Mesh support. 230 A better approach would be to run a daemon on each machine that could 231 receive update notifications from the portal whenever a significant 232 event (profile addition/deletion) had occurred. 234 3.6.3. Batched Connection Requests 236 The existing management tools require a device to be connected to a 237 profile before use of applications are enabled on the device. 239 3.6.4. Enhanced administration 241 While this approach is functional, it does not meet the requirement 242 for complete mediation of the log in request. While the system 243 administrator has the ability to permit or deny remote access 244 capabilities to a user, these are the only options that the 245 administration tools currently supported by most SSH configurations 246 provide. The administrator cannot control the types of credentials 247 used by specific users. 249 The Mesh could be employed to permit a closer level of control. 250 Storing the user?s profile fingerprint in the password database 251 (/etc/passwd or /etc/shadow) would allow every application and system 252 utility to refer to a single root of trust for authenticating every 253 credential presented by a user. 255 4. Platform Bindings 257 Since SSH is an application program 259 4.1. OpenSSH Files 261 Contains a list of all the keys that are authorized to access the 262 corresponding account. This is a list of Mesh SSH per device 263 application keys. 265 Default name for the user?s RSA public key 267 Default name for the user?s RSA private key 269 List of host keys known to this user. 271 5. Application Profile 273 6. Acknowledgements 275 7. Security Considerations 277 [This is just a sketch for the present.] 279 8. IANA Considerations 281 [TBS list out all the code points that require an IANA registration] 283 9. References 285 9.1. Normative References 287 [draft-hallambaker-mesh-architecture] 288 Hallam-Baker, P., "Mathematical Mesh: Architecture", 289 draft-hallambaker-mesh-architecture-03 (work in progress), 290 May 2017. 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, 294 DOI 10.17487/RFC2119, March 1997. 296 9.2. Informative References 298 [draft-hallambaker-mesh-developer] 299 Hallam-Baker, P., "Mathematical Mesh: Developer's Guide", 300 draft-hallambaker-mesh-developer-02 (work in progress), 301 September 2016. 303 Author's Address 305 Phillip Hallam-Baker 306 Comodo Group Inc. 308 Email: philliph@comodo.com