120 \begin{center}

   120 

   121 \begin{tabular}{l@{\hspace{2mm}}l}

   121 \begin{equation}

   122 $A \to S$: & $SYN$\\

   122 \begin{array}{l@{\hspace{2mm}}l}

   123 $S \to A$: & $SYN\_ACK$\\

   123 A \to S: & SYN\\

   124 $A \to S$: & $ACK$\\

   124 S \to A: & SYN\_ACK\\

   125 \end{tabular}

   125 A \to S: & ACK\\

   126 \end{center}

   126 \end{array}\label{SYNACK}

   127 \end{equation}

   128 

   167 

   169 \noindent The idea is that even if attacker Eve has the

   168 

   170 key $K_{BC}$ she could decrypt the outer envelop, but

   169 Note, however,

   171 still do not get to the message, because it is still

   172 encrypted with the key $K_{AB}$. Note, however,

   171 without the key, this encrypted message can be observed

   174 without the key, encrypted messages can be observed

   172 and be recorded and then replayed at another time.

   175 and be recorded and then replayed at another time, or

   173 

   176 send to another person!

   177 

   178 Another very important point is that the notation for

   179 protocols such as shown in \eqref{SYNACK} is a

   180 \underline{schema} how the protocol should proceed.

   181 It could be instantiated by an actual protocol run

   182 between Alice, say, and the server Calcium at King's. In this 

   183 case the specific instance would look like

   184 

   185 \[

   186 \begin{array}{l@{\hspace{2mm}}l}

   187 \text{Alice} \to \text{Calcium}: & SYN\\

   188 \text{Calcium} \to \text{Alice}: & SYN\_ACK\\

   189 \text{Alice} \to \text{Calcium}: & ACK\\

   190 \end{array}

   191 \]

   192 

   193 \noindent But a server like Calcium of course needs to

   194 serve many clients. So there could be the same protocol

   195 also running with Bob, say

   196 

   197 \[

   198 \begin{array}{l@{\hspace{2mm}}l}

   199 \text{Bob} \to \text{Calcium}: & SYN\\

   200 \text{Calcium} \to \text{Bob}: & SYN\_ACK\\

   201 \text{Bob} \to \text{Calcium}: & ACK\\

   202 \end{array}

   203 \]

   204 

   205 \noindent And these two instances of the protocol could be

   206 running in parallel or be at different stages. So the protocol

   207 schema shown in \eqref{SYNACK} can be thought of how two 

   208 programs need to run on the side of $A$ and $S$ in order to 

   209 successfully complete the protocol. But it is really just a 

   210 blue print how the communication is supposed to proceed. 

   211 

   212 This is actually already a way how such protocols can fail. 

   213 Although very simple the $SYN\_ACK$ protocol can cause 

   214 headaches for system administrators where an attacker

   215 starts the protocol, but does not complete it. This looks 

   216 graphically like

   217 

   218 \begin{center}

   219 \includegraphics[scale=0.4]{../pics/synflood.png}

   220 \end{center}

   221 

   222 \noindent The attacker sends lots of $SYN$ requests which the

   223 server dutifully answers, but needs to keep track of such

   224 protocol exchanges. So every time a little bit of memory

   225 resource will be eaten away on the server side until all

   226 resources are exhausted and when Alice tries to contact the

   227 server then the server is overwhelmed and does not respond

   228 anymore. This kind of attack are called \emph{SYN

   229 floods}.\footnote{\url{http://en.wikipedia.org/wiki/SYN_flood}}

   230 

   231 After reading four pages, you might be wondering where the

   232 magic is. For this let us take a closer look at authentication 

   233 protocols.

   234 

   235 \subsubsection*{Authentication Protocols}

   236 

   237 The simplest authentication protocol between principals

   238 $A$ and $B$, say is

   239 

   240 \begin{center}

   241 $A \to B: K_{AB}$ 

   242 \end{center}

   243 

   244 

   245 

   246 \bigskip\bigskip