Subject: [saag] Fwd: SSH Key Management Best Practice - Monday 13:00-14:00 at Boca 8

From: Stephen Farrell <[email-masked]>
Date: Mon, 11 Mar 2013 17:04:44 +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 <[email-masked]>
To: [email-masked]
CC: [email-masked]

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