SIP Working Group                                             Jari Arkko
INTERNET-DRAFT                                             Vesa Torvinen
     <draft-ietf-sip-sec-agree-00.txt>
<draft-ietf-sip-sec-agree-01.txt>                      Gonzalo Camarillo
May 2002                                                        Ericsson
     April
Expires: December 2002                                        Tao Haukka
                                                                   Nokia
                                                              Sanjoy Sen
                                                               Lee Valerius
                                                         Nortel Networks

             Security Mechanism Agreement for SIP Sessions

1.

Status of this Memo memo

  This document is an Internet-Draft and is in full conformance with
  all provisions of Section 10 of RFC2026.

  Internet-Drafts are working docu¡
     ments documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups. Note that other
  groups may also distribute work¡
     ing working documents as Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or made obsolete obsoleted by other documents at any
  time. It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as work "work in progress. progress".

  The list of current Internet-Drafts may can be found accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt
  http://www.ietf.org/ietf/lid-abstracts.txt

  The list of Internet-Draft Shadow Directories may can be found accessed at
     http://www.ietf.org/shadow.html.

     The distribution of this memo is unlimited.  It
  http://www.ietf.org/shadow.html

  This document is filed as <draft-
     ietf-sip-sec-agree-00.txt>, and  expires October, 2002.  Please send
     comments an individual submission to the author or IETF. Comments
  should be directed to SIPPING or SIP working group.

2. the authors.

Abstract

  SIP has a number of security mechanisms for hop-by-hop and end-to-end
     protection. mechanisms. Some of the security mechanisms them have been built
  in to the SIP protocol, such as HTTP authentication or secure
  attachments. In
     these These mechanisms there are have even alternative algorithms and
  parameters.
     Currently it isn't possible to select SIP does not currently provide any mechanism for
  selecting which security mechanisms to use over a connection. In
  particular, even if some mechanisms such as OPTIONS were used to make
  this selection, the selection would be vul¡
     nerable vulnerable against the
  Bidding-Down attack. This document defines a three header fields for
  negotiating the security mechanisms within SIP. SIP between a user agent
  client and its next hop SIP entity. A SIP entity applying this
  mechanism must always require some minimum secu¡
     rity security (i.e. integrity
  protection) from all communicating parties in order to secure the
  negotiation, but the negotiation can agree on which specific minimum
  security is used.

3.   Contents

TABLE OF CONTENTS

  1.          Status of this Memo..................................1  Introduction....................................................2
  2.          Abstract.............................................1
       3.          Contents.............................................2
       4.          Introduction.........................................2
       5.  The Problem..........................................3
       6.          Solution.............................................4
         6.1.      Requirements.........................................4
         6.2.      Different Mechanisms.................................5
         6.3. Problem.....................................................3
  3.  Solution........................................................4
      3.1. Requirements...............................................4
      3.2. Overview of Operations...............................5
         6.4.      Header descriptions..................................7
       7. Operations.....................................5
      3.3. Syntax.....................................................6
      3.4. Protocol Operation.........................................7
        3.4.1 Client Initiated........................................7
        3.4.2 Server Initiated........................................8
      3.5. Security Mechanism Initiation..............................9
      3.6. Duration of the Security Association......................10
      3.7. Summary of header usage..............................9
       8. Header Field Use...............................10
  4.  Backwards Compatibility..............................10 Compatibility........................................11
  5.  Examples.......................................................11
      5.1. Client Initiated..........................................10
      5.2. Server Initiated..........................................12
  6.  Security Considerations........................................13
  7.  IANA Considerations............................................14
  8.  Modifications..................................................14
  9.          Examples.............................................10
         9.1.      Selecting Between New and Old Mechanisms.............10
         9.2.      Selections Along the Path............................11  Acknowledgments................................................15
  10.         Security Considerations..............................13 Normative References...........................................15
  11.         IANA Considerations..................................13 Non-Normative References.......................................15
  12.         Modifications........................................14
       13.         Acknowledgments......................................15

4. Authors’s Addresses............................................16

1. Introduction

  Traditionally, security protocols have included facilities to agree
  on the used mechanisms, algorithms, and other security parameters.
  The reason for this is that experience has shown that e.g. algorithm
  development uncovers problems in old algorithms and produces new
  ones. Furthermore, different mechanisms and algorithms are suitable
  for dif¡
     ferent different situations. Typically, protocols also select other
  parameters beyond algorithms at the same time.

  The purpose of this specification is to define a similar negotiation
  functionality in SIP [1]. SIP has some security functionality built-in built-
  in such as HTTP Digest authentication [4], secure attachments such as
  S/MIME [5], and can also use underlying security protocols such as
     IPSec/IKE
  IPsec/IKE [2] or TLS [3]. Some of the built-in security functionality
  allows also alternative algorithms and other parameters. While some
  work within the SIP Working Group has been looking towards reducing
  the number of recommended security solutions (e.g. (i.e., recommend just
  one lower layer security protocol), we can not expect to cut down the num¡
     ber
  number of items in the whole list to one. There will still be
  multiple security solutions utilized by SIP. Furthermore, it is
  likely that new  methods will appear in the future, to complete complement the
  methods that exist today.

  Chapter 5 2 shows that without a secured method to choose between secu¡
     rity
  security mechanisms and/or their parameters, SIP is vulnerable to
  certain attacks. As the HTTP authentication RFC [4] points out,
  authentication and integrity protection using multiple alternative
  methods and algo¡
     rithms algorithms is vulnerable to Man-in-the-Middle (MITM) (MitM)
  attacks. More seri¡
     ously, seriously, it is hard or sometimes even impossible to
  know whether a SIP peer entity is truly unable to perform e.g. (e.g.,
  Digest, TLS, or S/MIME, S/MIME) or if a MITM MitM attack is in action. In small
  networks consisting of workstations and servers these issues are not
  very relevant, as the administrators can deploy appropriate software
  versions and set up policies for using exactly the right type of
  security. However, SIP will soon be deployed to hundreds of millions of
  small devices with little or no possibilities for coordinated
  security policies, let alone software upgrades, and this makes these
  issues much worse. This conclusion is also supported by the
  requirements from 3GPP [6].

  Chapter 6 documents the proposed solution, and chapter 7 gives some
  demonstrative examples.

5.   The

2. Problem Description

  SIP has alternative security mechanisms such as HTTP authentication /
  with integrity protection, lower layer security protocols, and
  S/MIME. It is likely that their use will continue in the future. SIP
  security is developing, and is likely to see also new solutions in
  the future.

  Deployment of large number of SIP-based consumer devices such as 3GPP
  terminals requires all network devices to be able to accommodate
  past, current and future mechanisms; there is no possiblity possibility for instanta¡
     neous
  instantaneous change since the new solutions are coming gradually in
  as new standards and product releases occur. It is sometimes even
  impossible to upgrade some of the devices without getting completely
  new hard¡
     ware. hardware.

  So, the basic security problem that such a large SIP-based network
  must consider, would be on how do security mechanisms get selected?
  It would be desirable to take advantage of new mechanisms as they
  become available in products.

  Firstly, we need to know somehow what security should be applied, and
  preferably find this out without too many additional roundtrips.

  Secondly, selection of security mechanisms MUST be secure.  Tradition¡
     ally,
  Traditionally, all security protocols use a secure form of
  negotiation. For instance, after establishing mutual keys through
  Diffie-Hellman, IKE sends hashes of the previously sent data --
  including the offered crypto mechanisms. This allows the peers to
  detect if the initial, unprotected offers were tampered with.

  The security implications of this are subtle, but do have a fundamen¡
     tal
  fundamental importance in building large networks that change over
  time. Given that the hashes are produced also using algorithms agreed
  in the first unprotected messages, one could ask what the difference
  in security really is. Assuming integrity protection is mandatory and
  only secure algorithms are used, we still need to prevent MITM MitM
  attackers from mod¡
     ifying modifying other parameters, such as whether encryption
  is provided or not. Let us first assume two peers capable of using
  both strong and weak security. If the initial offers are not
  protected in any way, any attacker can easily "downgrade" the offers
  by removing the strong options. This would force the two peers to use
  weak security between them. But if the offers are protected in some
  way -- such as by hash¡
     ing, hashing, or repeating them later when the selected
  security is really on -- the situation is different. It would not be
  sufficient for the attacker to modify a single message. Instead, the
  attacker would have to modify both the offer message, as well as the
  message that contains the hash/repetition. More importantly, the
  attacker would have to forge the weak security that is present in the
  second message, and would have to do so in real time between the sent
  offers and the later messages. Otherwise, the peers would notice that
  the hash is incor¡
     rect. incorrect. If the attacker is able to break the weak
  security, the security method and/or the algorithm should not be
  used.

  In conclusion, the security difference is making a trivial attack pos¡
     sible
  possible versus demanding the attacker to break algorithms. An
  example of where this has a serious consequence is when a network is
  first deployed with integrity protection (such as HTTP Digest [4]),
  and then later new devices are added that support also encryption
  (such as S/MIME [1]). In this situation, an insecure negotiation
  procedure allows attackers to trivially force even new devices to use
  only integrity protection.

6.

3. Solution

6.1.

3.1 Requirements

  The solution to the SIP security negotiation problem should have the
  following properties:

  (a) It allows the selection of security mechanisms, such as lower
  layer security protocols or secure attachments. HTTP digest. It also allows the selection
  of individual algorithms and parameters when the security functions
  are integrated in SIP (such as in the case of HTTP authenti¡
     cation or secure attachments). authentication).

  (b) It allows both end-to-end and hop-by-hop first-hop security negotiation.

  (c) It is secure, e.g. secure (i.e., prevents the bidding down attack. attack.)

  (d) It is capable of running without additional roundtrips. This is
  important in the cellular environment, where an additional roundtrip
  could delay the call set up for 1000-1500 ms.

  (e) It does not introduce any additional state to servers and
  proxies.

  Currently, SIP does not have any mechanism which fulfills all the
  requirements above. The basic SIP features such as OPTIONS and
  Require, Supported headers are capable of informing peers about vari¡
     ous
  various capabilities including security mechanisms. However, the straight¡
  straight forward use of these features can not guarantee a secured
  agreement. HTTP Digest algorithm lists [4] are not secure for picking
  among the digest integrity algorithms, as is described in the RFC
  itself. More seriously, they have no provisions for allowing
  encryption to be nego¡
     tiated. negotiated. Hence, it would be hard to turn on
  possible future encryption schemes in a secure manner.

6.2. Different Mechanisms

  A self-describing security mechanism is a security mechanism that,
  when used, contains all necessary information about the method being
  used as well as all of its parameters such as algorithms.

  A non-self-describing security mechanism is a security mechanism
  that, when used, requires that the use of the method or some of its parame¡
     ters
  parameters have been agreed beforehand.

  Most security mechanisms used with SIP are self-describing. The use
  of HTTP digest, as well as the chosen algorithm is visible from the
  HTTP authentication headers. The use of S/MIME is indicated by the
  MIME headers, and the CMS structures inside S/MIME describe the used
  algorithms. TLS is run on a separate port in SIP, and where IPsec/IKE
  is used, IKE negotiates all the necessary parameters.

  The only exception to this list is the use of manually keyed IPsec.
  IPsec headers do not contain information about the used algorithms.
  Furthermore, peers have to set up IPsec Security Associations before
  they can be used to receive traffic. In contrast S/MIME can be
  received even if no Security Association was in place, because the
  application can search for a Security Association (or create a new
  one) after having received a message that contains S/MIME.

  In order to make it possible to negotiate both self-describing and
  non-self-describing security mechanisms, we need another requirement
  on the security agreement scheme:

  (f) the security agreement scheme must allow both sides to decide on
  the desired security mechanism before it is actually used.

  This decision can, and must, take place on both sides before we can
  be sure that the negotiation has not been tampered by a man-in-the-middle. man-in-the-
  middle. This tampering will be detected later.

6.3.

3.2. Overview of Operations

     This specification uses the following approach.

  The clients and
     servers offer their lists message flow below illustrates how the mechanism defined in this
  document works:

         1. Client ----------client list---------> Server
         2. Client <---------server list---------- Server
         3. Client ------(turn on security)------- Server
         4. Client ----------server list---------> Server
         5. Client <---------ok or error---------- Server

       Figure 1: Security negotiation message flow

  Step 1: Clients wishing to use this specification can send a list of
  their supported security mechanisms and parame¡
     ters in along the first, unprotected messages. They then proceed first request to turn on the selected security, and finally repeat some information under
  server.

  Step 2: Servers wishing to use this
     security in order specification can challenge the
  client to ensure that perform the first exchanged lists had security agreement procedure. The security
  mechanisms and parameters supported by the server are sent along in
  this challenge.

  Step 3: The client then proceeds to select the highest-preference
  security mechanism they have in common and to turn on the selected
  security.

  Step 4: The client contacts the server again, now using the selected
  security mechanism. The server's list of supported security
  mechanisms is returned as a response to the challenge.

  Step 5: The server verifies its own list of security mechanisms in
  order to ensure that the original list had not been modified.

  This procedure is stateless for servers (unless the used security
  mechanisms require the server to keep some state).

  The client and the server lists are both static i.e. (i.e., they do not
  and
     can not cannot change based on the input from the other side. side). Nodes MAY, how¡
     ever, may,
  however, maintain several static lists, one for each interface, for exam¡
     ple.

       1. Client ----------client list---------> Server
       2. Client <---------server list---------- Server
       3. Client ------(turn on security)------- Server
       4. Client ----------server list---------> Server
       5. Client <---------ok or error---------- Server
     The steps are explained below:

     - Step 1: The client MUST announce a list of supported security mecha¡
     nisms in their fist request. The client SHOULD also add the option-tag
     'sec-agree' to
  example.

  Between Steps 1 and 2, the Supported header.

     - Step 2: The server MUST announce may set up a list of supported non-self-describing
  security mecha¡
     nisms in their first response. The server MUST add its list to the
     response even mechanism if there were no common security mechanisms in the
     client's and server's lists, and the list MUST NOT depend on the con¡
     tents necessary. Note that with this type of security
  mechanisms, the client's list. server is necessarily stateful. The list MUST also be added regardless of
     any potential error codes in the response.

     An error has occurred if the client list is not present in would set
  up the request
     of Step 1, this request is not OPTIONS, non-self-describing security mechanism between Steps 2 and the server's policy
     requires the use of this specification. This error will be reported by
     returning 421 (Extension Required).  In this case the server MUST also
     include a Require header with an option-tag 'sec-agree' in its
     response.

     - Step 3: The peers MUST initiate the security mechanism, if necessary
     to carry this outside the request in Step 4. For instance, TLS should
     be turned on at this stage.

     - Step 4: The client MUST select and use the first matching security
     mechanism from the server's list. The client MUST also repeat the
     server's list.

     - Step 5: The server MUST check that the server list sent in the
     secured message in Step 4 corresponds to its static list of supported
     security mechanisms.  The server MUST send a positive answer or pro¡
     ceed to execute the requested operation if and only if the list was
     not modified.  If modification of the list is detected, the server
     MUST return a 494 (Security Agreement Failed) response or disconnect.
     The 494 response MUST include server's unmodified list of supported
     security mechanisms. The server MUST NOT copy any Security-Mechanism
     header from the request in Step 4 to the 494 response in Step 5.

     The server MAY decide to use a security mechanism between Steps 1 and
     2 but it MUST do so before processing request in Step 4. The client
     MUST decide to use a security mechanism between Steps 2 and 3.

     Between Steps 1 and 2, the server MAY set up a non-self-describing
     security mechanism if necessary. Note that with this type of security
     mechanisms, the server is necessarily stateful. Between Steps 2 and 4,
     the client MAY set up a non-self-describing security mechanism.

     Note that non-adjacent SIP entities can not use hop-by-hop security
     mechanisms such as TLS or IPsec. If a client receives a list of hop-
     by-hop security mechanisms from a server several hops away, it MUST
     NOT try to use these mechanisms with the first hop proxy. The client
     MAY try to contact the server directly leaving the proxies in between
     away.

     Once the security has been negotiated between two SIP entities, the
     same SIP entities MAY use the same security when communicating with
     each other in different SIP roles. For example, if a UAC in a end-user
     equipment and a UAS in a proxy negotiate some security, they may try
     to use the same security for terminating requests.

     The results of the security mechanism negotiation MAY be informed to
     the user of an UAC or an UAS. The user MAY decline to accept a partic¡
     ular security mechanism, and abort further SIP communications with the
     peer.

     One SIP request MAY include several independent list.  Only one list
     SHOULD be used between two 4.

3.3. Syntax

  We define three new SIP entities.  This allows a negotiation of
     the first-hop security mechanism while at the same time running e.g. a
     REGISTER with Digest authentication to a server some hops away.

6.4. Header descriptions

     The Security-Mechanism header indicates who wants security towards
     whom, and what kind of security.  The security features are repre¡
     sented using the header fields, namely Security-Client,
  Security-Server and Security-Verify. Their BNF syntax described below.

     The following ABNF describes the syntax of this header and extends
     section 25.1 in [1]:

     "Security-Mechanism" is provided
  below:

     security-client = "Security-Client" HCOLON to-uri from-uri mechanism-list

         to-uri
                       sec-mechanism *(COMMA sec-mechanism)
     security-server = "to" EQUAL sip-uri COMMA
         from-uri "Security-Server" HCOLON
                       sec-mechanism *(COMMA sec-mechanism)
     security-verify = "from" EQUAL sip-uri COMMA
         mechanism-list "Security-Verify" HCOLON
                       sec-mechanism *(COMMA sec-mechanism)
     sec-mechanism   = 1*(COMMA mechanism [SEMI preference]
                             [SEMI algorithm] [SEMI params])
         mechanism mechanism-name *(SEMI mech-parameters)
     mechanism-name  = "mech" EQUAL ( "digest" "digest-integrity" / "tls" / "ipsec-ike" /
                        "ipsec-man" / "smime" / token )
         preference
     mech-parameters = "pref" EQUAL preference-value ( preference / algorithm / extension )
     preference      = "alg" “q” EQUAL algorithm-value
         params qvalue
     qvalue          = parameter *[SEMI parameter]
         parameter ( “0” [ “.” 0*3DIGIT ] )
                        / ( “1” [ “.” 0*3(“0”) ] )
     algorithm       = param-name "alg" EQUAL param-value
         param-name     = token
         param-value
     extension       = token / quoted-string

     The meaning of these fields is as follows:

     to-uri         Indicates the desired receiver of the information.
                    The value of this field should be a SIP URI. When
                    sent by a client, the value would typically (but
                    not necessarily) contain just the host and port
                    number parts.

     from-uri       Indicates the sender of the security agreement
                    information. The value of this generic-param

  Note that qvalue is also a SIP URI.
                    When sent by a client, already defined in the value would typically
                    (but not necessarily) include a username part.

     mechanism SIP BNF [1]. We have
  copied its definitions here for completeness.

  The parameters described by the BNF above have the following
  semantics:

    Mechanism-name: It identifies the security mechanism supported by
    the SIP entity
                    identified client, when it appears in a security-client header fields, or
    by the from-uri. server, when it appears in a security-server header field.
    This specification defines six values:

      - "tls" for TLS [3], [3].
      - "digest" "digest-integrity" for HTTP Digest [4], [4] using additional
      integrity protection (i.e., the qop parameter) for the Security-
      Verify header field.
      - "ipsec-ike" for IPsec with IKE [2], [2].
      - "ipsec-man" for manually keyed IPsec without IKE, IKE.
      - "smime" for S/MIME [5], and
                    - token [5].

    Preference: The "q" value indicates a relative preference for extensions

                   To use TLS, the client MUST contact
    particular mechanism. The higher the server side on
                   port 5061. If this connection attempt fails, value the more preferred the
    mechanism is.

    Algorithm: An optional algorithm field for those security agreement procedure MUST be considered to have
                   failed, and MUST be terminated.

                   To use
    mechanisms which are not self-describing or which are vulnerable
    for bidding-down attacks (e.g., HTTP Digest). In the case of HTTP
    Digest, it alone does not fulfill the
                   minimum security requirements same rules apply as defined in [4] for the "algorithm"
    field in HTTP Digest.

3.4. Protocol Operation

  This section deals with the protocol details involved in the
  negotiation between a user agent client and its next-hop SIP entity.
  Throughout the text the next-hop SIP entity is referred to as the
  first-hop proxy or outbound proxy. However, the reader should bear in
  mind that a user agent server can also be the next-hop for a user
  agent client in the absence of this specification. In
                   order proxies. Note as well that a proxy can
  also have an outbound proxy.

3.4.1 Client Initiated

  A client wishing to use HTTP Digest securely, establish some variant type of MIME
                   tunneling security with its first-
  hop proxy SHOULD be used add a Security-Client header field to a request
  addressed to this proxy (i.e., the destination of the request is the
  first-hop proxy). This header field contains a list of all the
  security mechanisms that the client supports. The client SHOULD NOT
  add preference parameters to force this list. The client MUST also add a
  Require header field with the Security-Mechanism value "sec-agree" to its request.

  The Security-Client header field is used by the server to be integrity protected include any
  necessary information in the MIME body. Also, its response. For example, if the server decides that the first matching mechanism digest-
  integrity is HTTP digest in Step 2 of Section 6.3, the chosen mechanism, the server
                   SHOULD include includes a HTTP authentication challenge WWW-
  Authenticate header in its the response. However, HTTP Digest need not to be negotiated
                   if some underlying security If S/MIME is used (e.g. TLS or
                   IPsec). The proxy/server can always challenge chosen, the client
                   after some security mechanism
  appropriate certificate is already in place.

                   To use either "ipsec-ike" or "ipsec-man", included. If the security mechanisms
  supported by the client and do not need any further information to be
  established (e.g., TLS) the server MUST request their IPsec implementations client MAY choose not to
                   protect all further communications between include the same IP
                   addresses and ports which where used in
  Security-Client header field in the first its request.

  A server receiving a request from that contains a Require header field
  with the value "sec-agree" MUST challenge the client and first with a 494
  (Security Agreement Required) response. The server MUST add a
  Security-Server header field to this response from the
                   server. If listing the IKE connection attempt fails, security
  mechanisms that the
                   agreement procedure server supports. The server MUST be considered add its list to have failed,
                   and MUST be terminated. Clients and servers SHOULD
                   terminate
  the IPsec protection when it is no longer
                   used.

                   Note also that "ipsec-man" will only work response even if there are no common security mechanisms in the
                   communicating SIP entities know which keys
  client's and other
                   parameters to use. It is outside server's lists. The server’s list MUST NOT depend on the scope
  contents of this
                   specification the client's list.

  The server MUST compare the list received in the Security-Client
  header field with the list to describe how this information can be
                   made known to sent in the peers.

                   To use S/MIME, Security-Server header
  field. When the client MUST construct its request in
                   Step 4 (see 6.3) using S/MIME. If receives this response, it will choose the
  common security mechanism with the higher preference value.
  Therefore, the server sees MUST add the necessary information so that
                   S/MIME is the selected
  client can initiate that mechanism in Step 2, (e.g., a WWW-Authenticate header
  field for digest-integrity).

  When the client receives a response with a Security-Server header
  field, it MAY send
                   its own certificate within an S/MIME body SHOULD choose the security mechanism in the
                   response of Step 2.

     preference    A positive integer identifying server’s list
  with the preferred order of highest "q" value among all the mechanisms. Servers MUST use preference numbers in
                   their lists mechanisms that are known to identify the preferred order of
  the
                   security mechanisms. Clients client. Then, it MUST NOT use preference
                   numbers in their lists.

     algorithm     An optional algorithm field for those initiate that particular security
                   mechanisms which are not self-describing or which are
                   vulnerable for bidding-down attacks (e.g. HTTP Digest).
                   In mechanism
  as described in Section 3.5. This initiation may be carried out
  without involving any SIP message exchange (e.g., establishing a TLS
  connection).

  All the case subsequent SIP requests sent by the client SHOULD make use of HTTP Digest,
  the same rules apply as
                   defined security mechanism initiated in [4] for the "algorithm" field in HTTP
                   Digest.

     params        An optional field that allows future extensions. Any
                   unrecognized directive previous step. These requests
  MUST be ignored.

                   Multiple instances of the same contain a Security-Verify header field can appear that mirrors the server’s
  list received previously in the Security-Server header field. This
  request MAY use SIP messages. Typically, loose routing mechanism (i.e., Route header
  fields) to traverse the proxy, but its final destination may be
  different than the proxy. In this case, the client inserts its own
                   Security-Mechanism header when it sends request SHOULD NOT
  include a request, and Require header field with the server/proxy adds its own to value "sec-agree".

    For example, the response. The
                   parameters are in all cases set in first request was an appropriate manner OPTIONS request directly
    addressed to indicate in the "to-uri" paremeter the party who
                   inserted proxy and the header. Or rather -- since second request is an INVITE that
    will traverse the client proxy but that is
                   copying some of addressed to a real user (see
    example in section 4.1).

  The server MUST check that the server's responses -- whose security
                   capabilities mechanisms listed in the
  Security-Verify header applies to.

7.   Summary field of header usage

     The Security-Mechanism header may be used incoming requests correspond to negotiate the its
  static list of supported security
     mechanisms between various SIP entities including UAC, UAS, proxy, mechanisms.  The server can proceed
  processing a particular request if, and
     registrar.  Information about only if, the use list was not
  modified.  If modification of Security-Mechanism header in
     relation to SIP methods and proxy processing the list is summarized in Table 1.

       Header field           where        proxy ACK BYE CAN INV OPT REG
       _________________________________________________________________
       Security-Mechanism       R           ar    -   -   -   c   c   c
       Security-Mechanism      2xx detected, the server MUST
  challenge the client with a     -   -   -   c   c   c
       Security-Mechanism  401,407,421,494 494 (Security Agreement Required). This
  response MUST include a     -   -   -   c   c   c

                  Table 1: Summary challenge with server's unmodified list of header usage.

     The "where" column describes
  supported security mechanisms.

  Once the request and response types in which security has been negotiated between two SIP entities, the header field may be used. The header may not appear in other types
     of
  same SIP messages. Values in entities MAY use the where column are:

     - R: Header field same security when communicating with
  each other in different SIP roles. For example, if a UAC and its
  outbound proxy negotiate some security, they may appear in requests.

     - 2xx, 401, etc.: A numerical value or range indicates response codes
     with which try to use the header field can same
  security for incoming requests (i.e., the UA will be used. acting as a
  UAS).

  The "proxy" column describes the operations user of a proxy may perform on UA MAY be informed about the results of the security
  mechanism negotiation. The user MAY decline to accept a
     header field:

     - a: A proxy can add or concatenate particular
  security mechanism, and abort further SIP communications with the header field if not present.

     - r:
  peer.

3.4.2 Server Initiated

  A proxy must be able server decides to read use the header field, and thus security negotiation described in this
     header field cannot be encrypted.

     The next six columns relate
  document based on local policy. A server that decides to use this
  negotiation MUST challenge requests regardless of the presence or the
  absence of a any Require or Supported header field fields in a
     method:

     - c: Conditional; requirements on the header field depend on incoming
  requests.

  A server that by policy requires the con¡
     text use of the message.

8.   Backwards Compatibility

     SIP entities which support this specification but whose policy and
  receives a request that does not require its use, SHOULD only start using it if so required by the
     peer. Such SIP entities can thus communicate with other SIP entities
     even if they do not support this specification.

     SIP entities that support this specification and have the sec-agree option tag in a policy which
     requires its use
  Require or Supported header field MUST insert return a 421 (Extension
  Required) response. If the request had the sec-agree option tag in a
  Supported and Require headers as
     described header field, it MUST return a 494 (Security Agreement
  Required) response. In both situation the server MUST also include in this specification. This makes communications possible
     only with nodes that support this specification. The OPTIONS method
     can still be used with any node.

     Note that
  the use of this specification together response a Security-Server header field listing its capabilities
  and a Require header field with an option-tag 'sec-agree' in it. All
  the Proxy-
     Require Via header demands field entries in the response except the topmost value
  MUST be removed.

  Clients that support of this specification from all SIP
     entities along the path.

9.   Examples

9.1. Selecting Between New and Old Mechanisms

     In extension defined in this example we demonstrate the use document MAY add a
  Supported header field with a value of the framework for securing "sec-agree". In addition to
  this, clients SHOULD add a
     hop using some security mechanism, without knowing beforehand which
     methods the server supports. We assume Security-Client header field so that they
  can save a round trip in case the client is not willing
     to reveal any information on what it intends server decides to do, so it uses OPTIONS
     in challenge the first message that is sent in
  request.

3.5. Security mechanism initiation

  Once the clear. The example starts by
     a client sending chooses a message to security mechanism from the list received
  in the Security-Server header field from the server, indicating that it is of the
     new variant initiates
  that supports mechanism. Different mechanisms require different initiation
  procedures.

  If TLS in Step 1. In Step 2, is chosen, the client MUST contact the server
     responds that with it own list using the host
  part of security mechanisms -- S/MIME or TLS the Request-URI in this case -- and the peers start only common security service i.e.
     TLS at Step 3. In Step 4, first request to the client resends server as the server's Security-
     Mechanism header, which
  destination of the server verifies, and responds with 200 OK.

       1. Client -> Server:

          OPTIONS server SIP/2.0
          Security-Mechanism: to=sip:server.example.com,
                              from=sip:client.example.com,
                              mech=tls

       2. Server -> Client:

          200 OK
          Security-Mechanism: to=sip:client.example.com,
                              from=sip:server.example.com,
                              mech=smime;pref=1, mech=tls;pref=2

       3. Security handshake at a lower layer i.e. TLS

       4. Client -> Server:

          INVITE server SIP/2.0
          Security-Mechanism: to=sip:client.example.com,
                              from=sip:server.example.com,
                              mech=smime;pref=1, mech=tls;pref=2

       5. Server -> Client:

          200 OK

     In connection (note that this may involve using
  standard SIP DNS procedures to locate a server). If this connection
  attempt fails, the example we security agreement procedure MUST be considered to
  have omitted failed, and MUST be terminated.

  If digest-integrity is chosen, the returned values 494 (Security Agreement Required)
  response will contain an HTTP authentication challenge. The client
  MUST use the qos parameter possibly together with some variant of Security-Mecha¡
     nism
  MIME tunneling so that the Security-Verify header field in replies for clarity. Typically the
  request is integrity protected in SIP the servers do MIME body. Note that digest
  alone would not
     remove header fields as they answer, they only add new headers.

     If fulfill the minimum security requirements of this example was run without Security-Mechanism in Step 2,
  specification.

  To use "ipsec-ike", the client would not know what kind attempts to establish an IKE
  connection to the host part of security the other one supports,
     and would Request-URI in the first request
  to the server. If the IKE connection attempt fails, the agreement
  procedure MUST be forced considered to error-prone trials.

     More seriously, have failed, and MUST be terminated.

  Note that "ipsec-man" will only work if the Security-Mechanism was omitted in Step 4, communicating SIP
  entities know which keys and other parameters to use. It is outside
  the
     whole process would scope of this specification to describe how this information can
  be prone for MITM attacks. An attacker could spoof
     "ICMP Port Unreachable" message on made known to the trials, peers.

  In both IPsec-based mechanisms, it is expected that appropriate
  policy entries for protecting SIP have been configured or remove will be
  created before attempting to use the stronger security option from the header in Step 1, therefore substantially
     reducing the security.

9.2. Selections Along agreement procedure,
  and that SIP communications use port numbers and addresses according
  to these policy entries. It is outside the Path

     This example attempts scope of this
  specification to show describe how selections this information can be made between a
     client and known to
  the first-hop proxy while peers, but it could be typically configured at the actual SIP messages are still
     destinated to a server further on in same time as
  the network. This example demon¡
     strates how we can securely agree on IKE credentials or manual SAs have been entered.

  To use S/MIME, the client MUST construct its request using S/MIME.
  The client may have received the server’s certificate in an S/MIME
  body in the 494 (Security Agreement Required) response.

3.6. Duration of Security Associations

  Once a security mechanism between has been negotiated, both the client server and its first hop proxy, without adding roundtrips.

     In this example,
  the client sends need to know until when it can be used. All the mechanisms
  described in this document have a REGISTER request different way to its registrar.
     At signal the same time, end of
  a security association. When TLS is used, the client termination of the
  connection indicates that a new negotiation is needed. IKE negotiates
  the security with duration of a different
     first hop proxy. There are three alternative security solutions: a)
     TLS, b) IPsec/IKE, and c) HTTP Digest.

     The example starts association. If the credentials provided
  by a client coming using digest-integrity are not longer valid, the server
  will re-challenge the client. It is assumed that when IPsec-man is
  used, the same out-of-band mechanism used to a new network and learning distribute keys is used
  to define the address duration of the local proxy. security association.

3.7. Summary of Header Field Use

  The header fields defined in this document may be used to negotiate
  the security mechanisms between a UAC and other SIP entities
  including UAS, proxy, and registrar. Information about the use of
  headers in relation to SIP methods and proxy processing is summarized
  in Table 1.

  Header field           where        proxy ACK BYE CAN INV OPT REG

  _________________________________________________________________
  Security-Client          R           ard   -   o   -   o   o   o
  Security-Server     401,407,421,494        -   o   -   o   o   o
  Security-Verify          R           ard   -   o   -   o   o   o

  Header field           where        proxy SUB NOT PRK IFO UPD MSG

  _________________________________________________________________
  Security-Client          R           ard   o   o   -   o   o   o
  Security-Server     401,407,421,494        o   o   -   o   o   o
  Security-Verify          R           ard   o   o   -   o   o   o

                    Table 1: Summary of an upgraded version,
     so it supports all security mechanisms. The client supports alterna¡
     tives b) and c). header usage.

  The client also knows the address of the registrar.
     We assume that some trust has already been established between the
     client and the home, and between "where" column describes the client request and the proxy. Perhaps
     this trust is response types in which
  the form header field may be used. The header may not appear in other
  types of SIP messages. Values in the nodes belonging under where column are:

  - R: Header field may appear in requests.

  - 401, 407 etc.: A numerical value or range indicates response codes
    with which the same PKI, header field can be used.

  The "proxy" column describes the operations a proxy may perform on a
  header field:

  - a: A proxy can add or having distributed shared secrets beforehand.

     In Step 1 concatenate the client contacts header field if not present.

  - r: A proxy must be able to read the header field, and thus this
       header field cannot be encrypted.

  - d: A proxy using can delete a REGISTER message. We
     omit header field value.

  The next six columns relate to the details presence of a header field in a
  method:

  - o: The header field is optional.

4. Backwards Compatibility

  A server that, by local policy, decides to use the communications negotiation
  mechanism defined in this document, will not accept requests from
  clients that do not support this extension. This obviously breaks
  interoperability with the home server every plain SIP client. Therefore, this
  extension should only be used in closed environments where it is
  ensured somehow that every client implements this
     discussion, but the proxy forwards extension.

5. Examples

  The following examples illustrate the messages onwards in Step 2.  In
     Step 3, use of the registrar responds with an end-to-end HTTP Digest authen¡
     tication challenge. Using mechanism defined
  above.

5.1. Client Initiated

  A UA negotiates the same response, security mechanism to be used with its outbound
  proxy without knowing beforehand which mechanisms the proxy adds supports.

          UAC                 Proxy               UAS

           |                    |                  |
           |----(1) OPTIONS---->|                  |
           |                    |                  |
           |<-----(2) 494-------|                  |
           |                    |                  |
           |<=======TLS========>|                  |
           |                    |                  |
           |----(3) INVITE----->|                  |
           |                    |----(4) INVITE--->|
           |                    |                  |
           |                    |<---(5) 200 OK----|
           |<---(6) 200 OK------|                  |
           |                    |                  |
           |------(7) ACK------>|                  |
           |                    |-----(8) ACK----->|
           |                    |                  |
           |                    |                  |
           |                    |                  |
           |                    |                  |

         Figure 2: Negotiation initiated by the client

  The UAC sends an indica¡
     tion OPTIONS request to its outbound proxy, indicating
  that it is able to negotiate security mechanisms and that it supports
  TLS with HTTP Digest, IPsec/IKE, and plain HTTP
     Digest.  In Step 4, the client selects digest-integrity (Step 1 of figure 1). The outbound proxy
  challenges the first method it supports
     (IPsec/IKE in this case), UAC with its own list of security mechanisms – IPsec
  and TLS (Step 2 of figure 1). The only common security mechanism is
  TLS, so they establish a TLS connection between them (Step 3 of
  figure 1). When the protection connection is turned on. In Step 5, successfully established, the
     client UAC
  sends an INVITE over the next round TLS connection just established (Step 4 of REGISTER messages to the registrar.
  figure 1). This message includes the repetition of INVITE contains the original server’s security capabil¡
     ities of the proxy. list. The proxy
  server verifies this it, and since it matches its static list, it
  processes the INVITE and forwards it to the
     request next hop.

  If this example was run without Security-Server header in Step 2, the
  UAC would not know what kind of security the other one supports, and
  would be forced to error-prone trials.

  More seriously, if the registrar. In Security-verify was omitted in Step 7, 4, the registrar responds with a 200
     OK.

       1. Client -> Proxy:

          REGISTER server SIP/2.0
          Security-Mechanism: to=sip:proxy.example.com,
               from=sip:client.example.com,
               mech=ipsec-ike, mech=digest;alg=MD5

       2. Proxy communicates with
  whole process would be prone for MitM attacks. An attacker could
  spoof "ICMP Port Unreachable" message on the Server.

       3. Proxy -> Client:

          401 Authentication Required
          (HTTP Digest challenge from trials, or remove the registrar to
  stronger security option from the client)
          Security-Mechanism: to=sip:client.example.com,
               from=sip:proxy.example.com,
               mech=tls;pref=1, mech=ipsec-ike;pref=2,
               mech=digest;pref=3;alg=MD5

       4. Security handshake at a lower layer i.e. IPsec/IKE

       5. Client -> Proxy:

          REGISTER server SIP/2.0
          Security-Mechanism: to=sip:client.example.com,
               from=sip:proxy.example.com,
               mech=tls;pref=1, mech=ipsec-ike;pref=2,
               mech=digest;pref=3;alg=MD5

       6. Proxy communicates with header in Step 1, therefore
  substantially reducing the Server.

       7. Proxy -> Client: security.

        (1) OPTIONS proxy.example.com
            Security-Client: tls;q=0.1
            Security-Client: digest-integrity;q=0.2
            Require: sec-agree

        (2) 494 (Security Agreement Required)
            Security-Server: ipsec-ike;q=0.1
            Security-Server: tls;q=0.2

        (3) INVITE proxy.example.com
            Security-Verify: ipsec-ike;q=0.1
            Security-Verify: tls;q=0.2
            Route: callee@domain.com

  The 200 OK

     As in response for the previous example, if this was run without Security-Mechanism
     in Step 3, INVITE and the ACK are also sent over the client would not know what kind of algorithms
  TLS connection. The ACK (7) will contain the
     server supports. same Security-Verify
  header field as the INVITE (3).

5.2. Server Initiated
  In this example we demonstrate also the need for of figure 3 the client to send its own mechanism list in Step 1. If this wasn't known
     to sends an INVITE towards the proxy when it responds in Step 3, it could
  callee using an outbound proxy. This INVITE does not have provided contain any
  Require header field.

         UAC                 Proxy               UAS

          |                    |                  |
          |-----(1) INVITE---->|                  |
          |                    |                  |
          |<-----(2) 421-------|                  |
          |                    |                  |
          |------(3) ACK------>|                  |
          |                    |                  |
          |<=======IKE========>|                  |
          |                    |                  |
          |-----(4) INVITE---->|                  |
          |                    |----(5) INVITE--->|
          |                    |                  |
          |                    |<---(7) 200 OK----|
          |<----(6) 200 OK-----|                  |
          |                    |                  |
          |------(8) ACK------>|                  |
          |                    |-----(9) ACK----->|
          |                    |                  |
          |                    |                  |

       Figure 3: Server initiated security negotiation

  The proxy, following its local policy, challenges the INVITE. It
  returns a
     suitable HTTP Digest challenge because at 421 (Extension Required) with a Security-Server header
  field that point the proxy would
     not have known if lists IPsec-IKE and TLS. Since the client UAC supports that.

     As in IPsec-IKE
  it performs the previous example, removing key exchange and establishes a security association
  with the repetition of proxy. The second INVITE (4) and the Security-
     Mechanism ACK (8) contain a
  Security-Verify header field that mirrors the Security-Server header
  field received in Step 5 would open the system to MITM attacks.

10. 421. The INVITE (4), the 200 OK (6) and the ACK
  (8) are sent using the security association that has been
  established.

6. Security Considerations

  This specification is about making it possible to select between vari¡
     ous
  various SIP security mechanisms in a secure manner. In particular,
  the method presented here allow current networks using e.g. Digest later
     securely upgrade using, for instance,
  Digest, to e.g. S/MIME be securely upgraded to, for instance, IPsec without
  requiring a simultaneous modi¡
     fication modification in all equipment. The method
  presented in this specification is secure only if the weakest
  proposed mechanism offers at least integrity protection.

  Attackers could try to modify the server's list of security
  mechanisms in the first response. This would be revealed to the
  server when the client returns the received list using the security.

  Attackers could also try to modify the repeated list in the second
  request from the client. However, if the selected security mechanism
  uses encryption this may not be possible, and if it uses integrity
  protection any modifications will be detected by the server.

  Finally, attackers could try to modify the client's list of security
  mechanisms in the first message. The client selects the security mech¡
     anism
  mechanism based on its own knowledge of its own capabilities and the
  server's list, hence the client's choice would be unaffected by any
  such modification. However, the server's choice could still be
  affected as described below:

  - If the modification affected the server's choice, the server and
  client would end up choosing different security mechanisms in Step 3
  or 4.) 4 of figure 1. Since they would be unable to communicate to each
  other, this would be detected as a potential attack. The client would
  either retry or give up in this situation.

  - If the modification did not affect the server's choice, there's no
  effect.

  All clients that implement this specification MUST select HTTP Digest,
     S/MIME, Digest
  with integrity, TLS, IPsec, or any stronger method for the protection
  of the second request. If HTTP Digest is used alone, the security
  agreement headers MUST be protected. This can be done with HTTP
  Digest if com¡
     bined combined with MIME/SIP tunneling, for example.

11.

7. IANA Considerations

  This specification defines the 'sec-agree' SIP option tag which
  should be reg¡
     istered registered in IANA.  The option-tag 'sec-agree' can be used in header
     related to the SIP compatibility mechanisms for extensions (e.g.
     Require and Supported).

  This specification also defines a new error SIP status code, 494 (Security Agree¡
     ment
  Agreement Failed), which should be registered in IANA.

12.

8. Modifications

  The draft-sip-sec-agree-01.txt version of this specification
  introduced the following modifications:

   - Scope narrowed down to first-hop negotiation.

   - Fixed syntax of header fields.

  The draft-sip-sec-agree-00.txt version of this specification intro¡
     duced
  introduced the following modifications:

    - Many editorial changes, restructuring and clarifications.

    - Motivation section has been shortened since this is now a WG
    item.

    - Clarified that the solution requires always some base level of secu¡
     rity
    security (i.e. integrity) in order to work. Even 'the weak
    security' must not be broken.

    - Text related to alternative solutions shortened and moved to a
    new place.

    - New rules for possible error and special cases has been added, e.g.
    (e.g., for the case in which an non-adjacent SIP entities try to
    negotiate hop-by-hop security mechanisms. mechanisms).

    - Syntax of the header redesigned. Wanted to get rid of the
    semantics related to the relative position of a header component in
    the header
     (e.g. e.g., first parameters defines the 'from-uri', second
    the 'to-uri', and third the first supported security mechanism).
    The option tags are now used to identify the Security Agreement
    extension, not the indi¡
     vidual individual security mechanisms.

    - The semantics of the header slightly changed: the AND operator
    between the indivicual mechanisms is removed because it is really
    need with HTTP Digest only. And even in this case, the negotiation
    is not needed beforehand if some underlying security is used.

    - Options for HTTP Digest algorithms and manually keyed IPsec
    added.

    - Explicit rules were added to all mechanisms on how they should be
    used, such as TLS to be run on port 5061 etc.

    - References to Enhanced HTTP Digest removed.

    - Example related to 3GPP generalized.

  The draft-arkko-sip-sec-agree-01.txt version of this specification
  introduced the following modifications:

    - Reversed approach to make servers stateless

    - Removed discussion of the use of this for Digest algorithm selec¡
     tion,
    selection, since Enhanced Digest already has bidding-down
    protection

    - Renamed org.iana.sip.digest to org.iana.sip.edigest and removed
    the parameters, as we can rely on Enhanced Digest to perform the
    algorithm selection.

    - Removed agreements for full paths.

    - Simplified syntax

13.

9. Acknowledgments

  The authors wish to thank Lee Valerius, Rolf Blom, James Undery,
  Jonathan Rosenberg, Hugh Shieh, Gunther Horn, Krister Boman, David
  Castellanos-Zamora, Aki Niemi, Miguel Garcia, Valtteri Niemi, Martin
  Euchner, Eric Rescorla, Rescorla and members of the 3GPP SA3 group for
  interesting discussions in this problem space.

     14.

10. Normative References
  [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peter¡
     son,
  Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session Initiation Pro¡
     tocol",
  Protocol", Work In Progress, draft-ietf-sip-rfc2543bis-09.txt, IETF,
  February 2002.

  [2] S. Kent, R. Atkinson, "Security Architecture for the Internet Pro¡
     tocol",
  Protocol", RFC 2401, IETF, November 1998.

  [3] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246,
  IETF January 1999.

  [4] Franks, J. et al, "HTTP Authentication: Basic and Digest Access
  Authentication", RFC 2617, IETF, June 1999.

  [5] B. Ramsdell and Ed, "S/MIME version 3 message specification," RFC
  2633, IETF, June 1999.

     15.

11. Non-Normative References

  [6] M. Garcia, D. Mills, G. Bajko, G. Mayer, F. Derome, H. Shieh, A.
  Allen, S. Chotai, K. Drage, J. Bharatia, "3GPP requirements on SIP",
  draft-garcia-sipping-3gpp-reqs-00.txt. Work In Progress, IETF,
  October 2001.

     16.  Author's Address

12.  Authors's Addresses

  Jari Arkko, Arkko
  Ericsson
  02420 Jorvas
  Finland
  EMail: Jari.Arkko@ericsson.com

  Vesa Torvinen
  Ericsson
  02420 Jorvas
  Finland
  EMail: Jari.Arkko@ericsson.com, Vesa.Torvinen@ericsson.fi

  Gonzalo Camarillo
  Ericsson
  02420 Jorvas
  Finland
  EMail: Gonzalo.Camarillo@ericsson.com

  Tao Haukka
  Nokia
  Finland
  EMail: Tao.Haukka@nokia.com

  Sanjoy Sen
  Nortel Networks
  2735-B Glenville Drive
  Richardson, TX 75082, USA
  EMail: sanjoy@nortelnetworks.com

     Lee Valerius
     Nortel Networks
     2201 Lakeside Blvd
     Richards, TX 75082, USA
     EMail: valerius@nortelnetworks.com