Re: [MMUSIC] Tsvart last call review of draft-ietf-mmusic-msrp-usage-data-channel-23

[Yoshifumi Nishida <[e-mail]>]

Hi Christer,

On Thu, Aug 13, 2020 at 6:34 AM Christer Holmberg <
[e-mail]> wrote:

> Hi Yoshi ,
>
> >>>1: If the other endpoints is on a TCP connection, It seems to me that
> it can look downgrading the security level of the connection.
> >>>   If this is the case, do we need some guidance here?
> >>
> >> I assume you are talking about the gateway.
> >
> > Yes.
> >
> >> It is true that "legacy" MSRP allows TCP transport. RFC 4975 describe
> the security issues associated with that.
> >>
> >> I suggest to add the following text to the Security Considerations.
> >>
> >> OLD:
> >>
> >>   "MSRP traffic over data channels is secured, including
> >>   confidentiality, integrity and source authentication, as specified by
> >>   [I-D.ietf-rtcweb-data-channel]."
> >>
> >> NEW:
> >>
> >>   "MSRP traffic over data channels is secured, including
> >>   confidentiality, integrity and source authentication, as specified by
> >>   [I-D.ietf-rtcweb-data-channel]. However, [RFC4975] allows transport of
> >>   MSRP traffic over non-secured TCP connections. In a gateway scenario,
> >>   unless the operator mandates usage of TLS, the MSRP traffic will not
> be
> >>   secured all the way between the MSRP endpoints. [RFC4975] describes
> >>   the security considerations associated with non-secured MSRP traffic."
> >
> > Thanks. Works for me.
>
> Great.  I will modify as suggested.
>
> ---
>
> >>> 2: 'If the non-data channel endpoint does not support MSRP CEMA,
> transport level interworking mode is not possible,
> >>>   it needs to act as an MSRP B2BUA.'
> >>>   -> This may sound like it falls back to B2BUA when CEMA is not
> available.
> >>>        But, I guess there might be a case where users don't want
> fallback.
> >>
> >> I don't think the users really care. CEMA is a transport connection
> establishment feature. Even with legacy MSRP, there
> >> could be a fallback if one of the endpoints don't support CEMA, but
> users are not informed about whether CEMA is used or not.
> >
> > I agree that users don't really care about if CEMA is used or not
> in general.
> > But, how about the cases where the gateway uses a non-secured TCP
> connection after it found CEMA is not available.
> > I guess some users might care about the security level is downgraded.
>
> The usage of TCP or TLS has nothing to do with whether CEMA is used or
> not. CEMA can be used with both TCP and TLS, and both TCP and TLS can be
> used with or without CEMA :)
>
> CEMA is basically about what SDP information elements you use to exchange
> the IP address information where to send your MSRP messages. CEMA uses
> generic SDP offer/answer rules, while non-CEMA uses a more MSRP-specific
> way.
>

OK. I am just concerned about the situations where a user specifies msrps
but msrp is used at the other endpoint and the user cannot aware of it.
if this won't happen, I don't have any more comments here.

>>> 3: As the doc mentions the use of B2BUA, it might be useful to refer
> security consideration in RFC7092 in Section 9.
> >>
> >> I assume you mean Section 6?
> >
> > Sorry.. I meant the security consideration section in the doc which is
> Section 8. But, Section 6 is also fine for me. I don't have a strong
> opinion here.
> > My point is that I'm not worrying about the use cases without gateways
> and the use cases with CEMA enabled gateway.
> > But, I'm concerned about the case where B2BUA gateway is used as the
> draft simply mentions that it can be used.
> > So, I am thinking that something in the security consideration in
> RFC7092 (e.g. B2BUA can be a tempting point of attack) might be useful for
> readers.
>
> Gotcha.
>
> So, I could add the following paragraph to the Security Considerations.
>
> "[RFC7092] describes security considerations associated with B2BUAs."
>

Thanks. works for me.
--
Yoshi