Binary file handouts/ho05.pdf has changed

--- a/handouts/ho05.tex	Wed Oct 29 13:08:11 2014 +0000
+++ b/handouts/ho05.tex	Wed Oct 29 14:23:20 2014 +0000
@@ -117,13 +117,15 @@
 in is in which order the messages are sent. For the SYN-ACK
 protocol we will therefore use the notation 
 
-\begin{center}
-\begin{tabular}{l@{\hspace{2mm}}l}
-$A \to S$: & $SYN$\\
-$S \to A$: & $SYN\_ACK$\\
-$A \to S$: & $ACK$\\
-\end{tabular}
-\end{center}
+
+\begin{equation}
+\begin{array}{l@{\hspace{2mm}}l}
+A \to S: & SYN\\
+S \to A: & SYN\_ACK\\
+A \to S: & ACK\\
+\end{array}\label{SYNACK}
+\end{equation}
+
 
 \noindent The left-hand side specifies who is the sender and
 who is the receiver of the message. On the right of the colon
@@ -164,21 +166,91 @@
 \{\{msg\}_{K_{AB}}\}_{K_{BC}}
 \] 
 
+\noindent The idea is that even if attacker Eve has the
+key $K_{BC}$ she could decrypt the outer envelop, but
+still do not get to the message, because it is still
+encrypted with the key $K_{AB}$. Note, however,
+while an attacker cannot obtain the content of the message
+without the key, encrypted messages can be observed
+and be recorded and then replayed at another time, or
+send to another person!
+
+Another very important point is that the notation for
+protocols such as shown in \eqref{SYNACK} is a
+\underline{schema} how the protocol should proceed.
+It could be instantiated by an actual protocol run
+between Alice, say, and the server Calcium at King's. In this 
+case the specific instance would look like
+
+\[
+\begin{array}{l@{\hspace{2mm}}l}
+\text{Alice} \to \text{Calcium}: & SYN\\
+\text{Calcium} \to \text{Alice}: & SYN\_ACK\\
+\text{Alice} \to \text{Calcium}: & ACK\\
+\end{array}
+\]
+
+\noindent But a server like Calcium of course needs to
+serve many clients. So there could be the same protocol
+also running with Bob, say
+
+\[
+\begin{array}{l@{\hspace{2mm}}l}
+\text{Bob} \to \text{Calcium}: & SYN\\
+\text{Calcium} \to \text{Bob}: & SYN\_ACK\\
+\text{Bob} \to \text{Calcium}: & ACK\\
+\end{array}
+\]
+
+\noindent And these two instances of the protocol could be
+running in parallel or be at different stages. So the protocol
+schema shown in \eqref{SYNACK} can be thought of how two 
+programs need to run on the side of $A$ and $S$ in order to 
+successfully complete the protocol. But it is really just a 
+blue print how the communication is supposed to proceed. 
+
+This is actually already a way how such protocols can fail. 
+Although very simple the $SYN\_ACK$ protocol can cause 
+headaches for system administrators where an attacker
+starts the protocol, but does not complete it. This looks 
+graphically like
+
+\begin{center}
+\includegraphics[scale=0.4]{../pics/synflood.png}
+\end{center}
+
+\noindent The attacker sends lots of $SYN$ requests which the
+server dutifully answers, but needs to keep track of such
+protocol exchanges. So every time a little bit of memory
+resource will be eaten away on the server side until all
+resources are exhausted and when Alice tries to contact the
+server then the server is overwhelmed and does not respond
+anymore. This kind of attack are called \emph{SYN
+floods}.\footnote{\url{http://en.wikipedia.org/wiki/SYN_flood}}
+
+After reading four pages, you might be wondering where the
+magic is. For this let us take a closer look at authentication 
+protocols.
+
+\subsubsection*{Authentication Protocols}
+
+The simplest authentication protocol between principals
+$A$ and $B$, say is
+
+\begin{center}
+$A \to B: K_{AB}$ 
+\end{center}
 
 
-Note, however,
-while an attacker cannot obtain the content of the message
-without the key, this encrypted message can be observed
-and be recorded and then replayed at another time.
 
+\bigskip\bigskip
 Keyfobs - protocol
 
+\subsubsection*{Further Reading}
+
 {\small
 \url{http://www.cs.ru.nl/~rverdult/Gone_in_360_Seconds_Hijacking_with_Hitag2-USENIX_2012.pdf}}
 
-attack such protocols because they use weak ciphers (Oyster
-card)
-
 \end{document}
 
 %%% Local Variables: