RFC 3329 (rfc3329) - Page 3 of 24

Security Mechanism Agreement for the Session Initiation Protocol (SIP)

RFC 3329                 SIP Security Agreement             January 2003


   security.  However, SIP 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, which
   necessitates the need for the negotiation functionality to be
   available from the very beginning of deployment (e.g., see [11]).

1.2 Design Goals

   1. The entities involved in the security agreement process need to
      find out exactly which security mechanisms to apply, preferably
      without excessive additional roundtrips.

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

   3. The entities involved in the security agreement process need to be
      able to indicate success or failure of the security agreement
      process.

   4. The security agreement process should not introduce any additional
      state to be maintained by the involved entities.

1.3 Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119 [9].

2. Solution

2.1 Overview of Operation

   The 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 agreement message flow.




Arkko, et. al.              Standards Track