access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.example.com/the-indirect-content";
size=52723
<CRLF>
Content-Description: Multicast gaming session
Content-Disposition: render
5.14. Relationship to Call-Info, Error-Info, and Alert-Info Headers
SIP [9] defines three headers that supply additional information with
regard to a session, a particular error response, or alerting. All
three of these headers allow the UAC or UAS to indicate additional
information through a URI. They may be considered a form of content
indirection. The content indirection mechanism defined in this
document is not intended as a replacement for these headers. Rather,
the headers defined in SIP MUST be used in preference to this
mechanism, where applicable, because of the well-defined semantics of
those headers.
6. Examples
6.1. Single Content Indirection
INVITE sip:boromir@example.com SIP/2.0
From: <sip:gandalf@example.net>;tag=347242
To: <sip:boromir@example.com>
Call-ID: 3573853342923422@example.net
CSeq: 2131 INVITE
Accept: message/external-body application/sdp
Content-Type: message/external-body;
ACCESS-TYPE=URL;
URL="http://www.example.net/party/06/2002/announcement";
EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT";
size=231
Content-Length: 105
Content-Type: application/sdp
Content-Disposition: session
Content-ID: <4e5562cd1214427d@example.net>
6.2. Multipart MIME with Content Indirection
MESSAGE sip:boromir@example.com SIP/2.0
From: <sip:gandalf@example.net>;tag=34589882
To: <sip:boromir@example.com>
Call-ID: 9242892442211117@example.net
CSeq: 388 MESSAGE
Accept: message/external-body, text/html, text/plain,
image/*, text/x-emoticon
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=zz993453
--zz993453
Content-Type: message/external-body;
access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.example.net/company_picnic/image1.png";
size=234422
Content-Type: image/png
Content-ID: <9535035333@example.net>
Content-Disposition: render
Content-Description: Kevin getting dunked in the wading pool
--zz993453
Content-Type: message/external-body;
access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.example.net/company_picnic/image2.png";
size=233811
Content-Type: image/png
Content-ID: <1134299224244@example.net>
Content-Disposition: render
Content-Description: Peter on his tricycle
--zz993453--
7. Security Considerations
Any content indirection mechanism introduces additional security
concerns. By its nature, content indirection requires an extra
processing step and information transfer. There are a number of
potential abuses of a content indirection mechanism:
o Content indirection allows the initiator to choose an alternative
protocol with weaker security or known vulnerabilities for the
content transfer (for example, asking the recipient to issue an
HTTP request that results in a Basic authentication challenge).
o Content indirection allows the initiator to ask the recipient to
consume additional resources in the information transfer and
content processing, potentially creating an avenue for denial-of-
service attacks (for example, an active FTP URL consuming 2
connections for every indirect content message).
o Content indirection could be used as a form of port-scanning
attack where the indirect content URL is actually a bogus URL
pointing to an internal resource of the recipient. The response
to the content indirection request could reveal information about
open (and vulnerable) ports on these internal resources.
o A content indirection URL can disclose sensitive information about
the initiator such as an internal user name (as part of an HTTP
URL) or possibly geolocation information.
Fortunately, all of these potential threats can be mitigated through
careful screening of both the indirect content URIs that are received
and those that are sent. Integrity and confidentiality protection of
the indirect content URI can prevent additional attacks as well.
For confidentiality, integrity, and authentication, this content
indirection mechanism relies on the security mechanisms outlined in
RFC 3261. In particular, the usage of S/MIME as defined in section
23 of RFC 3261 provides the necessary mechanism to ensure integrity,
protection, and confidentiality of the indirect content URI and
associated parameters.
Securing the transfer of the indirect content is the responsibility
of the underlying protocol used for this transfer. If HTTP is used,
applications implementing this content indirection method SHOULD
support the HTTPS URI scheme for secure transfer of content and MUST
support the upgrading of connections to TLS, by using starttls. Note
that a failure to complete HTTPS or starttls (for example, due to
certificate or encryption mismatch) after having accepted the
indirect content in the SIP request is not the same as rejecting the
SIP request, and it may require additional user-user communication
for correction.
Note that this document does not advocate the use of transitive
trust. That is, just because the UAS receives a URI from a UAC that
the UAS trusts, the UAS SHOULD NOT implicitly trust the object
referred to by the URI without establishing its own trust
relationship with the URI provider.
Access control to the content referenced by the URI is not defined by
this specification. Access control mechanisms may be defined by the
protocol for the scheme of the indirect content URI.
If the UAC knows the content in advance, the UAC SHOULD include a
hash parameter in the content indirection. The hash parameter is a
hexadecimal-encoded SHA-1 [8] hash of the indirect content. If a
hash value is included, the recipient MUST check the indirect content
against that hash and indicate any mismatch to the user.
In addition, if the hash parameter is included and the target URI
involves setting up a security context using certificates, the UAS
MUST ignore the results of the certificate validation procedure, and
instead verify that the hash of the (canonicalized) content received
matches the hash presented in the content-indirection hash parameter.
If the hash parameter is NOT included, the sender SHOULD use only
schemes that offer message integrity (such as https:). When the hash
parameter is not included and security using certificates is used,
the UAS MUST verify any server certificates, by using the UAS’s list
of trusted top-level certificate authorities.
If hashing of indirect content is not used, the content returned to
the recipient by exercise of the indirection might have been altered
from that intended by the sender.
8. Contributions
Sean Olson, seanol@microsoft.com, provided the vast majority of the
content of this document, including editorship through the first IESG
review. Dean Willis touched it next.
Eric Burger edited the document and addressed IESG comments,
including the access protocol negotiation mechanism.
9. Acknowledgements
Cullen Jennings and Nancy Greene provided a through review and
valuable comments and suggestions.
10. References
10.1. Normative References
[1] Freed, N. and K. Moore, "Definition of the URL MIME External-
Body Access-Type", RFC 2017, October 1996.
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2068, January 1997.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] Daniel, R., "A Trivial Convention for using HTTP in URN
Resolution", RFC 2169, June 1997.
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[8] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
RFC 3174, September 2001.
[9] 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.
[10] Burger, E., "Critical Content Multi-purpose Internet Mail
Extensions (MIME) Parameter", RFC 3459, January 2003.
[11] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004.
[12] Braden, R., "Requirements for Internet Hosts - Application and
Support", STD 3, RFC 1123, October 1989.
10.2. Informative Reference
[13] Levinson, E., "The MIME Multipart/Related Content-type", RFC
2387, August 1998.
Author’s Address
Eric Burger (editor)
Cantata Technolgy, Inc.
EMail: eburger@cantata.com
URI: http://www.cantata.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
Intellectual Property
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).