\documentclass[11pt]{article}
\usepackage{times}
\usepackage{graphics}
\usepackage{ifthen}
\usepackage{i-d}
%\usepackage{rfc}
\usepackage{html}
\usepackage{txtpsfig}
\usepackage{tight}
\usepackage[dvips]{changebar}

\title{A Minimalist Security Framework for SIP}
\author{Schulzrinne}
\shorttitle{Minimalist Security}
\filename{draft-schulzrinne-sip-security-00}
\wg{}
\expires{May 2002}
\address{Columbia U.}
\pubdate{\today}
\input{../defs}

\begin{document}
\maketitle
\begin{abstract}
This document describes a minimalist set of algorithms and protocols
that solve some of the more important security issues in SIP.
\end{abstract}

\section{Introduction}

SIP \cite{rfc2543} has a number of security issues that remain to be
addressed.  There is not likely to be a single security mechanism that
is appropriate for all threat scenarios or applications, while
minimizing complexity and message overhead.  Numerous attempts have been
made to make progress on SIP security, but with little visible output
that is ready to be standardized and deployed in the near term.  Thus,
this draft takes a minimalist approach and tries to find the smallest
set of approaches that solve the most urgent problems. The emphasis is
on solutions that do not require extensive new infrastructure or
algorithms. Approaches relaxing this assumption are complementary to the
recommendations in this memo.

\section{Goals and Assumptions}

\begin{itemize}
\item Avoid inventing new security algorithms to minimize risks and
delay.

\item Any new algorithm or protocol should be applicable to all similar
protocols, such as HTTP/1.1 \cite{rfc2068}, SIP \cite{rfc2543} and RTSP
\cite{rfc2326} or RFC 2822 \cite{rfc2822}.

\item It is unlikely that a single mechanism will be able to solve all
SIP security issues.  It is thus pointless to argue whether, say, IPsec,
TLS, digest authentication or some other mechanism is ``better''.  It is
likely that a variety of mechanisms will be deployed, depending on the
infrastructure that is available or can be built, restrictions on the
computational power of end systems, security expectations, attack models
and bandwidth constraints.

\item There is a strong preference for mechanisms that do not require an
elaborate on-line infrastructure across the whole set of participants.
Such an on-line infrastructure adds additional points of failure and
compromise. (Local infrastructures such as RADIUS or DIAMETER servers
are not considered to be a major drawback, but these are likely to be
useful mostly for end-to-end authentication within an administrative
domain and for registration. Note that public key mechanisms also require
certificate revocation servers.)

\item The administrative domains of participants are assumed to be only
``loosely coupled'', i.e., there is not likely to be mutual trust or a
common KDC infrastructure. This corresponds to the typical web model.

\item Server and per-domain public-key certificates are widely used for
web servers and thus likely to be available for SIP servers.

\item Client public-key certificates are less likely to be available
than server certificates.

\item Computational resources in proxies are more readily available than
those in UAs.  (For example, on an 800 MHz Pentium III, signing a
request takes about 16\,ms.)

\item In many cases, it is sufficient if the outbound proxy ``assumes
responsibility'' for a message, e.g., signs it. Often, the outbound
proxy has other mechanisms at its disposal to verify the identity of the
requestor.

\end{itemize}

\section{Threat Models}

Below, we categorize the attacks we worry about here. There are many
other classifications, but we believe that they capture the essential
differences, i.e., this is the minimal set of classifications that
allows one to pick different approaches. (In other words, if all methods
are equivalent to variations on a single attack, there is not much point
in distinguishing these variations.)

We attempt to follow the terminology of RFC 2828 \cite{rfc2828} and use
the standard naming conventions \cite{Schn96:Applied} (p.  23) with the
cast of characters including Alice, Bob and Carol as the three parties
that wish to communicate with each other (the "legitimate" users), Eve
as the eavesdropper, and Mallory as the malicious active attacker.

SIP is primarily concerned with two-party communications, rather than
multi-party communications. Thus, we focus our attention on that model.

\begin{description}
\item[Third-party messages (TP):] In this attack, the attacker cannot
intercept or modify messages between communicating parties (e.g., Alice
and Bob), but can send arbitrary messages to either party, possibly with
spoofed IP source addresses.

\item[Passive man-in-the-middle (PMIM):] In a passive attack, the
attacker can intercept arbitrary messages between the two principals. 
However, the attacker cannot modify the messages.  (It does not matter
whether the attacker in this model can drop messages, as this is hard to
distinguish from normal network operation.  In some cases, the inability
to drop packets may allow the legitimate participants to detect the
presence of the man-in-the-middle, as they will receive both the altered
request as well as the original request.  However, this difference does
not seem worth exploiting.)

\item[Active man-in-the-middle (AMIM):] An active man-in-the-middle
attacker can modify messages, insert additional messsages and drop
arbitrary messages.
\end{description}

\section{Interactions}

We can also classify security interactions by the parties involved:

\begin{description}
\item[UA-registrar:] In a UA-to-registrar relationship, the UA attempts
to register securely with its registrar. Almost always, the UA has a
pre-existing relationship with its registrar, established by non-SIP
means.

\item[UA-UA:] UA-to-UA relationships are also often referred to as
end-to-end. 

\item[UA-outbound proxy:] The UA interacts with the outbound proxy. Note
that the outbound proxy may not be in the user's home network.
\end{description}

\section{Authentication without Encryption}

In SIP, one of primary concerns is authentication of requests and
responses, as spoofed requests can cause major damage.  Authentication
is needed, for example, for the following cases:

\begin{description}
\item[Session setup:] During session setup, each participant desires to
know the true identity of the other party. In some cases, it is
sufficient to know that the party calling is the same one that called
earlier, even if the legal name, for example, of the party is not
verifiable.

In addition, any SIP intermederias, such as B2BUA's or proxies, may need
to be able to ascertain the identity of the participants, for billing
and logging purposes.

\item[Triggering requests:] The {\REFER} request can be used to ask a
user to generate a request to a third party.  There are two situations
with different requirements.  In the first case (known-party {\REFER}),
the sender and recipient of the {\REFER} request are already in an
existing SIP session.  In the second case (spontaneous {\REFER}), the
sender of the {\REFER} request is unknown to the recipient.

\item[Session modification:] Even if the session participants do not
know or care who the other participant is, they do care that an
unauthorized third party does not modify their session in progress.

\item[Terminating sessions:] Terminating a session, via {\BYE}, is a
special case of the previous problem.

\item[Registration:] Malicious users need to be prevented from
registering for parties that have not authorized to do so.
\end{description}

From the perspective of the caller and callee, session setup
authentication is probably the least important of these, as users
routinely receive PSTN calls or messages from unknown users that are
traceable only with large amounts of effort, if at all.

In many, but not all, of these cases, the actual content of the message
is of secondary importance and contains information that is equivalent
to traffic analysis rather than revealing sensitive information.

Authentication may be limited to the request or may be mutual, i.e., the
requestor may also want to assure that it is indeed communicating with
the desired entity rather than some MIM.

Outbound proxy authentication and privacy can be addressed by network or
transport-layer security.  There are two somewhat different cases:  for
the outbound proxy in a visited network, there may not be a
pre-established shared secret, while standard digest proxy
authentication with shared secrets appears to be workable for the
outbound proxy in the user's home network.

TBD: Multiple proxies?

\subsection{Digest Authentication}
\label{sec:digest}

The current digest authentication \cite{rfc2617} only protects the
request URI, method and body of the request, but does not protect the
header fields.  Since the header fields are critical for all SIP users,
we need to add header signing, as described in
\cite{draft-undery-sip-digest,draft-sen-sipping-onehop-digest}.  We
refer to this variant of digest authentication as ``header-protecting
digest authentication''.

Shared secrets are reasonable assumptions for registration, but less so
for session establishment.

Ephemeral keys require signed certificates for AMIM, but not for PMIM.

\section{Encryption}
\label{sec:encryption}

Encryption is needed for two reasons:  to protect the signaling SIP
information itself from disclosure and to make it possible to carry
session keys used for secure media (e.g., SRTP
\cite{draft-ietf-avt-srtp}) end-to-end in SDP.

\motivation{SRTP has lower packet overhead than IPsec ESP and is robust
against bit errors.}

The basic SIP header fields needed to identify the request (\header{To},
\header{From}, \header{Call-ID}, \header{CSeq}, \header{Request-URI})
have to be invisible to proxies, although the \header{From} header does
not necessarily have to carry the actual identity of the caller.

There are at least two approaches to end-to-end encryption.  In the
first, the signaling path is made to consist of a number of encrypted
hops, e.g., using IPsec or TLS.  The client needs to have a way of
requesting that the request not be forwarded unless it is via a secure
connection, e.g., via \header{Proxy-Require}, and has to trust the
intermediaries to respect those wishes. IPsec and TLS generally also
authenticate the two end points, decreasing the likelihood that a rogue
proxy server either intercepts the message or forwards it unencrypted.

Another possibility is to negotiate a direct secure connection between
the two end systems \cite{manyfolks} and then use the secure connection
to exchange any sensitive information such as media session keys. This
approach is likely to work only without firewalls.

\section{S/MIME for SIP}
\label{sec:smime}

RFC 2633 \cite{rfc2633} appears to be directly applicable to SIP, as
long as each SIP request and response is treated as an independent
message.  This approach is only suitable for end-to-end (UA-to-UA)
security; it does not address UA-to-proxy and proxy-to-UA security.

It may be possible to optimize performance by establishing a session key
during the initial {\INVITE} and then use HMAC or header-protecting
digest authentication to protect the response and future exchanges
between the two parties, either for the same session or for a session
key lifetime spanning multiple sessions. 

Example:

\begin{verbatim}
  INVITE sip:UserB@there.com SIP/2.0
  Via: SIP/2.0/UDP here.com:5060
  From: BigGuy <sip:UserA@here.com>
  To: LittleGuy <sip:UserB@there.com>
  Call-ID: 12345601@here.com
  CSeq: 1 INVITE
  Content-Type: multipart/signed;
    protocol="application/pkcs7-signature";
    micalg=sha1; boundary=boundary42

  --boundary42
  Content-Type: message/sip

  INVITE sip:UserB@there.com SIP/2.0
  Via: SIP/2.0/UDP here.com:5060
  From: BigGuy <sip:UserA@here.com>
  To: LittleGuy <sip:UserB@there.com>
  Call-ID: 12345601@here.com
  CSeq: 1 INVITE
  Contact: <sip:UserA@100.101.102.103>
  Content-Type: application/sdp
  Content-Length: 147

  v=0
  o=UserA 2890844526 2890844526 IN IP4 here.com
  s=Session SDP
  c=IN IP4 100.101.102.103
  t=0 0
  m=audio 49172 RTP/AVP 0
  a=rtpmap:0 PCMU/8000

  --boundary42
  Content-Type: application/pkcs7-signature; name=smime.p7s
  Content-Transfer-Encoding: base64
  Content-Disposition: attachment; filename=smime.p7s

  ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
  4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
  n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
  7GhIGfHfYT64VQbnj756

  --boundary42--
\end{verbatim}

Section 3.1.3 of RFC 2633 \cite{rfc2633} does not apply to SIP, since
SIP message bodies are eight-bit clean. Thus, base-64 encoding is
{\NOTRECOMMENDED}. (Since this memo is restricted to 7-bit ASCII, we do
use it in the example above.)

Other constraints on S/MIME?

\section{CMS for SIP}

Instead of using S/MIME, it is more efficient to use CMS \cite{rfc2630},
without multipart.  This, however, reeks of a kludge and only works for
authentication-only.

\begin{verbatim}
  INVITE sip:UserB@there.com SIP/2.0
  Via: SIP/2.0/UDP here.com:5060
  From: BigGuy <sip:UserA@here.com>
  To: LittleGuy <sip:UserB@there.com>
  Call-ID: 12345601@here.com
  CSeq: 1 INVITE
  Signature: ;algorithm=pkcs7
    ;header="From,To,Call-ID,CSeq,Contact,Content-Type,Content-Length,body"
    ;value="ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
    ..."
  Contact: <sip:UserA@100.101.102.103>
  Content-Type: application/sdp
  Content-Length: 147

  v=0
  o=UserA 2890844526 2890844526 IN IP4 here.com
  s=Session SDP
  c=IN IP4 100.101.102.103
  t=0 0
  m=audio 49172 RTP/AVP 0
  a=rtpmap:0 PCMU/8000
\end{verbatim}

\section{Ephemeral Keys}

If the S/MIME operation is considered too heavy-weight AND if AMIM
attack is discounted, ephemeral keys may be used instead.  (If AMIM is
possible, only public key cryptography, e.g., using S/MIME, or a
Kerberos-like KDC model is known to work.)

\section{In-Session Authentication for SIP}

In some cases, a full challenge-response exchange is not necessary for
shared secret authentication.  Avoiding such an exchange significantly
reduces the bandwidth overhead of in-session signaling, e.g., for
re-{\INVITE}, known-party {\REFER} and {\BYE}.  In particular, for an
existing session, Eve can replay a message, but it would either be
treated as a duplicate and discarded or, if it has an old \header{CSeq}
number treated as an old message and discarded.  If digest
authentication has been used, the next-nonce mechanism allows this.  If
the shared secret is established using S/MIME, however, this mechanism
is not suitable.  In that case, it may be desirable to transfer a shared
session secret to the other party and use it to sign the content using HMAC
\cite{rfc2104}. The signature protects the method, request-URI, body and
a selected set of headers indicated in the \header{header} attribute.
[THIS NEEDS WORK.]

TBD:  Use CMS UserKeyingMaterial or define SIP header
\header{Session-Key}, with expiration time and preferred methods?  Can
this be easily extracted from S/MIME?

\begin{verbatim}
  Authorization: HMAC header="To,From,CSeq,Date",
    hmac="750c783e6ab0b503eaa86e310a5db738"
\end{verbatim}

The \header{To}, \header{From}, \header{Call-ID}, \header{CSeq} and
\header{Date} header fields {\MUST} be included in the HMAC header set.

Note: It may be possible to use Kerberos to generate such a session key.
Indeed, one possibility might be to transport a ticket obtained by Alice
for Bob to Bob in SIP (header or attachment).

\subsection{{\REFER}}

From a security perspective, there are two use models for {\REFER}
\cite{draft-ietf-sip-refer} requests, depending on whether the {\REFER}
request occurs as part of an existing signaling session or not.

If the issuer of the {\REFER} request is the same as the caller or
callee, the recipient wants to ensure that the {\REFER} request does
indeed come from the same party. Below, we use ``REFER (X)'' to indicate
that the {\REFER} request has a \header{Refer-To} header field value of
``X''.

\begin{verbatim}
   A -- INVITE   --> B
   A -- REFER (C) -> B
                     B --- INVITE --> C
                        Referred-By: A
\end{verbatim}
 
In this case, B needs to be assured that the {\REFER} request originates
from A and C wants to authenticate B, but C may not care that whether B
has been authenticated to A.  In this scenario, B is in any event
responsible for requests it issues.

There have been requests to not just be able to authenticate A, but
to allow B to prove to C that A asked this request be sent, so that
C can put the appropriate acceptance policies in place and B can't
put the blame on A unless it really belongs there.

{\REFER} requests can also be issued outside of an existing signaling
relationship, as in 
\begin{verbatim}
   A -- INVITE --> B
                   B --- REFER (A) --> C
 
   A <------------ INVITE ------------ C
\end{verbatim}

This case is no different than standard request authentication.  C will
need to make a policy decision as to whether to indeed issue the request
indicated in the {\REFER} request; part of the policy will be whether C
requires B to authenticate itself.  Independently, C also needs to
authenticate itself to A.

\section{Summary of Recommendations}

\begin{itemize}
\item SIP proxies {\SHOULD} use network or transport-level security
mechanisms, preferably using long-lived associations, for hop-by-hop
security.

\item {\REGISTER} uses header-protecting digest authentication, with
response digests (\header{Authorization-Info}).

\item For the PMIM threat model only, known-party {\REFER} requests may
use header-protecting SIP digest authentication based on ephemeral keys
established during the session setup.

\item UACs {\MAY} protect initial requests within a session using
S/MIME.

\item UACs can choose HMAC authentication or S/MIME for subsequent
authentication.

\item Outbound proxies {\MUST} sign all unsigned requests and responses,
including {\REFER}, via S/MIME.  Such outbound proxies {\SHOULD} use
appropriate mechanisms, such as proxy digest authentication, to
ascertain the identity of the UA.

\end{itemize}

\section{Open Issues}

\bibliographystyle{ieeetr}
\bibliography{string,i-d,rfc,net96}

\section{Acknowledgements}

TBD

\section{Authors' Addresses}
\begin{flushleft}
Henning Schulzrinne\\
Dept. of Computer Science\\
Columbia University\\
1214 Amsterdam Avenue\\
New York, NY 10027\\
USA\\
electronic mail: {\sf schulzrinne@cs.columbia.edu}
\end{flushleft}

\tableofcontents

\input{copyright}

\end{document}
