cyber.tex

\documentclass[10pt]{article}

\usepackage{hyperref, enumitem, times}
\usepackage[top=.85in, bottom=.85in, left=.85in, right=.85in]{geometry}

\urlstyle{rm}

\newcommand{\slim}{\vspace{0.5\baselineskip}}

\usepackage{microtype}

\begin{document}

\noindent \textbf{Title:} Policy-friendly remote access to computer resources: the successor to SSH

\vspace{-.5\baselineskip}

\section*{Abstract}

From its introduction in 1995, the Secure Shell (SSH) has become a
ubiquitous tool for users to connect securely with networked and
``cloud'' servers. But as the importance of cybersecurity has
increased in the last two decades, and as systems like the Secure Web
and TLS have seen considerable evolution, SSH has yet to realize
commensurate improvements in its manageability, auditability, or
support of prudent security policies.

This project is a collaboration between PIs at the Stanford Computer
Science Department and in the Cyber Security organization of SLAC, a
national laboratory that Stanford operates for the U.S.~Department of
Energy. The Computer Science PIs have prior experience developing
SSH-like systems that have been deployed to millions of users. The
SLAC PIs create cybersecurity policies that govern SLAC's use of SSH,
and implement these policies subject to federal cybersecurity regulations and oversight.

Together, we will develop a successor to SSH that is responsive to
today's real-world cybersecurity concerns \emph{and} deployable at
security-conscious and policy-driven organizations. Relative to
today's SSH, the improvements will focus on three areas:
\textbf{policy-friendliness}, allowing the implementation and analysis
(including ``what if?'' questions) of cybersecurity policies governing
authentication and authorization, \textbf{security improvements}, and
\textbf{usability improvements} to encourage consistent and
appropriate use. We will use SLAC as a motivating ``launch customer'':
if the new system can be welcomed and deployed in a security-conscious
and regulated environment like SLAC, we believe it will see widespread
use.

\vspace{-.5\baselineskip}

\section{Participants}

\subsection{Stanford Computer Science PIs}

\noindent \textbf{Keith Winstein} is an assistant professor of
computer science and, by courtesy, of law at Stanford. Winstein
created the Mosh (mobile shell) tool and the State Synchronization
Protocol, which is estimated to have more than a million users. He and
his colleagues and students developed the Sprout protocol for mobile
networking, the Remy tool for automated protocol design, the ExCamera
system for massively parallel video encoding on cloud microservices,
and the Lepton system, which has re-compressed hundreds of petabytes
of image files. Winstein has received the Usenix NSDI Community Award
(2017), a Google Faculty Research Award (2017 and 2015), the ACM
SIGCOMM Doctoral Dissertation Award for Outstanding PhD Thesis in
Computer Networking and Data Communication (2015), a Sprowls award for
best thesis in computer science at MIT (2014), and the Applied
Networking Research Prize (2013). Winstein previously served as a
staff reporter at The Wall Street Journal (2007--2010) and consulting
engineer at Dropbox (2014--2017).

\slim

\noindent \textbf{David Mazi\`{e}res} is a professor of computer
science at Stanford University, where he leads the Secure Computer
Systems research group. He also serves as Chief Scientist at Stellar
Development Foundation, and is a founder of Intrinsic,
Inc. Prof.~Mazi\`{e}res's research interests include Operating Systems
and Distributed Systems, with a focus on security. Some of
the projects he and his students have worked on include SFS (a
self-certifying network file system), SUNDR (a file system that
introduced the notion of fork linearizability), Kademlia (a widely
used peer-to-peer routing algorithm), Coral (a peer-to-peer content
distribution network), HiStar (a secure operating system based on
decentralized information flow control), tcpcrypt (a TCP option
providing forward-secure encryption), Hails (a web framework that can
preserve privacy while incorporating untrusted third-party apps), Dune
(a driver granting linux processes safe access to privileged CPU
features), and COWL (an information-flow-control-based browser
security architecture). Prof.~Mazi\`{e}res has received an Oakland distinguished paper award (2014), Sloan award
(2002), USENIX best paper award (2001), NSF CAREER award (2001), and MIT
Sprowls best thesis in computer science award (2000).

\subsection{SLAC PIs}

\noindent \textbf{Ben Calvert} is the Chief Information Security
Officer (CISO) at SLAC for the Infrastructure and Safety Directorate,
reporting directly to the Chief Information Officer. In his role, Ben
is responsible for establishing the information security strategy and
direction for SLAC, overseeing and coordinating all information
security efforts across the laboratory and being accountable and
responsible for lab-wide results. Ben has more than 14+ years of
global experience at Fortune 500 companies in the areas of risk
management, intellectual property and IT performance.

\slim

\noindent \textbf{Erwin Lopez} is the Deputy Chief Information
Security Officer (Deputy CISO) at SLAC. He has over 15+ years of IT
experience, specifically focusing on Cyber Security. Erwin came to
SLAC from Lawrence Livermore National Laboratory where he worked for
over 11 years in the Cyber Security program, where he held numerous
technical and leadership positions. Erwin is a proficient IT leader
with a wealth of technical experience in network intrusion analysis,
forensics, malware reversing, cyber incident handling, security
assessments, web application and penetration testing, and application
software development. Erwin has a Bachelor's degree from California
State University, Chico in Computer Engineering; in addition, he holds
numerous Cyber Security certifications.

\slim

\noindent \textbf{Ashley Tolbert} is a Cyber Security Analyst at SLAC,
focusing on security operations in incident response, forensics
software, and cyber security awareness and training. She has a diverse
background that includes researching cyber security and modeling
software for other research labs such as NASA Ames and ABB Research
Center in Germany. Directly prior to her work at SLAC, Ashley earned a
Master's of Science in Information Security from Carnegie Mellon
University. She holds a bachelor’s degree from Auburn University,
where she studied software engineering.  \slim

\subsection{Doctoral students}

\noindent \textbf{Dima Kogan} is a doctoral student in computer science,
advised by Profs.~Winstein and Mazi\`{e}res. He was previously a Software
Engineer at Google.

\slim

\noindent \textbf{Riad S.~Wahby} is a doctoral student in computer science,
advised by Profs.~Winstein and Mazi\`{e}res. He was previously a
research scientist in the NYU Computer Science department, a
visiting researcher at the University of Texas at Austin, and a Staff
Design Engineer at Silicon Labs.

\section{Technical Research Agenda}

SSH~\cite{SSH} is used by tens of millions of people as the \emph{de
  facto} standard for users to connect security with networked and
``cloud'' servers. After more than 20 years of accumulated experience,
we believe it is time to use what the community has
learned to design, build, and deploy a next-generation system.

The proposed collaboration reflects widespread interest in SSH across
Stanford: Winstein and Mazi\`{e}res (the Stanford CS PIs) have each
independently developed software that improves on facets of
SSH.\footnote{Mazi\`{e}res's Rex~\cite{rex} demonstrates that it is
  possible to build an SSH-like service in a much more modular and
  secure manner. Winstein's Mosh (mobile shell)~\cite{Mosh} adds
  roaming, support for suspend/resume and intermittent connectivity,
  and latency compensation. It has seen wide deployment, especially
  among software developers and at Silicon Valley companies such as
  Facebook.} Meanwhile, SLAC represents an ideal ``launch customer''
for a practical next-general SSH. SLAC is a Department of Energy
National Laboratory subject to federal cybersecurity
regulations~\cite{cyberframework, nist80053}, including a NIST policy
specific to SSH~\cite{nistSSH} and the president's May 2017 Executive
Order on cybersecurity~\cite{trumpeo}. The lab's scientists are
intensive users of SSH, and the SLAC Cyber Security PIs have drafted
and implemented several local policies governing its use. Together, we
intend to develop and deploy a next-generation SSH that will be
welcomed at policy-driven and security-conscious organizations like
SLAC.

We first discuss the policymaking process and practical deployment of
SSH at SLAC (\S\ref{ss:sshatslac}), then give an outline
(\S\ref{ss:outline}) of our proposed improvements in a next-generation
SSH in the three areas of policy-friendliness, security, and
usability. In section~\ref{ss:authentication}, we drill into one
area of the proposed design: the authentication architecture that
allows the system to implement practical security policies.

Finally, we describe a ``warmup'' deployment (\S\ref{ss:warmup}) that
will be our first step in learning more about user needs and
requirements in this area. Before embarking on a clean-slate redesign
of SSH, we will improve the current version of SSH to add
enforcement of security policies regarding credential delegation to
third-party servers (in other words, \emph{secure} ssh-agent
forwarding) without modifying the remote SSH servers. We believe that
the experience of attempting to deploy a minimally invasive change to
SSH at SLAC will teach us about the realities of this area and will
better inform our development of a clean-slate SSH successor.

\subsection{SSH at SLAC: usage in a regulated and policy-driven environment}
\label{ss:sshatslac}
SLAC is a national laboratory funded by the Department of Energy, and
subject to cybersecurity legislation and regulations, including the
Federal Information Security Management Act of 2002
(FISMA)~\cite{fisma}. As SLAC is an open lab, cybersecurity policies
must balance the need for flexibility for scientific research, while
managing compliance requirements and reducing cybersecurity risk. A
majority of SLAC cybersecurity policies, including the ``Remote Access
Management Policy,'' the ``Account Management Policy,'' the ``Access
Control Policy,'' and the ``Audit Logging and Monitoring Policy,'' are
based on NIST Special Publication 800-53~\cite{nist80053}
controls. These policies reinforce the notion that cybersecurity is a
shared responsibility across all departments: cybersecurity is
centrally managed by the Computing Division but applies across all lab
departments. NIST additionally provides guidelines and recommendations
around securing Secure Shell (SSH) for federal entities in the
document NISTIR 7966~\cite{nistSSH}.

SLAC's network is an enterprise network with a tight perimeter control
for most protocols using a stateful firewall. Unlike other protocols,
SSH is broadly allowed to enter through the network perimeter. It
provides access to science enclaves and experimental facilities. The
scientific group holds a Science DMZ (demilitarized zone). In a
Science DMZ, the ``equipment, configuration, and security policies are
optimized for high-performance scientific applications.'' This solves
a common issue at research labs by creating an environment for high
performance science applications, including high-volume bulk data
transfer and remote experiment control. The Science DMZ has no
stateful firewalls but some router-based access controls. SLAC
monitors the detection of SSH-based attacks using syslog and Bro and
automatically blocks Internet based hosts participating in these
attacks.

One issue that SLAC experiences with SSH is limitations with not
having a centralized mechanism for key management, especially since
vendor solutions can be expensive and difficult to deploy. SSH
sessions are also encrypted, which hides traffic and can stall
cybersecurity analysis during attacks. To solve this, some national
labs use \emph{Instrumented SSH}, a modified version of SSH built at
Lawrence Berkeley Labs, to see the content of SSH sessions and gain
visibility into encrypted sessions that help to identify
attacks. Another issue is that syslog logs are not granular enough for
the detail needed for cyber analysis. Furthermore, with increased use
of off-premise ``cloud'' services (e.g., GitHub, Bitbucket, AWS), a
cybersecurity analyst no longer has access to syslog from all services
that may have been affected by an exposure of a user's credentials.
This frustrates efforts to understand and mitigate attacks.

\subsection{Outline of improvements in a next-generation SSH}
\label{ss:outline}
The proposed next-generation SSH will reflect the accumulated wisdom
and experience of the last 20 years of SSH usage, focusing on
\textbf{policy-friendliness}, \textbf{security}, and
\textbf{usability}. We note that these three areas are necessarily
intertwined: usability improvements mean that users are less likely to
circumvent security policies. Improvements that make it possible to
develop and implement cybersecurity policies are
connected with security concerns in general.

\subsubsection{Policy-friendliness}
%
\begin{itemize}[topsep=0pt, itemsep=0pt]

\item Provide a global authentic audit log of actions taken under each
  user's key. This supplements the ``server-based'' model of logging
  (e.g.~syslog) to reflect the current popularity of cloud services: a
  user's credentials, if compromised by malware or an attacker, are
  now as likely to take improper action on a server outside a local
  administrator's control as inside. We would like users and
  administrators to be able to answer the question, ``What
  actions---anywhere---did my identity authorize in the last 20
  minutes? Has my key been compromised?''

\item Adopt a robust notion of the identity of users and hosts, so
  that a compromised key may be revoked globally, and different client
  devices confirm that they agree with one another about each host's
  identity, and vice versa. Move away from SSH's ``trust on first
  use'' security model. The intention is to mitigate the ``key
  juggling'' management challenges at SLAC and similar sites.

\item Ability to search and use audit logs as a tool to develop new
  cybersecurity policies. We would like administrators to be able to
  ask ``what-if'' questions in order to make \emph{data-driven}
  decisions about the effects that new policies relating to identity
  management, passwords and password reuse, etc., would have on the
  user base.

\item Enable usable policies for \emph{delegation} of credentials to a
  remote server. In practice, this means enhancing the current
  mechanism of ``ssh-agent forwarding,'' so it can be enabled by
  default. Before approving or denying a request, the agent will learn
  (a) what host is asking to take an action on the user's behalf, (b)
  what remote host they want to authenticate to, and (c) the command
  that will be executed. (In SSH-2, the agent does not learn any of
  this information and essentially signs a blank check.)  Based on
  this request, the agent can intelligently execute a policy that
  specifies which servers are allowed to take which actions on the
  user's behalf. We will develop a usable user experience for
  developing such a policy incrementally, e.g.~by prompting the
  user to approve requests ``once'' or ``always.''

\end{itemize}

\subsubsection{Security improvements}
%
\begin{itemize}[topsep=0pt, itemsep=0pt]

\item Improve protocol to allow cleaner abstractions in the
  implementation and rigid privilege separation, eliminating a
  category of security vulnerabilities.

\item Make nested interactive sessions secure---if a user connects to
  server A, and from there to server B, we want the connection to be
  protected end-to-end (from the user to B), eliminating exposure
  of the plaintext to A.

\item First-class support for hardware identity tokens (e.g. U2F and
  Yubikey) originally developed for Web applications.

\end{itemize}

\subsubsection{Usability/performance improvements}
%
\begin{itemize}[topsep=0pt, itemsep=0pt]

\item Features currently in Mosh: Connections survive sleep/resume and
  changes in client or server IP address. On slow connections, the
  client figures out if the server is likely to echo the user's
  typing, and if so, it shows the user their typing immediately,
  without waiting for the server.

\item Intelligent use of the network: route connections over whatever
  path gives the best performance (IPv4, IPv6, directly, or via a
  cloud node), dynamically changing the route as necessary. Improve
  on TCP's performance by maintaining \emph{one} congestion-controlled
  channel between each pair of hosts, then intelligently subdividing
  these pipes among flows~\cite{congmgr, ron}.

\item Eliminate runtime use of DNS and other insecure
  mechanisms. Maintain a dynamic secure mapping of hosts to underlying
  IPv4 and IPv6 addresses, meaning connections are still possible even
  if DNS is under attack.

\item Proxy arbitrary traffic: Users might choose to route all their
  traffic over the new SSH (including Web traffic intended for the
  outside world), and it handles the routing and congestion-control to
  a proxy server.

\end{itemize}

\subsection{Authentication architecture}
\label{ss:authentication}
We begin by describing the long-term authentication architecture we
envision for a hypothetical SSH version~3, then discuss how an
approximation of this architecture can be shoe-horned into existing
SSH~2 implementations in the nearer term.  An important principle
underlying our authentication architecture is a separation of
server-side authentication mechanisms from the client side
implementation of those mechanisms.

On the server side, authentication takes place by verifying signatures
on messages that identify what is being authenticated as unambiguously
as possible, including at a minimum: (a) the public key of the server,
(b) the server's own notion of its human-readable name, (c) the exact
command being executed, (d) a fresh channel identifier derived from a
cryptographic hash of a server nonce and session keying material, and
(e) bounds on other uses of the channel being authenticated (master
  channel establishment, port forwarding, etc.

On the client side, the agent protocol must be amenable to numerous
implementations, including a standard agent process, an agent process
combined with a hardware token, and, importantly, an agent process
spread across two or more machines.  The latter architecture is
particularly important for users who maintain a central log of
authentication requests.

As an example, consider a user whose agent process signs requests in
conjunction with a secure server.  The secure server has necessarily
but not sufficient privileges to authenticate the user.  If the user
believes her office was physically breached before her screen locked,
she cannot trust any local logs or process.  However, so long as the
remote server is not compromised, she can examine the remote server
logs to discover exactly what commands the intruder authorized on what
servers.  With visibility across all of a user's different
authentication requests, an authentication server can run anomaly
detection and potentially require step-up authentication following
unusual activity.

Using pro-active key sharing, it is even be possible for the user to
recover from such a compromise without changing her public key
everywhere, simply by refreshing the key sharing between her client
and the server.  That said, we will likely require servers to support
``multi-key'' setups where an authentication request must be signed by
multiple keys, because threshold cryptography is not always convenient
to retrofit to hardware tokens.

Another important aspect of the client-side authentication
architecture is that clients must know exactly where authentication
requests originate.  This requires a way of attenuating the privileges
of a channel to the authentication server when an agent connection is
forwarded across machines, by recursively annotating authentication
requests as they are forwarded back to the agent.

\subsection{Warmup deployment: retrofitting improved authentication
  and delegation to SSH~2}
\label{ss:warmup}

To get a feel for the deployability of our authentication
architecture, we will retrofit an approximation of the architecture to
SSH~2 (the current version of SSH).  This will require a significant
re-write of \texttt{ssh-agent} and minor modifications to \texttt{ssh}
(the client), but can be done with no chances to \texttt{sshd} on the
server side.

The main idea is that when the \texttt{ssh} client connects to a
server, rather than initiate the connection itself, it will act as a
simple packet relay so that the \texttt{ssh-agent} is actually the
program establishing the connection.  \texttt{ssh-agent} will drive
the protocol until it has committed to the command being executed on
the server.  At that point, there will be a logical connection between
the agent and the server relayed by the \texttt{ssh} client that
cannot read the messages because it doesn't have the session key.  The
agent can then initiate a rekey request so as to hand the logical
connection endpoint off to the \texttt{ssh} client.

\section{Collaboration, Funding, and Publication Plans}

\textbf{Collaboration Plan.} Between the Computer Science and SLAC PIs, we will meet monthly,
alternating between SLAC and the Gates Building, for the duration of
the project. Over the last several weeks, the Computer Science and
SLAC Cyber Security PIs have met several times, joined by the student
participants, in the course of the ``warmup'' project and to prepare
this proposal. The Computer Science PIs have adjacent lab space in the
Gates Building and meet more than once per week with the student
participants.

\slim

\noindent \textbf{Additional Funding Sources.} The PIs will seek
additional and long-term funding for this project as part
of a pending multi-PI proposal to SRCCo (a DARPA-industry consortium)
and to the National Science Foundation. A preliminary white-paper submission to SRCCo
was successful and was met with an invitation to submit a full proposal, due this summer.

\slim

\noindent \textbf{Publication Plan.} All software developed will be
released as open-source software.  We intend to develop practical
software intended for wide deployment on multiple operating systems,
following in the same steps as the CS PIs' prior work on
Mosh~\cite{Mosh} and Rex~\cite{rex}. We will submit the work to
academic venues such as SIGCOMM, NSDI, OSDI, SOSP, and USENIX
Security, as well as to practitioner-focused venues such as SREcon,
IETF, or \texttt{;login:} magazine.

\slim

\noindent \textbf{Timeline.} We have embarked on the ``warmup''
project, which retrofits the ability to create secure policies for
credential delegation to the existing SSH system. We intend to have a
prototype ready to deploy by the end of summer 2017, and to submit a
research paper to a workshop such as ACM HotNets for early feedback
from the community. We will deploy the prototype to users of Mosh and
attempt to deploy it at SLAC and to learn from the experience as we
draft the ``clean-slate'' SSH redesign. Based on what we know now, we
expect a beta version can be deployable for testing by summer 2018.

\vspace{-.5\baselineskip}
\enlargethispage{\baselineskip}

\section{Annual Budget}

The budget represents support for two Ph.D.~students, plus one month
of summer salary and 10\% academic-year offset for the CS PIs. (SLAC
PIs are on 12-month employment.) Student support costs are from the
``Cost of Research Assistantships, AY16-17 Rates'' departmental
document.

\slim

\noindent \begin{tabular}{ll|l}
& \bf Amount & \bf \$ \\
Student $\times 2$ & Academic-year 50\% RA & \$60,048 \\
        & Summer 90\% RA & \$40,032 \\

Tuition $\times 2$ & Academic-year & \$39,348 \\
        & Summer        & \$3,935 \\

CS PI $\times 2$ & Summer: 1 mo. & \$35,557 \\
CS PI $\times 2$ & Academic-year: 10\% & \$32,000 \\

Benefits & Student & \$5,404 \\
Benefits & Faculty & \$20,673 \\

Travel &         & \$10,000 \\

\hline

Facility fee & 8\% & \$16,297 \\
Annual total & & \$263,294 \\

\end{tabular}

{\footnotesize

\bibliographystyle{abbrv}
\bibliography{cyber}
}

\end{document}