SIPPING WG R. Mahy Internet-Draft Cisco Systems, Inc. Expires: December 30, 2004 Jul 2004 Pros and Cons of allowing SIP Intermediaries to add MIME bodies draft-mahy-sipping-body-add-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I 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 December 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The SIPPING Working Group has developed requirements for session policy (including bandwidth and codec restrictions, logging, and middlebox traversal), request history, and identity. This document discusses the pros and cons of allowing intermediaries to add SIP message bodies to address these requirements. It is intended to provoke serious discussion rather than as a complete proposal. Mahy Expires December 30, 2004 [Page 1] Internet-Draft SIP body addition Jul 2004 Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview of the body addition proposal . . . . . . . . . . . . 6 5. Applications with and without body modification . . . . . . . 9 5.1 Logging . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2 Session codec / bandwidth policy checking . . . . . . . . 10 5.3 Midcom-style firewall traversal . . . . . . . . . . . . . 10 5.4 NAT traversal (including v4/v6 translators) . . . . . . . 10 5.5 3rd-party Asserted Identity . . . . . . . . . . . . . . . 10 5.6 Request History . . . . . . . . . . . . . . . . . . . . . 11 5.7 3rd Party Authentication Service . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 9.2 Informational References . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 15 Mahy Expires December 30, 2004 [Page 2] Internet-Draft SIP body addition Jul 2004 1. Conventions 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 [2]. 2. Introduction Certain classes of applications the SIP and SIPPING WGs are considering ([9], [10], [11], [12]), lend themselves casually to an approach where intermediaries can inspect, add, or modify bodies. Unfortunately, this practice as currently implemented is completely incompatible with the S/MIME [3] end-to-end security mechanisms specified in the core SIP specification (RFC 3261 [1]), and consequently an explicit violation of the spec. The SIP community is at an impasse regarding how these classes of feature need to be implemented. This document attempts to present an overview of the two major proposals for moving forward. One proposal suggests that body additions (as opposed to modifications) can be done safely by SIP intermediaries if these bodies are optional in nature and if certain restrictions are placed on which intermediaries are allowed to add bodies and under what circumstances. This proposal would require a relaxation of one sentence in the SIP specification and would effectively enable a generic mechanism which could be used for a variety of applications. This mechanism would not interfere with user agents which do end-to-end security directly. Intermediaries which could add bodies could sign or encrypt these as the product of a specific intermediary. The receiving user agent would be responsible for verifying the validity and trustworthiness of each body part. Another proposal suggests that allowing intermediaries to add bodies introduces unneeded complexity and a handful of other undesirable properties. These undesirable properties could be avoided by addressing each of the requirements individually while carefully limiting the scope of some of these applications. In addition, this proposal accommodates a model where a new intermediary role called an Authentication Service which has a direct TLS [4] connection and a specific trust relationship with one of the user agents could make change to bodies on behalf of that user agent if also performing end-to-end security operations on its behalf. In addition to supporting the required applications in the presence of true end-to-end security, it is highly desirable to support a mechanism that allows specific intermediaries to safely sign and verify and possibly encrypt and decrypt requests and responses on behalf of user agents which have not implemented S/MIME. This allows Mahy Expires December 30, 2004 [Page 3] Internet-Draft SIP body addition Jul 2004 for a migration path from existing implementations to a completely end-to-end environment in a safe manner. 3. Topologies An explicit policy fetch allows user agents to fetch a policy document directly from their intermediaries, for example using the approach described in [14] and [13]. This significantly reduces, but does not completely eliminate the need for policy "corrections" by specific intermediaries for specific sessions. The remainder of this section assumes that available policy information available in the local domain has already been exhausted. Note that through configuration or prior negotiation, Alice and atlanta.com probably have few policy conflicts, and Bob and biloxi.com probably have few policy conflicts. The bulk of policy conflicts are likely to be between Alice or atlanta.com and Bob or biloxi.com. This section explores the possible paths that a request can take from sip:alice@phone2.atlanta.com to sip:bob@pc1.biloxi.com and the policy implications. Full Redirect Model: This topology results in Alice sending a request to sip:bob@biloxi.com, which redirects her request to bob@pc1.biloxi.com. Alice opens a new connection directly to pc1.biloxi.com and sends her request directly with no intermediate proxies . There is no opportunity for either atlanta.com or biloxi.com to enforce session policy here at all, since neither is involved in further signaling. INVITE sip:bob@biloxi.com SIP/2.0 [biloxi.com redirects] SIP/2.0 302 Moved Contact: [Alice retries request to new target URI] INVITE sip:bob@pc1.biloxi.com SIP/2.0 Triangle Signaling Model: Alice opens a connection to biloxi.com which routes Alice's request to bob@pc1.biloxi.com. This offers an opportunity for biloxi.com to issue a repairable error response which Alice could fix and retry. This is the most elegant toplogy because it has the simplest security characteristics. Unfortunately this model does not allow atlanta.com to influence requests from Alice. Many organizations require policy influence over requests which originate within their networks. Mahy Expires December 30, 2004 [Page 4] Internet-Draft SIP body addition Jul 2004 INVITE sip:bob@biloxi.com SIP/2.0 [biloxi.com retargets] INVITE sip:bob@pc1.biloxi.com SIP/2.0 Trapezoid Signaling Model: Alice routes its request to bob@biloxi.com through atlanta.com. Then biloxi.com retargets the requests and forwards it to bob@pc1.biloxi.com. This model allows both atlanta.com and biloxi.com to influence policy on new sessions. There are still variations of how atlanta.com and biloxi.com can influence the session. INVITE sip:bob@biloxi.com SIP/2.0 Route: sip:atlanta.com;lr [atlanta.com forwards the request to biloxi.com] INVITE sip:bob@biloxi.com SIP/2.0 [biloxi.com retargets] INVITE sip:bob@pc1.biloxi.com SIP/2.0 One way to allow proxies to influence policy in the trapezoid model causes an extra round trip to allow Alice to "consent" to each proposed policy change. For example, atlanta.com could issue a repairable error response to influence a new request, and then biloxi.com could likewise issue a repairable error response to add its policy requirements. This model results in many messages and can result in significant additional delay due to extra round trips. In addition, information which is potentially private between biloxi.com and Bob is sent to Alice. Also, Alice may be asked to forward opaque or encrypted data from an intermediary with whom Alice has no trust relationship. It hard to imagine how Alice could decide on what basis to "consent" to include such content. Alice -> atlanta.com [atlanta.com asks Alice to comply with specific policy] Alice -> atlanta.com -> biloxi.com [biloxi.com asks Alice to comply with specific policy or forward opaque data to Bob] Alice -> atlanta.com -> biloxi.com -> bob@pc1.biloxi.com Alternatively, many existing deployments "piggyback" extra information at atlanta.com and biloxi.com (or modify the MIME [5] content). In addition to expressly violating RFC 3261 [1] and breaking any end-to-end security used by Alice and Bob, this model can cause Alice or Bob to receive MIME bodies with Content-Types Mahy Expires December 30, 2004 [Page 5] Internet-Draft SIP body addition Jul 2004 which they don't understand (This is known as the "415" problem after the 415 response code). Imagine Alice sends a requests including only the text/foo MIME type, but receives a 415 Unacceptable response which includes text/foo as an acceptable MIME type. Alice has no information about what happened (Bob rejected the text/bar MIME type inserted by atlanta.com), and cannot do anything to repair the "error". The compromise approach described in the next section allows atlanta.com to "challenge" Alice with repairable error responses to comply with atlanta's policies, while biloxi.com can add a message body intended for consumption by Bob. This may be a technically workable solution, but requires complex MIME and authorization processing by intermediaries that participate in policy. This approach would still require a relaxation of Section 16.6, Step 1 of RFC 3261 [1]. Alice -> atlanta.com [atlanta.com asks Alice to comply with specific policy] Alice -> atlanta.com -> biloxi.com [biloxi adds its policy requests to the request] -> Bob Pentagram Signaling Model: In this model, extra intermediaries who are not directly associated with either Alice or Bob are included. This model is to be avoided as it dramatically increases the complexity of the security required. Alice -- atlanta.com -- provider.net -- biloxi.com -- Bob 4. Overview of the body addition proposal Of prime importance to the body addition proposal is insuring that the mechanism can be added in a backwards compatible way. To facilitate backward compatibility, the body addition proposal introduces a new option-tag called "repack" which indicates that a user agent supports multipart MIME [6] and allows bodies to be addressed to and from intermediaries. User Agents include this token in a Supported header when registering along with an Accept header with all the MIME types the User Agent supports. When a User Agent supports body repacking, we assume that the wrapping of the outermost MIME type in the SIP body is not relevant for the authentication purposes. Each of the MIME parts inside the outermost part can stand alone as a separate message. Each of these Mahy Expires December 30, 2004 [Page 6] Internet-Draft SIP body addition Jul 2004 MIME parts MUST have a Content-Disposition MIME header. If the MIME part is sent to or from an intermediary (instead of the original UAC or the final UAS), the Content-Disposition header MUST contain a src or dest parameter indicating the source or destination of the request. If the UAC needs to include some content for a specific intermediary, it indicates this by adding a content parameter to the Route header field value which corresponds to the target intermediary. The content parameter contains a content ID [7] which is referenced in the appropriate body. (For illustrative purposes, a band of asterisks (*****) surrounds content that would actually be signed or encrypted using S/MIME). INVITE sip:bob@biloxi.example.com From: To: Route: ;content="lki290s8" ... Content-Type: multipart/mixed;boundary=bar --bar Content-ID: Content-Disposition: policy ;handling=optional ;dest="sip:atlanta.example.com" ***** * ... ***** --bar Content-Disposition: session ;handling=required ***** * Content-Type: application/sdp * ... ***** --bar When an intermediary operating on the UACs behalf requires additional information in a request it needs to send a repairable error response asking for the appropriate additional information. We can define a new response code for this, for example "497 Policy Error". However, the UAC and intermediaries operating on the UACs behalf are expected to be well matched, for example mutually configured using session independent policies, so this extra round trip should not happen very often. When an intermediary operating on behalf of the UAS needs to include additional information about the request, it can add a body part to the message if it knows that the UAS supports the repack option and that any required body types that were added are acceptable to the Mahy Expires December 30, 2004 [Page 7] Internet-Draft SIP body addition Jul 2004 UAS. In most cases, the UAS registered with the repack option-tag in a Supported header or is administratively configured to known that the UAS supports the extension. In addition, the UAS proxy can include any MIME types as long as the handling parameter (in the Content-Disposition header) indicates the body part is optional. In addition, if the intermediary is collocated with the registrar for the UAS, the intermediary can observe the MIME types listed in the Accept header and send these even as "required" body parts. Any body parts added by the intermediary need to have a src parameter which corresponds the SIP URI of the intermediary that added the body part. In addition, these MIME parts MUST be signed using S/MIME using the key from a certificate which contains a SubjectAltName field which exactly matches the SIP URI in the src parameter. Content-Disposition: policy ;handling=optional ;src="sip:biloxi.example.com" ***** * Content-Type: application/sip-session-policy+xml * ... ***** When a UAC receives a request, it MUST examine the src parameter for each body type that it understands. If any of the body parts are signed it then must discard body parts from untrusted sources, or improperly signed body parts. The UAC can then clearly distinguish the body parts which were signed by the UAC from the body parts that were signed by the a proxy operating on behalf of the UAS. When the UAS sends a response, intermediaries operating on behalf of the UAS can examine the response and forward the response along. Typically the response will cooperate with the policies that were just sent in the request, but if not, the intermediary can send a 500 Server Error response to the request and drop the illegal response it received from the UAS. Intermediaries can similarly add body parts to the response as long as the UAC indicated support for the repack option-tag and all "required" MIME types are acceptable to the UAC. Finally, when the UAC receives the response, it MUST examine the src parameter for each body type that it understands, discard untrusted or improperly signed body parts and act on body parts sent by the UAS differently from body parts added by its intermediary. This proposal addresses the three most serious technical concerns with adding bodies. The proposal is backward safe and can operate even if only one side supports the extension. It is impossible for the UAC to receive a 415 Not Acceptable response due to content inserted by an intermediary. The User Agents can distinguish which body parts were sent by the other User Agent and which were added by an intermediary. Mahy Expires December 30, 2004 [Page 8] Internet-Draft SIP body addition Jul 2004 Unfortunately the proposal requires very sophisticated MIME parsing and verification/generation of multiple S/MIME signatures per message on both User Agents and intermediaries which decide to add bodies. This requires that UACs either sign all bodies, no bodies, or that they trust an appropriate service to do so (and that the protocol support necessary for this is available). On first glance, it may also seem to increase message size and processing time, however initial analysis does not suggest any significant difference between this approach and any other proposals in this regard. Note also, that this approach opens up opportunities for intermediaries to abuse this functionality for so-called "middle-to-middle" communications which can introduce a significant burden on other SIP intermediaries and the infrastructure of the Internet. Finally, this approach can be modified slightly to allow a 3rd party user agent to sign, verify, encrypt, and decrypt SIP messages on behalf of a user agent which does not support end-to-end security. This SIP node would keep credentials for the address-of-record of the user agent and apply these to each of its messages. It could handle all the authorization and verification duties (for example, throwing away bodies inserted by malicious intemediaries) normally required of user agents under this proposal. 5. Applications with and without body modification 5.1 Logging This application [10] requires an intermediary to inspect SIP message bodies. This can be session descriptions [18] which reference specific streams, or in the case of the MESSAGE method [22], actual content. If this session description or content is encrypted, either the logging service needs to receive a copy of the Content Encryption Key or it needs to receive another copy of the message. It is clear that if Alice wants to provide a copy of Content Encryption Key to her logging proxy she can, but less clear how she can (directly or indirectly) provide this information to Bob's logging proxy. Bob could provide this information to its proxy, but this requires that either Bob's proxy ask for this information (and that Alice provide it) or that Bob provide the Content Encryption Key to his proxy in a way that is easy to correlate. For this application, it is not necessary for an intermediary to ever add its own body (commonly called end-to-middle [15] security or e2m). Addressing some bodies from a user agent to an intermediary instead of the other user agent could be used here, but this application could be accomodated nearly as easily without addressing bodies at intermediaries. Mahy Expires December 30, 2004 [Page 9] Internet-Draft SIP body addition Jul 2004 5.2 Session codec / bandwidth policy checking This application requires an intermediary to inspect session descriptions, but does not require them to be changed. This is problematic if the session description is encrypted however, especially if the session description contains keying information [24] which Alice or Bob don't want to be provided to an intermediary and is not otherwise required. Directing a copy of a portion of the session description at an intermediary (e2m) could mitigate the privacy lost here, but does not require body addition. 5.3 Midcom-style firewall traversal Like the previous application, a firewall traversal intermediary (ex: using the MIDCOM architecture [19]) needs access to the transport protocols, IP addresses, and ports in use for each m-line. Again, if the session description is encrypted and contains sensitive keying material, it would be desirable to provide an additional copy of this information in another body using e2m. No body additions by intermediaries are required for this application either. 5.4 NAT traversal (including v4/v6 translators) NAT [20] traversal using protocols such as STUN [8] and ICE [25] would not normally require body modification, addition, or even inspection. (An intermediary might need to provide an address of a STUN server for example.) NAT traversal using a MIDCOM-style approach however introduces a tremendous amount of complexity. This application is fairly complex with the body modification proposal (a specific proposal is described in the next paragraph, which does ), and even more challenging when body modifications are not permitted. However, it may be prudent for the SIP community to completely reject this as a valid application of the SIP session policy mechanism when superior mechanisms for NAT traversal are available. [Description of MIDCOM-style NAT traversal with body addition approach] 5.5 3rd-party Asserted Identity This application involves an intermediary providing an assertion of the identity of the sender of the message. A proposal which describes this concept using a body (in this case an authenticated identity body) is described in Mahy Expires December 30, 2004 [Page 10] Internet-Draft SIP body addition Jul 2004 . A proposal which describes this concept using a header is [11]. Note that the auth-id [16] body could be replaced with a different body to allow unambiguous use in both requests and responses. End-to-end identity could be provided in such a way to provide a secure binding between the original Request-URI and a Contact header provided. When used in a body, this would unfortunately require a new Identity header anytime a Contact header changes (for example when transitioning from a 2-party call to a SIP conference [26]). 5.6 Request History This application involves an intermediary providing an assertion that a request was retargetted. Request history using body addition [12] is extremely natural. An auth-id body is provided for every retargetting signed by the proxy performing that retargetting. This provides an alternative way of binding an original Request-URI with a provided Contact header. History without body addition could be accomplished in one of three ways. The Request-History header field value itself could contain a cryptographic object similar to the current Identity proposal. The Request-History service could be restricted so it can only be provided by a server which also provides the Identity service (the most common cases), Finally, request history could be provided as a P-Header [21] only for use in certain administrative domains using a technique similar to RFC 3325 [23] (P-Asserted-Identity) that requires specific trust relationships. 5.7 3rd Party Authentication Service This service signs, verifies, encrypts, and decrypts on behalf of a user agent which cannot perform these functions itself. A third party which performs these functions most definitely needs to inspect and add MIME bodies. This third part however would have credentials used on behalf of the user, and would presumably be reachable directly over a secure channel (for example over a TLS connection). This application is easily implemented using the body addition proposal. If Alice needed a new request signed or encrypted she would need to send her request to this server, which would return her signed or encrypted content. She would then resend the request. Bob's service could add a MIME body with the decrypted and verified contents, and also encrpyt and/or sign Bob's response. As an alternative to the body addition proposal, you could relax the body modification requirement just for this specific application which would be defined as a new SIP role with specific normative Mahy Expires December 30, 2004 [Page 11] Internet-Draft SIP body addition Jul 2004 behavior. In either case, such a service could be collocated with a SIP Credential Service [17] or an . 6. Security Considerations Much to talk about here. 7. IANA Considerations 8. Acknowledgments Thanks to Jon Peterson and Cullen Jennings for a hearty discussion. 9. References 9.1 Normative References [1] 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. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [4] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [7] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998. [8] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Mahy Expires December 30, 2004 [Page 12] Internet-Draft SIP body addition Jul 2004 Network Address Translators (NATs)", RFC 3489, March 2003. [9] Rosenberg, J., "Requirements for Session Policy for the Session Initiation Protocol (SIP)", draft-ietf-sipping-session-policy-req-01 (work in progress), February 2004. [10] Ono, K. and S. Tachimoto, "Requirements for End-to-middle Security for the Session Initiation Protocol (SIP)", draft-ietf-sipping-e2m-sec-reqs-03 (work in progress), July 2004. [11] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-02 (work in progress), May 2004. [12] Barnes, M., "An Extension to the Session Initiation Protocol for Request History Information", draft-ietf-sip-history-info-02 (work in progress), February 2004. [13] Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-03 (work in progress), May 2004. [14] Hilt, V., "Session-Independent Policies for the Session Initiation Protocol (SIP)", draft-hilt-sipping-session-indep-policy-01 (work in progress), May 2004. [15] Ono, K. and S. Tachimoto, "End-to-middle security in the Session Initiation Protocol(SIP)", draft-ono-sipping-end2middle-security-02 (work in progress), May 2004. [16] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", draft-ietf-sip-authid-body-03 (work in progress), May 2004. [17] Jennings, C., "Certificate Management Service for SIP", draft-jennings-sipping-certs-03 (work in progress), May 2004. 9.2 Informational References [18] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [19] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox communication architecture and framework", Mahy Expires December 30, 2004 [Page 13] Internet-Draft SIP body addition Jul 2004 RFC 3303, August 2002. [20] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [21] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002. [22] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [23] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [24] Andreasen, F., Baugher, M. and D. Wing, "Session Description Protocol Security Descriptions for Media Streams", draft-ietf-mmusic-sdescriptions-06 (work in progress), July 2004. [25] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols", draft-ietf-mmusic-ice-01 (work in progress), February 2004. [26] Johnston, A. and O. Levin, "Session Initiation Protocol Call Control - Conferencing for User Agents", draft-ietf-sipping-cc-conferencing-03 (work in progress), February 2004. Author's Address Rohan Mahy Cisco Systems, Inc. 5617 Scotts Valley Drive, Suite 200 Scotts Valley, CA 95066 USA EMail: rohan@cisco.com Mahy Expires December 30, 2004 [Page 14] Internet-Draft SIP body addition Jul 2004 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 (2004). 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. Mahy Expires December 30, 2004 [Page 15]