RFC 3329 (rfc3329) - Page 3 of 24
Security Mechanism Agreement for the Session Initiation Protocol (SIP)
Alternative Format: Original Text Document
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
