Subject: RE: [Simple] MSRP: Contributor ID

From: "Orit Levin" <[email-masked]>
Date: Wed, 25 Aug 2004 14:09:45 -0700

Inline.

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]] 
> Sent: Wednesday, August 25, 2004 12:37 PM
> To: Orit Levin
> Cc: Adam Roach; Alan Johnston; [email-masked]; Paul Kyzivat
> Subject: Re: [Simple] MSRP: Contributor ID
> 
> 
> On Aug 25, 2004, at 12:45 PM, Orit Levin wrote:
> 
> > Inline.
> >
> >> -----Original Message-----
> >> From: Adam Roach [mailto:[email-masked]]
> >> Sent: Wednesday, August 25, 2004 6:31 AM
> >> To: Orit Levin
> >> Cc: Paul Kyzivat; Alan Johnston; [email-masked]
> >> Subject: Re: [Simple] MSRP: Contributor ID
> >>
> >> Orit Levin wrote:
> >>
> >>> I am back from my one week vacation :-) I can see at least two 
> >>> independent major problems when using CPIM wrapper for MSRP
> >>> conferencing:
> >>>
> >>> 1. Let's assume that CPIM support is mandatory but CPIM use
> >> is optional
> >>> as per Paul. If the sender is a conference-unaware
> >> participant, there
> >>> is no way to "negotiate" or to request the sender to wrap 
> the MSRP 
> >>> message
> >>>
> >>>
> >>
> >> Yes, there is. In the SDP, you can indicate that the only 
> unwrapped 
> >> type that you accept is CPIM. This forces the remote endpoint to 
> >> always send CPIM-wrapped messages.
> >>
> > I understand. This case will work if a focus will always 
> request for 
> > (and insist on) CPIM wrap for both dial-in and dial-out calls. This 
> > assumption needs to be explicitly stated in the core MSRP 
> if we stick 
> > to CPIM. I still have privacy concerns with this scenario, but they 
> > depend on the solution to the second "problem" below.
> >
> >>> 2. Let's assume that the sender is a conference-aware
> >> participant who
> >>> also wants to convey its private identity in an encrypted
> >> CPIM header
> >>> to its peer(s). This is the original purpose for using CPIM
> >> and it must
> >>> be possible to convey the identity without letting any 
> intermediate, 
> >>> including the focus, to learn it. The collison problem 
> here is that
> >>> - the CPIM content is the peer-to-peer application
> >> information and, as
> >>> such, is transport independent and can be encrypted
> >>> - the missing from MSRP "Source ID" is the transport
> >> protocol identity
> >>> and can't be encrypted in order to be used by intermediates
> >> Any focus
> >>> (e.g. operated by XCON) must be able to include some
> >> well-defined user
> >>> identity in its (XCON, conferencing package) 
> communications with the 
> >>> participants.
> >>>
> >>
> >> This correlation is provided by the first element in the From-Path.
> >>
> > I hope I don't understand your answer.
> > Do you envision that for each real source a different 
> From-Path value 
> > will be generated by the focus? (a-la SSRC by mixer)
> >
> 
> I think Adam's point was, if the focus needs to know who sent 
> a particular message, it can compare the From-Path value with 
> the values used in the initial session creation, and infer 
> the sender's identity.
> 
I am glad to hear that. Hope you are right in your interpretation.
> 
> > What is the perceived "dialog-id" or "session-id" for MSRP and how 
> > many MSRP "dialogs" or "sessions" do you see being established (by 
> > SDP) and maintained between a focus and its single participant?
> 
> There is likely one MSRP session, and one SIP dialog between 
> the focus and a given participant. Clearly that does not 
> _have_ to be the case, but it will be the common case.
> 
I agree 100%.

> I think there are two basic models of focus operation we need 
> to deal with, and your problem statement appears to be rooted 
> in the second of them.
> 
> 1) The focus tells each participant to identify themselves. 
> The focus requires all messages to be wrapped in CPIM using 
> the wrapped-types mechanism.
> 
> 2) The focus says, no _I_ will identify you. The focus 
> determines the identity from the session parameters, and 
> inserts something attributing the message to a sender. This 
> could be a header, or it could add its on CPIM wrapper.
 
Again, I agree with your presentation of the possible cases.
> If 
> the message already had a cpim wrapper, then the focus could 
> choose to leave it alone, or put it inside yet another wrapper. 
> (You can have nested cpim wrappers.)
>
To accommodate the end-to-end encrypted CPIM, it will need to be
something like:
If the message already had a cpim wrapper and the destination is
conference-aware, then the focus puts it inside yet another clear
wrapper (that is in order to provide mapping to conferencing
extensions).
If the message already had a cpim wrapper and the destination is
conference-unaware (e.g. doesn't use XCON) leave it alone (that is in
order to not confuse the receiving client with conferencing information
vs. peer-to-peer information).

This is VERY DIFFERENT from the existing today conferencing architecture
where the focus logic is NOT dependant on the participant's ability to
understand or actively support conferencing extensions and protocols.

Yet "MY MAJOR PROBLEM" with using CPIM wrapper for conferencing/focus
can be summarised as following:
There is no (well-defined simple) way in the CPIM header to distinguish
whether a particular CPIM is being used for intermediate (e.g. focus,
GW) vs. for peer-to-peer needs. A user may have very different privacy
policies regarding each. In the case of conference-unaware user - the UA
will not even have the ability to distinguish between the two cases.
Which identity will the user put in the requested CPIM header? The
private (for peer-to-peer) or the public for the focus use? How the
receiving participant (which can be conference unaware as well) will
undertsand what kind of identity he is looking at?

Just to add to it, in many systems GW functionality is achived by MCUs
that are responsible for "bridging" among different protocols. This
clearly illustrates that the privacy and security requirements for using
MCUs are similar to those for GWs: i.e. the end-to-end privacy, for
which CPIM techniques have been introdiced in the first place, is
required to be addressed when working through MCUs.

Orit.
> >> /a
> >>
> >
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> >
> 
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Aug 2004 15:00:04 -0400

> understand or actively support conferencing extensions and protocols.

I don't understand why you are splitting out different behaviors for 
conference aware and unaware participants.

If the focus wants to ensure that messages are properly identified as to 
source, then it will either have to add a CPIM wrapper, or else inspect 
and approve one that is already present. If the message is encrypted e2e 
so that the focus can't decrypt, then it doesn't matter whether the 
encrypted body is CPIM or not. Either way the focus will have to wrap 
the encrypted body in a new CPIM wrapper.

It can only avoid this if it doesn't feel it is necessary to identify 
the message sender. It will be up to the conference arch to decide about 
that. Maybe it will depend on whether the recipient is conference aware, 
maybe not.

> will not even have the ability to distinguish between the two cases.

Why should there be? there isn't any way to do this for RTP/RTCP. There 
isn't any ability to have both kinds. And it is up to the mixer whether 
it preserves the IDs provided by the sender or puts in artificial ones. 
The recipient can't tell which is the case.

> undertsand what kind of identity he is looking at?

If there are multiple unsigned and unencrypted identities, then the 
recipient should probably display them all, or maybe none of them if it 
is untrusting. If some or all of the identities are signed, then it 
could choose to only display ones signed by somebody it trusts.

	Paul