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

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
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.


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

> Hello all,
>
> 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?
>
>    "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."
>
> Thanks and Regards
>
>
> Xiangsong
>
> ----- Original Message -----
> From: Paul Kyzivat
> To: Sedlacek Ivo
> Cc: 'SIP IETF'
> Sent: Tuesday, September 23, 2008 11:42 PM
> Subject: Re: [Sip] [sip] extensions of "handling" parameter  
> ofContent-Disposition header
>
>
>
> Sedlacek Ivo wrote:
> > Hello,
> >
> > see further explanation below.
>
> > 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
> > Media sent by the participants.
> > 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
> > 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
> > 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
> > 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

_______________________________________________
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