Subject: RE: [Simple] MSRP: Contributor ID

From: "Orit Levin" <[email-masked]>
Date: Wed, 1 Sep 2004 12:58:13 -0700

A clarification to the clarification.

We are not debating "a redundant mechanism for doing the same thing".
I don't think that there has been a doubt that MSRP entities MUST
support CPIM and MUST be able to receive and process it.

The ongoing debate is whether
- the CPIM technique can work for both centralized conferencing and
peer-to-peer security/privacy in the same time
OR
- MSRP needs to define additional means for conferencing support (in
order to be able to use CPIM for its original purpose!)

Orit.
 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: Tuesday, August 31, 2004 4:39 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Simple] MSRP: Contributor ID
> 
> [email-masked] wrote:
> 
> >- Rohan will write up a separate internet draft describing 
> the header approach with its security considerations.
> >
> >- Robert will kick off an internet draft describing the body 
> approach (be it CPIM or something else) and its security 
> considerations.
> >
> 
> Just to be clear: Section 4.1.1 of RFC 2779 absolutely, 
> unambiguously, and without recourse for appeal binds SIMPLE 
> to support CPIM in MSRP. 
> Section 4.1.2 similarly requires us to be able to identify 
> the sender. 
> These mechansims, simply put, must be in MRSP, or it dies in 
> IESG review.
> 
> Full stop.
> 
> So, I want to clear up any misunderstanding that this might 
> be an either-or decision -- an impression Hisham's note may 
> have given some particpants.
> 
> The support of CPIM _will_ be part of MSRP, it _will_ contain 
> mechanisms for identifying the sender, and there's not a 
> thing any member of this working group can do about it.
> 
> At this point, we're just debating whether there will be a 
> redundant mechanism for doing the same thing.
> 
> /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: Tue, 07 Sep 2004 14:06:48 -0400

Sorry for delayed response - I've been on vacation, but am now back.

Orit Levin wrote:
> Paul,
> The answer to "why" in each of the cases relates to the fact that
> different cases belong to same architecture/possible deployment. Even
> when you see a solution to one case - you are unintentionally missing
> another unless you go through the exercise of defining the full
> conferencing architecture.
> 
> Instead, if we step back and try to look at the problem from the top,
> CPIM is a simple means for peer-to-peer private communications with
> non-trusted intermediates (e.g. GW, MCUs) potentially present in the
> middle. Using CPIM for communications between users and the
> intermediates themselves (and still being able to use CPIM for what it
> had been designed for) without defining standard ubiquitous means for
> distinguishing between the cases - is close to impossible.

I'm still not convinced of why the recipient needs to be able to 
distinguish the cases.

If a message is received, it could have:
- no indication of source. All that is known is the identification
   of the other end of the signaling path.

- it could have a single CPIM wrapper, unsigned, unencrypted,
   that identifies the source. The recipient doesn't know if this
   came from the actual sender, or from some intermediary. But
   does it matter? In either case it can't be authenticated.

- it could have a single CPIM wrapper, signed by the actual
   sender.

- it could have a single CPIM wrapper, signed by the mixer.

- it could have two CPIM wrappers, one signed by the sender,
   one signed by the mixer.

In all of the signed cases, what is the value in knowing via the 
protocol whether a signature came from the mixer or the sender? What is 
really important is who is signing and whether you can authenticate the 
signature. If you have multiple signatures that you trust, and the 
corresponding CPIM wrappers disagree about who the sender is, then you 
have to decide which to trust, or else just display them both. If you 
want to pick one, does it really help to know whether it came from the 
mixer or not?

> On the RTP note, RTP is different from MSRP in many aspects:

True. The analogy can only be stretched so far.

> - RTP doesn't use CPIM and as a result doesn't have this problem to
> start from :-)

True. That of course wasn't the analogy I was considering.

My point was that in a conference, the sender uses RTP/RTCP to talk to 
the mixer, including its capabilities for identifying the sender. Then 
the mixer uses RTP/RTCP to talk to the recipient, again using its 
capabilities for identifying the sender. There isn't one way for the 
sender to identify itself to the recipient and a different way for the 
mixer to represent its notion of the sender to the recipient.

An analogous same state of affairs could be achieved using CPIM, if the 
mixer refuses to accept encrypted messages that it cannot decrypt. It 
could then receive messages, remove any incoming CPIM wrapper, then add 
and sign a CPIM wrapper for the recipient.

> - SSRC is used as a stream identifier only. In the core RTP, there is no
> multiplexing inside the UDP connection (which is 1-to-1 with the RTP
> session). In MSRP, the from-path value is used as the part of the "MSRP
> session identifier" for multiplexing inside a TCP tunnel.

This is all true. But I don't see how it affects the discussion at hand.

> - in addition to the RTP "mixer" mode being implemented today, RTP also
> defines the "translator" mode - which is much closer to what happening
> in IM conferencing case. It this mode, the original SSRC is PRESERVED by
> translators (and the CSRC list is not created because it doesn't have
> any meaning at all).

This would be analogous to an MSRP mixer passing CPIM messages thru 
unmodified. Note that the description of translator mode in RFC 3550 
mentions that when it is used the recipient can't tell that a translator 
is present.

Note that RTP doesn't ever address the case where the sender doesn't 
provide CNAME info, or when it is wrong. Our case in MSRP of having the 
focus provide identification of the sender when the sender didn't 
provide that information is functionality not considered in RTP.

 > As it was stated earlier, voice and video
> conferencing vendors got away with it only because the user can guess
> the source by his/her voice or video. This doesn't work for IM unless an
> advanced conferencing protocol (e.g. XCON) is being used by ALL
> participants.

Agreed that it is more important to receive sender identification with 
MSRP than it is with RTP. But then we are free to work out what the 
extended needs are.

	Paul

>>From: Paul Kyzivat [mailto:[email-masked]] 
>>Sent: Thursday, August 26, 2004 12:00 PM
>>To: Orit Levin
>>Cc: Ben Campbell; Adam Roach; Alan Johnston; [email-masked]
>>Orit Levin wrote:
>>>>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.
>>
>>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.
>>
>>
>>>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.
>>
>>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.
>>
>>
>>>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?
>>
>>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
>>
>>
> 
>