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 the
Show full document text