Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP)
RFC 4189

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

• Versions
• 06

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 a