Hi Yoshi,
...
>>> 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.
Note that, with pure legacy MSRP, there is no guarantee that there will be end-to-end security. RFC 4975 says:
"For this reason, a URI with the "msrps" scheme makes no assertion about the security properties of
other hops, just the next hop. The user agent knows the URI for each
hop, so it can verify that each URI has the desired security
properties."
Perhaps I could enhance the new text I suggested to address your comment #1:
OLD 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."
NEW 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, and does not provide
a mechanism to guarantee usage of TLS end-to-end. As described in [RFC4975],
even if TLS is used between some hops TCP might still be used between other hops.
Operators need to ensure that proper policies are established in order to ensure
that the MSRP traffic is protected between endpoints."
Regards,
Christer
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
