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