\section{Security Considerations: Threat Model and Security Usage 
Recommendations}
\label{sec:security}

SIP is not an easy protocol to secure.  Its use of intermediaries, its
multi-faceted trust relationships, its expected usage between elements
with no trust at all, and its user-to-user operation make security far
from trivial.  Security solutions are needed that are deployable today,
without extensive coordination, in a wide variety of environments and
usages.  In order to meet these diverse needs, several distinct
mechanisms applicable to different aspects and usages of SIP will be
required.

Note that the security of SIP signaling itself has no bearing on the
security of protocols used in concert with SIP such as RTP, or with the
security implications of any specific bodies SIP might carry (although
MIME security plays a substantial role in securing SIP).  Any media
associated with a session can be encrypted end-to-end independently of
any associated SIP signaling.  Media encryption is outside the scope of
this document.

The considerations that follow first examine a set of classic threat
models that broadly identify the security needs of SIP. 
The set of security services required to address these threats is then
detailed, followed by an explanation of several security mechanisms that
can be used to provide these services.  Next, the requirements for
implementers of SIP are enumerated, along with exemplary deployments in
which these security mechanisms could be used to improve the security of
SIP.  Some notes on privacy conclude this section. 


\subsection{Attacks and Threat Models}

\label{sec:security:threats}

This section details some threats that should be common to most
deployments of SIP.  These threats have been chosen specifically to
illustrate each of the security services that SIP requires.

The following examples by no means provide an exhaustive list of the
threats against SIP; rather, these are ''classic'' threats
that demonstrate the need for particular security services that can
potentially prevent whole categories of threats.


These attacks assume an environment in which attackers can potentially
read any packet on the network - it is anticipated that SIP will 
frequently be used on the public Internet. Attackers on the network 
may be able to modify packets (perhaps at some compromised intermediary). 
Attackers may wish to steal services, eavesdrop on communications, or 
disrupt sessions.


\subsubsection{Registration Hijacking}
\label{sec:security:threats:hijack}

The SIP registration mechanism allows a user agent to identify itself to
a registrar as a device at which a user (designated by an address of
record) is located.  A registrar assesses the identity asserted in the
\header{From} header field of a {\REGISTER} message to determine whether
this request can modify the contact addresses associated with the
address-of-record in the \header{To} header field. While these two
fields are frequently the same, there are many valid deployments in
which a third-party may register contacts on a user's behalf.

The \header{From} header field of a SIP request, however, can be
modified arbitrarily by the owner of a UA, and this opens the
door to malicious registrations.  An attacker that successfully
impersonates a party authorized to change contacts associated with an
address-of-record could, for example, de-register all existing contacts
for a URI and then register their own device as the appropriate contact
address, thereby directing all requests for the affected user to the
attacker's device.

This threat belongs to a family of threats that rely on the absence of
cryptographic assurance of a request's originator.  Any SIP UAS that
represents a valuable service (a gateway that interworks SIP requests
with traditional telephone calls, for example) might want to control
access to its resources by authenticating requests that it receives. 
Even end-user UAs, for example SIP phones, have an interest in
ascertaining the identities of originators of requests.

This threat demonstrates the need for security services that enable SIP
entities to authenticate the originators of requests. 

\subsubsection{Impersonating a Server}
\label{sec:security:threats:impers}

The domain to which a request is destined is generally specified in the
\header{Request-URI}. UAs commonly contact a server in this
domain directly in order to deliver a request.  However, there is always
a possibility that an attacker could impersonate the remote server, and
that the UA's request could be intercepted by some other party.

For example, consider a case in which a redirect server at one domain,
chicago.com, impersonates a redirect server at another domain,
biloxi.com.  A user agent sends a request to biloxi.com, but the
redirect server at chicago.com answers with a forged response that has
appropriate SIP header fields for a response from biloxi.com.  The forged
contact addresses in the redirection response could direct the
originating UA to inappropriate or insecure resources, or simply
prevent requests for biloxi.com from succeeding.

This family of threats has a vast membership, many of which are
critical.  As a converse to the registration hijacking threat, consider
the case in which a registration sent to biloxi.com is intercepted by
chicago.com, which replies to the intercepted registration with a forged
301 (Moved Permanently) response.  This response might seem to come from
biloxi.com yet designate chicago.com as the appropriate registrar.  All
future {\REGISTER} requests from the originating UA would then
go to chicago.com.

Prevention of this threat requires a means by which UAs can
authenticate the servers to whom they send requests.

\subsubsection{Tampering with Message Bodies}
\label{sec:security:threats:eaves}

As a matter of course, SIP UAs route requests through trusted
proxy servers.  Regardless of how that trust is established
(authentication of proxies is discussed elsewhere in this section), a
UA may trust a proxy server to route a request, but not to
inspect or possibly modify the bodies contained in that request.

Consider a UA that is using SIP message bodies to communicate session
encryption keys for a media session.  Although it trusts the proxy
server of the domain it is contacting to deliver signaling properly, it
may not want the administrators of that domain to be capable
of decrypting any subsequent media session.  Worse yet, if the proxy
server were actively malicious, it could modify the session key, either
acting as a man-in-the-middle, or perhaps changing the security
characteristics requested by the originating UA.


This family of threats applies not only to session keys, but to most
conceivable forms of content carried end-to-end in SIP.  These might
include MIME bodies that should be rendered to the user, SDP, or
encapsulated telephony signals, among others. Attackers might attempt to
modify SDP bodies, for example, in order to point RTP media streams to a
wiretapping device in order to eavesdrop on subsequent voice 
communications.


Also note that some header fields in SIP are meaningful end-to-end, for
example, \header{Subject}.  UAs might be protective of these
header fields as well as bodies (a malicious intermediary changing the
\header{Subject} header field might make an important request appear to be
spam, for example).  However, since many header fields are legitimately
inspected or altered by proxy servers as a request is routed, not all
header fields should be secured end-to-end.

For these reasons, the UA might want to secure SIP message bodies, and
in some limited cases header fields, end-to-end.  The security services
required for bodies include confidentiality, integrity, and
authentication.  These end-to-end services should be independent of the
means used to secure interactions with intermediaries such as proxy
servers.

\subsubsection{Tearing Down Sessions}
\label{sec:security:threats:bye}

Once a dialog has been established by initial messaging, subsequent
requests can be sent that modify the state of the dialog and/or session. 
It is critical that principals in a session can be certain that such
requests are not forged by attackers. 

Consider a case in which a third-party attacker captures some initial
messages in a dialog shared by two parties in order to learn the
parameters of the session (\header{To} tag, \header{From} tag, and so forth) and
then inserts a {\BYE} request into the session.  The attacker could opt
to forge the request such that it seemed to come from either
participant.  Once the {\BYE} is received by its target, the session
will be torn down prematurely.

Similar mid-session threats include the transmission of forged
re-{\INVITE}s that alter the session (possibly to reduce session
security or redirect media streams as part of a wiretapping attack).

The most effective countermeasure to this threat is the authentication
of the sender of the {\BYE}. In this instance, the recipient needs only
know that the {\BYE} came from the same party with whom the
corresponding dialog was established (as opposed to ascertaining the
absolute identity of the sender).  Also, if the attacker is unable to
learn the parameters of the session due to confidentiality, it would not
be possible to forge the {\BYE}. However, some intermediaries (like
proxy servers) will need to inspect those parameters as the session is
established.

\subsubsection{Denial of Service and Amplification}
\label{sec:security:threats:dos}

Denial-of-service attacks focus on rendering a particular network
element unavailable, usually by directing an excessive amount of network
traffic at its interfaces.  A distributed denial-of-service attack
allows one network user to cause multiple network hosts to flood a
target host with a large amount of network traffic.

In many architectures, SIP proxy servers face the public Internet in
order to accept requests from worldwide IP endpoints.  SIP creates a
number of potential opportunities for distributed denial-of-service
attacks that must be recognized and addressed by the implementers and
operators of SIP systems. 

Attackers can create bogus requests that contain a falsified
source IP address and a corresponding 
\header{Via} header field that identify a targeted host as the
originator of the request and then send this request to a large number
of SIP network elements, thereby using hapless SIP UAs or proxies to
generate denial-of-service traffic aimed at the target. 
 
Similarly, attackers might use falsified \header{Route} header field values in a
request that identify the target host and then send such messages to
forking proxies that will amplify messaging sent to the target. 
\header{Record-Route} could be used to similar effect when the attacker
is certain that the SIP dialog initiated by the request will result in
numerous transactions originating in the backwards direction.

A number of denial-of-service attacks open up if {\REGISTER} requests
are not properly authenticated and authorized by registrars.  Attackers
could de-register some or all users in an administrative domain, thereby
preventing these users from being invited to new sessions.  An attacker
could also register a large number of contacts designating the same host
for a given address-of-record in order to use the registrar and any
associated proxy servers as amplifiers in a denial-of-service attack. 
Attackers might also attempt to deplete available memory and disk
resources of a registrar by registering huge numbers of bindings.

The use of multicast to transmit SIP requests can greatly increase the
potential for denial-of-service attacks.

These problems demonstrate a general need to define architectures that
minimize the risks of denial-of-service, and the need to be mindful in
recommendations for security mechanisms of this class of attacks.

\subsection{Security Mechanisms}
\label{sec:security:mechanisms}

From the threats described above, we gather that the fundamental
security services required for the SIP protocol are: preserving the
confidentiality and integrity of messaging, preventing replay attacks or
message spoofing, providing for the authentication and
privacy of the participants in a session, and preventing
denial-of-service attacks.  Bodies within SIP messages separately
require the security services of confidentiality, integrity, and
authentication.

Rather than defining new security mechanisms specific to SIP, SIP reuses
wherever possible existing security models derived from the HTTP and
SMTP space.

Full encryption of messages provides the best means to preserve the
confidentiality of signaling - it can also guarantee that messages are
not modified by any malicious intermediaries.  However, SIP requests and
responses cannot be naively encrypted end-to-end in their entirety
because message fields such as the
\header{Request-URI}, \header{Route}, and \header{Via} need to be visible
to proxies in most network architectures so that SIP requests are routed correctly.  Note that proxy
servers need to modify some features of messages as well (such as adding
\header{Via} header field values) in order for SIP to function.  Proxy servers must
therefore be trusted, to some degree, by SIP UAs.  To this
purpose, low-layer security mechanisms for SIP are recommended, which
encrypt the entire SIP requests or responses on the wire on a hop-by-hop
basis, and that allow endpoints to verify the identity of proxy servers
to whom they send requests.

SIP entities also have a need to identify one another in a secure
fashion.  When a SIP endpoint asserts the identity of its user to a peer
UA or to a proxy server, that identity should in some way be
verifiable.  A cryptographic authentication mechanism is provided in SIP
to address this requirement.

An independent security mechanism for SIP message bodies supplies an
alternative means of end-to-end mutual authentication, as well as
providing a limit on the degree to which user agents must trust
intermediaries.

\subsubsection{Transport and Network Layer Security}
\label{sec:security:transport}

Transport or network layer security encrypts signaling traffic,
guaranteeing message confidentiality and integrity.

Oftentimes, certificates are used in the establishment of lower-layer
security, and these certificates can also be used to provide a means 
of authentication in many architectures.


Two popular alternatives for providing security at the transport and
network layer are, respectively, TLS~\citenorm{rfc2246} and 
IPSec~\citenorm{rfc2401}.


IPSec is a set of network-layer protocol tools that collectively can be
used as a secure replacement for traditional IP (Internet Protocol). 
IPSec is most commonly used in architectures in which a set of hosts
or administrative domains have an existing trust relationship with one 
another. IPSec is usually implemented at the operating system level in
a host, or on a security gateway that provides confidentiality and
integrity for all traffic it receives from a particular interface (as
in a VPN architecture). IPSec can also be used on a hop-by-hop basis. 

In many architectures IPSec does not require integration with SIP
applications; IPSec is perhaps best suited to deployments in which
adding security directly to SIP hosts would be arduous. UAs that have
a pre-shared keying relationship with their first-hop proxy server are
also good candidates to use IPSec. Any deployment of IPSec for SIP would 
require an IPSec profile describing the protocol tools that would be 
required to secure SIP. No such profile is given in this document. 



TLS provides transport-layer security over connection-oriented protocols
(for the purposes of this document, TCP); ``tls'' (signifying TLS over
TCP) can be specified as the desired transport protocol within a
\header{Via} header field value or a SIP-URI.  TLS is most suited to
architectures in which hop-by-hop security is required between hosts 
with no pre-existing trust association.
For example, Alice trusts her local proxy server, which 
after a certificate exchange decides to trust
Bob's local proxy server, which Bob trusts, hence Bob and Alice can
communicate securely.

TLS must be tightly coupled with a SIP application.  Note that transport
mechanisms are specified on a hop-by-hop basis in SIP, thus a UA 
that sends requests over TLS to a proxy server has no assurance that TLS 
will be used end-to-end.


The TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA ciphersuite {\MUST} be supported at 
a minimum by implementers when TLS is used in a SIP application. For
purposes of backwards compatibility, proxy servers, redirect servers, and
registrars {\SHOULD} support TLS\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA. 
Implementers {\MAY} also support any other ciphersuite.

\begin{changebar}
\subsubsection{SIPS URI Scheme}
\label{sec:security:sips}

The SIPS URI scheme adheres to the syntax of the SIP URI
(described in~\ref{sec:common-message}), although the scheme
string is "sips" rather than "sip". The semantics of SIPS are very
different from the SIP URI, however. SIPS allows resources to 
specify that they should be reached securely.

A SIPS URI can be used as an address-of-record for a particular user - the
URI by which the user is canonically known (on their business cards, in the
\header{From} header field of their requests, in the \header{To} header field
of {\REGISTER} requests). When used as the \header{Request-URI} of 
a request, the SIPS scheme signifies that each hop over which the request 
is forwarded, until the request reaches the SIP entity responsible for the
domain portion of the \header{Request-URI},
must be secured with TLS; once it reaches the domain in question it is 
handled in accordance with local security and routing policy, quite
possibly using TLS for any last hop to a UAS.  When used by the originator 
of a request (as would be the case if they employed a SIPS URI as the 
address-of-record of the target), SIPS dictates that the entire request 
path to the target domain be so secured. 

The SIPS scheme is applicable to many of the other
ways in which SIP URIs are used in SIP today in addition to 
the \header{Request-URI}, including in addresses-of-record, contact 
addresses (the contents of  \header{Contact} headers, including those 
of {\REGISTER} methods), and \header{Route} headers. In each instance, 
the SIPS URI scheme allows these existing fields to designate secure 
resources. The manner in which a SIPS URI is dereferenced in any of 
these contexts has its own security properties which are detailed in 
\cite{draft-ietf-sip-srv}.

The use of SIPS in particular entails that mutual TLS authentication
{\SHOULD} be employed, as {\SHOULD} the ciphersuite 
TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA. Certificates received in the 
authentication process {\SHOULD} be validated with root certificates
held by the client; failure to validate a certificate {\SHOULD} result 
in the failure of the request.

motivation{Note that in the SIPS URI scheme, transport is independent of 
TLS, and thus ``sips:alice@atlanta.com;transport=tcp'' and
``sips:alice@atlanta.com;transport=sctp'' are both valid (although note that
UDP is not a valid transport for SIPS). The use of ``transport=tls'' has 
consequently been deprecated, partly because it was specific to a single
hop of the request. This is a change since RFC~2543.} 

Users that distribute a SIPS URI as an address-of-record may elect to
operate devices that refuse requests over insecure transports.
\end{changebar}

\subsubsection{HTTP Authentication}
\label{sec:security:other:auth}

SIP provides a challenge capability, based on HTTP authentication, that
relies on the 401 and 407 response codes as well as header fields for carrying
challenges and credentials.  Without significant modification, the reuse
of the HTTP Digest authentication scheme in SIP allows for replay
protection and one-way authentication.

The usage of Digest authentication in SIP is detailed in
Section~\ref{sec:security:auth}.

\subsubsection{S/MIME}
\label{sec:security:other:smime}

As is discussed above, encrypting entire SIP messages end-to-end for the
purpose of confidentiality is not appropriate because network
intermediaries (like proxy servers) need to view certain header fields in
order to route messages correctly, and if these intermediaries are
excluded from security associations, then SIP messages will essentially
be non-routable.

However, S/MIME allows SIP UAs to encrypt MIME bodies within
SIP, securing these bodies end-to-end without affecting message headers. 
S/MIME can provide end-to-end confidentiality and integrity for message
bodies, as well as mutual authentication.  It is also possible to use
S/MIME to provide a form of integrity and confidentiality for SIP
header fields through SIP message tunneling.

The usage of S/MIME in SIP is detailed in
Section~\ref{sec:security:smime}.

\subsection{Implementing Security Mechanisms}
\label{sec:security:implement}

\subsubsection{Requirements for Implementers of SIP}
\label{sec:security:requirements}

Proxy servers, redirect servers, and registrars {\MUST} implement TLS,
and {\MUST} support both mutual and one-way authentication.  It is
strongly {\RECOMMENDED} that UAs be capable initiating TLS; UAs
{\MAY} also be capable of acting as a TLS server.  Proxy servers,
redirect servers, and registrars {\SHOULD} possess a site certificate
whose subject corresponds to their canonical hostname.  UAs {\MAY} have
certificates of their own for mutual authentication with TLS, but no
provisions are set forth in this document for their use.  
\begin{changebar}
All SIP
elements that support TLS {\MUST} have a mechanism for validating 
certificates received during TLS negotiation; this entails 
possession of one or more root certificates issued by certificate 
authorities (preferably well-known distributors of site certificates
comparable to those that issue root certificates for web browsers).

All SIP elements that support TLS {\MUST} also support the SIPS URI 
scheme.
\end{changebar}

Proxy servers, redirect servers, registrars, and UAs {\MAY} also
implement IPSec or other lower-layer security protocols.

When a UA attempts to contact a proxy server, redirect server, or
registrar, the UAC {\SHOULD} initiate a TLS connection over which it
will send SIP messages.  In some architectures, UASs {\MAY} receive
requests over such TLS connections as well.

Proxy servers, redirect servers, registrars, and UAs {\MUST}
implement Digest Authorization,
\begin{changebar}
encompassing all of the aspects required in~\ref{sec:security:auth}.
\end{changebar}
Proxy servers, redirect servers, and
registrars {\SHOULD} be configured with at least one Digest realm, and
at least one ``\header{realm}'' string supported by a given server
{\SHOULD} correspond to the server's hostname or domainname.

\begin{changebar}
UAs {\MAY} support the signing and encrypting of MIME bodies,
and transference of credentials with S/MIME as described in 
Section~\ref{sec:security:smime}. 
If a UA holds one or more root certificates of 
certificate authorities in order to validate certificates for TLS or
IPSec, it {\SHOULD} be capable of reusing these to verify S/MIME 
certificates, as appropriate. A UA {\MAY} hold root 
certificates specifically for validating S/MIME certificates.
\end{changebar}

\motivation{Note that is it anticipated that future security extensions
may upgrade the normative strength associated with S/MIME as S/MIME
implementations appear and the problem space becomes better understood.}

\subsubsection{Security Solutions}
\label{sec:security:solutions}

The operation of these security mechanisms in concert can follow 
the existing web and email security models to some degree.  At a high
level, UAs authenticate themselves to servers (proxy servers,
redirect servers, and registrars) with a Digest username and password;
\begin{changebar}
servers authenticate themselves to UAs one hop away, or to another server
one hop away (and vice versa), with a site certificate delivered by TLS. 
\end{changebar}

On a peer-to-peer level, UAs trust the
network to authenticate one another ordinarily; however, S/MIME can 
also be used to provide direct authentication when the network does 
not, or if the network itself is not trusted.

The following is an illustrative example in which these security
mechanisms are used by various UAs and servers to prevent the
sorts of threats described in Section~\ref{sec:security:threats}.  While
implementers and network administrators {\MAY} follow the normative
guidelines given in the remainder of this section, these are provided
only as example implementations.

\paragraph{Registration}

When a UA comes online and registers with its local
administrative domain, it {\SHOULD} establish a TLS connection with its
registrar (Section~\ref{sec:reg} describes how the UA reaches its registrar).
The registrar
{\SHOULD} offer a certificate to the UA, and the site identified
by the certificate {\MUST} correspond with the domain in which the UA
intends to register; for example, if the UA intends to
register the address-of-record 'alice@atlanta.com', the site certificate
must identify a host within the atlanta.com domain (such as
sip.atlanta.com).  When it receives the TLS Certificate message, the
UA {\SHOULD} verify the certificate and inspect the site
identified by the certificate.  If the certificate is invalid, revoked,
or if it does not identify the appropriate party, the UA 
{\MUSTNOT} send the {\REGISTER} message and otherwise proceed with the
registration.

\motivation{When a valid certificate has been provided by the registrar,
the UA knows that the registrar is not an attacker who might
redirect the UA, steal passwords, or attempt any similar
attacks.}

The UA then creates a {\REGISTER} request that {\SHOULD} be
addressed to a \header{Request-URI} corresponding to the site
certificate received from the registrar.  When the UA sends the
{\REGISTER} request over the existing TLS connection, the
registrar {\SHOULD} challenge the request with a 401 (Proxy
Authentication Required) response. The ``realm'' parameter within the
\header{Proxy-Authenticate} header field of the response {\SHOULD} correspond
to the domain previously given by the site certificate.  When the UAC
receives the challenge, it {\SHOULD} either prompt the user for
credentials or take an appropriate credential from a keyring
corresponding to the ``realm'' parameter in the challenge.  The username
of this credential {\SHOULD} correspond with the ``userinfo'' portion of
the URI in the \header{To} header field of the {\REGISTER} request.  Once the
Digest credentials have been inserted into an appropriate
\header{Proxy-Authorization} header field, the {\REGISTER} should be
resubmitted to the registrar. 

\motivation{Since the registrar requires the user agent to authenticate
itself, it would be difficult for an attacker to forge {\REGISTER}
requests for the user's address-of-record.  Also note that since the
{\REGISTER} is sent over a confidential TLS connection, attackers will
not be able to intercept the {\REGISTER} to record credentials for any
possible replay attack.}

Once the registration has been accepted by the registrar, the UA
{\SHOULD} leave this TLS connection open provided that the registrar
also acts as the proxy server to which requests are sent for users in
this administrative domain.  The existing TLS connection will be reused
to deliver incoming requests to the UA that has just completed
registration.

\motivation{Because the UA has already authenticated the server
on the other side of the TLS connection, all requests that come over
this connection are known to have passed through the proxy server -
attackers cannot create spoofed requests that appear to have been sent
through that proxy server.}

\paragraph{Interdomain Requests}

Now let's say that Alice's UA would like to initiate a session
with a user in a remote administrative domain, namely ``bob@biloxi.com''. 
We will also say that the local administrative domain (atlanta.com) has
a local outbound proxy.

The proxy server that handles inbound requests for an administrative
domain {\MAY} also act as a local outbound proxy; for simplicity's sake
we'll assume this to be the case for atlanta.com (otherwise the user
agent would initiate a new TLS connection to a separate server at this
point).  Assuming that the client has completed the registration process
described in the preceding section, it {\SHOULD} reuse the TLS
connection to the local proxy server when it sends an {\INVITE}
request to another user.  The UA {\SHOULD} reuse cached
credentials in the {\INVITE} to avoid prompting the user unnecessarily.

When the local outbound proxy server has validated the credentials
presented by the UA in the {\INVITE}, it {\SHOULD} inspect the
\header{Request-URI} to determine how the message should be routed 
(see~\citenorm{draft-ietf-sip-srv}).  If the ``domainname'' portion of the
\header{Request-URI} had corresponded to the local domain
(atlanta.com) rather than biloxi.com, then the proxy server would
have consulted its location service to determine how best to reach the
requested user.

\motivation{Had ``alice@atlanta.com'' been attempting to contact, say,
``alex@atlanta.com'', the local proxy would have proxied to the request to
the TLS connection Alex had established with the registrar when he
registered.  Since Alex would receive this request over his
authenticated channel, he would be assured that Alice's request had been
authorized by the proxy server of the local administrative domain.}

However, in this instance the \header{Request-URI} designates a remote
domain.  The local outbound proxy server at atlanta.com {\SHOULD}
therefore establish a TLS connection with the remote proxy server at
biloxi.com.  Since both of the participants in this TLS connection are
servers that possess site certificates, mutual TLS authentication
{\SHOULD} occur.  Each side of the connection {\SHOULD} verify and
inspect the certificate of the other, noting the domain name that
appears in the certificate for comparison with the header fields of SIP
messages.  The atlanta.com proxy server, for example, {\SHOULD} verify
at this stage that the certificate received from the remote side
corresponds with the biloxi.com domain.  Once it has done so, and TLS
negotiation has completed, resulting in a secure channel between the two
proxies, the atlanta.com proxy can forward the {\INVITE} request to
biloxi.com.

\begin{changebar}
The proxy server at biloxi.com {\SHOULD} inspect the
certificate of the proxy server at atlanta.com in turn and compare the domain
asserted by the certificate with the ``domainname'' portion of the
\header{From} header field in the {\INVITE} request.  The biloxi proxy {\MAY}
have a strict security policy that requires it to reject requests that 
do not match the administrative domain from which they have been proxied.  

\motivation{Such security policies could be instituted to prevent the
SIP equivalent of SMTP 'open relays' that are frequently exploited to
generate spam.}

This policy, however, only guarantees that the request came from the 
domain it ascribes to itself; it does not allow biloxi.com to ascertain
how atlanta.com authenticated Alice. Only if biloxi.com 
has some other way of knowing atlanta.com's authentication policies 
could it possibly ascertain how Alice proved her identity. biloxi.com
might then institute an even stricter policy that forbids requests that
come from domains that are not known administratively to share a common 
authentication policy with biloxi.com.
\end{changebar}

Once the {\INVITE} has been approved by the biloxi proxy, the proxy
server {\SHOULD} identify the existing TLS channel, if any, associated
with the user targeted by this request (in this case ``bob@biloxi.com''). 
The {\INVITE} should be proxied through this channel to Bob. Since the
request is received over a TLS connection that had previously been
authenticated as the biloxi proxy, Bob knows that the \header{From}
\begin{changebar}
header field was not tampered with and that atlanta.com has validated 
Alice, although not necessarily whether or not to trust Alice's identity.
\end{changebar}

Before they forward the request, both proxy servers {\SHOULD} add a
\header{Record-Route} header field to the request so that all future requests
in this dialog will pass through the proxy servers. The proxy servers
\begin{changebar}
can thereby continue to provide security services for the lifetime of this
dialog.  If the proxy servers do not add themselves to the
\header{Record-Route}, future messages will pass directly end-to-end
between Alice and Bob without any security services (unless the two
parties agree on some independent end-to-end security such as S/MIME). 
In this respect the
SIP trapezoid model can provide a nice structure where conventions of 
agreement between the site proxies can provide a reasonably secure 
channel between Alice and Bob.
\end{changebar}

\motivation{An attacker preying on this architecture would, for example,
be unable to forge a {\BYE} request and insert it into the signaling
stream between Bob and Alice because the attacker has no way of
ascertaining the parameters of the session and also because the 
integrity mechanism transitively protects the traffic between Alice and Bob.}

\paragraph{Peer to Peer Requests}

Alternatively, consider a UA asserting the identity
``carol@chicago.com'' that has no local outbound proxy.  When Carol wishes
to send an {\INVITE} to ``bob@biloxi.com'', her UA {\SHOULD}
initiate a TLS connection with the biloxi proxy directly (using the
mechanism described in~\citenorm{draft-ietf-sip-srv} to determine how to best to
reach the given \header{Request-URI}).  When her UA receives a
certificate from the biloxi proxy, it {\SHOULD} be verified normally
before she passes her {\INVITE} across the TLS connection.  However,
Carol has no means of proving her identity to the biloxi
proxy, but she does have a CMS-detached signature over a ``message/sip''
body in the {\INVITE}.  It is unlikely in this instance that Carol would
have any credentials in the biloxi.com realm, since she has no formal
association with biloxi.com.  The biloxi proxy {\MAY} also have a strict
policy that precludes it from even bothering to challenge requests that
do not have biloxi.com in the ``domainname'' portion of the
\header{From} header field - it treats these users as unauthenticated.

The biloxi proxy has a policy for Bob that all non-authenticated
requests should be redirected to the appropriate contact address
registered against 'bob@biloxi.com', namely $<$sip:bob@192.0.2.4$>$.  Carol
receives the redirection response over the TLS connection she
established with the biloxi proxy, so she trusts the veracity of the
contact address.

Carol {\SHOULD} then establish a TCP connection with the designated
address and send a new {\INVITE} with a \header{Request-URI} containing
the received contact address (recomputing the signature in the body as
the request is readied).  Bob receives this {\INVITE} on an insecure
interface, but his UA inspects and, in this instance, recognizes
the \header{From} header field of the request and subsequently matches a
locally cached certificate with the one presented in the signature of
the body of the {\INVITE}.  He replies in similar fashion,
authenticating himself to Carol, and a secure dialog begins.

\motivation{Sometimes firewalls or NATs in an administrative domain
could preclude the establishment of a direct TCP connection to a UA.
In these cases, proxy servers could also potentially relay
requests to UAs in a way that has no trust implications (for
example, forgoing an existing TLS connection and forwarding the request
over cleartext TCP) as local policy dictates.}

\paragraph{DoS Protection}

In order to minimize the risk of a denial-of-service attack against
architectures using these security solutions, implementers should take
note of the following guidelines.

When the host on which a SIP proxy server is operating is routable from
the public Internet, it {\SHOULD} be deployed in an administrative
domain with defensive operational policies (blocking source-routed traffic,
preferably filtering ping traffic).  Both TLS and IPSec can also make
use of bastion hosts at the edges of administrative domains that
participate in the security associations to aggregate secure tunnels and
sockets.  These bastion hosts can also take the brunt of 
denial-of-service attacks, ensuring that SIP hosts within the administrative
domain are not encumbered with superfluous messaging.

No matter what security solutions are deployed, floods of messages
directed at proxy servers can lock up proxy server resources and prevent
desirable traffic from reaching its destination.  There is a
computational expense associated with processing a SIP transaction at a
proxy server, and that expense is greater for stateful proxy servers
than it is for stateless proxy servers.  Therefore, stateful proxies are
more susceptible to flooding than stateless proxy servers.

UAs and proxy servers {\SHOULD} challenge questionable requests
with only a \emph{single} 401 (Unauthorized) or 407 (Proxy
Authentication Required), forgoing the normal response retransmission
algorithm,  and thus behaving statelessly towards
unauthenticated requests.  

\motivation{Retransmitting
the 401 (Unauthorized) or 407 (Proxy Authentication Required) status
response amplifies the problem of an attacker using a falsified header field value
(such as \header{Via}) to direct traffic to a third party.}

\begin{changebar}
In summary, the mutual authentication of proxy servers through mechanisms
such as TLS significantly reduces the potential for rogue intermediaries
to introduce falsified requests or responses that can deny service. This 
commensurately makes it harder for attackers to make innocent SIP nodes 
into agents of amplification. 
\end{changebar}

\subsection{Limitations}
\label{sec:security:limits}

Although these security mechanisms, when applied in a judicious manner,
can thwart many threats, there are limitations in the scope of the
mechanisms that must be understood by implementers and network
operators.

\subsubsection{HTTP Digest}
\label{sec:security:limits:digest}

One of the primary limitations of using HTTP Digest in SIP is that the
integrity mechanisms in Digest do not work very well for SIP. 
Specifically, they offer protection of the \header{Request-URI} and the
method of a message, but not for any of the header fields that UAs
would most likely wish to secure.

The existing replay protection mechanisms described in RFC~2617 also
have some limitations for SIP.  The next-nonce mechanism, for example,
does not support pipelined requests.  The nonce-count mechanism should
be used for replay protection.

\begin{changebar}
Another limitation of HTTP Digest is the scope of realms.  Digest is
valuable when a user wants to authenticate themselves to a resource with
which they have a pre-existing association, like a service provider of
which the user is a customer (which is quite a common scenario and thus 
Digest provides an extremely useful function).  
By way of contrast, the scope of TLS is interdomain or multirealm, 
since certificates are often globally verifiable, so that the UA can
authenticate the server with no pre-existing association.
\end{changebar}

\subsubsection{S/MIME}
\label{sec:security:limits:smime}

The largest outstanding defect with the S/MIME mechanism is the lack of
a prevalent public key infrastructure for end users.  If self-signed
certificates (or certificates that cannot be verified by one of the
participants in a dialog) are used, the SIP-based key exchange mechanism
described in Section~\ref{sec:security:smime:exchange} is susceptible to a
man-in-the-middle attack with which an attacker can potentially inspect
and modify S/MIME bodies.  The attacker needs to intercept the first
exchange of keys between the two parties in a dialog, remove the
existing CMS-detached signatures from the request and response, and
insert a different CMS-detached signature containing a certificate
supplied by the attacker (but which seems to be a certificate for the
proper address-of-record).  Each party will think they have exchanged
keys with the other, when in fact each has the public key of the
attacker.

It is important to note that the attacker can only leverage this
vulnerability on the first exchange of keys between two parties - on
subsequent occasions, the alteration of the key would be noticeable to
the UAs.  It would also be difficult for the attacker to remain in
the path of all future dialogs between the two parties over time (as
potentially days, weeks, or years pass).

SSH is susceptible to the same man-in-the-middle attack on the first
exchange of keys; however, it is widely acknowledged that while SSH is
not perfect, it does improve the security of connections.  The use of
key fingerprints could provide some assistance to SIP, just as it does
for SSH.  For example, if two parties use SIP to establish a voice
communications session, each could read off the fingerprint of the key
they received from the other, which could be compared against the
original. It would certainly be more difficult for the man-in-the-middle
to emulate the voices of the participants than their signaling (a 
practice that was used with the Clipper chip-based secure telephone).

The S/MIME mechanism allows UAs to send encrypted requests
without preamble if they possess a certificate for the destination
address-of-record on their keyring.  
\begin{changebar}
However, it is possible that any particular device registered for
an address-of-record will not hold the certificate that has been 
previously employed by the device's current user, and that it will
therefore be unable to process an encrypted request properly, which
could lead to some avoidable error signaling.
\end{changebar}
This is especially likely when an encrypted request is
forked.

The keys associated with S/MIME are most useful when associated with a
particular user (an address-of-record) rather than a device (a UA).  
When users move between devices, it may be difficult to
transport private keys securely between UAs; how such keys might
be acquired by a device is outside the scope of this document.

Another, more prosaic difficulty with the S/MIME mechanism is that it
can result in very large messages, especially when the SIP tunneling
mechanism described in Section~\ref{sec:security:tunnel} is used. 
For that reason, it is {\RECOMMENDED} that TCP should be used as a
transport protocol when S/MIME tunneling is employed.

\subsubsection{TLS}
\label{sec:security:limits:tls}

The most commonly voiced concern about TLS is that it cannot run over
UDP; TLS requires a connection-oriented underlying transport protocol,
which for the purposes of this document means TCP.  

It may also be arduous for a local outbound proxy server and/or
registrar to maintain many simultaneous long-lived TLS connections with
numerous UAs.  This introduces some valid scalability
concerns, especially for intensive ciphersuites.  Maintaining redundancy
of long-lived TLS connections, especially when a UA is solely
responsible for their establishment, could also be cumbersome.

TLS only allows SIP entities to authenticate servers to which they are
adjacent; TLS offers strictly hop-by-hop security.  Neither TLS, nor any
other mechanism specified in this document, allows clients to
authenticate proxy servers to whom they cannot form a direct TCP
connection.

\begin{changebar}
\subsubsection{SIPS URIs}
\label{sec:security:limits:sips}

Actually using TLS on every segment of a request path entails that the 
terminating UAS must be reachable over TLS (perhaps registering with a 
SIPS URI as a contact address). This is the preferred use of SIPS.
Many valid architectures, however,
use TLS to secure part of the request path, but rely on some other 
mechanism for the final hop to a UAS, for example. Thus SIPS cannot 
guarantee that TLS usage will be truly end-to-end.
Note that since many UAs will not accept incoming TLS
connections, even those UAs that do support TLS may be required to 
maintain persistent TLS connections as described in the TLS
limitations section above in order to receive requests over TLS as a UAS.

Location services are not required to provide a SIPS binding for a 
SIPS \header{Request-URI}. Although location services are commonly
populated by user registrations (as described in
Section~\ref{sec:reg:const:add}), various other protocols and interfaces
could conceivably supply contact addresses for an AOR, and these 
tools are free to map SIPS URIs to SIP URIs as appropriate. When queried
for bindings, a location service returns its contact addresses without 
regard for whether it received a request with a SIPS \header{Request-URI}.
If a redirect server is accessing the location service, it is up to the
entity that processes the \header{Contact} header field of a redirection
to determine the propriety of the contact addresses.

Ensuring that TLS will be used for all of the request segments up to the
target domain is somewhat complex. It
is possible that cryptographically authenticated proxy servers along the
way that are non-compliant or compromised may choose to disregard the 
forwarding rules associated with SIPS (and the general forwarding rules in 
Section~\ref{sec:proxy-request-forwarding}).
Such malicious intermediaries could, for example, 
retarget a request from a SIPS URI to a SIP URI in an attempt to downgrade
security.  

Alternatively, an intermediary might legitimately retarget a request
from a SIP to a SIPS URI. Recipients of a request whose
\header{Request-URI} uses the SIPS URI scheme thus cannot assume
on the basis of the \header{Request-URI} alone that SIPS was used for 
the entire request path (from the client onwards).

To address these concerns, it is {\RECOMMENDED} that recipients of 
a request whose \header{Request-URI} contains a SIP or SIPS URI inspect 
the \header{To} header field value to see if it contains a SIPS URI 
(though note that it does not constitute a breach of security if this 
URI has the same scheme but is not equivalent to the URI in the 
\header{To} header field).  Although clients may choose to populate the 
\header{Request-URI} and \header{To} header field of a request 
differently, when SIPS is used this disparity could be 
interpreted as a possible security violation, and the request could 
consequently be rejected by its recipient. Recipients {\MAY} also 
inspect the \header{Via} header chain in order to double-check 
whether or not TLS was used for the entire request path until the 
local administrative domain was reached. S/MIME may also be used by 
the originating UAC to help ensure that the original form of the 
\header{To} header field is carried end-to-end. 

If the UAS has reason to believe that the scheme of the \header{Request-URI}
has been improperly modified in transit, the UA {\SHOULD} notify its user of 
a potential security breach.

As a further measure to prevent downgrade attacks, entities that accept 
only SIPS requests {\MAY} also refuse connections on insecure ports. 

End users will undoubtedly discern the
difference between SIPS and SIP URIs, and they may manually edit them in
response to stimuli. This can either benefit or degrade security. For
example, if an attacker corrupts a DNS cache, inserting a fake record set
that effectively removes all SIPS records for a proxy server, then any SIPS
requests that traverse this proxy server may fail. When a user, however,
sees that repeated calls to a SIPS AOR are failing, they could on some
devices manually convert the scheme from SIPS to SIP and retry. Of course,
there are some safeguards against this (if the destination UA is truly
paranoid it could refuse all non-SIPS requests), but it is a limitation
worth noting. On the bright side, users might also divine that 'SIPS' 
would be valid even when they are presented only with a SIP URI.

\end{changebar}

\subsection{Privacy}
\label{sec:security:privacy}

SIP messages frequently contain sensitive information about their 
senders - not just what they have to say, but with whom they 
communicate, when they communicate and for how long, and from where 
they participate in sessions. Many applications and their users require 
that this sort of private information be hidden from any parties that 
do not need to know it. 

Note that there are also less direct ways in which private information 
can be divulged. If a user or service chooses to be reachable at an 
address that is guessable from the person's name and organizational 
affiliation (which describes most addresses-of-record), the traditional 
method of ensuring privacy by having an unlisted ``phone number'' is 
compromised. A user location service can infringe on the privacy of the 
recipient of a session invitation by divulging their specific 
whereabouts to the caller; an implementation consequently {\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.  
\begin{changebar}
This is a whole class of problem that is expected to be studied further
in ongoing SIP work.

In some cases, users may want to conceal personal information in header 
fields that convey identity. This can apply not only to the \header{From}
and related headers representing the originator of the request, but also
the \header{To} - it may not be appropriate to convey to the final 
destination a speed-dialing nickname, or an unexpanded identifier for 
a group of targets, either of which would be removed from the 
\header{Request-URI} as the request is routed, but not changed in 
the \header{To} header field if the two were initially identical.  
Thus it {\MAY} be desirable for privacy reasons to create a \header{To}
header field that differs from the \header{Request-URI}.
\end{changebar}
