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

Versions: 00 01 02 03 04

SIPPING                                                           K. Ono
Internet-Draft                                              S. Tachimoto
Expires: August 23, 2005                                 NTT Corporation
                                                       February 19, 2005


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

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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 23, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   Some services provided by intermediaries depend on the ability to
   inspect the message bodies in the Session Initiation Protocol (SIP).
   When sensitive information is included in these bodies, a SIP User
   Agent (UA) needs to protect it from intermediaries except those that
   the UA agreed to disclose it to.  This document proposes a mechanism
   for securing information passed between an end user and



Ono & Tachimoto          Expires August 23, 2005                [Page 1]


Internet-Draft        End-to-middle security in SIP        February 2005


   intermediaries using S/MIME.  It also proposes mechanisms for an
   intermediary to notify the UA about its need to inspect an
   S/MIME-secured message body, and to notify the need for the message
   body to be transmitted securely.

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.   Generating S/MIME-secured message body . . . . . . . . . . .   3
   2.1  Generating S/MIME CMS EnvelopedData  . . . . . . . . . . . .   3
   2.2  Generating S/MIME CMS SignedData . . . . . . . . . . . . . .   4
   3.   Indicating the Target Content  . . . . . . . . . . . . . . .   5
   4.   Notification of the Proxy Server's Policies  . . . . . . . .   5
   5.   Behavior of UAs and Proxy Servers  . . . . . . . . . . . . .   6
   5.1  UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.2  UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.3  Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . .   8
   6.   Proxy-Required-Body Header Field Use . . . . . . . . . . . .   9
   7.   Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   7.1  Example of Request for End-to-Middle Confidentiality . . . .  10
   7.2  Example of Request for End-to-Middle Integrity . . . . . . .  11
   8.   Security Considerations  . . . . . . . . . . . . . . . . . .  12
   9.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  13
   10.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . .  13
   11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  13
   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  14
   12.1 Normative References . . . . . . . . . . . . . . . . . . . .  14
   12.2 Informative References . . . . . . . . . . . . . . . . . . .  14
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  15
        Intellectual Property and Copyright Statements . . . . . . .  16















Ono & Tachimoto          Expires August 23, 2005                [Page 2]


Internet-Draft        End-to-middle security in SIP        February 2005


1.  Introduction

   When a SIP [2] UA requires services provided by intermediaries that
   depend on the message bodies in request/response messages, end-to-end
   confidentiality currently has to be disabled.  This problem is
   pointed out in Section 23 of [2].  Since such intermediaries are not
   always adjacent to the UA, this situation requires security between
   the UA and the intermediary for the message bodies.  We call this
   "end-to-middle security", where by "end" we mean a UA and by "middle"
   we mean a specific intermediary, typically a proxy server.

   This document describes proposed mechanisms for providing data
   confidentiality and integrity for end-to-middle security to meet the
   requirements discussed in [3].  Since the major requirement is to
   have little impact on the standardized end-to-end security
   mechanisms, the proposed mechanisms are based on S/MIME [4].  The
   mechanisms consist of generating S/MIME-secured message body and
   indicating the target message body for a proxy server selected by the
   UA.  In addition, this document includes mechanisms for an
   intermediary to notify the UA about its need to inspect an
   S/MIME-secured message body, and to notify that the message body
   needs to be transmitted securely.

2.  Generating S/MIME-secured message body

2.1  Generating S/MIME CMS EnvelopedData

   For end-to-middle confidentiality, a UA MUST generate S/MIME CMS [5]
   EnvelopedData.  Before generating it, a UA needs to identify the
   target proxy servers.  The UA MUST obtain their credentials, such as
   their public key certificates or shared secrets.  The structure of
   the S/MIME CMS EnvelopedData contains encrypted data specified in the
   "encryptedContentInfo" field and its recipient list specified in the
   "recipientInfos" field.  The encrypted data is encrypted with a
   content-encryption-key (CEK) and the recipient list contains the CEKs
   encrypted with different key-encryption-keys (KEKs), one for each
   recipient.  The KEKs are the public keys of each recipient or the
   shared keys between the UA and each recipient.

   If the data is encrypted for a selected proxy server, the recipient
   list contains only the selected proxy server.  If the data is
   encrypted and destined for multiple proxy servers, the recipient list
   contains the multiple proxy servers.  If there is encrypted data
   destined for each proxy server, the recipient list of each piece of
   encrypted data contains the targeted proxy server.  In order to
   concatenate multiple pieces of encrypted data, the UAC MUST generate
   a multipart MIME body.




Ono & Tachimoto          Expires August 23, 2005                [Page 3]


Internet-Draft        End-to-middle security in SIP        February 2005


   Since proxy servers are prohibited from deleting any body, the
   encrypted data for the proxy server is transmitted to the user agent
   server (UAS) but the UAS is not able to decrypt it.  In order to
   avoid causing unnecessary error conditions in the UAS, the user agent
   client (UAC) MUST set the value "optional" in the handling parameter
   of the "Content-Disposition" MIME header for the message body.

   If the multipart MIME body consists of encrypted MIME bodies with the
   value "optional", the "Content-Disposition" MIME header of the
   multipart MIME body MUST also contain the value "optional" in the
   handling parameter.  The UAS SHOULD NOT try to decrypt encrypted data
   that has the value "optional".

   If the multipart MIME body contains a body with the value "required"
   and another body with the value "optional", the multipart MIME body
   SHOULD have the value "required" in the handling parameter of the
   "Content-Disposition" MIME header.

   If the encrypted data is meant to be shared with the UAS and selected
   proxy servers, the recipient list SHOULD be addressed to the UAS and
   the selected proxy servers.  The UAC SHOULD set the value "required"
   in the handling parameter of the "Content-Disposition" MIME header
   for the message body.  The UAS MUST try to decrypt the encrypted data
   that has the value "required" in the handling parameter.  If the
   handling parameter is not set, the default behavior is the same as
   for setting the value "required", as specified in [2].

   If a piece of encrypted data is destined for a selected proxy server
   and another piece of encrypted data for the UAS, the recipient of
   each piece of encrypted data is each entity respectively.  In this
   case, the UAC MUST generate a multipart MIME body to concatenate the
   two.

      For example, a UA uses this mechanism when keying materials, such
      as keys used for Secure RTP (SRTP), are included in the SDP[9].
      One CMS EnvelopedData contains SDP that includes keying materials
      of an SRTP stream only for the UA.  The other CMS EnvelopedData
      contains an SDP that does not include the keying materials for a
      selected proxy server that needs to view SDP (i.e., for a firewall
      traversal service).

2.2  Generating S/MIME CMS SignedData

   For end-to-end data integrity, a UA generates S/MIME CMS SignedData
   that can be verified by any entity that knows the public key of the
   UA.  For end-to-middle data integrity, a UA MUST generate S/MIME CMS
   SignedData in the same way as end-to-end data integrity.




Ono & Tachimoto          Expires August 23, 2005                [Page 4]


Internet-Draft        End-to-middle security in SIP        February 2005


3.  Indicating the Target Content

   A UA needs a way to indicate content that they expect to be viewed by
   a proxy server, in order for the proxy server to easily determine
   whether to process MIME bodies and if so, which one.  To meet this
   requirement, the UAs SHOULD set a label to indicate a selected proxy
   server and the target content with a new SIP header,
   "Proxy-Required-Body".  This header contains one or more "content-id"
   parameter(s) for setting the "Content-ID" MIME header into the target
   body.

      Note: There were three other options to label a body: a new SIP
      parameter to an existing SIP header, a new MIME header, or a new
      parameter to an existing MIME header.
      1) Using a new parameter to Route header.  Since a proxy server
      views this header when forwarding a request message, it seems to
      be a reasonable option.  However, it cannot work with strict
      routing.
      2) Using a new MIME header, "Content-Target", as proposed in a
      previous version of this draft.  Since this option is not
      necessary as a generic mechanism of MIME, it is not preferred.
      3) Using a new MIME parameter to "Content-Disposition".  The same
      reason as above.

   When a UA labels the encrypted data, it SHOULD set the
   "Proxy-Required-Body" SIP header that contains the address of the
   server and "content-id" parameter indicating the S/MIME CMS
   EnvelopedData.  When a UA labels the data with signature, it SHOULD
   set the "Proxy-Required-Body" SIP header that contains the address of
   the server and "content-id" parameter indicating the S/MIME CMS
   SignedData.

4.  Notification of the Proxy Server's Policies

   A notification mechanism for the proxy server's policies is needed
   when a UA does not know the policies of the proxy server in a
   signaling path and the proxy server has its own policies for
   providing some services which needs the UA's compliance.  There are
   two ways in which a UA can learn the policies of the proxy server.
   The UA MAY learn them by getting a policy package from a policy
   server.[10] When a proxy server needs to inspect the message body
   contained in the response, it needs to learn the policies from a
   policy server before sending the response.

   Alternatively, the UA MAY learn them by receiving a response with an
   error code.  When the proxy server receives a request in which it
   cannot view the message body that has to be read in order to proceed,
   the proxy server MUST send a response with an error code.  If the



Ono & Tachimoto          Expires August 23, 2005                [Page 5]


Internet-Draft        End-to-middle security in SIP        February 2005


   request contains encrypted data, the error code SHOULD be 493
   (Undecipherable), accompanied with a proxy's public key certificate
   and required Content-Type for viewing.  The proxy public key
   certificate is set as an "application/pkix-cert" body.  The required
   Content-Type is set in the Warning header.

   When the proxy server receives a request that can not be accepted due
   to its condition, the proxy server MUST also send a response with an
   error code.  If a digital signature is not attached to the request
   and it required for an integrity check, the error code SHOULD be 495
   (Signature Required) accompanied with a required Content-Type for the
   integrity check.  The required Content-Type is set in the Warning
   header.

   Note: 495 (Signature Required) response is not only generated by a
   proxy server, but also by the UAS.  Using this error code is more
   explicit than using an existing error code 403, that was described in
   the last version of this draft.

      Open Issues: How should the error message indicate the
      Content-Type to which a signature needs to be attached? Can these
      Content-Types be nested such as "Content-Type: multipart/mixed"
      for "Content-Type: application/sdp" and "Content-Type:
      message/sipfrag"?
      When proxy servers require both disclosure and an integrity check,
      how should it be described?


   When the UAC receives one of the above error codes, it needs to
   authenticate the proxy server.  Therefore, the error code SHOULD
   contain the digital signature of the proxy server.

   In the worst scenario, this notification 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 an increase in the delay before session establishment, it
   is recommended that a UA learns in advance the policies of as many
   proxy servers as they can.

5.  Behavior of UAs and Proxy Servers

   We describe here an example of the behavior of UAs and proxy servers
   in a model in which a proxy server that provides a logging service
   for instant messages exists in a message path as shown in Figure 1.






Ono & Tachimoto          Expires August 23, 2005                [Page 6]


Internet-Draft        End-to-middle security in SIP        February 2005


       +-----+     +-----+     +-----+     +-----+
       |  C  |-----|  C  |-----| [C] |-----|  C  |
       +-----+     +-----+     +-----+     +-----+
        UA #1      Proxy #1    Proxy #2     UA #2
                   w/Logging function

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

                      Figure 1: Deployment example


5.1  UAC Behavior

   When a UAC sends a MESSAGE [11] request including encrypted message
   content for end-to-end and end-to-middle confidentiality, it MUST use
   S/MIME CMS EnvelopedData to encrypt them.  In this example, UA #1 is
   assumed to know the services and the public key of Proxy #1.  UA #1
   MUST use S/MIME CMS EnvelopedData body for UA #2 and Proxy #1.  UA #1
   SHOULD specify the hostname of Proxy #1 and Content-ID of the S/MIME
   CMS EnvelopedData to be decrypted in the "Proxy-Required-Body" SIP
   header.

   When the UAC sends a request and needs both end-to-end and
   end-to-middle integrity for the message body, it MUST use S/MIME CMS
   SignedData to attach a digital signature.  In this example, UA #1
   MUST use the CMS SignedData body of the contents.  UA #1 SHOULD
   specify the hostname of Proxy#1 and Content-ID of the CMS SignedData
   to be validated in the "Proxy-Required-Body" SIP header.

   When the UAC sends multiple requests to the same UAS, the CEK reuse
   mechanism is beneficial in letting UAs efficiently encrypt/decrypt
   data.  The CEK reuse mechanism is described in [6][7].  The UAC
   SHOULD use the "unprotectedAttrs" field to stipulate reuse of the CEK
   and indicate its identifier.  When the UAC reuses the CEK in the
   previous request as the KEK, it generates CMS EnvelopedData with the
   type "KEKRecipientInfo" of "RecipientInfo" attribute.

5.2  UAS Behavior

   When a UAS sends a response to the request with this mechanism, the
   use of 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 CMS EnvelopedData body, the response is RECOMMENDED to be a
   "200 OK" containing the encrypted SDP based on the CMS EnvelopedData
   body.  In the above example, however, the response of the MESSAGE
   request does not need to use the same type of S/MIME CMS data since
   the response does not contain the message content.



Ono & Tachimoto          Expires August 23, 2005                [Page 7]


Internet-Draft        End-to-middle security in SIP        February 2005


   In particular, when the CMS EnvelopedData body of the request
   contains the "unprotectedAttrs" attribute specifying reuse of the
   CEK, the UAS SHOULD keep the CEK with the identifier specified in the
   "unprotectedAttrs" attribute.

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

   Even when the UAS receives a request without this mechanism, the UAS
   MAY need end-to-end and end-to-middle confidentiality of the message
   bodies and/or headers in the response.  In this case, the UAS MUST
   use CMS EnvelopedData to encrypt them.  When the UAS sends a response
   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 no different from how the UAC normally operates
   with this mechanism.

5.3  Proxy Behavior

   When a proxy server supporting this mechanism receives a message, it
   MUST inspect the "Proxy-Required-Body" header.  If the header
   includes the processing server's own hostname, the proxy server MUST
   inspect the specified body in the Content-ID.  When the specified
   body is CMS EnvelopedData, the proxy server MUST inspect it and try
   to decrypt the "recipientInfos" field.

   Even if there is the header does not include the server's own name,
   nor the header exists, the proxy server MAY view a message body.  If
   the UA encrypted data for the proxy, the proxy server will succeed in
   decryption using the "recipientInfos" field.

   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, otherwise any existing dialog MAY be terminated.
   If the proxy server succeeds in this decryption, it MUST inspect the
   "unprotectedAttrs" field of the CMS EnvelopedData body.  If the
   attribute gives the key's identifier, the proxy server MUST keep the
   CEK with its identifier until the lifetime of the CEK has expired.
   If it receives subsequent messages within the lifetime, it MUST try
   to decrypt the type "KEKRecipientInfo" of the "RecipientInfo"
   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 fails, the proxy server SHOULD reject the subsequent
   procedure and respond with a 495 (Signature Required) response if the
   message is a request, otherwise any existing dialog MAY be
   terminated.



Ono & Tachimoto          Expires August 23, 2005                [Page 8]


Internet-Draft        End-to-middle security in SIP        February 2005


   When the proxy server forwards the request, it modifies the routing
   headers normally, but does not modify the message body.  The proxy
   server MAY delete the "Proxy-Required-Body" header that contains own
   hostname.

      When a provider operating the proxy server does not allow any
      information related to its security policies to be revealed to the
      proxy serving the recipient UA, the proxy server deletes the
      "Proxy-Required-Body" header.  However, when a request message is
      transmitted to the proxy server via a proxy server operated by
      another provider, there is no way to conceal the header from the
      other proxy server.

   If a proxy does not support this mechanism and receives a message
   with the "Proxy-Required-Body" header, the proxy MUST ignore the
   header and operate as usual.

6.  Proxy-Required-Body Header Field Use

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC-2234 [8].  The new header
   "Proxy-Required-Body" is defined as a SIP header.

   Proxy-Required-Body   = "Proxy-Required-Body" HCOLON required-proxy
                           SEMI target-body
   required-proxy        = host
   target-body           = cid-param *(COMMA cid-param)
   cid-param             = "cid" EQUAL content-id
   content-id            = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT
   dot-atom              = atom *( "." atom )
   atom                  = 1*( alphanum / "-" / "!" / "%" / "*" /
                           "_" / "+" / "'" / "`" / "~"   )

   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-Required-Body  R        adr      -   o   -   o   o   o
   Proxy-Required-Body  200-699  adr      -   o   -   o   o   o
   Proxy-Required-Body  1xx      adr      -   -   -   o   -   -

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

   Table 1: Summary of header field use



Ono & Tachimoto          Expires August 23, 2005                [Page 9]


Internet-Draft        End-to-middle security in SIP        February 2005


      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.
      The "proxy" column gives the operations a proxy may perform on the
      header field:
      *  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, so it cannot
         be encrypted.
      *  d: A proxy can delete a header field value.
      The next six columns relate to the presence of a header field in a
      method:
      *  o: The header field is optional.
      *  -: The header field is not applicable.

7.  Examples

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

7.1  Example of Request for End-to-Middle Confidentiality

   In the following example, a UA needs the message content in a MESSAGE
   request to be confidential and it allows a selected proxy server to
   view the message content.  It also needs to protect the label of the
   target content.  In addition, it needs to reuse the CEK in the
   subsequent request messages.  In the example encrypted message below,
   the text with the box of asterisks ("*") is encrypted:

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


   MESSAGE 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 MESSAGE
   Date: Fri, 20 June 2003 13:02:03 GMT
   Proxy-Required-Body: ss1.atlanta.example.com;
                        cid=1234@atlanta.example.com
   Content-Type: multipart/signed;protocol="application/pkcs7-signature";
            micalg=sha1;boundary=boundary1



Ono & Tachimoto          Expires August 23, 2005               [Page 10]


Internet-Draft        End-to-middle security in SIP        February 2005


   Content-Length: ...

   --boundary1
   Content-Type: application/pkcs7-mime;smime-type=enveloped-data;
                 name=smime.p7m
   Content-Transfer-Encoding: binary
   Content-ID: 1234@atlanta.example.com
   Content-Disposition: attachment;filename=smime.p7m;handling=required
   Content-Length: ...

   ******************************************************************
   * (encryptedContentInfo)                                         *
   * Content-Type: text/plain                                       *
   * Content-Length: ...                                            *
   *                                                                *
   * Hello.                                                         *
   * This is confidential.                                          *
   *                                                                *
   * (recipientInfos)                                               *
   * RecipientInfo[0] for ss1.atlanta.example.com public key        *
   * RecipientInfo[1] for Bob's public key                          *
   *                                                                *
   * (unprotectedAttrs)                                             *
   * CEKReference                                                   *
   ******************************************************************
   --boundary1--
   Content-Type: application/pkcs7-signature; name=smime.p7s
   Content-Transfer-Encoding: binary
   Content-Disposition: attachment;
   filename=smime.p7s;handling=required

   [binary data]
   --boundary1--



7.2  Example of Request for End-to-Middle Integrity

   In the following example, a UA needs the integrity of the message
   content in a MESSAGE request to be validated by a selected proxy
   server before it views the message content.  It also needs to protect
   the label of the target content.









Ono & Tachimoto          Expires August 23, 2005               [Page 11]


Internet-Draft        End-to-middle security in SIP        February 2005


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


   MESSAGE 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 MESSAGE
   Date: Fri, 20 June 2003 13:02:03 GMT
   Proxy-Required-Body: ss1.atlanta.example.com;
                        cid=1234@atlanta.example.com
   Content-Type: multipart/signed;protocol="application/pkcs7-signature";
            micalg=sha1;boundary=boundary1
   Content-Length: ...

   --boundary1
   Content-Type: text/plain
   Content-Length: ...

   Hello.
   This is protected with the signature.
   --boundary1--
   Content-Type: application/pkcs7-signature; name=smime.p7s
   Content-Transfer-Encoding: binary
   Content-ID:1234@atlanta.example.com
   Content-Disposition: attachment;
   filename=smime.p7s;handling=required

   [binary data]
   --boundary1--



8.  Security Considerations

   This document describes a mechanism to encrypt data for multiple
   recipients, such as multiple proxy servers, or the recipient UA and
   proxy servers.  This means that the encrypted data is decipherable at
   a previous hop and it may be modified by an entity at the previous
   hop.  Therefore, the UA SHOULD protect the data integrity before
   encryption, when the encrypted data is meant to be shared with
   multiple proxy servers, or to be shared with the UAS and selected
   proxy servers.  The UA SHOULD generate S/MIME CMS SignedData and then
   SHOULD generate the EnvelopedData to encrypt attached data with a
   digital signature.  The recipient entity SHOULD verify the signature



Ono & Tachimoto          Expires August 23, 2005               [Page 12]


Internet-Draft        End-to-middle security in SIP        February 2005


   to see if the encrypted data has been modified after decryption at
   another entity on the recipient list.

   This document also describes a new SIP header for labeling a message
   body for a proxy server.  If a malicious user or proxy server
   modified/added/deleted the label, the specified message body will not
   be inspected by the specified proxy server, and then some service
   using its content can not be served.  Or a proxy server will do
   unnecessary processing on message bodies such as unpacking MIME
   structure, and/or signature verification.  This causes a
   Denial-of-Services attack to a proxy server.

   To prevent such attacks, protection of the label integrity is needed.
   UAs and proxy servers SHOULD use TLS mechanism to communicate each
   other.  A proxy server trusted to provide SIP routing is basically
   trusted to process SIP headers other than those related to routing.
   Therefore, hop-by-hop security is reasonable for the protection.  Of
   course, UAs MAY generate a "message/sipfrag" body and attach a
   digital signature for the whole body in order to protect the label
   integrity.

9.  IANA Considerations

   This document requires a new "Proxy-Required-Body" SIP header.

10.  Open Issues
   o  How should the error message indicate the Content-Type to which a
      signature needs to be attached? Can these Content-Types be nested
      such as "Content-Type: multipart/mixed" for
      "Content-Type:application/sdp" and "Content-Type:
      message/sipfrag"?
   o  When proxy servers require both disclosure and an integrity check,
      how should it be described?
   o  If the label of the target body has a wrong value, what should we
      do? 403 (Forbidden) response?
   o  Do we need to add text about CMS AuthenticationData for the
      integrity protection?
   o  Do we need to add text about the reason we don't have to define a
      new option-tag?

11.  Acknowledgments

   Thanks to Rohan Mahy and Cullen Jennings for their initial support of
   this concept and to many people for useful comments, especially Jon
   Peterson, Jonathan Rosenberg, Eric Burger.






Ono & Tachimoto          Expires August 23, 2005               [Page 13]


Internet-Draft        End-to-middle security in SIP        February 2005


12.  References

12.1  Normative 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]  Ono, K. and S. Tachimoto, "Requirements for end-to-middle
        security in the Session Initiation Protocol (SIP)",
        Internet-Draft draft-ietf-sipping-e2m-sec-reqs-04, October 2004.

   [4]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
        (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.

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

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

   [7]  Ono, K. and S. Tachimoto, "Key reuse in S/MIME for SIP",
        Internet-Draft draft-ono-sipping-keyreuse-smime-00, February
        2004.

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

12.2  Informative References

   [9]   Andreasen, F., Baugher, M. and D. Wing, "Session Description
         Protocol Security Descriptions for Media Streams",
         Internet-Draft draft-ietf-mmusic-sdescriptions-09, February
         2005.

   [10]  Hilt, V., Camarillo, G. and J. Rosenberg, "Profile Data for
         Session Initiation Protocol (SIP) Policies", September 2003.

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

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




Ono & Tachimoto          Expires August 23, 2005               [Page 14]


Internet-Draft        End-to-middle security in SIP        February 2005


Authors' Addresses

   Kumiko Ono
   Network Service Systems Laboratories, NTT Corporation
   Musashino-shi, Tokyo  180-8585
   Japan

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


   Shinya Tachimoto
   Network Service Systems Laboratories, NTT Corporation
   Musashino-shi, Tokyo  180-8585
   Japan

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



































Ono & Tachimoto          Expires August 23, 2005               [Page 15]


Internet-Draft        End-to-middle security in SIP        February 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

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




Ono & Tachimoto          Expires August 23, 2005               [Page 16]


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