[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04

SIPPING                                                           K. Ono
Internet-Draft                                              S. Tachimoto
Expires: December 22, 2003                               NTT Corporation
                                                           June 23, 2003


     End-to-middle security in the Session Initiation Protocol(SIP)
                draft-ono-sipping-end2middle-security-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 22, 2003.

Copyright Notice

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

Abstract

   End-to-end encryption for confidentiality services can conflict with
   some of the features provided by intermediaries.  For example, if a
   SIP UA encrypts the message body by using S/MIME for end-to-end
   security, it cannot use features that the proxy employs to inspect
   the message body contained in the request.  This situation requires
   securing information passed between the UA and an intermediary proxy,
   also called "end-to-middle security", which can work with end-to-end
   security.  This document describes a method of achieving
   end-to-middle security, allowing a SIP UA to disclose message data to
   selected intermediaries and protect the data from being seen by other
   intermediaries. It describes how to apply S/MIME CMS EnvelopedData
   body for use in end-to-middle security.



Ono & Tachimoto        Expires December 22, 2003                [Page 1]


Internet-Draft       End-to-middle Security in SIP             June 2003


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].

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problems with the Existing Situations  . . . . . . . . . . . .  4
   3.  Requirements for a Solution  . . . . . . . . . . . . . . . . .  6
   3.1 Requirements from UA's Perspective . . . . . . . . . . . . . .  6
   3.2 Requirements from Proxy's Perspective  . . . . . . . . . . . .  6
   4.  Overview of Proposed Mechanism . . . . . . . . . . . . . . . .  8
   4.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . .  9
   4.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 11
   4.4 Summary of Header Field Use  . . . . . . . . . . . . . . . . . 11
   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   5.1 Request example  . . . . . . . . . . . . . . . . . . . . . . . 13
   5.2 Response example . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
       Intellectual Property and Copyright Statements . . . . . . . . 22
























Ono & Tachimoto        Expires December 22, 2003                [Page 2]


Internet-Draft       End-to-middle Security in SIP             June 2003


1. Introduction

   The Session Initiation Protocol (SIP) [2] supports hop-by-hop
   security using TLS [3] and end-to-end security using S/MIME [4].
   This assumes a SIP UA trusts all proxy servers in a request path to
   decide whether or not to inspect the message bodies contained in a
   message.

   However, there is a model where trusted and partially-trusted proxy
   servers are mixed through a message path. The partially-trusted proxy
   servers are only trusted in terms of the SIP routing. Hop-by-hop
   confidentiality services using TLS are not suitable for this model.
   End-to-end confidentiality services using S/MIME are also not
   suitable when the intermediaries provide features based on reading
   the message bodies and/or headers. This problem is described in
   Section 23 of [2].

   One example of such a feature is NAT/firewall control, where a midcom
   [5] agent co-located with a proxy server controls a NAT/firewall
   based on certain SDP attributes in a SIP transaction. Another example
   of such a feature is the archiving of instant messaging traffic,
   where the archiving function co-located with a proxy server logs the
   message bodies in the MESSAGE [6] method. In these cases, a UA might
   want to protect the message bodies and/or headers from proxy servers
   excluding a selected proxy, which provides these features.

   Such a proxy is not always the first hop for the UA. These situations
   require security between the UA and the intermediary proxy for the
   message bodies and/or message headers. We call this "end-to-middle
   security".

   End-to-middle security consists of authentication, message integrity,
   and message confidentiality. As for authentication, HTTP digest
   authentication described in [2] is used for user-to-proxy and
   proxy-to-user authentication. The authenticating proxy is not limited
   to the first hop for the UA. Thus, HTTP digest authentication can be
   used for end-to-middle security. Digital signatures in a Public Key
   Infrastructure, that is S/MIME CMS [7] SignedData body with
   certificate, can also be used for authentication. As for message
   integrity, S/MIME CMS SignedData body can be used. S/MIME CMS
   SignedData body is created with the original data and the
   originator's private key, and anyone can verify the integrity using
   the originator's public key and the certificate. Thus, S/MIME CMS
   SignedData body can be used for end-to-middle security at the same
   time as end-to-end security. However, proxy servers usually transfer
   SIP messages without interpreting the S/MIME bodies.  This document
   mainly discusses the message confidentiality and integrity of
   end-to-middle security.



Ono & Tachimoto        Expires December 22, 2003                [Page 3]


Internet-Draft       End-to-middle Security in SIP             June 2003


2. Problems with the Existing Situations

   We describe here examples of models in which trusted and
   partially-trusted proxy servers are mixed along a message path. These
   situations demonstrate the reasons for requiring end-to-middle
   security.

   In the following example, Proxy#1 server is the home proxy server of
   User#1 using UA#1.  User#1 communicates with User#2 through Proxy#1
   and Proxy#2 as shown in Figure 1 .   UA#1 has already known the
   public key certificate of Proxy#1, and it allows Proxy#1 to inspect
   the message bodies in a request for some purpose.  However, User#1
   does not know whether Proxy#2 is trustworthy, and thus wants to
   protect the message bodies in the request.  Thus, there is the
   problem of granting a trusted intermediary permission to inspect
   message bodies while preserving their confidentiality with respect to
   other intermediaries.

   Even if UA#1's request message authorizes a selected proxy (Proxy#1)
   to see the message body, UA#1 is unable to authorize the same proxy
   to see the message body in the response from UA#2. Thus, there is the
   problem of designating and sharing a key that can be reused as a CEK
   for bidirectional exchanges of S/MIME-secured messages within SIP.

      Note: This document describes the two different problems and
      solutions. It might be a good idea to break this document into two
      separate drafts.


               Home network
               +---------------------+
               | +-----+     +-----+ |   +-----+     +-----+
   User#1------| |     |-----|     |-----|     |-----|     |-- User#2
               | +-----+     +-----+ |   +-----+     +-----+
               | UA#1        Proxy#1 |   Proxy#2     UA#2
               +---------------------+

                     Figure 1: Deployment example#1

   In the next example, User#1 connects UA#1 to a proxy server in a
   visited network, e.g. a hotspot service or a roaming service. Since
   User#1 wants to utilize certain home network services, UA#1 connects
   to a home proxy server, Proxy#1.  However, UA#1 has to connect
   Proxy#1 via the proxy server of the visited network (Proxy A),
   because User#1 has to follow the policy of that network. Proxy A may
   perform access control based on the destination addresses of calls.
   User#1 trusts Proxy A to route requests, but not to inspect the
   message bodies they contained. User#1 trusts Proxy#1 both to route



Ono & Tachimoto        Expires December 22, 2003                [Page 4]


Internet-Draft       End-to-middle Security in SIP             June 2003


   requests and to inspect the message bodies for some purpose.

   The same problems exist as those in the first example.

              Visited network
             +---------------------+
             | +-----+     +-----+ |   +-----+     +-----+     +-----+
   User#1 -- | |     |-----|     |-----|     |-----|     |-----|     |
             | +-----+     +-----+ |   +-----+     +-----+     +-----+
             | UA#1        Proxy A |   Proxy#1     Proxy#2      UA#2
             +---------------------+

                     Figure 2: Deployment example#2






































Ono & Tachimoto        Expires December 22, 2003                [Page 5]


Internet-Draft       End-to-middle Security in SIP             June 2003


3. Requirements for a Solution

   These requirements are similar to the general requirements described
   in the Internet Draft of the Session Policy Requirements [8].  The
   differences are that in this document a UA explicitly authorizes the
   use of the features provided by intermediaries. In [8], the
   intermediaries imposes a session policy without user authorization.
   This document describes security issues related to authorizing an
   intermediary to see message contents.

3.1 Requirements from UA's Perspective

   1.  The solution SHOULD work even with SIP end-to-end encryption for
       confidentiality service enabled.

   2.  It SHOULD work even with SIP end-to-end integrity service
       enabled.

   3.  It SHOULD have a minimal impact on the way to handle messages
       with S/MIME bodies.

   4.  It SHOULD allow a UA to request selected proxy servers to view
       selected message body.  In addition, the request itself SHOULD be
       secure.

   5.  It SHOULD allow a UA to request the UA on the opposite-side to
       impose the same proxy policy on the same proxy server. In
       addition, the request itself SHOULD be secure.

          It is not appropriate for the UA on the opposite-side to have
          knowledge of the public key certificate of the proxy server on
          the originating network. This last requirement can be modified
          into the following:

          +  The solution SHOULD allow a UA to request the opposite-side
             UA to reuse a content-encryption-key in subsequent messages
             during a dialog.

          +  It SHOULD allow a UA to request a selected proxy server to
             keep a content-encryption-key in a message during a dialog.

          +  The above requests themselves SHOULD be secure.


3.2 Requirements from Proxy's Perspective

   1.  The solution SHOULD have no impact on proxy servers that do not
       provide features based on S/MIME bodies in terms of handling the



Ono & Tachimoto        Expires December 22, 2003                [Page 6]


Internet-Draft       End-to-middle Security in SIP             June 2003


       existing SIP headers.

   2.  It SHOULD have less impact on proxy servers that provide features
       based on S/MIME bodies.

          When a proxy server receives an S/MIME message, it should be
          able to quickly and easily determine the necessity to
          investigate the S/MIME body. This last requirement can be
          modified into the following:

          +  It SHOULD allow proxy servers to quickly and easily
             determine whether to handle S/MIME bodies and, if so, how
             and which one.






































Ono & Tachimoto        Expires December 22, 2003                [Page 7]


Internet-Draft       End-to-middle Security in SIP             June 2003


4. Overview of Proposed Mechanism

   The proposed mechanism uses a new SIP header, "Proxy-Policy". The
   "Proxy-Policy" header indicates that a UA wants selected proxy
   servers to view selected S/MIME bodies. The proxy servers view the
   "Proxy-Policy" to determine whether to handle the S/MIME bodies and
   if so, which one.

      Note: An alternative mechanism would be to add a parameter in the
      "Content-Disposition" header. However, since proxy servers usually
      do not inspect the "Content-Disposition" header, it is not as good
      as using an additional SIP header.

   In addition, the proposed mechanism employs the "unprotectedAttrs"
   attribute in the S/MIME CMS EnvelopedData body to expresses a
   sender's preferences to reuse a content-encryption-key in subsequent
   messages during a dialog.

      Note: An alternative mechanism would be to add a parameter in the
      "Proxy-Policy" header. However, since the key reuse is executed
      after the investigation of CMS data, it is not necessary to be set
      at the SIP layer.  In addition, since [9] has already defined the
      reuse method of content-encryption-key using the
      "unprotectedAttrs" attribute in the EnvelopedData, it is better to
      use the existing mechanism.

   We assume that UA#1 requires Proxy#1 to view the message body's SDP
   in order to control a firewall for the session in the situation shown
   in Figure 1.

   Since UA#1 requires end-to-end and end-to-middle confidentiality for
   the content of the SDP, it uses S/MIME CMS EnvelopedData for multiple
   recipients and sets the "Content-ID" header to identify the content.
   The "recipientInfos" data of the EnvelopedData contains the encrypted
   content-encryption-keys for each recipient of the same encrypted
   content.  One of the "RecepientInfo" attributes is for Proxy#1, while
   another is for UA#2. UA#1 may use the "unprotectedAttrs" attribute to
   request UA#2 to reuse the content-encryption-key instead of a public
   key to encrypt a content-encryption-key of a response.


   +----------------+    +-------+     +-----+      +-----+
   |E-CEK(C) with   |--->|C,     |---->|     |----->|C,   |
   |E-UA#2key(CEK)& |    |       |     |     |      |CEK  |
   |E-P#1key(CEK)   |    |CEK    |     |     |      |     |
   +----------------+    +-------+     +-----+      +-----+
   UA#1                  Proxy#1(P#1)   Proxy#2       UA#2




Ono & Tachimoto        Expires December 22, 2003                [Page 8]


Internet-Draft       End-to-middle Security in SIP             June 2003


   C: Content of a request
   CEK: Content-encryption-key
   E-CEK(C): Content encrypted using CEK
   E-Xkey(CEK): CEK encrypted using X's public key.

          Figure 3: Overview of message with CMS EnvelopedData



   +----------------+    +-------+     +-----+      +----------------+
   |C'              |<---|C',    |<----|     |<-----|E-CEK'(C') with |
   |CEK'            |    |CEK'   |     |     |      |E-CEK(CEK')&    |
   +----------------+    +-------+     +-----+      +----------------+
   UA#1                  Proxy#1(P#1)   Proxy#2       UA#2


   C': Content of a response
   CEK': Content-encryption-key.

    Figure 4: Overview of subsequent message with CMS EnvelopedData

      Issue:How does this mechanism apply for the case when Proxy#2
      needs to inspect the message body contained in the request to
      UA#2?

   When UA#1 requires the message integrity for end-to-end and
   end-to-middle security, it uses the S/MIME CMS SignedData for the
   "message/sipfrag"[10] Content-type.  When it requires confidentiality
   and integrity for the message, it uses the S/MIME SignedData of the
   S/MIME EnvelopedData for the message.

4.1 UAC Behavior

   When a UAC sends a request and it requires end-to-end and
   end-to-middle confidentiality of the message bodies and/or headers ,
   it uses S/MIME to encrypt them.  In the above examples, UA#1 uses S/
   MIME EnvelopedData for UA#2 and Proxy#1. At the SIP layer, UA#1
   requires Proxy#1 to decrypt selected content and to view the content
   by using the "Proxy-Policy" header.  Proxy#1 then provides some
   feature based on the decrypted content.

   When the UAC needs Proxy#1 to inspect the message bodies and/or
   headers in the response, it SHOULD request the UAS to encrypt the
   response by using the same content-encryption-key as for the request.
   The UAC uses the "unprotectedAttrs" attribute to stipulate reuse of
   the content-encryption-key and indicate its identifier.

      Note: The "unprotectedAttrs" data is not protected, so it should



Ono & Tachimoto        Expires December 22, 2003                [Page 9]


Internet-Draft       End-to-middle Security in SIP             June 2003


      be protected using S/MIME SignedData.

   When the UAC sends a request and needs the end-to-end and
   end-to-middle integrity for the message bodies and/or headers, it
   uses S/MIME to attach a digital signature. In the above examples, it
   uses the S/MIME CMS SignedData of the contents. At the SIP layer,
   UA#1 requires Proxy#1 to validate the integrity of the selected
   content by employing the "Proxy-Policy" header.

   When the UAC receives a response that uses S/MIME, it decrypts and/or
   validates the S/MIME bodies as usual. If it receives a response that
   uses S/MIME EnvelopedData with the "KEKRecipentInfo" type of
   "RecepientInfo" attribute, it should decrypt the "RecipentInfo" by
   using the same content-encryption-key as for the sending request.

4.2 UAS Behavior

   When a UAS sends a response for the request with this mechanism,
   using the same type of S/MIME CMS data is recommended. For example,
   if the UAS receives an INVITE request in which the SDP is encrypted
   by using S/MIME EnvelopedData, the recommended response would be a
   "200 OK" containing the encrypted SDP based on the the S/MIME
   EnvelopedData.

   In particular, when the S/MIME EnvelopedData of the request contains
   the "unprotectedAttrs" attribute specifying reuse of the
   content-encryption-key, the UAS SHOULD encrypt a
   content-encryption-key with the content-encryption-key that was used
   in the request, instead of a public key of the UAC. The UAS SHOULD
   use the S/MIME EnvelopedData to contain the encrypted SDP in the "200
   OK" response. In addition, the UAS SHOULD set the same proxy server
   as in the request and the Content-id of the encrypted SDP in the
   "Proxy-Policy" header.

   If the UAS encrypted the SDP with a content-encryption-key that was
   itself encrypted with the content-encryption-key in the request, the
   proxy server selected by the UAC can view the SDP in the "200 OK"
   response.

      Note: In the case when the response does not contain a message
      body, even if the request contains a message body and was
      encrypted by using S/MIME EnvelopedData, the UAS does not need to
      use the S/MIME EnvelopedData.

   When the UAS receives a request that uses S/MIME, it decrypts and/or
   validates the S/MIME bodies as usual.

   When the UAS sends a response for the request without this mechanism



Ono & Tachimoto        Expires December 22, 2003               [Page 10]


Internet-Draft       End-to-middle Security in SIP             June 2003


   and needs end-to-end and end-to-middle confidentiality of the message
   bodies and/or headers , it uses S/MIME to encrypt them. When the UAC
   sends a request and needs end-to-end and end-to-middle integrity of
   the message bodies and/or headers, it uses S/MIME to attach a digital
   signature. This is the same way the UAC normally performs with this
   mechanism.

4.3 Proxy Behavior

   When a proxy supporting this mechanism receives a message, the proxy
   server inspects the "Proxy-Policy" header. If the header includes the
   processing server's own name, the proxy server inspects the specified
   Content-ID.

   When the specified content is S/MIME EnvelopedData, the proxy server
   inspects it and tries to decrypt the "RecipientInfo" attribute. If
   the proxy fails to decrypt that, it should cancel the subsequent
   procedure and respond with a 493 (Undecipherable) response if it is a
   request, or any existing dialog MAY be terminated. If the proxy
   succeeds in this decryption, it inspects the "unprotectedAttrs" data
   of the S/MIME EnvelopedData. If the attribute gives the key's
   identifier, the proxy must keep the content-encryption-key with its
   identifier during the dialog. When it receives subsequent messages in
   the dialog, it tries to decrypt the "KEKRecipientInfo" type of
   "RecepientInfo" attribute by using this content-encryption-key.

   When the specified content is S/MIME SignedData, the proxy server
   inspects it and validates the digital signature. If the verification
   is unsuccessful, the proxy server should reject the subsequent
   procedure and respond with a 403 (Forbidden) response if the message
   is a request, or any existing dialog MAY be terminated.

   When the proxy server transfers the request, it modifies the routing
   headers normally. It does not need to modify the S/MIME body.

   If a proxy does not support this mechanism and receives a message
   with the "Proxy-Policy" header, the proxy ignores the header and
   perform as usual.

4.4 Summary of Header Field Use

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC-2234 [11].

   Proxy-Policy         = HCOLON proxy-uri *( SEMI (proxy-policy-param) )
   proxy-uri            = ( name-addr / addr-spec )
   proxy-policy-param   = content-id ( SEMI policy )
   content-id           = "cid" EQUAL cid



Ono & Tachimoto        Expires December 22, 2003               [Page 11]


Internet-Draft       End-to-middle Security in SIP             June 2003


   cid                  = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT
   dot-atom                     = atom *( "." atom )
   atom                 = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+" / "'" / "`" / "~"   )
   policy                       = "policy" EQUAL ( token )

   Information about the use of headers in relation to SIP methods and
   proxy processing is summarized in Table 1.

   Header field  where   proxy  ACK BYE CAN INV OPT REG
   -----------------------------------------------------
   Proxy-Policy  R        adr    o   o   o   o   o   o
   Proxy-Policy  200-699  adr    -   o   -   o   o   o
   Proxy-Policy  1xx      adr    -   -   -   o   -   -

   Header field  where   proxy  SUB NOT PRK IFO UPD MSG
   -----------------------------------------------------
   Proxy-Policy  R        adr    o   o   -   o   o   o
   Proxy-Policy  200-699  adr    o   o   -   o   o   o

   Table 1: Summary of header field use

   The "where" column gives the request and response types in which the
   header field can be used. The values in the "where" column are as
   follows:

      *  R: The header field may appear in requests

      *  200-699: A numeral range indicates response codes with which
         the header field can be used.

      *  a: A proxy can add or concatenate the header field if it is not
         present.

      *  r: A proxy must be able to read the header field, and thus it
         cannot be encrypted.

      *  d: A proxy can delete a header field value.

      *  o: The header field is optional.












Ono & Tachimoto        Expires December 22, 2003               [Page 12]


Internet-Draft       End-to-middle Security in SIP             June 2003


5. Examples

   The following examples illustrate the use of the mechanism defined in
   the previous section.

5.1 Request example

   In the following example, a UA needs the confidentiality of the SDP
   in INVITE message and the UA allows a proxy server to view the SDP in
   INVITE request. In addition, the UA needs to protect the policy for
   the proxy server. In the example encrypted message below, the text
   boxed in asterisks ("*") is encrypted:

    INVITE alice@atlanta.example.com --> ss1.atlanta.example.com


   INVITE sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   Max-Forwards: 70
   Route: <sip:ss1.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 1 INVITE
   Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
   Date: Fri, 20 June 2003 13:02:03 GMT
   Proxy-Policy: ss1.atlanta.example.com; cid="2UWQFN309shb3@atlanta.example.com"
   Content-Type: multipart/singed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary2
   Content-Length: 878

   --boundary1

   Content-Type: multipart/mixed; boundary=boundary2
   Content-Length: 568

   --boundary2
   Content-Type: message/sipfrag

   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 1 INVITE
   Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
   Date: Fri, 20 June 2003 13:02:03 GMT
   Proxy-Policy: ss1.atlanta.example.com; cid="2UWQFN309shb3@atlanta.example.com"

   --boundary2
   Content-Type: application/pkcs7-mime; smime-type=enveloped-data;name=smime.p7m



Ono & Tachimoto        Expires December 22, 2003               [Page 13]


Internet-Draft       End-to-middle Security in SIP             June 2003


   Content-Transfer-Encoding: base64
   Content-Disposition: session; filename=smime.p7m;handling=required
   Content-ID: <2UWQFN309shb3@atlanta.example.com>
   Content-Length: 231

   ******************************************************************
   * (encryptedContentInfo)                                         *
   * Content-Type: application/sdp                                  *
   * Content-Length: 151                                            *
   *                                                                *
   * v=0                                                            *
   * o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com*
   * s=-                                                            *
   * c=IN IP4 192.0.2.101                                           *
   * t=0 0                                                          *
   * m=audio 49172 RTP/AVP 0                                        *
   * a=rtpmap:0 PCMU/8000                                           *
   *                                                                *
   * (recipientInfos)                                               *
   * RecepientInfo[0] for ss1.atlanta.example.com public key        *
   * RecepientInfo[1] for bob's public key                          *
   *                                                                *
   * (unprotectedAttr)                                              *
   * CEKReference                                                   *
   ******************************************************************

   --boundary2--

   --boundary1--
   Content-Type: application/pkcs7-signature; name=smime.p7s
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=smime.p7s;handling=required

   ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
   4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
   n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
   7GhIGfHfYT64VQbnj756

   --boundary1--



5.2 Response example

   In the following example, a UA sends a response with this mechanism.
   In the example encrypted message below, the text boxed in asterisks
   ("*") is encrypted:




Ono & Tachimoto        Expires December 22, 2003               [Page 14]


Internet-Draft       End-to-middle Security in SIP             June 2003


    200 OK bob@biloxi.example.com --> ss2.biloxi.example.com


   SIP/2.0 200 OK
   Via: SIP/2.0/TCP
   ss2.biloxi.example.com:5060;branch=z9hG4bK721e418c4.1
   ;received=192.0.2.222
   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
   ;received=192.0.2.111
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   ;received=192.0.2.101
   Record-Route: <sip:ss2.biloxi.example.com;lr>,
   <sip:ss1.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 2 INVITE
   Contact: <sip:bob@client.biloxi.example.com;transport=tcp>

   --boundary41

   Content-Type: multipart/mixed; boundary=boundary2
   Content-Length: 468

   --boundary42
   Content-Type: message/sipfrag

   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 2 INVITE
   Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
   Date: Fri, 20 June 2003 13:02:03 GMT
   Proxy-Policy: ss1.atlanta.example.com; cid="2UWQFN309shb3@biloxi.example.com"

   --boundary2
   Content-Type: application/pkcs7-mime; smime-type=enveloped-data;name=smime.p7m
   Content-Transfer-Encoding: base64
   Content-Disposition: session; filename=smime.p7m;handling=required
   Content-ID: <2UWQFN309shb3@biloxi.example.com>
   Content-Length: 211

   ******************************************************************
   * (encryptedContentInfo)                                         *
   * Content-Type: application/sdp                                  *
   * Content-Length: 147                                            *
   *                                                                *
   * v=0                                                            *



Ono & Tachimoto        Expires December 22, 2003               [Page 15]


Internet-Draft       End-to-middle Security in SIP             June 2003


   * o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com   *
   * s=-                                                            *
   * c=IN IP4 192.0.2.201                                           *
   * t=0 0                                                          *
   * m=audio 3456 RTP/AVP 0                                         *
   * a=rtpmap:0 PCMU/8000                                           *
   *                                                                *
   * (recipientInfos)                                               *
   * RecepientInfo[0] for KEKidentifier                             *
   ******************************************************************

   --boundary42--

   --boundary41--
   Content-Type: application/pkcs7-signature; name=smime.p7s
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=smime.p7s;handling=required

   hhhHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
   4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
   n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
   7GhIGfHfYT64VQbnj756

   --boundary41--



























Ono & Tachimoto        Expires December 22, 2003               [Page 16]


Internet-Draft       End-to-middle Security in SIP             June 2003


6. Security Considerations

   This specification is about applying S/MIME-secured messages for use
   in end-to-middle security. It is also applying the CEK reuse method
   defined in [9]. This requires the same security consideration as
   those of [4] and [9].













































Ono & Tachimoto        Expires December 22, 2003               [Page 17]


Internet-Draft       End-to-middle Security in SIP             June 2003


7. IANA Considerations

   This document requires a new header fields, namely "Proxy-Policy".
















































Ono & Tachimoto        Expires December 22, 2003               [Page 18]


Internet-Draft       End-to-middle Security in SIP             June 2003


8. Acknowledgments

   Thanks to Rohan Mahy and Cullen Jennings for their initial support of
   this concept, and to Jon Peterson for his helpful comments.















































Ono & Tachimoto        Expires December 22, 2003               [Page 19]


Internet-Draft       End-to-middle Security in SIP             June 2003


References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, BCP 14, March 1997.

   [2]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [3]   Allen, C. and T. Dierks, "The TLS Protocol Version 1.0", RFC
         2246, January 1999.

   [4]   Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
         2633, June 1992.

   [5]   Srisuresh, P., Kuthan, J., Rosenberg, J., Brim, S., Molitor, A.
         and A. Rayhan, "Middlebox communication architecture and
         framework", RFC 3303, August 2002.

   [6]   Campbell, Ed., B., Rosenberg, J., Schulzrinne, H., Huitema, C.
         and D. Gurle, "Session Initiation Protocol (SIP) Extension for
         Instant Messaging", RFC 3428, December 2002.

   [7]   Housley, R., "Cryptographic Message Syntax", RFC 2630, June
         1999.

   [8]   Rosenberg, J., "Requirements for Session Policy for the Session
         Initiation Protocol (SIP)",
         draft-rosenberg-sipping-session-policy-req-00  (work in
         progress), December 2002.

   [9]   Farrell, S. and S. Turner, "Reuse of CMS Content Encryption
         Keys", RFC 3185, October 2001.

   [10]  Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
         November 2002.

   [11]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 2234, November 1997.












Ono & Tachimoto        Expires December 22, 2003               [Page 20]


Internet-Draft       End-to-middle Security in SIP             June 2003


Authors' Addresses

   Kumiko Ono
   Network Service Systems Laboratories
   NTT Corporation
   9-11, Midori-Cho 3-Chome
   Musashino-shi, Tokyo  180-8585
   Japan

   EMail: ono.kumiko@lab.ntt.co.jp


   Shinya Tachimoto
   Network Service Systems Laboratories
   NTT Corporation
   9-11, Midori-Cho 3-Chome
   Musashino-shi, Tokyo  180-8585
   Japan

   EMail: tachimoto.shinya@lab.ntt.co.jp































Ono & Tachimoto        Expires December 22, 2003               [Page 21]


Internet-Draft       End-to-middle Security in SIP             June 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Ono & Tachimoto        Expires December 22, 2003               [Page 22]


Internet-Draft       End-to-middle Security in SIP             June 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Ono & Tachimoto        Expires December 22, 2003               [Page 23]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/