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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Christer,

Thanks for the reply. I put my comments in lines.

On Wed, Aug 12, 2020 at 1:22 PM Christer Holmberg <christer.holmberg@xxxxxxxxxxxx> wrote:
Hi Yoshifumi,

Thank You for the review! Please see inline.

>Summary: This document is almost ready for publication, but I think it will be better to clarify the following points.
>
>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.

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

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

Thanks,
--
Yoshi 
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux