1 Sep 2004 01:38
Re: MSRP: Contributor ID
Adam Roach <adam <at> nostrum.com>
2004-08-31 23:38:53 GMT
2004-08-31 23:38:53 GMT
hisham.khartabil <at> nokia.com 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
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
> Orit.
>
>
>>-----Original Message-----
>>From: Paul Kyzivat [mailto:pkyzivat <at> cisco.com]
>>Sent: Thursday, August 26, 2004 12:00 PM
>>To: Orit Levin
>>Cc: Ben Campbell; Adam Roach; Alan Johnston; simple <at> ietf.org
>>Subject: Re: [Simple] MSRP: Contributor ID
>>
>>
>>
>>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
>>
>>
>
>
> _______________________________________________
> Simple mailing list
> Simple <at> ietf.org
> 
RSS Feed