SIP
Network Working Group                                             Jari                                           J. Arkko
INTERNET-DRAFT                                             Vesa
Internet-Draft                                               V. Torvinen
<draft-ietf-sip-sec-agree-04.txt>                      Gonzalo
Expires: April 28, 2003                                     G. Camarillo
June 2002
                                                                Ericsson
Expires: December 2002                                        Tao
                                                                A. Niemi
                                                               T. Haukka
                                                                   Nokia
                                                              Sanjoy Sen
                                                         Nortel Networks
                                                        October 28, 2002

    Security Mechanism Agreement for SIP Sessions the Session Initiation Protocol
                                 (SIP)
                      draft-ietf-sip-sec-agree-05

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 documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-Drafts. Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or 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 in progress". progress."

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

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

   This document is an individual submission to the IETF. Comments
  should be directed to the authors. Internet-Draft will expire on April 28, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

  SIP has a number of security mechanisms. Some of them have been built
  in to the SIP protocol, such as HTTP authentication or secure
  attachments. These mechanisms have even alternative algorithms and
  parameters. SIP does not currently provide any mechanism for
  selecting which security mechanisms to use between two entities. In
  particular, even if some mechanisms such as OPTIONS were used to make
  this selection, the selection would be vulnerable against the
  Bidding-Down attack.

   This document defines three header fields new functionality for negotiating the security
   mechanisms within SIP used between a SIP entity Session Initiation Protocol (SIP) user
   agent and its next SIP hop. A next-hop SIP entity applying this mechanism must
  always require some minimum security (i.e. integrity protection) from
  all communicating parties in order to secure the negotiation, but entity.  This new functionality
   supplements the
  negotiation can agree on which specific existing methods of choosing security is used.

TABLE OF CONTENTS mechanisms
   between SIP  entities.

Table of Contents

   1.  Introduction....................................................2    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1   Motivations  . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2   Design Goals . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.3   Conventions  . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  The Problem.....................................................3
  3.  Solution........................................................4
      3.1. Requirements...............................................4
      3.2.    Solution . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.1   Overview of Operations.....................................5
      3.3. Syntax.....................................................6
      3.4. Operation  . . . . . . . . . . . . . . . . . . .  4
   2.2   Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.3   Protocol Operation.........................................7
        3.4.1 Operation . . . . . . . . . . . . . . . . . . . . .  7
   2.3.1 Client Initiated........................................7
        3.4.2 Initiated . . . . . . . . . . . . . . . . . . . . . .  7
   2.3.2 Server Initiated........................................8
      3.5. Initiated . . . . . . . . . . . . . . . . . . . . . .  9
   2.4   Security Mechanism Initiation..............................9
      3.6. Initiation  . . . . . . . . . . . . . . . 10
   2.5   Duration of the Security Association......................10
      3.7. Associations  . . . . . . . . . . . . . 10
   2.6   Summary of Header Field Use...............................10
  4. Use  . . . . . . . . . . . . . . . . 11
   3.    Backwards Compatibility........................................11
  5.  Examples.......................................................11
      5.1. Compatibility  . . . . . . . . . . . . . . . . . . 12
   4.    Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   4.1   Client Initiated..........................................10
      5.2. Initiated . . . . . . . . . . . . . . . . . . . . . . 12
   4.2   Server Initiated..........................................12
      5.3. Initiated . . . . . . . . . . . . . . . . . . . . . . 14
   5.    Security Negotiation between Proxies......................13 Considerations  . . . . . . . . . . . . . . . . . . 16
   6.  Security Considerations........................................13
  7.    IANA Considerations............................................15 Considerations  . . . . . . . . . . . . . . . . . . . . 17
   6.1   Registration Information . . . . . . . . . . . . . . . . . . 18
   6.2   Registration Template  . . . . . . . . . . . . . . . . . . . 19
   6.3   Header Field Names . . . . . . . . . . . . . . . . . . . . . 19
   6.4   Response Codes . . . . . . . . . . . . . . . . . . . . . . . 19
   6.5   Option Tags  . . . . . . . . . . . . . . . . . . . . . . . . 20
   7.    Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
   8.  Acknowledgments................................................15
  9.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
         Normative References...........................................15
  10. Non-Normative References.......................................16
  11. AuthorsĘs Addresses............................................16 References . . . . . . . . . . . . . . . . . . . . 20
         Informative References . . . . . . . . . . . . . . . . . . . 21
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22
   A.    Syntax of ipsec-3gpp . . . . . . . . . . . . . . . . . . . . 23
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 25

1. Introduction

   Traditionally, security protocols have included facilities to agree
   on the used mechanisms, algorithms, and other security parameters.
  The reason for this
   This is that algorithm development typically uncovers
  problems in old algorithms and sometimes even produces new problems.
  Furthermore, to add flexibility, since different mechanisms and algorithms are usually
   suitable for to different situations. Typically, protocols also select other
  parameters beyond algorithms at scenarios.  Also, the same time.

  The purpose evolution of this specification is to define a similar negotiation
  functionality in SIP [1]. SIP has some security functionality built-
  in (e.g. HTTP Digest authentication [4]), it can utilize secure
  attachments (e.g. S/MIME [5]), and it can also use underlying security protocols (e.g. IPsec/IKE [2]
   mechanisms often introduces new algorithms, or TLS [3]). Some uncovers problems in
   existing ones, making negotiation 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 mechanisms a necessity.

   The purpose of recommended security
  solutions (i.e., recommend just one lower layer security protocol),
  we can not expect this specification is to cut down the number of items in define negotiation
   functionality for the whole list
  to one. There will still be multiple security solutions utilized by
  SIP. Furthermore, it Session Initiation Protocol (SIP) [1].  This
   negotiation is likely that new  methods will appear in the
  future, intended to complement the methods that exist today.

  Chapter 2 shows that without work only between a UA and its first-hop
   SIP entity.

1.1 Motivations

   Without a secured method to choose between security mechanisms and/or
   their parameters, SIP is vulnerable to certain attacks. As the HTTP authentication RFC [4] points out,
  authentication
   Authentication and integrity protection using multiple alternative
   methods and algorithms is vulnerable to Man-in-the-Middle (MitM)
  attacks. More seriously, it
   attacks (e.g., see [4]).

   It is also hard or sometimes even impossible to know whether a SIP peer entity
   specific security mechanism is truly unable unavailable to perform (e.g.,
  Digest, TLS, or S/MIME) a SIP peer
   entity, or if in fact a MitM attack is in action.

   In certain small networks consisting of workstations and servers these issues are not very relevant, as the
   administrators of such networks can deploy appropriate software
   versions and set up policies for using exactly the right type of
   security.  However, SIP will is also expected to 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 [7].

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

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 need for the future. SIP
  security is developing, and is likely negotiation functionality to be
   available from the very beginning of deployment (e.g., see also new solutions [11]).

1.2 Design Goals

   1.  The entities involved in the future.

  Deployment of large number of SIP-based consumer devices such as 3GPP
  terminals requires all network devices security agreement process need to be able
       find out exactly which security mechanisms to accommodate
  past, current and future mechanisms; there is no possibility for
  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 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 apply, preferably find this out
       without too many excessive additional roundtrips.

  Secondly,

   2.  The selection of security mechanisms MUST itself needs to be secure.
       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. mechanisms [8].  This allows
       the peers to detect if the initial, unprotected offers were
       tampered with.

   3.  The security implications of this are subtle, but do have a
  fundamental importance in building large networks that change over
  time. Given that the hashes are produced also using algorithms agreed entities involved 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 agreement process need to prevent MitM
  attackers from modifying other parameters, such as whether encryption
  is provided
       be able to indicate success or not. Let us first assume two peers capable failure of using
  both strong and weak security. If the initial offers are security agreement
       process.

   4.  The security agreement process should not
  protected in any way, introduce any attacker can easily "downgrade" the offers
  by removing the strong options. This would force the two peers
       additional state to use
  weak security between them. But if be maintained by the offers are protected involved entities.

1.3 Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in some
  way -- such this
   document are to be interpreted as by hashing, or repeating them later when the selected
  security is really on -- described in BCP 14, RFC 2119 [9].

2. Solution

2.1 Overview of Operation

   The message flow below illustrates how the situation is different. It would not be
  sufficient for the attacker 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 agreement message flow.

   Step 1:  Clients wishing to modify use this specification can send a single message. Instead, list of
      their supported security mechanisms along the
  attacker would have first request to modify both the offer message, as well as the
  message that contains the hash/repetition. More importantly,
      server.

   Step 2:  Servers wishing to use this specification can challenge the
  attacker would have
      client to forge perform the weak security that is present 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
  second message, and would highest-preference
      security mechanism they have to do so in real time between the sent
  offers common and to turn on the later messages. Otherwise, the peers would notice that selected
      security.

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

   Step 5:  The server verifies its own list of security method and/or mechanisms in
      order to ensure that the algorithm should original list had not be
  used.

  In conclusion, been modified.

   This procedure is stateless for servers (unless the used security difference is making a trivial attack
  possible versus demanding
   mechanisms require the attacker server 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]), keep some state).

   The client and then later new devices the server lists 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.

3. Solution

3.1 Requirements

  The solution to both static (i.e., they do not
   and cannot change based on the SIP security negotiation problem should have input from the
  following properties:

  (a) It allows other side).  Nodes
   may, however, maintain several static lists, one for each interface,
   for example.

   Between Steps 1 and 2, the selection server may set up a non-self-describing
   security mechanism if necessary.  Note that with this type of
   security mechanisms, such as lower
  layer security protocols or HTTP digest. It also allows the selection
  of individual algorithms and parameters when server is necessarily stateful.  The client
   would set up the non-self-describing security functions
  are integrated in mechanism between Steps
   2 and 4.

2.2 Syntax

   We define three new SIP (such as header fields, namely Security-Client,
   Security-Server and Security-Verify.  The notation used in the case of HTTP authentication).

  (b) It allows next-hop security negotiation.

  (c) It is secure (i.e., prevents
   Augmented BNF definitions for the bidding down attack.)

  (d) It is capable of running without additional roundtrips. This syntax elements in this section is
  important
   as used in the cellular environment, where link delays are
  relatively high, SIP [1], and an additional roundtrip could delay the call
  set up further.

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

  Currently, SIP does elements not have any mechanism which fulfills all the
  requirements above. The basic SIP features such defined in this section are
   as OPTIONS defined in SIP and
  Require, Supported headers are capable of informing peers about
  various capabilities including security mechanisms. However, the
  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 HTTP
  authentication RFC [4] itself. More seriously, they have no
  provisions for allowing encryption documents to be negotiated. Hence, which it would
  be hard to turn on possible future encryption schemes in a secure
  manner.

  A self-describing security mechanism refers:

        security-client  = "Security-Client" HCOLON
                           sec-mechanism *(COMMA sec-mechanism)
        security-server  = "Security-Server" HCOLON
                           sec-mechanism *(COMMA sec-mechanism)
        security-verify  = "Security-Verify" HCOLON
                           sec-mechanism *(COMMA sec-mechanism)
        sec-mechanism    = mechanism-name *(SEMI mech-parameters)
        mechanism-name   = ( "digest" / "tls" / "ipsec-ike" /
                            "ipsec-man" / token )
        mech-parameters  = ( preference / digest-algorithm /
                             digest-qop / digest-verify / extension )
        preference       = "q" EQUAL qvalue
        qvalue           = ( "0" [ "." 0*3DIGIT ] )
                            / ( "1" [ "." 0*3("0") ] )
        digest-algorithm = "d-alg" EQUAL token
        digest-qop       = "d-qop" EQUAL token
        digest-verify    = LDQUOT 32LHEX RDQUOT
        extension        = generic-param

   Note that qvalue is a security mechanism that,
  when used, contains all necessary information about already defined in the method being
  used as well as all of SIP BNF [1].  We have
   copied its definitions here for completeness.

   The parameters such as algorithms.

  A non-self-describing security mechanism is a security mechanism
  that, when used, requires that the use of described by the method or some of its
  parameters BNF above 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 following
   semantics:

   Mechanism-name
      This token identifies the
  HTTP authentication headers. The use of S/MIME is indicated security mechanism supported by the
  MIME headers, and the CMS structures inside S/MIME describe the used
  algorithms. TLS is run on
      client, when it appears in a separate port Security-Client header field; or by
      the server, when it appears in SIP, and where IPsec/IKE
  is used, IKE negotiates all the necessary parameters. a Security-Server or in a Security-
      Verify header field.  The only exception to this list is mechanism-name tokens are registered
      with the use of IANA.  This specification defines four values:

      *  "tls" for TLS [3].

      *  "digest" for HTTP Digest [4].

      *  "ipsec-ike" for IPsec with IKE [2].

      *  "ipsec-man" for manually keyed IPsec. IPsec headers do not contain information about without IKE.

   Preference
      The "q" value indicates a relative preference for the used algorithms.
  Furthermore, peers particular
      mechanism.  The higher the value the more preferred the mechanism
      is.  All the security mechanisms MUST have different "q" values.
      It is an error 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 provide two mechanisms with the
  application can search same "q" value.

   Digest-algorithm
      This optional parameter is defined here only for a Security Association (or create a new
  one) after having received a message that contains S/MIME.

  In HTTP Digest [4]
      in order to make it possible to negotiate both self-describing and
  non-self-describing security mechanisms, we need another requirement
  on prevent the security agreement scheme:

  (f) bidding-down attack for the HTTP Digest
      algorithm parameter.  The security agreement scheme must allow both sides to decide on content of 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 field may have same
      values as defined in [4] for the negotiation has not been tampered by a man-in-the-
  middle. "algorithm" field.

   Digest-qop
      This tampering will be detected later.

3.2. Overview of Operations optional parameter is defined here only for HTTP Digest [4]
      in order to prevent the bidding-down attack for the HTTP Digest
      qop parameter.  The message flow below illustrates how content of the mechanism field may have same values as
      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 along the first request to [4] for the
  server.

  Step 2: Servers wishing "qop" field.

   Digest-verify
      This optional parameter is defined here only for HTTP Digest [4]
      in order to use this specification can challenge prevent the
  client to perform bidding-down attack for the SIP security
      mechanism agreement procedure. (this document).  The security
  mechanisms and parameters supported by content of the server are sent along field is
      counted exactly the same way as "request-digest" in
  this challenge.

  Step 3: The client then proceeds to select [4] except
      that the highest-preference
  security mechanism they have Security-Server header field is included in common and to turn on the selected
  security.

  Step 4: The client contacts A2
      parameter.  If the server again, now using "qop" directive's value is "auth" or is
      unspecified, then A2 is:

         A2 = Method ":" digest-uri-value ":" security-server

      If the selected
  security mechanism. The server's list of supported security
  mechanisms "qop" value is returned as "auth-int", then A2 is:

         A2 = Method ":" digest-uri-value ":" H(entity-body) ":"
         security-server

      All linear white spaces in the Security-Server header field MUST
      be replaced by a response to single SP before calculating or interpreting the challenge.

  Step 5: The server verifies its own list of security mechanisms
      digest-verify parameter.  Method, digest-uri-value, entity-body,
      and any other HTTP Digest parameter are as specified in
  order to ensure [4].

   Note that the original list had this specification does not been modified. introduce any extension or
   change to HTTP Digest [4].  This procedure is stateless for servers (unless specification only re-uses the used security
   existing HTTP Digest mechanisms require the server to keep some state).

  The client and protect the server lists are both static (i.e., they do not
  and cannot change based on the input from the other side). Nodes may,
  however, maintain several static lists, one for each interface, for
  example.

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

3.3. Syntax

  We define three new SIP header fields, namely Security-Client,
  Security-Server and Security-Verify. Their BNF syntax is provided
  below:

     security-client = "Security-Client" HCOLON
                       sec-mechanism *(COMMA sec-mechanism)
     security-server = "Security-Server" HCOLON
                       sec-mechanism *(COMMA sec-mechanism)
     security-verify = "Security-Verify" HCOLON
                       sec-mechanism *(COMMA sec-mechanism)
     sec-mechanism   = mechanism-name *(SEMI mech-parameters)
     mechanism-name  = ( "digest-integrity" / "tls" / "ipsec-ike" /
                        "ipsec-man" / "smime" / token )
     mech-parameters = ( preference / algorithm / extension )
     preference      = "q" EQUAL qvalue
     qvalue          = ( "0" [ "." 0*3DIGIT ] )
                        / ( "1" [ "." 0*3("0") ] )
     algorithm       = "alg" EQUAL token
     extension       = generic-param

  Note that qvalue is already defined entities.

2.3 Protocol Operation

   This section deals with the protocol details involved in the
   negotiation between a SIP BNF [1]. We have
  copied UA and its definitions here for completeness.

  The parameters described by next-hop SIP entity.  Throughout
   the BNF above have text the following
  semantics:

    Mechanism-name: It identifies next-hop SIP entity is referred to as the security mechanism supported by first-hop
   proxy or outbound proxy.  However, the client, when it appears reader should bear in mind
   that a Security-Client header fields, or
    by user agent server can also be the server, when it appears in next-hop for a Security-Server or in user agent
   client.

2.3.1 Client Initiated

   If a
    Security-Verify header field. This specification defines five
    values:

      - "tls" for TLS [3].
      - "digest-integrity" for HTTP Digest [4] using additional
      integrity protection for the Security-Verify header field. The
      additional integrity protection consists of client ends up using the qop
      parameter TLS to protect a MIME body (e.g., "message/sip") that
      contains the Security-Verify header field.
      - "ipsec-ike" for IPsec with IKE [2].
      - "ipsec-man" for manually keyed IPsec without IKE.
      - "smime" for S/MIME [5].

    Preference: The "q" value indicates a relative preference for contact the
    particular mechanism. The higher the value the more preferred server because it has
   followed the
    mechanism is. All rules specified in [5], the security mechanisms client MUST have different "q"
    values. It is an error to provide two mechanisms with NOT use the same "q"
    value.

    Algorithm: An optional algorithm field for those
   security
    mechanisms which are not self-describing or which are vulnerable
    for bidding-down attacks (e.g., HTTP Digest). In the case agreement procedure of this specification.  If a client ends
   up using non-TLS connections because of HTTP
    Digest, the same rules apply as defined in RFC 2617 [4] for [5], the
    "algorithm" field in HTTP Digest.

3.4. Protocol Operation

  This section deals with client
   MAY use the protocol details involved in security agreement of this specification to detect DNS
   spoofing, or to negotiate some other security than TLS.

   A client wishing to use the
  negotiation between security agreement of this specification
   MUST add a SIP entity and Security-Client header field to a request addressed to its next-hop SIP entity.
  Throughout
   first-hop proxy (i.e., the text destination of the next-hop SIP entity request 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 proxy
  or, in absence of proxies, for a user agent client. Note as well that
  a proxy can also have an outbound proxy.

3.4.1 Client Initiated

  A client wishing to establish some type of security with its first-
  hop proxy MUST 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 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 this list.  The client MUST add both a
   Require and Proxy-Require header field with the value "sec-agree" to
   its request.

   The contents of the Security-Client header field is may be used by the
   server to include any necessary information in its response. For example, if digest-
  integrity is the chosen mechanism, the server includes an HTTP
  authentication challenge  in the response. If S/MIME is chosen, the
  appropriate certificate is included.

   A server receiving an unprotected request that contains a Require or
   Proxy-Require header field with the value "sec-agree" MUST challenge respond to
   the client with a 494 (Security Agreement Required) response.  The
   server MUST add a Security-Server header field to this response
   listing the security mechanisms that the server supports.  The server
   MUST add its list to the response even if there are no common
   security mechanisms in the client's and server's lists.  The serverĘs server's
   list MUST NOT depend on the contents of the client's list.

   The server MUST compare the list received in the Security-Client
   header field with the list to be sent in the Security-Server header
   field.  When the client receives this response, it will choose the
   common security mechanism with the highest "q" value.  Therefore, the
   server MUST add the necessary information so that the client can
   initiate that mechanism (e.g., a WWW-Authenticate Proxy-Authenticate header field for
  digest-integrity).
   HTTP Digest).

   When the client receives a response with a Security-Server header
   field, it MUST choose the security mechanism in the serverĘs server's list
   with the highest "q" value among all the mechanisms that are known to
   the client.  Then, it MUST initiate that particular security
   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).

   If an attacker modified the Security-Client header field in the
   request, the server may not include in its response the information
   needed to establish the common security mechanism with the highest
   preference value (e.g., the WWW-authenticate Proxy-Authenticate header field is
   missing).  A client detecting such a lack of information in the
   response MUST consider the current security negotiation agreement process
   aborted, and MAY try to start it again by sending a new request with
   a Security-Client header field as described above.

   All the subsequent SIP requests sent by the client to that server
   SHOULD make use of the security mechanism initiated in the previous
   step.  These requests MUST contain a Security-Verify header field
   that mirrors the serverĘs server's list received previously in the Security-Server Security-
   Server header field.  These requests MUST also have both a Require
   and Proxy- Require header fields with the value "sec-agree".

   The server MUST check that the security mechanisms listed in the
   Security-Verify header field of incoming requests correspond to its
   static list of supported security mechanisms.

      Note that, following the standard SIP header field comparison
      rules defined in [1], both lists have to contain the same security
      mechanisms in the same order to be considered equivalent.  In
      addition, for each particular security mechanism, its parameters
      in both lists need to have the same values.

   The server can proceed processing a particular request if, and only
   if, the list was not modified.  If modification of the list is
   detected, the server MUST challenge respond to the client with a 494 (Security
   Agreement Required). Required) response.  This response MUST include a challenge with the
   server's unmodified list of supported security mechanisms.  If the
   list was not modified, and the server is a proxy, it MUST remove the
   "sec-agree" value from both the Require and Proxy-Require header
   fields, and then remove the header fields if no values remain.

   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 and its
   outbound proxy negotiate some security, they may try to use the same
   security for incoming requests (i.e., the UA will be acting as a
   UAS).

   The user of a UA SHOULD be informed about the results of the security
   mechanism negotiation. agreement.  The user MAY decline to accept a particular
   security mechanism, and abort further SIP communications with the
   peer.

3.4.2

2.3.2 Server Initiated

   A server decides to use the security negotiation agreement described in this
   document based on local policy.  If a server receives a request from
   the network interface that is configured to use this mechanism, it
   must check that the request has only one Via header field.  If there
   are several Via header fields, the server is not the first-hop SIP
   entity, and it MUST NOT use this mechanism.  For such a request, the
   server must return a 502 (Bad Gateway) response.

   A server that decides to use this
  negotiation agreement mechanism MUST challenge
   unprotected requests with one Via header field regardless of the
   presence or the absence of any Require, Proxy-Require or Supported
   header fields in incoming requests.

   A server that by policy requires the use of this specification and
   receives a request that does not have the sec-agree option tag in a
   Require, Proxy-Require or Supported header field MUST return a 421
   (Extension Required) response.  If the request had the sec-agree
   option tag in a Supported header field, it MUST return a 494
   (Security Agreement Required) response.  In both situation the server
   MUST also include in the response a Security-Server header field
   listing its capabilities and a Require header field with an option-
   tag "sec-agree" in it. All the Via header field entries in the
  response except the topmost value  The server MUST be removed. This ensures also add necessary
   information so that the previous hop is the one processing client can initiate the response (see example in
  Section 5.3). preferred security
   mechanism (e.g., a Proxy-Authenticate header field for HTTP Digest).

   Clients that support the extension defined in this document MAY add a
   Supported header field with a value of "sec-agree". In addition to
  this, clients SHOULD add a Security-Client header field so that they
  can save a round trip in case the server decides to challenge the
  request.

3.5. Security mechanism initiation

  Once the client chooses

2.4 Security Mechanism Initiation

   Once the client chooses a security mechanism from the list received
   in the Security-Server header field from the server, it initiates
   that mechanism.  Different mechanisms require different initiation
   procedures.

   If TLS "tls" is chosen, the client uses the procedures of Section 8.1.2
   of
  [1] to [1]to determine the URI to be used as an input to the DNS
   procedures of [6]. [5].  However, if the URI is a sip SIP URI, it MUST treat
   the scheme as if it were sips, not sip.  If the URI scheme is not
   sip, the request MUST be sent using TLS.

   If digest-integrity "digest" is chosen, the 494 (Security Agreement Required) response
   will contain an HTTP Digest authentication challenge.  The client
   MUST use the algorithm and qop parameter to protect a MIME body (e.g.,
  "message/sip") that contains parameters in the Security-Verify Security-Server
   header field to replace the same parameters in the
  request. Currently, only HTTP Digest
   challenge.  The client MUST also use the qop value Ęauth-intĘ is able digest-verify parameter to provide
  required protection. Note that digest alone without placing Security-
  Verify
   protect the Security-Server header field as specified in the body would not fulfill the minimum security
  requirements of this specification. 2.2.

   To use "ipsec-ike", the client attempts to establish an IKE
   connection to the host part of the Request-URI in the first request
   to the server.  If the IKE connection attempt fails, the agreement
   procedure MUST be considered to have failed, and MUST be terminated.

   Note that "ipsec-man" will only work if the communicating SIP
   entities know which keys and other parameters to use.  It is outside
   the scope of this specification to describe how this information can
   be made known to the peers.  All rules for minimum implementations,
   such as mandatory-to-implement algorithms, apply as defined in [2],
   [6], and [7].

   In both IPsec-based mechanisms, it is expected that appropriate
   policy entries for protecting SIP have been configured or will be
   created before attempting to use the security agreement procedure,
   and that SIP communications use port numbers and addresses according
   to these policy entries.  It is outside the scope of this
   specification to describe how this information can be made known to
   the peers, but it could be would typically be configured at the same time as
   the 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. Note that
  S/MIME can only be used if the next hop SIP entity is a UA.

3.6.

2.5 Duration of Security Associations

   Once a security mechanism has been negotiated, both the server and
   the client need to know until when it can be used.  All the
   mechanisms described in this document have a different way to signal of
   signaling the end of a security association.  When TLS is used, the
   termination of the connection indicates that a new negotiation is
   needed.  IKE negotiates the duration of a security association.  If
   the credentials provided by a client using digest-integrity digest are not no longer
   valid, the server will re-challenge re- challenge the client.  It is assumed that
   when IPsec-man is used, the same out-of-band mechanism used to
   distribute keys is used to define the duration of the security
   association.

3.7.

2.6 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       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       421,494              o   o   -   o   o   o
       Security-Verify          R           ard   o   o   -   o   o   o

   Table 1: Summary of header usage. Header Usage.

   The "where" column describes the request and response types in which
   the header field may be used.  The header may not appear in other
   types of SIP messages.  Values in the where column are:

  -

   o  R: Header field may appear in requests.

  - 401, 407 etc.:

   o  421, 494: A numerical value or range indicates response codes with which
      the header field can be used.

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

  -

   o  a: A proxy can add or concatenate the header field if not present.

  -

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

  -

   o  d: A proxy can delete a header field value.

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

  -

   o  o: The header field is optional.

4.

3. Backwards Compatibility

   The use of this extension in a network interface is a matter of local
   policy.  Different network interfaces may follow different policies,
   and consequently the use of this extension may be situational by
   nature.  UA and server implementations MUST be configurable to
   operate with or without this extension.

   A server that, by local policy, decides that is configured to use the negotiation
  mechanism defined in this document, will not mechanism, may also accept
   requests from clients that use TLS based on the rules defined in [5].
   Requests from clients that do not support this extension. extension, and do not
   support TLS, can not be accepted.  This obviously breaks
   interoperability with every plain some SIP client. clients.  Therefore, this extension
   should be used in environments where it is somehow ensured that every
   client implements this extension. extension or is able to use TLS.  This
   extension may also be used in environments where insecure
   communication is not acceptable if the option of not being able to
   communicate is also accepted.

5.

4. Examples

   The following examples illustrate the use of the mechanism defined
   above.

5.1.

4.1 Client Initiated

   A UA negotiates the security mechanism to be used with its outbound
   proxy without knowing beforehand which mechanisms the proxy supports.
   The OPTIONS method can be used here to request the security
   capabilities of the proxy.  In this way, the security can be
   initiated even before the first INVITE is sent via the proxy.

             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 Initiated by the client Client.

   The UAC sends an OPTIONS request to its outbound proxy, indicating at
   the same time that it is able to negotiate security mechanisms and
   that it supports TLS and digest-integrity (Step 1 of figure 1). HTTP Digest (1).

   The outbound proxy
  challenges responds to the UAC with its own list of security
   mechanisms ū - IPsec and TLS (Step 2 of figure 1). (2).  The only common security mechanism
   is TLS, so they establish a TLS connection between them (Step 3 of
  figure 1). them.  When the
   connection is successfully established, the UAC sends an INVITE
   request over the TLS connection just established (Step 4 of
  figure 1). (3).  This INVITE
   contains the serverĘs server's security list.  The server verifies it, and
   since it matches its static list, it processes the INVITE and
   forwards it to the 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 Security-Verify was omitted in Step 4, 3, the
   whole process would be prone for MitM attacks.  An attacker could
   spoof "ICMP Port Unreachable" message on the trials, or remove the
   stronger security option from the header in Step 1, therefore
   substantially reducing the security.

           (1) OPTIONS sip:proxy.example.com SIP/2.0
               Security-Client: tls
               Security-Client: digest-integrity digest
               Require: sec-agree
               Proxy-Require: sec-agree

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

           (3) INVITE sip:proxy.example.com SIP/2.0
               Security-Verify: ipsec-ike;q=0.1
               Security-Verify: tls;q=0.2
               Route: sip:callee@domain.com
               Require: sec-agree
               Proxy-Require: sec-agree

   The 200 OK response (6) for the INVITE and the ACK (7) are also sent
   over the TLS connection.  The ACK (7) will contain the same Security-Verify Security-
   Verify header field as the INVITE (3).

5.2.

4.2 Server Initiated

   In this example of figure 3 the client sends an INVITE towards the
   callee using an outbound proxy.  This INVITE does not contain any
   Require header field.

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

   Figure 3: Server initiated security negotiation Initiated Security Negotiation.

   The proxy, following its local policy, challenges does not accept the INVITE.
   It returns a 421 (Extension Required) with a Security-Server header
   field that lists IPsec-IKE and TLS.  Since the UAC supports IPsec-IKE
   it performs the key exchange and establishes a security association
   with the proxy.

   The second INVITE (4) and the ACK (8) contain a Security-Verify
   header field that mirrors the Security-Server header field received
   in the 421.  The INVITE (4), the 200 OK (7) and the ACK (8) are sent
   using the security association that has been established.

5.3 Security Negotiation between Proxies

  The example in Figure 4 shows a security negotiation between two
  adjacent proxies. P1 forwards an

           (1) INVITE sip:uas.example.com SIP/2.0

           (2) to P2. P2, by policy,
  requires that a security negotiation takes place before accepting any
  request. Therefore, it challenges P1 with a SIP/2.0 421 (Extension Required)
  response (3). P2 removes all the Via entries except the topmost one
  (i.e., P1) so that P1 itself processes the response rather than
  forwarding Extension Required
               Security-Server: ipsec-ike;q=0.1
               Security-Server: tls;q=0.2

           (4) INVITE sip:uas.example.com SIP/2.0
               Security-Verify: ipsec-ike;q=0.1
               Security-Verify: tls;q=0.2

5. Security Considerations

   This specification is about making it possible to the UAC. This 421 response contains a Security-
  Server header field listing the server's capabilities and a Require
  header field with an option-tag "sec-agree" in it. P2 includes "TLS"
  and "ipsec-ike" select between
   various SIP security mechanisms in a secure manner.  In particular,
   the Security-Server header field. P1 sends an ACK
  (4) method presented herein allow current networks using, for the response and proceeds
   instance, HTTP Digest, to establish be securely upgraded to, for instance,
   IPsec without requiring a TLS connection,
  since simultaneous modification in all equipment.
   The method presented in this specification is the secure only security mechanism supported by P1. Once if the
  TLS connection is established, session establishment proceeds
  normally. Messages (5), (8)
   weakest proposed mechanism offers at least integrity and (11) are sent using replay
   protection for the just
  established TLS connection. Messages (5) and (11) contain a Security-
  Verify Security-Verify header field field.

   The security implications of this are subtle, but do have a
   fundamental importance in building large networks that change over
   time.  Given that P2 removes before forwarding them to the
  UAS. Note that, following normal SIP procedures, P1 uses a different
  branch ID for INVITE (5) than hashes are produced also using algorithms
   agreed in the first unprotected messages, one it used for INVITE (2).

       UAC            P1            P2           UAS
        |             |             |             |
        |-(1) INVITE->|             |             |
        |             |-(2) INVITE->|             |
        |             |             |             |
        |             |<--(3) 421---|             |
        |             |             |             |
        |             |---(4) ACK-->|             |
        |             |             |             |
        |             |<====TLS====>|             |
        |             |             |             |
        |             |-(5) INVITE->|             |
        |             |             |-(6) INVITE->|
        |             |             |             |
        |             |             |<-(7) 200 OK-|
        |             |<-(8) 200 OK-|             |
        |<-(9) 200 OK-|             |             |
        |             |             |             |
        |--(10) ACK-->|             |             |
        |             |--(11) ACK-->|             |
        |             |             |--(12) ACK-->|
        |             |             |             |

   Figure 4: Negotiation between two proxies

6. Security Considerations

  This specification is about making it possible to select between
  various SIP security mechanisms in a secure manner. In particular, could ask what the method presented here allow current networks using, for instance,
  Digest, to be securely upgraded to, for instance, IPsec without
  requiring a simultaneous modification in all equipment. The method
  presented
   difference in this specification security really is.  Assuming integrity protection is secure
   mandatory and only if the weakest
  proposed mechanism offers at least integrity protection.

  Attackers could try secure algorithms are used, we still need to modify
   prevent MitM attackers from 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 server's list 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 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 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
   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 TLS [3]).  In this situation, an insecure negotiation
   procedure allows attackers to trivially force even new devices to use
   only integrity protection.

   Possible attacks against the security agreement include:

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

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

   3.  Attackers could try to modify the client's list of security
       mechanisms in the first message.  The client selects the security
       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 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.

   4.  Finally, attackers may also try to reply old security agreement
       messages.  Each security mechanism must provide replay
       protection.  In particular, HTTP Digest implementations should
       carefully utilize existing reply protection options such as
       including a time-stamp to the nonce parameter, and using nonce
       counters [4].

   All clients that implement this specification MUST select HTTP
   Digest, TLS, IPsec, or any stronger method for the protection of the
   second request.

6. IANA Considerations

   This specification defines a new mechanism-name namespace in Section
   2.2 which requires a central coordinating body.  The body responsible
   for this coordination is the Internet Assigned Numbers Authority
   (IANA).

   This document defines four mechanism-names to be initially
   registered, namely "digest", "tls", "ipsec-ike", and "ipsec-man".  In
   addition to these mechanism-names, "ipsec-3gpp" mechanism-name is
   also registered (see Appendix A).  Following the policies outlined in
   [10], further mechanism-names are allocated based on IETF Consensus.

   Registrations with the IANA MUST include the mechanism-name token
   being registered, and a pointer to a published RFC describing the
   details of the corresponding security mechanism.  Further, the
   registration MUST include contact information for the party
   responsible for the registration.

6.1 Registration Information

   As this document specifies five mechanism-names, the initial IANA
   registration for mechanism-names will contain the information shown
   in Table 2.  It also demonstrates the type of information maintained
   by the IANA.

        Mechanism Name         Contact                  Reference
        --------------         -------                  ---------
         digest                 [1]                      [RFCNNNN]
         tls                    [1]                      [RFCNNNN]
         ipsec-ike              [1]                      [RFCNNNN]
         ipsec-man              [1]                      [RFCNNNN]
         ipsec-3gpp             [1]                      [RFCNNNN]

        People
        ------
        [1] Jari Arkko <Jari.Arkko@ericsson.com>
            Vesa Torvinen <Vesa.Torvinen@ericsson.fi>
            Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
            Aki Niemi <Aki.Niemi@nokia.com>
            Tao Haukka <Tao.Haukka@nokia.com>

        References
        ----------
        [RFCNNNN] Arkko, et. al., "Security Mechanism Agreement for the
                  Session Initiation Protocol", RFC NNNN, October 2002.

   Table2: Initial IANA registration.

   (Note to RFC Editor: Replace NNNN with the RFC number of this
   document when published.)

6.2 Registration Template

        To: ietf-sip-sec-agree-mechanism-name@iana.org
        Subject: Registration of a new SIP Security Agreement mechanism

        Mechanism Name:

          (Token value conforming to the syntax described in
           Section 2.2.)

        Published Specification(s):

          (Descriptions of new SIP Security Agreement mechanisms
           require a published RFC.)

        Person & email address to contact for further information:

          (Must contain contact information for the person(s)
           responsible for the registration.)

6.3 Header Field Names

   This specification registers three new header fields, namely
   Security-Client, Security-Server and Security-Verify.  These headers
   are defined by the following information, which is to be included
   inthe sub-registry for SIP headers under http://www.iana.org/
   assignments/sip-parameters.

        Header Name:    Security-Client
        Compact Form:   (none)

        Header Name:    Security-Server
        Compact Form:   (none)

        Header Name:    Security-Verify
        Compact Form:   (none)

6.4 Response Codes

   This specification registers a new response code, namely 494
   (Security Agreement Required).  The response code is defined by the
   following information, which is to be included to the sub-registry
   for SIP methods and response-codes under http://www.iana.org/
   assignments/sip-parameters.

         Response Code Number:     494
         Default Reason Phrase:    Security Agreement Required

6.5 Option Tags

   This specification defines a new option tag, namely sec-agree.  The
   option tag is defined by the following information, which is to be
   included in the sub-registry for option tags under http://
   www.iana.org/assignments/sip-parameters.

        Name:         sec-agree
        Description:  This option tag indicates support for the Security
                      Agreement mechanism. When used in the Require, or
                      Proxy-Require headers, it indicates that proxy servers
                      are required to use the Security Agreement mechanism.
                      When used in the Supported header, it indicates that
                      the User Agent Client supports the Security Agreement
                      mechanism. When used in the Require header in the 494
                      (Security Agreement Required) or 421 (Extension Required)
                      responses, it indicates that the User Agent Client must
                      use the Security Agreement Mechanism.

7. Contributors

   Sanjoy Sen and Lee Valerius from Nortel Networks have contributed to
   the document.

8. Acknowledgements

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

Normative References

   [1]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

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

   [3]   Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
         P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
         1999.

   [4]   Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
         Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
         Basic and Digest Access Authentication", RFC 2617, June 1999.

   [5]   Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
         (SIP): Locating SIP Servers", RFC 3263, June 2002.

   [6]   Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
         November 1998.

   [7]   Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
         (ESP)", RFC 2406, November 1998.

   [8]   Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
         RFC 2409, November 1998.

   [9]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [10]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434, October
         1998.

Informative References

   [11]  Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP)
         Release 5 requirements on the  Session Initiation Protocol
         (SIP)", draft-ietf-sipping-3gpp-r5-requirements-00 (work in
         progress), October 2002.

   [12]  3rd Generation Partnership Project, "Access security for IP-
         based services, Release 5", TS 33.203 v5.3.0, September 2002.

   [13]  Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and
         AH", RFC 2403, November 1998.

   [14]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP
         and AH", RFC 2404, November 1998.

   [15]  Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms",
         RFC 2451, November 1998.

Authors' Addresses

   Jari Arkko
   Ericsson
   Hirsalantie 1
   Jorvas, FIN  02420
   Finland

   Phone: +358 40 507 9256
   EMail: jari.arkko@ericsson.com

   Vesa Torvinen
   Ericsson
   Joukahaisenkatu 1
   Turku, FIN  20520
   Finland

   Phone: +358 40 723 0822
   EMail: vesa.torvinen@ericsson.fi

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 1
   Jorvas, FIN  02420
   Finland

   Phone: +358 40 702 3535
   EMail: gonzalo.camarillo@ericsson.com

   Aki Niemi
   Nokia
   P.O. Box 301
   NOKIA GROUP, FIN  00045
   Finland

   Phone: +358 50 389 1644
   EMail: aki.niemi@nokia.com
   Tao Haukka
   Nokia
   P.O. Box abc
   NOKIA GROUP, FIN  00045
   Finland

   Phone: +358 40 517 0079
   EMail: tao.haukka@nokia.com

Appendix A. Syntax of security
  mechanisms in the first response. ipsec-3gpp

   This would be revealed to the
  server when appendix specifies the client returns the received list using the security.

  Attackers could also try syntax of non-normative parameters to modify the repeated list be
   used in the second
  request from the client. However, if the selected 3GPP IP Multimedia Subsystem [12] with security mechanism
  uses encryption this may not be possible, and if it uses integrity
  protection any modifications will be detected by
   "ipsec-3gpp".  The notation used in the server.

  Finally, attackers could try Augmented BNF definitions is
   as used in SIP [1].

        mechanism-name   = ( "ipsec-3gpp" )
        mech-parameters    = ( algorithm / protocol /mode /
                               encrypt-algorithm / spi /
                               port1 / port2 )
        algorithm          = "alg" EQUAL ( "hmac-md5-96" /
                                           "hmac-sha-1-96" )
        protocol           = "prot" EQUAL ( "ah" / "esp" )
        mode               = "mod" EQUAL ( "trans" / "tun" )
        encrypt-algorithm  = "ealg" EQUAL ( "des-ede3-cbc" / "null" )
        spi                = "spi" EQUAL spivalue
        spivalue           = 10DIGIT; 0 to modify 4294967295
        port1              = "port1" EQUAL port
        port2              = "port2" EQUAL port
        port               = 1*DIGIT

   The parameters described by the client's list of security
  mechanisms in BNF above have the first message. The client selects following
   semantics:

   Algorithm
      This parameter defines the security
  mechanism based on its own knowledge used authentication algorithm.  It may
      have a value of its own capabilities and "hmac-md5-96" for HMAC-MD5-96 [13], or "hmac-sha-
      1-96" for HMAC-SHA-1-96 [14].  The algorithm parameter is
      mandatory.

   Protocol
      This parameter defines the
  server's list, hence IPsec protocol.  It may have a value of
      "ah" for AH [6], or "esp" for ESP [7].  If no Protocol parameter
      is present, the client's choice would protocol will be unaffected ESP by any
  such modification. However, default.

   Mode
      This parameter defines the server's choice could still be
  affected as described below:

  - mode in which the IPsec protocol is
      used.  It may have a value of "trans" for transport mode, or a
      value of "tun" for tunneling mode.  If no Mode parameter is
      present the modification affected the server's choice, the server and
  client would end up choosing different security mechanisms IPsec protocol is used in Step 3
  or 4 of figure 1. Since they would be unable to communicate to each
  other, this would be detected as transport mode.

   Encrypt-algorithm
      This parameter defines the used encryption algorithm.  It may have
      a potential attack. The client would
  either retry value of "des-ede3-cbc" for 3DES [15], or give up in this situation.

  - "null" for no
      encryption.  If the modification did no Encrypt-algorithm parameter is present,
      encryption is not affect used.

   Spi
      Defines the server's choice, there's SPI number used for inbound messages.

   Port1
      Defines the port number for inbound messages.

   Port2
      Defines the port number for outbound messages.  If no
  effect.

  All clients Port2
      parameter is present port1 is also used for outbound messages.

   The communicating SIP entities need to know beforehand which keys to
   use.  It is also assumed that implement this specification MUST select HTTP Digest the underlying IPsec implementation
   supports selectors that allow all transport protocols supported by
   SIP to be protected with integrity, TLS, IPsec, or any stronger method for a single SA.  The duration of security
   association is the protection same as in the expiration interval of the second request.

7. IANA Considerations
   corresponding registration binding.

Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This specification defines three new header fields, namely Security-
  Client, Security-Server document and Security-Verify that should translations of it may be included copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in the registry for SIP header fields maintained by IANA.

  This specification defines the 'sec-agree' SIP option tag which
  should its implementation may be registered prepared, copied, published
   and distributed, in IANA.

  This specification also defines a new SIP status code, 494 (Security
  Agreement Failed), which should whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be registered modified in IANA.

8. Acknowledgments
  The authors wish any way, such as by removing
   the copyright notice or references to thank Lee Valerius, Allison Mankin, 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 and members of the 3GPP SA3
  group Internet Society or other
   Internet organizations, except as needed for interesting discussions in this problem space.

9. Normative References

  [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
  Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session Initiation
  Protocol", Work the purpose of
   developing Internet standards in Progress, draft-ietf-sip-rfc2543bis-09.txt, IETF,
  February 2002.

  [2] S. Kent, R. Atkinson, "Security Architecture which case the procedures for
   copyrights defined in the Internet
  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 Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and Ed, "S/MIME version 3 message specification", RFC
  2633, IETF, June 1999.

  [6] H. Schulzrinne will not be
   revoked by the Internet Society or its successors or assigns.

   This document and J. Rosenberg, "SIP: Locating SIP servers",
  Work in Progress, draft-ietf-sip-srv-06.txt, IETF, February 2002.

10. Non-Normative References

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

11.  Authors's Addresses

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

  Vesa Torvinen
  Ericsson
  02420 Jorvas
  Finland
  EMail: 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 an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.