Re: [Sip] [sip] extensions of "handling" parameter ofContent-Disposition header

[Eric Burger]

Nope. S/MIME ensures the content was not adulterated in flight. However, it does not mean the requester is authorized to make the request.

Here is an example:

UAC alice issues an INVITE to UAS bob.
bob likes alice, so he accepts the INVITE
What bob doesn't like is having alice do weird stuff in a conference





On Sep 23, 2008, at 10:07 PM, Xiangsong Cui wrote:

bob doesn't know that alice is into weird stuff until he gets to this bizarre MIME disposition (note I use "disposition" here, because "handling" is clearly wrong for this purpose) If bob rejects the INVITE because he doesn't like the MIME disposition, bob has no way to say why he rejects the INVITE. He can reject the MIME type, but that is draconian and does not let alice know her deficiency is wanting to do something weird. bob may very well accept the MIME type with a different MIME disposition. Likewise, he may be very happy to accept a normal INVITE.

Hello all,





   "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

   protection, and confidentiality of the indirect content URI and
   associated parameters.

   Securing the transfer of the indirect content is the responsibility

   applications implementing this content indirection method SHOULD

   that a failure to complete HTTPS or starttls (for example, due to
   certificate or encryption mismatch) after having accepted the

   SIP request, and it may require additional user-user communication
   for correction.

   Note that this document does not advocate the use of transitive

   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.


   protocol for the scheme of the indirect content URI."

Thanks and Regards


Xiangsong

----- Original Message -----
From: Paul Kyzivat
To: Sedlacek Ivo
Cc: 'SIP IETF'
Sent: Tuesday, September 23, 2008 11:42 PM




Sedlacek Ivo wrote:
> Hello,
>
> see further explanation below.


> Media sent by the participants.

> participants using their media streams negotiated in SIP dialogs.
> Hope this makes this use case clearer.

> As mentioned above - by "sharing the resource"  I meant the focus is

> to the participants.

This sounds like a desire to have the conference mixer do something
special. As such, something around mediactl might be appropriate.

Or, it might be viewed as introducing another sort of participant into
the conference. Perhaps this could be done by sending a REFER to the
focus, with a URL for the resource in the Refer-To header.

Thanks,
Paul
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

I want to make a supplement because I think the new-introduced participant in the use case is a SEND-ONLY participant (fetching ... to the participants), how about the solution in this situation? To Eric: the statement on the authentication in RFC4483 is as follow, is it enough? 23 of RFC 3261 provides the necessary mechanism to ensure integrity, of the underlying protocol used for this transfer. If HTTP is used, support the HTTPS URI scheme for secure transfer of content and MUST support the upgrading of connections to TLS, by using starttls. Note indirect content in the SIP request is not the same as rejecting the trust. That is, just because the UAS receives a URI from a UAC that Access control to the content referenced by the URI is not defined by this specification. Access control mechanisms may be defined by the Subject: Re: [Sip] [sip] extensions of "handling" parameter ofContent-Disposition header > There is a SIP based multiparty conference with a focus - every participant > is connected using a SIP dialog to a central focus, which mixes/ switches > One of the participants wants the focus to fetch e.g. a picture / an audio > clip from an HTTP server / an RTSP server and play it to the conference > fetching the picture / audio clip from the HTTP server / the RTSP server and > distribute it using the MSRP / MSRP media streams agreed in the SIP sessions

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip