Security Mechanism Agreement for the Session Initiation Protocol (SIP)
RFC 3329

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

Network Working Group                                           J. Arkko
Request for Comments: 3329                                   V. Torvinen
Category: Standards Track                                   G. Camarillo
                                                                Ericsson
                                                                A. Niemi
                                                               T. Haukka
                                                                   Nokia
                                                            January 2003

                 Security Mechanism Agreement for the
                   Session Initiation Protocol (SIP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This document defines new functionality for negotiating the security
   mechanisms used between a Session Initiation Protocol (SIP) user
   agent and its next-hop SIP entity.  This new functionality
   supplements the existing methods of choosing security mechanisms
   between SIP entities.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
      1.1   Motivations . . . . . . . . . . . . . . . . . . . . . . 2
      1.2  Design Goals . . . . . . . . . . . . . . . . . . . . . . 3
      1.3  Conventions  . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3
      2.1   Overview of Operation . . . . . . . . . . . . . . . . . 3
      2.2  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4
      2.3  Protocol Operation . . . . . . . . . . . . . . . . . . . 6
         2.3.1 Client Initiated . . . . . . . . . . . . . . . . . . 6
         2.3.2 Server Initiated . . . . . . . . . . . . . . . . . . 8
      2.4  Security Mechanism Initiation. . . . . . . . . . . . . . 9
      2.5  Duration of Security Associations. . . . . . . . . . . .10
      2.6  Summary of Header Field Use. . . . . . . . . . . . . . .10

Arkko, et. al.              Standards Track                     [Page 1]
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