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

Versions: 00 01 02 03 04

SIPPING                                                           K. Ono
Internet-Draft                                              S. Tachimoto
Expires: August 16, 2004                                 NTT Corporation
                                                            Feb 16, 2004


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

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 August 16, 2004.

Copyright Notice

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

Abstract

   A Session Initiation Protocol (SIP) User Agent (UA) does not always
   trust all proxy servers in a request path enough to allow them
   inspect the message bodies and/or headers contained in a message. The
   UA might want to protect the message bodies and/or headers from all
   proxy servers except the particular proxy that provides services that
   depend on the ability to inspect them. In this situation, SIP needs a
   mechanism for 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 proposes mechanisms to
   achieve end-to-middle security, mainly data confidentiality for
   end-to-middle communication.




Ono & Tachimoto         Expires August 16, 2004                 [Page 1]


Internet-Draft       End-to-middle security in SIP              Feb 2004


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.  Overview of Proposed Mechanisms  . . . . . . . . . . . . . . .  4
   2.1 Creation of S/MIME CMS Bodies for UAs and Proxy servers  . . .  4
   2.2 Indicating the Target Content  . . . . . . . . . . . . . . . .  5
   2.3 Discovery of Proxy Server's Policies . . . . . . . . . . . . .  5
   3.  Behavior of UAs and Proxy Servers  . . . . . . . . . . . . . .  7
   3.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Summary of Content-Disposition Header Field Use  . . . . . . . 10
   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   5.1 Request Example  . . . . . . . . . . . . . . . . . . . . . . . 11
   5.2 Response Example . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
       Intellectual Property and Copyright Statements . . . . . . . . 19
























Ono & Tachimoto         Expires August 16, 2004                 [Page 2]


Internet-Draft       End-to-middle security in SIP              Feb 2004


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].
   However, a UA sometimes wants to protect the message bodies and/or
   headers from all proxy servers except a selected proxy server, which
   provides some sort of service based on their content. Such a proxy is
   not always adjacent to the UA. These situations require security
   between the UA and the intermediary proxy server for the message
   bodies and/or message headers. We call this "end-to-middle security",
   where by "end" we mean a UA and by "middle" we  mean a specific
   proxy.

   End-to-middle security is useful in a network where trusted and
   partially trusted proxy servers both exist in a message path. The
   partially trusted proxy servers are trusted only to view headers
   related to routing. The trusted proxy servers are trusted to view the
   message bodies and/or headers to provide services based on their
   content. For a UA requiring such services from intermediaries,
   end-to-end confidentiality will currently have to be disabled to take
   advantage of them. This problem is pointed out in Section 23 of [2].

   Some examples of services that a proxy provides using the content of
   message bodies and/or headers follow. One example is firewall
   traversal.  A midcom agent co-located with a proxy server controls a
   firewall entity. The agent needs to view certain Session Description
   Protocol (SDP) attributes in a message body or the same kind of data
   in a SIP header. Another example is the archiving of instant
   messaging traffic, where the archiving function co-located with a
   proxy server logs the message bodies in the MESSAGE method. A similar
   example is the archiving of all SIP headers and bodies traffic after
   being checked by the proxy server. These services might be deployed
   for financial or health care applications, where archiving
   communications is required by policies, as well as other
   applications.

   This document describes proposed mechanisms to achieve data
   confidentiality and the integrity of end-to-middle security to meet
   the requirements discussed in [9]. The major requirement is to be
   compatible with the end-to-end encryption that the S/MIME mechanism
   provides. Therefore, the proposed mechanisms are based on S/MIME. The
   mechanisms consists of the creation of encrypted data that is not
   readable by other proxy servers and the indication by the UA of the
   data that the UA requests the proxy server to read. In addition, it
   also includes a mechanism for the discovery of intermediate proxy
   servers.





Ono & Tachimoto         Expires August 16, 2004                 [Page 3]


Internet-Draft       End-to-middle security in SIP              Feb 2004


2. Overview of Proposed Mechanisms

   First, UAs MUST support the creation of CMS EnvelopedData body for
   multiple recipients for end-to-middle confidentiality. For
   compatibility with end-to-end security, the data needs to be
   encrypted for UAs and selected proxy servers. Second, UAs SHOULD
   support an indication mechanism to specify content in S/MIME that
   needs to be disclosed to a selected proxy server. Proxy servers MUST
   support to inspect the indicated content in S/MIME CMS bodies. Third,
   UAs MAY support a discovery mechanism to find which proxy in a
   signaling path needs to inspect and/or validate what data. In some
   cases, UAs will be statically configured with the intermediary
   proxy's policies and so they would not need to use this discovery
   mechanism. Proxy servers SHOULD provide the discovery mechanism to
   notify their policies of UAs.

2.1 Creation of S/MIME CMS Bodies for UAs and Proxy servers

   Since end-to-middle security needs to be compatible with end-to-end
   security, a creation mechanism for S/MIME CMS body is required. For
   end-to-end data integrity, UAs use S/MIME CMS SignedData body that
   can be validated by any entity. Therefore no new CMS SignedData
   creation mechanism is required.

   For data confidentiality, UAs use S/MIME CMS EnvelopedData body,
   whose recipients are specified. There are two ways of creating this
   data. The first way is to create an S/MIME CMS EnvelopedData body
   that contains encrypted content that is addressed to multiple
   recipients, such as a UA and a selected proxy server. UA MUST create
   an CMS EnvelopedData body can contain multiple recipients for
   encrypted data as specified in [7]. The structure contains data
   encrypted with a content-encryption-key (CEK) and the CEK is then
   encrypted with different key-encryption-keys (KEKs), that are
   actually the public keys for each recipient. For example, one would
   be for the recipient UA and another would be for the selected proxy
   server in the end-to-middle case.

   The second way is to create multiple S/MIME CMS EnvelopedData bodies,
   one for each recipient. For example, one for UA and one for a
   selected proxy server, and make them part of a multipart MIME body.
   UAs SHOULD use this method when keying materials, such keys for use
   by Secure RTP (SRTP)[14], are included in the SDP. One CMS
   EnvelopedData body contains SDP that includes keying materials of an
   SRTP stream only for the UA, and the other EnvelopedData body
   contains an SDP that does not include the keying materials of an SRTP
   stream that are for the UA and a selected proxy server that needs to
   view SDP (i.e.: for a firewall control service).




Ono & Tachimoto         Expires August 16, 2004                 [Page 4]


Internet-Draft       End-to-middle security in SIP              Feb 2004


2.2 Indicating the Target Content

   When proxy servers receive a message, the proxy server MUST inspect
   the "Content-Disposition" MIME headers to determine whether to
   process the S/MIME bodies and if so, which one. UA MUST support a new
   parameter called "required-entity" in the "Content-Disposition" MIME
   header that indicates required proxy servers to view the content of
   the MIME body. There is less of an impact on proxy servers that do
   not support end-to-middle security because these proxy servers do not
   inspect the "Content-Disposition" MIME header anyway.

      Note: There is an altenative option that use a new SIP header. The
      proposed mechanism requires more cost on proxy servers to
      determine the necessity of MIME body handling than using a new SIP
      header. However, the proxy can view the indicated MIME body more
      effectively than using a new SIP header. In addition, using a new
      SIP header could be negative impact on intermediary proxy servers
      that do not support end-to-middle security, causing unnecessary
      processing load. We feel that this MIME header parameter mechanism
      is not as simple, but it is equally effective.


2.3 Discovery of Proxy Server's Policies

   A discovery mechanism for proxy server's policies is needed when UAs
   do not know the policies of the proxy server in a signaling path and
   the proxy server has its own policy for providing some services.
   When the proxy server receives a request in which it cannot view some
   data that must be read in order to proceed or the proxy server
   receives a request whose sending policy cannot be accepted, the proxy
   MUST send a response with an error code. If the request is in plain
   text, the error code SHOULD be 403 (Forbidden) accompanied with a
   required Content-Type, such as "application/sdp". If the request is
   in plain text and the digital signature of it is required for an
   integrity check, the error code SHOULD be 403 (Forbidden) accompanied
   with a required Content-Type that is "multipart/signed".  If the
   request contains encrypted data, the error code SHOULD be 493
   (Undecipherable), accompanied with a proxy's public key certificate
   and required Content-Type.

      Open Issues: Which header is the appropriate one to use to set the
      required Content-Types in a response? When nested Content-Types
      are required such as "Content-Type: multipart/signed" for
      "Content-Type: application/pkcs7-mime;smime-type=enveloped-data",
      how will it be described?

   When the UA receives one of the above error codes, the UA needs to
   authenticate the proxy server. Therefore, the error code SHOULD



Ono & Tachimoto         Expires August 16, 2004                 [Page 5]


Internet-Draft       End-to-middle security in SIP              Feb 2004


   contain the digital signature of the proxy server.

   In the worst case, this discovery mechanism requires two messages for
   each proxy server in the signaling path to establish a session
   between the UAs. In addition, it requires validation procedures using
   the digital signatures for all proxy servers. Since this causes a
   increase in the delay before session establishment, it is recommended
   that UAs learn in advance the policies of as many proxy servers as
   they can.

      Open Issue: How does this mechanism apply in the case when a proxy
      server needs to inspect the message body contained in the request
      in order to provide a service for a UAS? This might be happen
      where there a firewall in the network on the UAS's side.





































Ono & Tachimoto         Expires August 16, 2004                 [Page 6]


Internet-Draft       End-to-middle security in SIP              Feb 2004


3. Behavior of UAs and Proxy Servers

   We describe here some examples of the behavior of UAs and proxy
   servers in a model in which trusted and partially trusted proxy
   servers are mixed along a message path. In the following example,
   User #1 does not know the services or security policies of Proxy #1.
   User#1 sends an INVITE request including encrypted SDP for end-to-end
   security as shown in Figure 1. Proxy #1 may reject the request
   because its inability to offer a firewall traversal service. Or Proxy
   #1 may delete the encrypted data from the body based on a security
   policy that prevents it from sending unknown data.

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

   C: Content that UA #1 allows the entity to inspect
   *: Content that UA #1 prevents the entity from inspecting

                      Figure 1: Deployment example


3.1 UAC Behavior

   When a UAC sends a request and 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 MUST use CMS
   EnvelopedData body for UA #2 and Proxy #1. At the SIP layer, UA #1
   MUST require Proxy #1 to decrypt selected content and to view the
   content by using the "required-entity" parameter in the
   Content-Disposition header. Proxy #1 then provides some services
   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 CEK as for the request.  The UAC uses the
   "unprotectedAttrs" attribute to stipulate reuse of the CEK and
   indicate its identifier as described in [10] [11].

   When the UAC sends a request and needs 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 CMS
   SignedData body of the contents. At the SIP layer, UA #1 requires
   Proxy #1 to validate the integrity of the selected content by



Ono & Tachimoto         Expires August 16, 2004                 [Page 7]


Internet-Draft       End-to-middle security in SIP              Feb 2004


   employing the "required-entity" parameter.

   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 CMS EnvelopedData body with the "KEKRecipientInfo" type of
   "RecepientInfo" attribute, it should decrypt the "RecipientInfo" by
   using the same CEK as for the sending request.

3.2 UAS Behavior

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

   In particular, when the CMS EnvelopedData body of the request
   contains the "unprotectedAttrs" attribute specifying reuse of the
   CEK, the UAS SHOULD encrypt a CEK with the CEK that was used in the
   request, instead of the public key of the UAC. The UAS SHOULD use the
   CMS EnvelopedData body to contain the encrypted SDP in the "200 OK"
   response. In addition, the UAS SHOULD set the same proxy server in
   the "required-entity" parameter of the "Content-Dispositon" MIME
   header in the request.

   If the UAS encrypted the SDP with a CEK that was itself encrypted
   with the CEK 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 CMS EnvelopedData body, the UAS does not need
      to use the CMS EnvelopedData body.

   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
   and needs end-to-end and end-to-middle confidentiality of the message
   bodies and/or headers , it MUST use CMS EnvelopedData 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 MUST
   use CMS SignedData to attach a digital signature. This is the same
   way the UAC normally performs with this mechanism.

3.3 Proxy Behavior




Ono & Tachimoto         Expires August 16, 2004                 [Page 8]


Internet-Draft       End-to-middle security in SIP              Feb 2004


   When a proxy supporting this mechanism receives a message, the proxy
   server MUST inspect the "Content-Disposition" MIME header and the
   "required-entity" parameter of that. If the MIME header includes the
   processing server's own name, the proxy server MUST inspect the
   specified content.

   When the specified content is CMS EnvelopedData body, the proxy
   server MUST inspect it and try to decrypt the "recipientInfo"
   attribute. If the proxy server 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 server succeeds in this decryption,
   it MUST inspect the "unprotectedAttrs" data of the CMS EnvelopedData
   body. If the attribute gives the key's identifier, the proxy server
   MUST keep the CEK with its identifier during the dialog. When it
   receives subsequent messages in the dialog, it MUST try to decrypt
   the "KEKRecipientInfo" type of "recepientInfo" attribute by using
   this CEK.

   When the specified content is CMS SignedData body, the proxy server
   MUST inspect it and validate the digital signature. If the
   verification is failed, 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 forwards 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 "required-parameter" parameter in the "Content-Disposition"
   header, the proxy MUST ignore the header and perform as usual.




















Ono & Tachimoto         Expires August 16, 2004                 [Page 9]


Internet-Draft       End-to-middle security in SIP              Feb 2004


4. Summary of Content-Disposition Header Field Use

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC-2234 [13]. The new parameter
   "required-entity" is defined in "required-param" as one of
   "disp-param".

   Content-Disposition   =  "Content-Disposition" HCOLON
                            disp-type *( SEMI disp-param )
   disp-type             =  "render" / "session" / "icon" / "alert"
                            / disp-extension-token
   disp-param            =  handling-param / required-param / generic-param
   handling-param        =  "handling" EQUAL
                            ( "optional" / "required" / other-handling )
   other-handling        =  token
   disp-extension-token  =  token
   required-param        =  "required-entity" EQUAL
                            proxy-uri *(COMMA proxy-uri)
   proxy-uri             = ( name-addr / addr-spec )
































Ono & Tachimoto         Expires August 16, 2004                [Page 10]


Internet-Draft       End-to-middle security in SIP              Feb 2004


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 SDP in an INVITE message to be
   confidential and the UA allows a proxy server to view the SDP in an
   INVITE request. In addition, the UA needs to protect the policy of
   the proxy server. In the example encrypted message below, the text
   with the box of 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
   Content-Type: multipart/signed;protocol="application/pkcs7-signature";
            micalg=sha1;boundary=boundary1
   Content-Length: ...

   --boundary1

   Content-Type: application/pkcs7-mime;smime-type=enveloped-data;
                 name=smime.p7m
   Content-Transfer-Encoding: base64
   Content-Disposition: session;filename=smime.p7m;handling=required;
                       required-entity=ss1.atlanta.example.com
   Content-Length: ...

   ******************************************************************
   * (encryptedContentInfo)                                         *
   * Content-Type: application/sdp                                  *
   * Content-Length: ...                                            *
   *                                                                *
   * v=0                                                            *
   * o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com*
   * s=-                                                            *
   * c=IN IP4 192.0.2.101                                           *



Ono & Tachimoto         Expires August 16, 2004                [Page 11]


Internet-Draft       End-to-middle security in SIP              Feb 2004


   * 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                                                   *
   ******************************************************************

   --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:

    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



Ono & Tachimoto         Expires August 16, 2004                [Page 12]


Internet-Draft       End-to-middle security in SIP              Feb 2004


   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 2 INVITE
   Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
   Content-Type:multipart/signed;protocol="application/pkcs7-signature";
                micalg=sha1;boundary=boundary41
   Content-Length: ...

   --boundary41

   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-Length: ...

   ******************************************************************
   * (encryptedContentInfo)                                         *
   * Content-Type: application/sdp                                  *
   * Content-Length: ...                                            *
   *                                                                *
   * v=0                                                            *
   * 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                             *
   ******************************************************************

   --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 August 16, 2004                [Page 13]


Internet-Draft       End-to-middle security in SIP              Feb 2004


6. Security Considerations

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













































Ono & Tachimoto         Expires August 16, 2004                [Page 14]


Internet-Draft       End-to-middle security in SIP              Feb 2004


7. IANA Considerations

   This document requires a new parameter in "Content-Disposition"
   header fields, namely "required-entity".















































Ono & Tachimoto         Expires August 16, 2004                [Page 15]


Internet-Draft       End-to-middle security in SIP              Feb 2004


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 August 16, 2004                [Page 16]


Internet-Draft       End-to-middle security in SIP              Feb 2004


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]   Ono, K. and S. Tachimoto, "Requirements for end-to-middle
         security in the Session Initiation Protocol (SIP)",
         draft-ietf-sipping-e2m-sec-reqs-01  (work in progress),
         February 2004.

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

   [11]  Ono, K. and S. Tachimoto, "Key reuse in S/MIME for SIP",
         draft-ono-sipping-keyreuse-smime-00  (work in progress),
         February 2004.

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

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



Ono & Tachimoto         Expires August 16, 2004                [Page 17]


Internet-Draft       End-to-middle security in SIP              Feb 2004


   [14]  Andreasen, F., Baugher, M. and D. Wing, "Session Description
         Protocol Security Descriptions for Media Streams",
         draft-ietf-mmusic-sdescriptions-03.txt (work in progress),
         February 2004.


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 August 16, 2004                [Page 18]


Internet-Draft       End-to-middle security in SIP              Feb 2004


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 (2004). 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 August 16, 2004                [Page 19]


Internet-Draft       End-to-middle security in SIP              Feb 2004


   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 August 16, 2004                [Page 20]


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