\documentclass[helvetica]{seminar} 
\input{xy}
\xyoption{all}
\usepackage{graphicx} 
\usepackage{slidesec} 
\usepackage{url} 

\long\def\symbolfootnote[#1]#2{\begingroup%
\def\thefootnote{\fnsymbol{footnote}}\footnote[#1]{#2}\endgroup}

% to fix problems making landscape seminar pdfs
% Letter...
\pdfpagewidth=11truein
\pdfpageheight=8.5truein
\pdfhorigin=1truein     % default value(?), but doesn't work without
\pdfvorigin=1truein     % default value(?), but doesn't work without
% A4
%\pdfpagewidth=297truemm % your milage may vary....
%\pdfpageheight=210truemm
%\pdfhorigin=1truein     % default value(?), but doesn't work without
%\pdfvorigin=1truein     % default value(?), but doesn't work without



\renewcommand{\familydefault}{\sfdefault}  
 
\input{seminar.bug} 
\input{seminar.bg2} % See the Seminar bugs list 
 
\slideframe{none} 
 
 
\usepackage{fancyhdr} 
 
% Headers and footers personalization using the `fancyhdr' package 
\fancyhf{} % Clear all fields 
\renewcommand{\headrulewidth}{0mm} 
\renewcommand{\footrulewidth}{0.1mm} 
 
\fancyfoot[L]{\tiny IETF 71} 
\fancyfoot[C]{\tiny KMART BOF}
\fancyfoot[R]{\tiny \theslide} 
 
 
% To center horizontally the headers and footers (see seminar.bug) 
\renewcommand{\headwidth}{\textwidth} 

% To adjust the frame length to the header and footer ones 
\autoslidemarginstrue 
\pagestyle{fancy} 
 

\newcommand{\heading}[1]{% 
  \begin{center} 
    \large\bf 
    #1 
  \end{center} 
  \vspace{.4 in}} 

\begin{document}
\begin{slide}
\begin{center}
\vspace{1 in}
\LARGE{{\bf}Key management... Dude, wait, what?}\\

\vspace{.5 in}

\large{Eric Rescorla} \\
\large{RTFM, Inc.} \\
\large{ekr@rtfm.com} \\
\vspace{.25 in} 
\large{{IETF 71}} \\

\end{center}
\end{slide}

% don't center vertically
\centerslidesfalse 


\begin{slide}
\heading{Current State of Routing Protocol Security\symbolfootnote[2]{We're just talking about securing adjacencies here}}

\vspace{-.25 in}

\begin{itemize}
\item Focus is on integrity and data origin authentication
\begin{itemize}
\item This data is not confidential
\end{itemize}
\item Routing protocols use manual key management
\begin{itemize}
\item Shared keys are configured at the router interface
\begin{itemize}
\item This usage model is critical to preserve
\end{itemize}
\item Traffic is protected with ad-hoc MACs based on those keys
\end{itemize}
\item Why is this bad?
\begin{itemize}
\item Replay and cut-and-paste attacks (see David Ward's presentation)
\item The MACs are generally pretty weak---and hard to upgrade
\end{itemize}
\end{itemize}
\vspace{.5 in}
\end{slide}


\begin{slide}
\heading{What's a replay attack?}

\vspace{-.25 in}

\begin{itemize}
\item Alice and Bob share a key ($K_{ab}$)
\begin{itemize}
\item But never change it
\end{itemize}
\end{itemize}

\xymatrix@R=.4in@C=1.5in{
Alice & Attacker & Bob\\
\ar[rr]^{Message, MAC(K_{ab},Message)} & & \\
& \ar[r]^{Message, MAC(K_{ab},Message)} & \\
}

\begin{itemize}
\item Requires an on-path attacker
\item Works whenever association parameters are repeated
\begin{itemize}
\item Keys
\item Other meta-data protected by the MAC (e.g., host/port)
\end{itemize}
\end{itemize}
\end{slide}


\begin{slide}
\heading{Defenses against replay attack}

\vspace{-.25 in}

\begin{itemize}
\item Fresh association parameters
\begin{itemize}
\item Implicit
\begin{itemize}
\item Example: TCP
\begin{itemize}
\item Each connection has its own host/port quartet
\item If in the MAC then you can't replay between connections
\item ... unless you get a host/port collision
\end{itemize}
\end{itemize}
\item Explicit
\begin{itemize}
\item Establish a fresh connection identifier
\begin{itemize}
\item Force it to be unique
\end{itemize}
\end{itemize}
\end{itemize}
\item Fresh keys for the association
\begin{itemize}
\item Using a key management protocol
\item This is the standard COMSEC solution
\begin{itemize}
\item Provides generic security without trusting the main protocol
\end{itemize}
\end{itemize}
\end{itemize}
\end{slide}



\begin{slide}
\heading{What's a key management protocol?}

\begin{itemize}
\item We have a number of elements $\mathbf{E} = E_1, E_2, ...$ that want to communicate
\begin{itemize}
\item They have some long term credentials
\begin{itemize}
\item Shared symmetric key/password
\item Asymmetric key pairs
\item Keys + certificates
\end{itemize}
\item Generally can't use these keys directly for communication
\end{itemize}
\item A key management protocol establishes shared cryptographic state
\begin{itemize}
\item Traffic protection keys
\item Algorithms and other parameters
\end{itemize}
\end{itemize}
\end{slide}


\begin{slide}
\heading{Why use a KMP?}

\vspace{-.35 in}
\begin{itemize}
\item Security
\begin{itemize}
\item Establish fresh keys
\begin{itemize}
\item Prevents replay and cut-and-paste attacks
\item Good ``cryptographic hygiene''
\end{itemize}
\item Explicit liveness and peer authentication
\end{itemize}
\item Performance
\begin{itemize}
\item Public key cryptography is slow
\item Faster to establish symmetric keys and then use them
\end{itemize}
\item Capability discovery
\begin{itemize}
\item Get peer's certificate
\begin{itemize}
\item Not an issue in systems with manual configuration
\end{itemize}
\item Discover/negotiate algorithms
\item Allows uncoordinated capability upgrade
\end{itemize}
\end{itemize}
\end{slide}



\begin{slide}
\heading{Deployment Scenarios}

\vspace{-.25 in} 

\begin{itemize}
\item Unicast
\begin{itemize}
\item This is a technically well understood problem (TLS, IPsec, ...)
\begin{itemize}
\item Issue is mapping it onto actual protocols with minimal disruption
\end{itemize}
\item BGP, LDP
\begin{itemize}
\item Run over TCP
\item Not the topic of this meeting (TCP-AO, etc.)
\end{itemize}
\item IS-IS, OSPF, RIP
\end{itemize}
\item Multicast/broadcast
\begin{itemize}
\item Less technically well understood
\begin{itemize}
\item Some experience in MSEC WG (GDOI, GSAKMP)
\end{itemize}
\item IS-IS, OSPF, RIP only
\end{itemize}
\end{itemize}

\end{slide}


\begin{slide}
\heading{A trivial unicast key management protocol}


\vspace{-.25 in}

\begin{itemize}
\item Assume Alice, Bob share a key: $K_{ab}$
\end{itemize}

\xymatrix@R=.4in@C=3in{
Alice & Bob \\
\ar[r]_{Algorithms=HMAC-SHA1, HMAC-SHA256}^{Name=Alice, Random} & \\ 
& \ar[l]_{Name=Bob, Random}^{Algorithm=HMAC-SHA1} \\
}

\begin{itemize}
\item Two new keys:
\item[] $K_{a \rightarrow b} = HMAC(K_{ab}, Random_{Alice} || Random_{Bob})$
\item[] $K_{b \rightarrow a} = HMAC(K_{ab}, Random_{Bob} || Random_{Alice})$
\end{itemize}
\vspace{.05 in}
Similar protocols can be used with asymmetric keys
\end{slide}


\begin{slide}
\heading{Key Management for Multicast Groups}

\begin{itemize}
\item We have a set of elements $\mathbf{E} = E_1, E_2, ...$ 
\begin{itemize}
\item They have some long term credentials
\item We want them to share a single symmetric key, parameters, etc.
\end{itemize}
\item Classic solution: Have a master element (group controller)
\begin{itemize}
\item Generates group key
\item Forms unicast associations with each element
\item Pushes group key to each group member
\begin{itemize}
\item Send $E(K_{E_i}, K_{group})$ to node $E_i$
\end{itemize}
\end{itemize} 
\item Examples: GDOI, GSAKMP
\end{itemize}
\end{slide}

\begin{slide}
\heading{Key Management with a Group Master}

\xymatrix@R=1.5in@C=1.5in{
& Master \ar[dl]_{E(K_{E_1}, K_{group})} \ar[d]_{E(K_{E_2}, K_{group})} \ar[dr]^{E(K_{E_3}, K_{group})}\\
E_1  & E_2 & E_3 \\
}

\begin{itemize}
\item $K_{group}$ is encrypted under the pre-established pairwise key $K_{E_i}$
\end{itemize}

\end{slide}



\begin{slide}
\heading{Integrity with a Group Key}

\xymatrix@R=1.5in@C=1.5in{
E_1 \ar[r]^{M_1, MAC(K_{group}, M_1)} \ar[d]_{M_1, MAC(K_{group}, M_1)} 
\ar[rd]^{M_1, MAC(K_{group}, M_1)}  & E_2 \\
E_3 & E_4 \\
}

\end{slide}


\begin{slide}
\heading{Problems with Group Key Management}

\begin{itemize}
\item The current schemes need a master/group controller
\begin{itemize}
\item Who runs this?
\item Why do you trust them?
\end{itemize}
\item Impersonation of other group members
\begin{itemize}
\item All group members have the same MAC key
\begin{itemize}
\item Used for both MAC generation and MAC verification
\end{itemize}
\item Any group member can impersonate any other group member
\end{itemize}
\item When is this a problem?
\begin{itemize}
\item When group members are mutually suspicious
\item Is this true for these protocols?
\end{itemize}
\end{itemize}
\end{slide}


\begin{slide}
\heading{Operating without a dedicated master}

\begin{itemize}
\item Option 1: joint key establishment
\begin{itemize}
\item Everyone works together to establish a group key
\item e.g., group Diffie-Hellman
\item What happens when a new member joins/leaves?
\begin{itemize}
\item Generate a new key
\item Or have some node act as master for it
\end{itemize}
\end{itemize}
\item Option 2: elect a master
\begin{itemize}
\item What happens if that master leaves?
\item New election...
\end{itemize}
\item Either of these would require significant new protocol work
\end{itemize}
\end{slide}



\begin{slide}
\heading{Dealing with impersonation}

\vspace{-.25 in}

\begin{itemize}
\item Basic problem is use of one symmetric key
\begin{itemize}
\item Used for both MAC generation and verification
\item Need to separate these functions
\end{itemize}
\item Option 1: Public key cryptography (digital signature)
\begin{itemize}
\item Every message is signed
\item Need to somehow establish all the key pairs
\begin{itemize}
\item PKI? Pairwise agreements? Bootstrap CA protocol?
\end{itemize}
\end{itemize}
\item Option 2: TESLA
\begin{itemize}
\item Needs a master
\begin{itemize}
\item Which you need to trust
\end{itemize}
\item We have no operational experience with TESLA
\begin{itemize}
\item The timing is known to be tricky
\end{itemize}
\end{itemize}
\end{itemize}
\end{slide}



\begin{slide}
\heading{What problem were we trying to solve again?}

\vspace{-.2 in}
\begin{itemize}
\item Hey this all looks pretty expensive
\vspace{.05 in}
\item Replay attack
\begin{itemize}
\item This can be fixed by hacking the non-security part
\item Add unique per-association identifiers inside the MAC
\end{itemize}
\item Key agility
\begin{itemize}
\item This can be fixed (clumsily) by adding a key identifier
\end{itemize}
\item Stronger algorithms and algorithm agility
\begin{itemize}
\item This can be fixed (clumsily) by tying algorithms to keys 
\end{itemize}
\item Impersonation of other group members
\begin{itemize}
\item This looks pretty hard to fix
\item How bad is it?
\end{itemize}
\end{itemize}

\end{slide}


\end{document}