idnits 2.17.1 draft-hallambaker-mesh-app-ssh-00.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 (September 19, 2016) is 2775 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 126, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 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 September 19, 2016 5 Expires: March 23, 2017 7 Mathematical Mesh: SSH Application 8 draft-hallambaker-mesh-app-ssh-00 10 Abstract 12 The use of the Mathematical Mesh to manage OpenSSH Keys is described. 14 Status of This Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at http://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on March 23, 2017. 31 Copyright Notice 33 Copyright (c) 2016 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 51 2.2. Related Specifications . . . . . . . . . . . . . . . . . 3 52 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. User Experience . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Initial profile creation . . . . . . . . . . . . . . . . 4 55 3.2. Configuring SSH for machine X . . . . . . . . . . . . . . 4 56 3.3. Configuring SSH for machine Y . . . . . . . . . . . . . . 4 57 3.4. Configuring SSH for machine Z . . . . . . . . . . . . . . 5 58 3.5. Deleting a Device . . . . . . . . . . . . . . . . . . . . 5 59 3.6. Future directions . . . . . . . . . . . . . . . . . . . . 5 60 3.6.1. Native Mesh support in SSH . . . . . . . . . . . . . 5 61 3.6.2. Update Daemon . . . . . . . . . . . . . . . . . . . . 5 62 3.6.3. Batched Connection Requests . . . . . . . . . . . . . 5 63 3.6.4. Enhanced administration . . . . . . . . . . . . . . . 6 64 4. Application Profile . . . . . . . . . . . . . . . . . . . . . 6 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 66 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 67 6.1. Reference Implementation . . . . . . . . . . . . . . . . 6 68 6.1.1. Coverage: . . . . . . . . . . . . . . . . . . . . . . 7 69 6.1.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 7 70 6.1.3. Implementation Experience . . . . . . . . . . . . . . 7 71 6.1.4. Contact Info . . . . . . . . . . . . . . . . . . . . 8 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 The Secure Shell (SSH) transport layer protocol [RFC4253] is widely 80 used as a mechanism for securing access to remote hosts. In addition 81 to providing a terminal connection to a remote host, SSH also 82 supports file transfer and remote access (VPN) functionality. It is 83 also used to provide remote procedure call (RPC) capabilities in 84 applications such as Git. 86 While SSH permits a high level of security to be achieved, achieving 87 a high security configuration requires a considerable degree of 88 attention to detail. Numerous 'how to' guides found on the Internet 89 advise the user to engage in many unsafe practices. These include: 91 Using a single private key for authentication for every machine to be 92 used as a client. 94 Emailing a copy of the authentication key to yourself to transfer it 95 to a new machine. (Alternatively use of insecure FTP, copying the 96 data to /temp, etc.) 98 Of equal concern was the fact that none of the guides mentioned any 99 form of maintenance activity such as deleting authentication keys for 100 a decommissioned device or performing a rekey operation in the case 101 that a device is compromised. 103 Configuring SSH securely is a non-trivial task because SSH is the 104 tool through which the administrator will be connecting to secure 105 their system. This is a bootstrap problem: It is easy to solve the 106 problem of SSH configuration once we have SSH configured for use. To 107 enable SSH access to a 109 The Mathematical Mesh provides an infrastructure for single touch 110 administration of all the devices a user has connected to their Mesh 111 profile. Managing SSH configuration with the Mesh guides the user 112 towards use of a maximally secure configuration. Once the 113 configuration is achieved, it is maintained automatically. 115 2. Definitions 117 [Please note that due to work in progress to support the new RFC 118 format etc, some of the formatting features are not currently working 119 as they should. These will be fixed in a future version.] 121 2.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 2.2. Related Specifications 129 The Mathematical Mesh [draft-hallambaker-mesh-architecture-01] 130 [draft-hallambaker-mesh-reference-02] 132 Is.. 134 2.3. Terminology 136 The following terms are used as terms of art in this document with 137 the meaning specified below: 139 3. User Experience 141 Alice is a user of three machines, X, Y and Z. Machines X and Y are 142 configured with monitors and keyboards enabling their use as an SSH 143 client. Machine Z is to be configured as a headless machine (no 144 monitor). When finished, Alice wants to be able to connect to 145 machines X, Y or Z from machine X or Y. 147 Since SSH is a tool principally used on UNIX based systems and 148 machines configured to provide similar behavior, this guide assumes 149 machines X, Y and Z are all UNIX systems when describing the files to 150 be modified. When used on a Windows machine, the Mesh tools 151 configure the equivalent Windows files. 153 3.1. Initial profile creation 155 If this is the first time Alice has used the Mesh, she creates a 156 personal profile for herself on machine X: 158 X> meshman /personal alice@mesh.prismproof.org 160 3.2. Configuring SSH for machine X 162 To configure SSH on machine X, Alice adds it to her profile. 164 X> meshman /ssh 166 Note that the meshman tool only performs the 168 At this point, Alice has a new private key that is unique to machine 169 X and the corresponding public key has been added to her profile 171 3.3. Configuring SSH for machine Y 173 To configure the second machine, Alice first requests adding it to 174 her profile: 176 Y> 178 This request must be accepted on machine X: 180 X> 182 Alice now adds the SSH profile to machine Y: 184 Y> meshman /ssh 185 At this point machines X and Y both have a unique private key and 186 both the corresponding public keys have been added to the authorized 187 key files on Y. The authorized key file on X will be updated by a 188 mesh profile manager running periodically. 190 3.4. Configuring SSH for machine Z 192 Configuration of machine Z begins in exactly the same way as for 193 machine Y. The only difference is that when she creates the SSH 194 profile for the device, she requests it be a host only profile: 196 Z> meshman /ssh /host 198 3.5. Deleting a Device 200 3.6. Future directions 202 3.6.1. Native Mesh support in SSH 204 The chief weakness in this user experience is that the machines 205 cannot update themselves automatically or even know when an update is 206 required. The only approach that is available is for the host 207 devices to periodically poll the Mesh portal and request updates for 208 the registered profiles. 210 This delay can be avoided if the SSH protocol and implementations 211 were updated to support direct use of Mesh profiles. This allows a 212 client to push the updated profile data to the server when making the 213 connection attempt. 215 3.6.2. Update Daemon 217 Native support allows the process of adding devices to be automated 218 but does not guarantee timely processing of deletion requests. It 219 also requires action by third parties who may not be interested in 220 providing Mesh support. 222 A better approach would be to run a daemon on each machine that could 223 receive update notifications from the portal whenever a significant 224 event (profile addition/deletion) had occurred. 226 3.6.3. Batched Connection Requests 228 The existing management tools require a device to be connected to a 229 profile before use of applications are enabled on the device. 231 3.6.4. Enhanced administration 233 While this approach is functional, it does not meet the requirement 234 for complete mediation of the log in request. While the system 235 administrator has the ability to permit or deny remote access 236 capabilities to a user, these are the only options that the 237 administration tools currently supported by most SSH configurations 238 provide. The administrator cannot control the types of credentials 239 used by specific users. 241 The Mesh could be employed to permit a closer level of control. 242 Storing the user's profile fingerprint in the password database 243 (/etc/passwd or /etc/shadow) would allow every application and system 244 utility to refer to a single root of trust for authenticating every 245 credential presented by a user. 247 4. Application Profile 249 5. Acknowledgements 251 6. Implementation Status 253 This section records the status of known implementations of the 254 protocol defined by this specification at the time of posting of this 255 Internet-Draft, and is based on a proposal described in RFC 6982. 256 The description of implementations in this section is intended to 257 assist the IETF in its decision processes in progressing drafts to 258 RFCs. Please note that the listing of any individual implementation 259 here does not imply endorsement by the IETF. Furthermore, no effort 260 has been spent to verify the information presented here that was 261 supplied by IETF contributors. This is not intended as, and must not 262 be construed to be, a catalog of available implementations or their 263 features. Readers are advised to note that other implementations may 264 exist. 266 According to RFC 6982, "this will allow reviewers and working groups 267 to assign due consideration to documents that have the benefit of 268 running code, which may serve as evidence of valuable experimentation 269 and feedback that have made the implemented protocols more mature. 270 It is up to the individual working groups to use this information as 271 they see fit". 273 6.1. Reference Implementation 275 Organization: Comodo Group Inc. 277 Implementer: Phillip Hallam-Baker 278 Maturity: Experimental Prototype 280 This implementation was used to produce the reference section and all 281 the examples in this document. Since the conversion of specification 282 to code is automatic, there is a high degree of assurance that the 283 reference implementation is consistent with this document. 285 6.1.1. Coverage: 287 The draft-xx branch describes the code used to create version xx of 288 this document. 290 The main current limitations are that the code only supports RSA key 291 pairs and for ease of development the server does not persist keys 292 across sessions. Nor does the implementation currently support the 293 HTTP payload authentication and encryption layer or make use of TLS. 294 These could be easily fixed. 296 The client and server are implemented as libraries that may be called 297 from a multi-protocol server. A standalone server will be provided 298 in a future release. 300 Only the JSON encoding is currently implemented. The JSON-B, JSON-C, 301 ASN.1 and TLS Schema implementations are all supported by the code 302 generation tool but not currently implemented as the build tool 303 bindings for those encodings have not yet been finalized or 304 documented. 306 The key restrictions for TLS key exchange have not yet been 307 implemented. 309 The code has only been tested on Windows 10 but passed compatibility 310 testing for both Mono and dotNetCore 10 run times which should in 311 theory permit use on Linux and OSX platforms. 313 6.1.2. Licensing 315 The code is released under an MIT License 317 Source code is available from GitHub at 318 https://github.com/hallambaker/LURK-PHB 320 6.1.3. Implementation Experience 322 The implementation and specification documentation were developed in 323 Visual Studio using the PHB Build Tools suite. 325 6.1.4. Contact Info 327 Contact Phillip Hallam-Baker phill@hallambaker.com 329 7. Security Considerations 331 [This is just a sketch for the present.] 333 8. IANA Considerations 335 [TBS list out all the code points that require an IANA registration] 337 9. Normative References 339 [draft-hallambaker-mesh-architecture-01] 340 "[Reference Not Found!]". 342 [draft-hallambaker-mesh-reference-02] 343 "[Reference Not Found!]". 345 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 346 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 347 January 2006. 349 Author's Address 351 Phillip Hallam-Baker 352 Comodo Group Inc. 354 Email: philliph@comodo.com