RFC 3329 (rfc3329) - Page 2 of 24

Security Mechanism Agreement for the Session Initiation Protocol (SIP)

RFC 3329                 SIP Security Agreement             January 2003


   3.  Backwards Compatibility  . . . . . . . . . . . . . . . . . .11
   4.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .12
      4.1  Client Initiated . . . . . . . . . . . . . . . . . . . .12
      4.2  Server Initiated . . . . . . . . . . . . . . . . . . . .14
   5.  Security Considerations  . . . . . . . . . . . . . . . . . .15
   6.  IANA Considerations. . . . . . . . . . . . . . . . . . . . .17
      6.1  Registration Information . . . . . . . . . . . . . . . .17
      6.2  Registration Template. . . . . . . . . . . . . . . . . .18
      6.3  Header Field Names . . . . . . . . . . . . . . . . . . .18
      6.4  Response Codes . . . . . . . . . . . . . . . . . . . . .18
      6.5  Option Tags. . . . . . . . . . . . . . . . . . . . . . .19
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . .19
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .19
   9.  Normative References . . . . . . . . . . . . . . . . . . . .19
   10. Informative References .  . . . . . . . . . . . . . . . . . 20
   A.  Syntax of ipsec-3gpp . . . . . . . . . . . . . . . . . . . .21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .23
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . .24

1. Introduction

   Traditionally, security protocols have included facilities to agree
   on the used mechanisms, algorithms, and other security parameters.
   This is to add flexibility, since different mechanisms are usually
   suitable to different scenarios.  Also, the evolution of security
   mechanisms often introduces new algorithms, or uncovers problems in
   existing ones, making negotiation of mechanisms a necessity.

   The purpose of this specification is to define negotiation
   functionality for the Session Initiation Protocol (SIP) [1].  This
   negotiation is intended to 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.
   Authentication and integrity protection using multiple alternative
   methods and algorithms is vulnerable to Man-in-the-Middle (MitM)
   attacks (e.g., see [4]).

   It is also hard or sometimes even impossible to know whether a
   specific security mechanism is truly unavailable to a SIP peer
   entity, or if in fact a MitM attack is in action.

   In certain small networks 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



Arkko, et. al.              Standards Track