Security Mechanism Agreement for the Session Initiation Protocol (SIP)
RFC 3329
Document | Type | RFC - Proposed Standard (January 2003; Errata) | |
---|---|---|---|
Authors | Gonzalo Camarillo , Vesa Torvinen , Jari Arkko , Aki Niemi , Tao Haukka | ||
Last updated | 2020-01-21 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3329 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
IESG note | RFC Ed Queue - expedited publication was requested after approval by Nov 14 meeting and not responded to. | ||
Send notices to | <rohan@cisco.com> |
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 theShow full document text