Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP)
RFC 4189
Document | Type | RFC - Informational (October 2005; No errata) | |
---|---|---|---|
Authors | Kumiko Ono , Shinya Tachimoto | ||
Last updated | 2015-10-14 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4189 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
Send notices to | rohan@ekabal.com, dean.willis@softarmor.com |
Network Working Group K. Ono Request for Comments: 4189 S. Tachimoto Category: Informational NTT Corporation October 2005 Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP) Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). Abstract A Session Initiation Protocol (SIP) User Agent (UA) does not always trust all intermediaries in its request path to inspect its message bodies and/or headers contained in its message. The UA might want to protect the message bodies and/or headers from intermediaries, except those that provide services based on its content. This situation requires a mechanism called "end-to-middle security" to secure the information passed between the UA and intermediaries, which does not interfere with end-to-end security. This document defines a set of requirements for a mechanism to achieve end-to-middle security. Table of Contents 1. Introduction ....................................................2 1.1. Conventions Used in This Document ..........................2 2. Use Cases .......................................................2 2.1. Examples of Scenarios ......................................2 2.2. Service Examples ...........................................4 3. Scope of End-to-Middle Security .................................6 4. Requirements for a Solution .....................................6 4.1. General Requirements .......................................6 4.2. Requirements for End-to-Middle Confidentiality .............7 4.3. Requirements for End-to-Middle Integrity ...................7 5. Security Considerations .........................................8 6. Acknowledgments .................................................9 7. References ......................................................9 7.1. Normative References .......................................9 7.2. Informative References .....................................9 Ono & Tachimoto Informational [Page 1] RFC 4189 End-to-Middle Security Requirements October 2005 1. Introduction The Session Initiation Protocol (SIP) [2] supports hop-by-hop security using Transport Layer Security (TLS) [3] and end-to-end security using Secure MIME (S/MIME) [4]. Use of TLS assumes that a SIP UA trusts all proxy servers along its request path to inspect the message bodies contained in the message, and use of S/MIME assumes that a SIP UA does not trust any proxy servers to do so. However, there is a model in which trusted and partially-trusted proxy servers are mixed along a message path. The partially-trusted proxy servers are only trusted to provide SIP routing, but these proxy servers are not trusted by users to inspect its data, except the routing headers. A hop-by-hop confidentiality service using TLS is not suitable for this model. An end-to-end confidentiality service using S/MIME is also not suitable when the intermediaries provide services based on reading the message bodies and/or headers. This problem is described in Section 23 of [2]. In some cases, a UA might want to protect its message bodies and/or headers from proxy servers along its request path, except from those that provide services based on reading its message bodies and/or headers. Conversely, a proxy server might want to view the message bodies and/or headers to sufficiently provide these services. Such proxy servers are not always the first hop from the UA. This situation requires a security mechanism to secure message bodies and/or headers between the UA and the proxy servers, while disclosing information to those that need it. We call this "end-to-middle security". 1.1. Conventions Used in This Document 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 RFC-2119 [1]. 2. Use Cases 2.1. Examples of Scenarios We describe here examples of scenarios in which trusted and partially-trusted proxy servers both exist in a message path. These situations demonstrate the reasons why end-to-middle security is required. Ono & Tachimoto Informational [Page 2] RFC 4189 End-to-Middle Security Requirements October 2005 In the following example, User #1 does not know the security policies or services provided by Proxy server #1 (Proxy#1). User #1 sends aShow full document text