\section{Security Considerations}
\label{sec:security}

\subsection{Confidentiality and Privacy: Encryption}

\subsubsection{End-to-End Encryption}
\label{sec:e2eencrypt}

SIP requests and responses can contain sensitive information about the
communication patterns and communication content of individuals.  The
SIP message body {\MAY} also contain encryption keys for the session
itself.  SIP supports two complementary forms of encryption to protect
privacy:

\begin{itemize}
\item End-to-end encryption of the SIP message body and certain
sensitive header fields;

\item hop-by-hop encryption to prevent eavesdropping that
tracks who is calling whom;

\end{itemize}

The SIP request or response cannot be encrypted end-to-end as a whole
because header fields such as \header{To} and \header{Via} need to be
visible to proxies so that the SIP request can be routed correctly. 
Hop-by-hop encryption encrypts the entire SIP request or response on the
wire so that packet sniffers or other eavesdroppers cannot see who is
calling whom.  Hop-by-hop encryption can also encrypt requests and
responses that have been end-to-end encrypted.  Note that proxies can
still see who is calling whom, and this information is also deducible by
performing a network traffic analysis, so this provides a very limited
but still worthwhile degree of protection.

End-to-end encryption relies on keys shared by the two user agents
involved in the request.  Typically, the message is sent encrypted
with the public key of the recipient, so that only that recipient can
read the message.  

A SIP request (or response) is end-to-end encrypted by splitting the
message to be sent into a part to be encrypted and a short header that
will remain in the clear.  Some parts of the SIP message, namely the
request line, the response line and certain header fields marked with
``r'' in the ``proxy'' column in Table~\ref{tab:headers1} and
\ref{tab:headers2} need to be read and returned by proxies and thus
{\MUSTNOT} be encrypted end-to-end.  Possibly sensitive information that
needs to be made available as plaintext include destination address
(\header{To}) and the forwarding path (\header{Via}) of the call.  The
\header{Authorization} header field {\MUST} remain in the clear if it
contains a digital signature as the signature is generated after
encryption, but {\MAY} be encrypted if it contains ``basic'' or
``digest'' authentication.  

Other header fields {\MAY} be encrypted or {\MAY} travel in the clear as
desired by the sender.  The \header{Subject}, \header{Allow}
and \header{Content-Type} header fields will typically
be encrypted.  The \header{Accept}, \header{Accept-Language},
\header{Date}, \header{Expires}, \header{Priority}, \header{Require},
\header{Call-ID}, \header{Cseq}, and \header{Timestamp} header fields
will remain in the clear.

All fields that will remain in the clear {\MUST} precede those that will
be encrypted.  The message is encrypted starting with the first
character of the first header field that will be encrypted and
continuing through to the end of the message body.  If no header fields
are to be encrypted, encrypting starts with the second CRLF pair after
the last header field, as shown below.  Carriage return and line feed
characters have been made visible as ``\$'', and the encrypted part of
the message is outlined.

\begin{verbatim}
  INVITE sip:watson@boston.bell-telephone.com SIP/2.0$
  Via: SIP/2.0/UDP 169.130.12.5$
  To: T. A. Watson <sip:watson@bell-telephone.com>$
  From: A. Bell <sip:a.g.bell@bell-telephone.com>;tag=7abm$
  Encryption: PGP version=5.0$
  Content-Length: 224$
  Call-ID: 187602141351@worcester.bell-telephone.com$ 
  Content-Type: message/sip
  CSeq: 488$
  $
*******************************************************
* Subject: Mr. Watson, come here.$                    *
* Content-Type: application/sdp$                      *
* $                                                   *
* v=0$                                                *
* o=bell 53655765 2353687637 IN IP4 128.3.4.5$        *
* s=Mr. Watson, come here.$                           *
* t=0 0$                                              *
* c=IN IP4 135.180.144.94$                            *
* m=audio 3456 RTP/AVP 0 3 4 5$                       *
*******************************************************
\end{verbatim}

An \header{Encryption} header field {\MUST} be added to indicate the
encryption mechanism used.  A \header{Content-Length} field is added
that indicates the length of the encrypted body.  The encrypted body
is preceded by a blank line as a normal SIP message body would be.

Upon receipt by the called user agent possessing the correct decryption
key, the message body as indicated by the \header{Content-Length} field
is decrypted, and the now-decrypted body is appended to the clear-text
header fields.  There is no need for an additional
\header{Content-Length} header field within the encrypted body because
the length of the actual message body is unambiguous after decryption.

A \header{Content-Type} indication of ``message/sip'' {\MAY} be added,
but will be overridden after receipt.

Had no SIP header fields required encryption, the message would have
been as below.  Note that the encrypted body {\MUST} then include a blank
line (start with CRLF) to disambiguate between any possible SIP header
fields that might have been present and the SIP message body.

\begin{verbatim}
  INVITE sip:watson@boston.bell-telephone.com SIP/2.0$
  Via: SIP/2.0/UDP 169.130.12.5$
  To: T. A. Watson <sip:watson@bell-telephone.com>$
  From: A. Bell <a.g.bell@bell-telephone.com>;tag=7abm$
  Encryption: PGP version=5.0$
  Content-Type: application/sdp$
  Content-Length: 107$
  Call-ID: 187602141351@worcester.bell-telephone.com$ 
  CSeq: 488$
  $
*************************************************
* $                                             *
* v=0$                                          *
* o=bell 53655765 2353687637 IN IP4 128.3.4.5$  *
* c=IN IP4 135.180.144.94$                      *
* m=audio 3456 RTP/AVP 0 3 4 5$                 *
*************************************************
\end{verbatim}

\subsubsection{Privacy of SIP Responses}

SIP requests can be sent securely using end-to-end encryption and
authentication to a called user agent that sends an insecure response. 
This is allowed by the SIP security model, but is not a good idea. 
However, unless the correct behavior is explicit, it would not always be
possible for the called user agent to infer what a reasonable behavior
was.  Thus, when end-to-end encryption is used by the request
originator, the encryption key to be used for the response {\SHOULD} be
specified in the request (Section~\ref{sec:Response-Key}).  If this were
not done, it might be possible for the called user agent to incorrectly
infer an appropriate key to use in the response.  Thus, to prevent
key-guessing becoming an acceptable strategy, we specify that a called
user agent receiving a request that does not specify a key to be used
for the response {\SHOULD} send that response unencrypted.

Any SIP header fields that were encrypted in a request {\SHOULD} also be
encrypted in an encrypted response.  \header{Contact} response fields
{\MAY} be encrypted if the information they contain is sensitive, or
{\MAY} be left in the clear to permit proxies more scope for localized
searches.

\subsubsection{Encryption by Proxies}

Normally, proxies are not allowed to alter end-to-end header fields and
message bodies.  Proxies {\MAY}, however, encrypt an unsigned request or
response with the key of the call recipient.

\motivation{Proxies need to encrypt a SIP request if the end system
cannot perform encryption or to enforce organizational security
policies.}

\subsubsection{Hop-by-Hop Encryption}

SIP requests and responses {\MAY} also be protected by security
mechanisms at the transport or network layer.  No particular mechanism
is defined or recommended here. Two possibilities are IPSEC
\cite{rfc2401} or TLS \cite{rfc2246}. The use of a particular mechanism
will generally need to be specified out of band, through manual
configuration, for example.

\subsection{Message Integrity and Access Control: Authentication}
\label{sec:authentication}

Protective measures need to be taken to prevent an active attacker from
modifying and replaying SIP requests and responses.  The same
cryptographic measures that are used to ensure the authenticity of the
SIP message also serve to authenticate the originator of the message. 
However, the ``basic'' and ``digest'' authentication mechanism offer
authentication only, without message integrity.

Transport-layer or network-layer authentication {\MAY} be used for
hop-by-hop authentication.  SIP also extends the HTTP
\header{WWW-Authenticate} (Section~\ref{sec:WWW-Authenticate}) and
\header{Authorization} (Section~\ref{sec:Authorization}) header field
and their \header{Proxy-} counterparts to include cryptographically
strong signatures.  SIP also supports the HTTP ``basic'' and ``digest''
schemes (see Section~\ref{sec:httpauth}) and other HTTP authentication
schemes to be defined that offer a rudimentary mechanism of ascertaining
the identity of the caller.

SIP requests {\MAY} be authenticated using the \header{Authorization}
header field to include a digital signature of certain header fields,
the request method and version number and the payload, none of which are
modified between client and called user agent.  The
\header{Authorization} header field is used in requests to authenticate
the request originator end-to-end to proxies and the called user agent,
and in responses to authenticate the called user agent or proxies
returning their own failure codes.  If required, hop-by-hop
authentication can be provided, for example, by the IPSEC Authentication
Header.

Generally, SIP authentication is for a specific request URI and realm, a
protection domain.  Thus, for basic and digest authentication, each such
protection domain has its own set of user names and secrets.  If a user
agent does not care about different request URIs, it makes sense to
establish a ``global'' user name, secret and realm that is the default
challenge if a particular request URI does not have its own realm or set
of user names.  Similarly, SIP entities representing many users, such as
PSTN gateways, {\MAY} try a pre-configured global user name and secret
when challenged, independent of the request URI.

SIP does not dictate which digital signature scheme is used for
authentication.  As indicated above, SIP implementations
{\MAY} also use ``basic'' and ``digest'' authentication and other
authentication mechanisms defined for HTTP \cite{rfc2617}.  Note that
``basic'' authentication has severe security limitations.  The following
does not apply to these schemes.

To cryptographically sign a SIP request, the order of the SIP header
fields is important.  When an \header{Authorization} header field is
present, it indicates that all header fields following the
\header{Authorization} header field have been included in the signature. 
Therefore, hop-by-hop header fields which {\MUST} or {\SHOULD} be
modified by proxies {\MUST} precede the \header{Authorization} header
field as they will generally be modified or added-to by proxy servers. 
Hop-by-hop header fields which {\MAY} be modified by a proxy {\MAY}
appear before or after the \header{Authorization} header.  When they
appear before, they {\MAY} be modified by a proxy.  When they appear
after, they {\MUSTNOT} be modified by a proxy.  To sign a request, a
client constructs a message from the request method (in upper case)
followed, without LWS, by the SIP version number, followed, again
without LWS, by the request headers to be signed and the message body. 
The message thus constructed is then signed.

For example, if the SIP request is to be:
\begin{verbatim}
INVITE sip:watson@boston.bell-telephone.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
Authorization: PGP version=5.0, signature=...
From: A. Bell <sip:a.g.bell@bell-telephone.com>;tag=7abm
To: T. A. Watson <sip:watson@bell-telephone.com>
Call-ID: 187602141351@worcester.bell-telephone.com
Subject: Mr. Watson, come here.
Content-Type: application/sdp
Content-Length: ...

v=0
o=bell 53655765 2353687637 IN IP4 128.3.4.5
s=Mr. Watson, come here.
t=0 0
c=IN IP4 135.180.144.94
m=audio 3456 RTP/AVP 0 3 4 5
\end{verbatim}

Then the data block that is signed is:
\begin{verbatim}
INVITESIP/2.0From: A. Bell <sip:a.g.bell@bell-telephone.com>;tag=7abm
To: T. A. Watson <sip:watson@bell-telephone.com>
Call-ID: 187602141351@worcester.bell-telephone.com
Subject: Mr. Watson, come here.
Content-Type: application/sdp
Content-Length: ...
 
v=0
o=bell 53655765 2353687637 IN IP4 128.3.4.5
s=Mr. Watson, come here.
t=0 0
c=IN IP4 135.180.144.94
m=audio 3456 RTP/AVP 0 3 4 5
\end{verbatim}

Clients wishing to authenticate requests {\MUST} construct the portion
of the message below the \header{Authorization} header using a
canonical form. This allows a proxy to parse the message, take it
apart, and reconstruct it, without causing an authentication failure
due to extra white space, for example. Canonical form consists of the
following rules:
\begin{itemize}
\item No short form header fields;

\item Header field names are capitalized as shown in this document;

\item No white space between the header name and the colon;

\item A single space after the colon;

\item Line termination with a \header{CRLF};

\item No line folding;

\item No comma separated lists of header values; each must appear as a
separate header;

\item Only a single \header{SP} between tokens, between tokens and
quoted strings, and between quoted strings; no SP after last token or
quoted string;

\item No \header{LWS} between tokens and separators, except as described
above for after the colon in header fields;

\item The \header{To} and \header{From} header fields always include the
$<$ and $>$ delimiters even if the \header{display-name} is empty.

\end{itemize}

Note that if a message is encrypted and authenticated using a digital
signature, when the message is generated encryption is performed before
the digital signature is generated.  On receipt, the digital signature
is checked before decryption.

A client {\MAY} require that a server sign its response by including a
\header{Require:  signed-response} request header field.  The client
indicates the desired authentication method via the
\header{WWW-Authenticate} header.

The correct behavior in handling unauthenticated responses to a
request that requires authenticated responses is described in section
\ref{sec:trustresp}.


\subsubsection{Trusting responses}
\label{sec:trustresp}

There is the possibility that an eavesdropper listens to requests and
then injects unauthenticated responses that terminate, redirect or
otherwise interfere with a call.  (Even encrypted requests contain
enough information to fake a response.)

Clients need to be particularly careful with 3xx redirection responses. 
Thus a client receiving, for example, a 301 (Moved Permanently) which
was not authenticated when the public key of the called user agent is
known to the client, and authentication was requested in the request
{\SHOULD} be treated as suspicious.  The correct behavior in such a
case would be for the called-user to form a dated response containing
the \header{Contact} field to be used, to sign it, and give this signed
stub response to the proxy that will provide the redirection.  Thus the
response can be authenticated correctly.  A client {\SHOULDNOT}
automatically redirect such a request to the new location without
alerting the user to the authentication failure before doing so.

Another problem might be responses such as 6xx failure responses which
would simply terminate a search, or ``4xx'' and ``5xx'' response
failures.  

If TCP is being used, a proxy {\SHOULD} treat 4xx and 5xx responses as
valid, as they will not terminate a search.  However, fake 6xx responses
from a rogue proxy terminate a search incorrectly.  6xx responses
{\SHOULD} be authenticated if requested by the client, and failure to do
so {\SHOULD} cause such a client to ignore the 6xx response and continue
a search.

With UDP, the same problem with 6xx responses exists, but also an
active eavesdropper can generate 4xx and 5xx responses that might
cause a proxy or client to believe a failure occurred when in fact it
did not.  Typically 4xx and 5xx responses will not be signed by the
called user agent, and so there is no simple way to detect these rogue
responses.  This problem is best prevented by using hop-by-hop
encryption of the SIP request, which removes any additional problems
that UDP might have over TCP.

These attacks are prevented by having the client require response
authentication and dropping unauthenticated responses. A server user
agent that cannot perform response authentication responds using the
normal \header{Require} response of 420 (Bad Extension). 

\subsection{Callee Privacy}

User location and SIP-initiated calls can violate a callee's privacy. 
An implementation {\SHOULD} be able to restrict, on a per-user basis,
what kind of location and availability information is given out to
certain classes of callers.

\subsection{Denial of Service}
\label{sec:security:dos}

Attackers can spoof a \header{Via} header field to direct responses to a
third party, using a SIP UAS or proxy to generate traffic. This attack
can be prevented by requiring an existing security association, such as
TLS or IPsec. This may be an appropriate solution, e.g., between proxy
servers that exchange significant amounts of signaling traffic or
between a user agent and its outbound proxy.

If such a security association is not feasible, clients and proxies
{\SHOULD} respond to unauthenticated requests with only a \emph{single}
401 (Unauthorized) or 407 (Proxy Authentication Required) instead of
using the normal response retransmission algorithm.  Retransmitting the
401 or 407 status response amplifies the problem of an attacker using a
spoofed \header{Via} header address to to direct traffic to a third
party.


\subsection{Known Security Problems}

With either TCP or UDP, a denial of service attack exists by a rogue
proxy sending 6xx responses.  Although a client {\SHOULD} choose to
ignore such responses if it requested authentication, a proxy cannot
do so.  It is obliged to forward the 6xx response back to the client.
The client can then ignore the response, but if it repeats the request
it will probably reach the same rogue proxy again, and the process
will repeat.
