26 Security Considerations: Threat Model and Security Usage
   Recommendations

   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.

26.1 Attacks and Threat Models

   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.

26.1.1 Registration Hijacking

   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 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 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 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.

26.1.2 Impersonating a Server

   The domain to which a request is destined is generally specified in
   the 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.

26.1.3 Tampering with Message Bodies

   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, Subject.  UAs might be protective of these header fields
   as well as bodies (a malicious intermediary changing the 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.

26.1.4 Tearing Down Sessions

   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 (To tag, 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-
   INVITEs 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.

26.1.5 Denial of Service and Amplification

   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 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 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.

   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.

26.2 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 Request-URI, Route,
   and 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 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.

26.2.1 Transport and Network Layer Security

   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 [25] and IPSec [26].

   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 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 [6] 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.

26.2.2 SIPS URI Scheme

   The SIPS URI scheme adheres to the syntax of the SIP URI (described
   in 19), 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 From header field of their requests, in the To header
   field of REGISTER requests).  When used as the 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 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 Request-URI, including
   in addresses-of-record, contact addresses (the contents of Contact
   headers, including those of REGISTER methods), and 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 [4].

   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.

      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.

26.2.3 HTTP Authentication

   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 22.

26.2.4 S/MIME

   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 23.

26.3 Implementing Security Mechanisms

26.3.1 Requirements for Implementers of SIP

   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.  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.

   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, encompassing all of the aspects required in 22.
   Proxy servers, redirect servers, and registrars SHOULD be configured
   with at least one Digest realm, and at least one "realm" string
   supported by a given server SHOULD correspond to the server's
   hostname or domainname.

   UAs MAY support the signing and encrypting of MIME bodies, and
   transference of credentials with S/MIME as described in Section 23.
   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.

      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.

26.3.2 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; 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.

   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 26.1.  While implementers and network
   administrators MAY follow the normative guidelines given in the
   remainder of this section, these are provided only as example
   implementations.

26.3.2.1 Registration

   When a UA comes online and registers with its local administrative
   domain, it SHOULD establish a TLS connection with its registrar
   (Section 10 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 MUST NOT send the
   REGISTER message and otherwise proceed with the registration.

      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
   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 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 To header field of the REGISTER request.
   Once the Digest credentials have been inserted into an appropriate
   Proxy-Authorization header field, the REGISTER should be resubmitted
   to the registrar.

      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.

      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.

26.3.2.2 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 Request-URI
   to determine how the message should be routed (see [4]).  If the
   "domainname" portion of the 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.

      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 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.

   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 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.

      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.

   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
   From header field was not tampered with and that atlanta.com has
   validated Alice, although not necessarily whether or not to trust
   Alice's identity.

   Before they forward the request, both proxy servers SHOULD add a
   Record-Route header field to the request so that all future requests
   in this dialog will pass through the proxy servers.  The proxy
   servers can thereby continue to provide security services for the
   lifetime of this dialog.  If the proxy servers do not add themselves
   to the 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.

      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.

26.3.2.3 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 [4] to determine how to best to reach the given
   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 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 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
   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.

      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.

26.3.2.4 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 single 401 (Unauthorized) or 407 (Proxy Authentication
   Required), forgoing the normal response retransmission algorithm, and
   thus behaving statelessly towards unauthenticated requests.

      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 Via) to direct
      traffic to a third party.

   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.

26.4 Limitations

   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.

26.4.1 HTTP 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 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.

   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.

26.4.2 S/MIME

   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 23.2 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.  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.  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 23.4 is used.  For that reason, it is
   RECOMMENDED that TCP should be used as a transport protocol when
   S/MIME tunneling is employed.

26.4.3 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.

26.4.4 SIPS URIs

   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 Request-URI.  Although location services are commonly populated
   by user registrations (as described in Section 10.2.1), 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 Request-URI.  If a redirect server is accessing
   the location service, it is up to the entity that processes the
   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 16.6).  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 Request-URI
   uses the SIPS URI scheme thus cannot assume on the basis of the
   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 Request-URI contains a SIP or SIPS URI inspect the 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 To header field).
   Although clients may choose to populate the Request-URI and 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 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 To
   header field is carried end-to-end.

   If the UAS has reason to believe that the scheme of the 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.

26.5 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.  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
   From and related headers representing the originator of the request,
   but also the 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
   Request-URI as the request is routed, but not changed in the To

   header field if the two were initially identical.  Thus it MAY be
   desirable for privacy reasons to create a To header field that
   differs from the Request-URI.