\documentstyle[12pt,postscript,/nfs/thor/thor/6826/92/macros/times]{article}
%\documentstyle[12pt]{article}

\input{/nfs/thor/thor/6826/92/macros/lecture}
%\begin{figure}
%\PostscriptPicture{/nfs/thor/thor/6826/92/lectures/}
%\caption{}
%\end{figure}

\Scribe{David Maw}
\Lecturer{Butler Lampson}
\LectureNumber{19}
\LectureDate{November 23, 1992}

\begin{document}
\MakeScribeTop

\section{Overview}

Today's lecture discuss two issues of distributed systems:

\begin{itemize}
\item {Consensus: Paxos Algorithm}
\item {Security}
\end{itemize}

Note: Handout 43 ``Consensus'' and handout 44 ``Authentication in Distributed
Systems: Theory and Practice'' contain details on Paxos consensus algorithm and
security issues respectively.

\section{Consensus: Paxos Algorithm}

In last lecture, the specifications for general consensus algorithm was
described. Today, a specific consensus algorithm, Paxos algorithm is
discussed. Generally speaking, the algorithm is run by a set of leader
processes that guide a set of voter processes to achieve consensus. It
involves three phases of communication between a leader and each voter:
\begin{enumerate}
\item {information collection} (one round-trip) --- a leader chooses a ballot
numbered {\it n} and sends to all processes. Each process tells the leader how
it voted in all ballots numbered less than {\it n} and the value of each
ballot in which it voted ``yes''. The leader looks for the most recent earlier
ballot in which any process voted ``yes'', and chooses that ballot's value
{\it d}.
\item {vote collection} (one round-trip) --- the leader asks every process to
vote for the chosen ballot's value {\it d}. If the leader collects a majority
of ``yes'' votes, then it knows the ballot has succeeded and accepts {\it
d} as the consensus value. (On the other hand, if it collects a majority
of ``no'' votes, then the ballot is said to be ``dead''.)
Note that the majority which voted yes may be
a different set from that which responded to phase 1 messages.
\item {result distribution} (half a round trip) --- the leader sends the
consensus value {\it d}, if any obtained, to all processes.
\end{enumerate}

A voter votes ``no'' on a ballot {\it n} only if it has already seen another
ballot with a number larger than {\it n}.

\subsection{An example}
For instance, consider 3 voter processes: {\tt a}, {\tt b}, and {\tt c}, and
history of votes as follows:
\begin{tabbing}
Ballots \= Value \= Yes  \= No    \=\\
1\> $d_1$ \>{\tt a} \>{\tt bc} \> \\
2\> $d_2$ \>{\tt b} \>{\tt ac} \> \\
3\> {\it nil} \>\>{\tt abc} \> \\
4\> $d_1$ \>{\tt ac} \>{\tt b} \> \\
...
\end{tabbing}
This history tells that process {\tt a} voted ``yes'' on ballot 1 before it
saw the information-collecting ({\it IC}) message for ballot 2. Also, process
{\tt a} voted ``no'' on ballots 2 and 3 because it saw the {\it IC}
message for ballot 4 ($IC_4$) before the vote-collecting ({\it VC}) messages
for ballots 2 and 3 ($VC_2$ and $VC_3$). A possible sequence of messages that
process {\tt a} saw was: 
$$IC_1,~VC_1,~IC_2,~IC_3,~IC_4,~VC_2,~VC_3,~VC_4,~ ...$$

In this case, as long as two processes voted ``yes'' on a ballot, a majority
could be reached.  The history shows that both processes {\tt a} and {\tt c}
saw message $VC_4$ before any {\it IC} message with a number larger than 4;
therefore, they both voted ``yes'' and a majority was determined with the
value of ballot 4, $d_1$, being the consensus value of the algorithm.



As for ballot 3, the leader has not yet reached the stage of fixing a
value for its ballot, but the three voters have already decided to vote
no because of having seen $IC_4$.

Note that the leader of ballot 4 might have chosen either $d_1$ or
$d_2$, depending upon the particular majority set it heard from in response
to its $IC_4$ message. If it heard from only {\tt a} and {\tt c}, then
it would choose $d_1$. If it heard from {\tt b} among others, then it
would choose $d_2$. Such non-determinism in the choice for $d$
exists only if consensus has not already been reached.



\subsection{ Consensus is Stable}

Consider the above example again, with the exception that process {\tt
c} voted ``yes'', stored its vote in its stable storage, sent out its
vote to the leader and crashed, and
the vote message got lost. The consensus was reached at this point with both
processes {\tt a} and {\tt c} voting ``yes'' on ballot 4, and the value of
ballot 4, $d_1$, was the consensus value.

However, the leader could not see a majority of votes, and thus could not
identify $d_1$ as the consensus value. The abstraction function and the
invariants of the Paxos algorithm do not guarantee that the leader knows of
the consensus result right after it is determined. They only ensure that once
the consensus is reached, it will not be changed. 

In the case above, the leader will be unable to obtain consensus on
ballot 4, so after some delay, the same or a different leader will
decide to start ballot 5. In response to $IC_5$, process {\tt a}
would reply that ballot 4 was the most recent earlier ballot in which it voted
``yes''; while process {\tt b} would reply with ballot numbered 2, and process
{\tt c}, if recovered, would reply with ballot numbered 4. It can be
seen that the only possible value for ballot 5 is that of ballot 4,
because a majority will contain at least one of {\tt a} or {\tt c}.
This is true in general of any consensus value, because the majority
that voted yes for the consensus will intersect with the majority that
responded to the new $IC$ message.

One complication in this algorithm is that it may not terminate if there are
always too many impatient leaders. If there are several leaders, the one
running the biggest ballot will eventually succeed. However, if
leaders keep starting bigger ballots in alternation, none may ever
succeed. As an example, a voter may see the following sequence of
messages: 
$$IC_{i},~IC_{i+1},~VC_{i},~IC_{i+2},~VC_{i+1},~IC_{i+3},~VC_{i+2},~ ...$$
which will cause the voter to vote no on all ballots.

\section{Security}

The security issue in computer systems is only briefly discussed this year.
Please refer to handout 44 and lecture notes of last year for more
details\footnote{Notes on this section make use of two lecture notes from Fall
'91: Lecture 22, scribed by Kah-Kay Sung, and Lecture 23, scribed by David
Waitzman}.

\subsection{Model: Access Control}
\label{sc:acm}

There are two popular security models in computer systems: information flow
and access control. Only the access control model is discussed in today's
lecture. Figure 1 shows the components that make up an Access Control Model of
computer system security. The model consists of an {\em agent} (subject) and a
{\em resource} (object). The subject issues {\em requests} that access or
change information at the object. In real life, some
\mbox{\tt [Subject, Object, Request]} examples are: (1) {\tt [User, File,
Read/Write requests]} in a file server setting, and (2) {\tt [Customer, Teller
Machine, Withdrawal/Deposit requests]} in a banking system.

\begin{figure}[htp]
%\fbox{ \begin{minipage}[b]{6.25in}
\PostscriptPicture{/nfs/thor/thor/6826/92/lectures/19/acm.idraw}
\caption{Access control model components.}
\label{fg:access}
%\end{minipage}}
\end{figure}

The Access Control Model assumes that all objects are protected by {\em
guards} that grant or deny access to the object. The guard associated
with an object, called the access control list (ACL),  maintains a
sequence of principals and the operations each of them is allowed to
perform.

The security issues are more
complicated in a distributed system than in a single local machine. There are
some problems specific to distributed systems, for example,
\begin{enumerate}
\item{Requests between {\em subject} and {\em object} may pass through a long
path with many intermediate machines.}
\item{Transport mechanism is unreliable.}
\end{enumerate}
A secure distributed system based on the Access Control Model must therefore
have a secure {\em channel}. A channel is a physical path between a subject
and an object, where data flows back and forth between the two ends. A channel
is ``secure'' if we know who is on each side of the channel.

\subsection{Channel}
{\em Channels}\/ provide a means for principals to make statements or for one
principal to communicate with another. Secure channels provide:
\begin{enumerate}
\item {\bf Multiplexing}: one channel to represent many channels 
\item {\bf Authentication}: determination of the true identity of whoever is
making the request. For example,
\begin{enumerate}
\item{A channel {\it C} may {\tt speak for} a person ({\it e.g. bwl}).
This is denoted as  {\it C } $\Longrightarrow$ {\it bwl}, and means that if
{\it C} {\tt says} something, then {\it bwl} {\tt says} it too. }
\item{A member {\it M} of a group {\it G} may {\tt speak for} the group. [ {\it
M} $\Longrightarrow$ {\it G} ]}
\end{enumerate}
\item {\bf Secrecy}: known receiver.
\item {\bf Integrity}: known sender.
\end{enumerate}

\subsection{Encryption}
Data encryption is typically needed for channels to be secure. If you believe
that P is the only sender that knows the encryption key, and will use it to
send messages, then you can use encryption to ensure integrity.

All methods of encryption have some common properties.  They
require the sender to encrypt the message using some key ${\tt K^{-1}}$
and transmit the encrypted message, which the receiver is supposed to
decrypt using a possibly different key {\tt K}. Encryption and
decryption must satisfy  the following relationship.
\begin{eqnarray*}
        {\tt Enc(K^{-1}, m) = x}\\
        {\tt Dec(K, x) = m} \\
        {\tt Dec(K, Enc(K^{-1}, m)) = m}
\end{eqnarray*}

Further, it is desirable that a message not encrypted using ${\tt
K^{-1}}$ be caught upon decryption as fake. In general, it is possible
for the decryption algorithm to output something random when given
something random as input. To avoid this, the legitimate sender appends
the checksum to the message {\em before} encrypting it. Upon decrypting, if
the included checksum does not match the computed checksum, the message
is discarded.

The keys {\tt K} and ${\tt K^{-1}}$ may or may not be the same. There
are two kinds of encryption: 
\begin{itemize}
\item {\bf shared}\ \  ${\tt (K = K^{-1})}$, is a common choice for pairwise
communication. 
\item {\bf public}\ \  ${\tt (K \neq K^{-1})}$, is used in two ways. If
the encryption key ${\tt K^{-1}}$ is private but the decryption key {\tt
K} is public, only the authorized senders can send a message, but any
one can read it. This provides integrity and can be used for broadcasts.
The scheme  is often referred as {\em digital signature}. On the other
hand, a public encryption key  and a private decryption key provides
secrecy and can be used in collecting information (dubbed
convergecast). We will concern ourselves with only the former usage,
because that is the one useful in access control.
\end{itemize}

\subsection{Certification Authority}

A formula like `${\tt K_{a}\ {\bf says}\ ``S'' }$' means that there is
an encrypted message which, when decrypted using ${\tt K_{a}}$, conveys
``S''. Since the decryption succeeded, the reader can be sure that it
was sent by someone that knew ${\tt K_{a}^{-1}}$. A statement like above is
said to be a {\em certificate} for ``S'' made by ${\tt K_{a}}$.

Consider this: P says ``read file foo''. We could make P some key ${\tt
K_{bwl}}$, and have file foo's access control list (ACL) say ``${\tt
K_{bwl}}$ can read foo''. The
problem is that this is not a humanly readable ACL, and it is hard to change
${\tt K_{bwl}}$ since we will need to update the ACL. Therefore, we want a key
${\tt K_{bwl} \Rightarrow bwl}$, and an ACL that says ``bwl can read foo''
with P being {\tt bwl}. So, we need a way for the file server to learn
things like ${\tt K_{bwl}\Rightarrow bwl}$.

We have the {\bf handoff rule}: If ${\tt A'\Rightarrow A}$  and ${\tt A'\
{\bf says}\ B\Rightarrow A}$, then ${\tt B\Rightarrow A}$

Suppose ${\tt K_{ca}\Rightarrow anybody}$; that is, there is a widely known
public key ${\tt K_{ca}}$ of  a certification authority, {\tt CA},
that can be trusted to speak on behalf of all. Since
{\tt CA} knows ${\tt K_{bwl}\Rightarrow bwl}$, it can generate the certificate
${\tt K_{ca}\ {\bf says}\ K_{bwl} \Rightarrow bwl}$. Because of the handoff
rule, we will believe ${\tt K_{bwl}\Rightarrow bwl}$.

To communicate with each other,
{\tt A} and {\tt B} need to ask the {\tt CA} for the certificates ${K_{ca}\
{\bf says}\ K_{b}\Rightarrow B}$ and ${K_{ca}\ {\bf says}\ K_{a}\Rightarrow
A}$ respectively. For public-key systems, these certificates can be
stored insecurely --- accessible to everyone. The case  with shared-key
systems is different. We want ${\tt K_{a/ca}\ {\bf says}\ K_{a/b}
\Rightarrow B}$ and ${\tt K_{b/ca}\ {\bf says}\
K_{a/b} \Rightarrow A}$, where ${\tt K_{x/y}}$ denotes the shared key between
Y and X. In this case, it is imperative to protect the contents of the
message from others because the key ${\tt K_{a/b}}$ is used for both
encryption and decryption. The certificates are in fact protected
because they have been encrypted using the shared-key ${\tt K_{a/ca}}$ or ${\tt
K_{a/ca}}$. 


\end{document}