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

[Christer Holmberg <[e-mail]>]

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.

---

>>> 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,
--
Yoshi