SSH Key Management Best Practice - Monday 13:00-14:00 at Boca 8

Tatu Ylonen <tyl@ssh.com> Thu, 07 March 2013 03:52 UTC

Return-Path: <bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org>
X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95B721F8824 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Wed, 6 Mar 2013 19:52:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.734
X-Spam-Level:
X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIiSowRYmuZ1 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Wed, 6 Mar 2013 19:52:26 -0800 (PST)
Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 4D50421F881A for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Wed, 6 Mar 2013 19:52:23 -0800 (PST)
Received: by mail.netbsd.org (Postfix, from userid 605) id B5FA514A36D; Thu, 7 Mar 2013 03:52:20 +0000 (UTC)
Delivered-To: ietf-ssh@netbsd.org
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6140514A36A for <ietf-ssh@netbsd.org>; Thu, 7 Mar 2013 03:52:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at NetBSD.org
Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id B5QZFV75jIDU for <ietf-ssh@netbsd.org>; Thu, 7 Mar 2013 03:52:11 +0000 (UTC)
Received: from allman.clausal.com (ip-194-137-52-208.ssh.com [194.137.52.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 6C0F514A329 for <ietf-ssh@netbsd.org>; Thu, 7 Mar 2013 03:52:11 +0000 (UTC)
Received: from [192.168.43.158] (md32836d0.tmodns.net [208.54.40.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by allman.clausal.com (Postfix) with ESMTPSA id D9208496001; Thu, 7 Mar 2013 04:42:36 +0200 (EET)
From: Tatu Ylonen <tyl@ssh.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: SSH Key Management Best Practice - Monday 13:00-14:00 at Boca 8
Date: Thu, 07 Mar 2013 04:34:02 +0200
Message-Id: <65453B05-7138-4146-BF08-E378DC32EADC@ssh.com>
Cc: ietf-ssh@netbsd.org
To: saag@ietf.org
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
Sender: ietf-ssh-owner@NetBSD.org
List-Id: ietf-ssh.NetBSD.org
Precedence: list

We will be having a side meeting on SSH Key Management Best Practice at the IETF on Monday, 13:00 to 14:00.  The assigned room is Boca 8.  Welcome!

I will present draft-ylonen-sshkeybcp-00 (http://tools.ietf.org/html/draft-ylonen-sshkeybcp-00) and we should have plenty of time for discussion.  The draft illustrates threats due to poorly managed SSH user keys, provides a process for getting from an unmanaged environment into a managed environment, and presents recommendations for ongoing management and continuous monitoring.  It also discusses the residual risks if any of the remediation steps are not taken.  The draft focuses on managing large environments (100 - 100000+ servers) and is targeted at security architects, Unix/Linux operations managers, policy makers, and auditors.  It also briefly addresses other technologies for automated access, as the several of the threats also apply to them.

As background, the SSH protocol is widely used for managing Unix/Linux servers, telecommunications networks, routers, and many embedded systems.  It is also widely used for file transfers (particularly with the SFTP protocol), and many systems management, security, and audit tools use it to access managed systems.  Many organizations have thousands of custom scripts using SSH to perform administrative tasks and to automatically transfer data between applications.  A lot of these uses are fully automated and run without an interactive user; keys (without passphrases) are usually used for authentication in those cases.

Many large organizations have accumulated hundreds of thousands, in some cases millions, of authorized SSH user keys on their servers over the years.  These keys have never been changed. Administrators don't know what each key is used for and cannot remove these keys because they don't know what applications would break if they remove a key.  System administrators can use key-based access to circumvent privileged access management systems, creating essentially permanent backdoors to production servers.  SSH user keys are already collected and used by various attack tools, and can help malware spread throughout an organization's server infrastructure in minutes.  The problem is largely unrecognized and is not understood by compliance auditors and IT risk managers.

The problem is not about managing keys but about managing access.  SSH user keys are generally strong enough.  The problem is that organizations do not know who can access what and many do not control who can add new authorized keys, do not audit key-based access to servers, and do not control what can be done with each key.  Generally, organizations do not properly terminate access when an employee leaves or changes roles.  Many organizations permit automated access from low-security hosts (e.g., development machines) to critical production systems.

The draft documents the current best practice of managing SSH user keys.  It is not a protocol document, but rather presents risks and recommendations for proper process and policy.

Feedback on the draft is very welcome regardless of whether you will be able to attend the meeting.  Please send comments directly to me.  We want the draft to make a reasonable compromise between security and implementability in an organization.  The plan is to eventually publish a future version of the document as a Best Current Practice.

Best regards,

Tatu Ylonen