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

Versions: 00 01 02 03 04

SIPPING                                                           K. Ono
Internet-Draft                                              S. Tachimoto
Expires: November 15, 2004                               NTT Corporation
                                                            May 17, 2004


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

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 November 15, 2004.

Copyright Notice

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

Abstract

   Some services provided the intermediaries depend on the ability to
   inspect the message bodies in the Session Initiation Protocol (SIP).
   When sensitive information is included in them, a SIP User Agent
   needs to protect it from all intermediaries except the certain
   selected intermediaries. This document proposes a mechanism for
   securing information passed between an end user and a selected
   intermediary using S/MIME. This also proposes a mechanism for the
   discovery of an intermediary that needs to inspect an S/MIME-secured
   message body.

Conventions used in this document




Ono & Tachimoto        Expires November 15, 2004                [Page 1]


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


   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 CMS Data . . . . . . . . . . . . . . . . . .  3
   3.  Indicating the Target Content  . . . . . . . . . . . . . . . .  4
   4.  Discovery of the Proxy Server's Policies . . . . . . . . . . .  5
   5.  Behavior of UAs and Proxy Servers  . . . . . . . . . . . . . .  6
   5.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Content-Target Header Field Use  . . . . . . . . . . . . . . .  8
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   7.1 Request Example for End-to-Middle Confidentiality  . . . . . .  8
   7.2 Request Example for End-to-Middle Integrity  . . . . . . . . . 10
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
       Intellectual Property and Copyright Statements . . . . . . . . 13



























Ono & Tachimoto        Expires November 15, 2004                [Page 2]


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


1. Introduction

   When a SIP [2] UA requires services that are provided by
   intermediaries depending on the message bodies in request/response
   messages, end-to-end confidentiality will currently have to be
   disabled to take advantage of the services. This problem is pointed
   out in Section 23 of [2]. Since such an intermediary is 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 to provide 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 CMS [5] data  and indicating target message body
   for a selected proxy server. In addition, it also includes a
   mechanism for the discovery of selected proxy servers.

2. Generating S/MIME CMS Data

   For end-to-middle confidentiality, a UAC MUST be able to generate S/
   MIME CMS EnvelopedData, whose recipients are specified in the
   "recipientInfos" field. The structure of the S/MIME CMS EnvelopedData
   contains data encrypted with a content-encryption-key (CEK) and the
   CEK encrypted with different key-encryption-keys (KEKs), one for each
   recipient as specified in [5]. The KEKs are the public keys of each
   recipient or the shared keys between the UAC and each recipient.

   If the data is encrypted only for a selected proxy server, the
   recipients contain only the proxy server. If there is encrypted data
   for destined for different proxy servers, the recipient list of each
   encrypted piece of data will contain the targeted proxy servers. The
   UAC MUST generate a multipart MIME body to contain the encrypted
   data. When the message body including the encrypted data is
   transmitted to a UAS, the UAS will be unable to decrypt it. The UAC
   MUST set the value "optional" in the handling parameter of the
   Content-Disposition MIME header for the message body in order to
   avoid causing unneeded error condition in the UAS.
      Open Issue: Is it necessary that a multipart MIME body contains
      the handling parameter of Content-Disposition header? How should
      it be set when the multipart MIME body contains a body with the
      value "required" and another body with the value "optional"?

   If the encrypted data is meant to be shared with the UAS and selected
   proxy servers, the recipients SHOULD be addressed to the UAS and



Ono & Tachimoto        Expires November 15, 2004                [Page 3]


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


   selected proxy servers. The UAS SHOULD decrypt the message body
   including the encrypted data. The UAC SHOULD set the value "required"
   in the handling parameter of the Content-Disposition MIME header for
   the message body. If the handling parameter is not set, the default
   behavior is the same as setting the value "required" as specified in
   [2]

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

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

   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
   generating mechanism is required for end-to-middle data integrity.
      Note: Even when the handling parameter is set to the value
      "optional", the UAS SHOULD validate the signature of whole MIME
      body, since Content-Disposition might be modified by a malicious
      entity.

3. Indicating the Target Content

   UAs needs a way to indicate the target of the content in order that a
   proxy server can easily determine whether to process S/MIME bodies
   and if so, which one.  The UA SHOULD set a new "Content-Target" MIME
   header to label the target message body for a selected proxy server.
   When UAs label the encrypted data, the UA SHOULD set the
   "Content-Target" MIME header of the S/MIME CMS EnvelopedData. When
   UAs label the data with signature, the UA SHOULD set the
   "Content-Target" MIME header of the S/MIME CMS SignedData. When proxy
   servers receive a message, the proxy server SHOULD inspect the
   "Content-Target" MIME header.

   UAs SHOULD generate a digital signature of whole message body
   including the "Content-Target" MIME header in order to protect the
   indication. The proxy server SHOULD validate the signature of whole
   message body to check the integrity of the indication, even when the
   "Content-Target" MIME header is not set to whole message body.

   This method of indicating the target has less of an impact on proxy



Ono & Tachimoto        Expires November 15, 2004                [Page 4]


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


   servers that do not support end-to-middle security because these
   proxy servers do not inspect the MIME header anyway. Also there is
   less of an impact on UAs that do not support this MIME header,
   because the UAs will ignore irrelevant MIME headers.
      Note: In the last version of this proposal, we used a new
      parameter in "Content-Disposition" MIME header. As pointed out,
      the semantic of the header is ambiguous. A new MIME header is
      better.
      Note: There is an alternative option, the use of a new SIP header.
      This proposed mechanism puts more load on proxy servers to
      determine the necessity of MIME body handling than using a new SIP
      header would. However, the proxy can view the indicated MIME body
      more effectively than using a new SIP header. Also, the validation
      cost for integrity protection of these headers reduces the merit
      on using a new SIP header. For the integrity protection of SIP
      headers, a message body that is application/sipfrag [7] needed. In
      addition, using a new SIP header could have a negative impact on
      intermediary proxy servers that do not support end-to-middle
      security, causing unnecessary processing load. We feel that this
      MIME header mechanism is not as simple, but it is equally
      effective.

4. Discovery of the 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".
      Open Issue: How does the error message indicate the Content-Type
      to be attached with a signature? Can these Content-Type be nested
      such as "Content-Type: multipart/signed" for "Content-Type:
      application/sdp"?  Is it better to define a new error code for
      requiring a signature attachment?

   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 Issue: Instead of 493, SHOULD it be 403 that is the same as
      for requiring a signature attachment? When proxy servers require
      both of disclosure and the integrity check, how will it be



Ono & Tachimoto        Expires November 15, 2004                [Page 5]


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


      described?

   When the UAC receives one of the above error codes, the UAC needs to
   authenticate the proxy server. Therefore, the error code SHOULD
   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
      response? This might be happen when the SDP offer/answer is done
      with 200/ACK messages.

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 logging services for
   instant messages exists in a message path as shown in Figure 1.

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

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

                      Figure 1: Deployment example


5.1 UAC Behavior

   When a UAC sends an MESSAGE [8] 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 CMS EnvelopedData for UA #2 and Proxy #1. UA #1 SHOULD
   specify Proxy #1 in the "Content-Target" MIME header of the message
   body to be decrypted.

   When the UAC sends a request and needs end-to-end and end-to-middle
   integrity for the message body, it MUST use S/MIME CMS SignedData to



Ono & Tachimoto        Expires November 15, 2004                [Page 6]


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


   attach a digital signature. In this example, UA #1 MUST use the CMS
   SignedData of the contents. UA #1 SHOULD specify Proxy #1 in the
   "Content-Target" MIME header of the signature to be validated.

   When the UAC sends multiple requests to the UAS, the CEK reuse
   mechanism is beneficial that UAs efficiently encrypt/decrypt data.
   The CEK reuse mechanism is described in [9][10]. the UAC SHOULD uses
   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, the UAC generate CMS EnvelopedData with the type
   "KEKRecipientInfo" of "RecipientInfo" attribute.

5.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 CMS EnvelopedData body, the response is RECOMMENDED to be a
   "200 OK" containing the encrypted SDP based on 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.

   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 the request without this mechanism, 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 the same way the UAC normally performs with this
   mechanism.

5.3 Proxy Behavior

   When a proxy supporting this mechanism receives a message, the proxy
   server MUST inspect the "Content-Target" MIME header. If the MIME
   header includes the processing server's own name, the proxy server
   MUST inspect the specified body.

   When the specified body is CMS EnvelopedData, the proxy server MUST



Ono & Tachimoto        Expires November 15, 2004                [Page 7]


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


   inspect it and try to decrypt 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, or any existing dialog MAY be terminated. If the proxy
   server succeeds in this decryption, it MUST inspect the
   "unprotectedAttrs" field of the CMS EnvelopedData. If the attribute
   gives the key's identifier, the proxy server MUST keep the CEK with
   its identifier until the lifetime of the CEK is expired. When it
   receives subsequent messages within the lifetime, it MUST try to
   decrypt the type "KEKRecipientInfo" of "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 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 "Content-Target" MIME header, the proxy MUST ignore the
   header and perform as usual.

6. Content-Target Header Field Use

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC-2234 [11]. The new header
   "Content-Target" is defined as a MIME header.

   Content-Target        =  "Content-Target" HCOLON target-entity
   target-entity         =  proxy-uri *(COMMA proxy-uri)
   proxy-uri             = ( name-addr / addr-spec )


7. Examples

   The following examples illustrate the use of the mechanisms defined
   in the previous sections.

7.1 Request Example for End-to-Middle Confidentiality

   In the following example, a UA needs the message content in a MESSAGE
   request to be confidential and the UA allows a selected proxy server
   to view the message content. The UA also needs to protect the label
   of the target content. In addition, the UA needs to reuse the CEK in
   the subsequent request messages. In the example encrypted message



Ono & Tachimoto        Expires November 15, 2004                [Page 8]


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


   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
   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: binary
   Content-Disposition: attachment;filename=smime.p7m
   Content-Target: ss1.atlanta.example.com
   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




Ono & Tachimoto        Expires November 15, 2004                [Page 9]


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


   [binary data]

   --boundary1--



7.2 Request Example 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. The UA also needs to protect the label of the target content.

   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
   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-Target: ss1.atlanta.example.com
   Content-Disposition: attachment; filename=smime.p7s;handling=required

   [binary data]

   --boundary1--






Ono & Tachimoto        Expires November 15, 2004               [Page 10]


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


8. Security Considerations

   TBD.

9. IANA Considerations

   This document requires a new "Content-Target" MIME header.

10. Acknowledgments

   Thanks to Rohan Mahy and Cullen Jennings for their initial support of
   this concept, and to Jon Peterson for his helpful comments. Jonathan
   Rosenberg gave us a useful comment.

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)",
         draft-ietf-sipping-e2m-sec-reqs-02 (work in progress), May
         2004.

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

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

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

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

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

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



Ono & Tachimoto        Expires November 15, 2004               [Page 11]


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


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

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


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 November 15, 2004               [Page 12]


Internet-Draft       End-to-middle security in SIP              May 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 November 15, 2004               [Page 13]


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


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


Acknowledgment

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











































Ono & Tachimoto        Expires November 15, 2004               [Page 14]


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