[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