[saag] Fwd: SSH Key Management Best Practice - Monday 13:00-14:00 at Boca 8
Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 11 March 2013 17:05 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B015A11E8167 for <saag@ietfa.amsl.com>; Mon, 11 Mar 2013 10:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 BTu6ntX3wHPN for <saag@ietfa.amsl.com>; Mon, 11 Mar 2013 10:05:19 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7C40521F8A41 for <saag@ietf.org>; Mon, 11 Mar 2013 10:05:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EC06EBE2F for <saag@ietf.org>; Mon, 11 Mar 2013 17:04:50 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOKe3CBi23iK for <saag@ietf.org>; Mon, 11 Mar 2013 17:04:45 +0000 (GMT)
Received: from [130.129.96.60] (dhcp-603c.meeting.ietf.org [130.129.96.60]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A8A0FBE25 for <saag@ietf.org>; Mon, 11 Mar 2013 17:04:45 +0000 (GMT)
Message-ID: <513E0EAC.30308@cs.tcd.ie>
Date: Mon, 11 Mar 2013 17:04:44 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: "saag@ietf.org" <saag@ietf.org>
References: <65453B05-7138-4146-BF08-E378DC32EADC@ssh.com>
In-Reply-To: <65453B05-7138-4146-BF08-E378DC32EADC@ssh.com>
X-Enigmail-Version: 1.5.1
X-Forwarded-Message-Id: <65453B05-7138-4146-BF08-E378DC32EADC@ssh.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [saag] Fwd: SSH Key Management Best Practice - Monday 13:00-14:00 at Boca 8
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Mar 2013 17:05:20 -0000
FYI. Not sure that this mail made it to the list, (can't see it in the archive). If you're interested and around we're meeting in Boca VIII right now S -------- Original Message -------- Subject: SSH Key Management Best Practice - Monday 13:00-14:00 at Boca 8 Date: Thu, 7 Mar 2013 04:34:02 +0200 From: Tatu Ylonen <tyl@ssh.com> To: saag@ietf.org CC: ietf-ssh@netbsd.org 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
- [saag] Fwd: SSH Key Management Best Practice - Mo… Stephen Farrell