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

From: Yoshifumi Nishida via Datatracker <[email-masked]>
Date: Wed, 12 Aug 2020 12:38:45 -0700

Reviewer: Yoshifumi Nishida
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

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 guidances here?

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.

3: As the doc mentions the use of B2BUA, it might be useful to refer security
consideration in RFC7092 in Section 9.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Aug 2020 20:22:49 +0000

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.

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

---

> 2: 'If the non-data channel endpoint does not support MSRP CEMA, transport level interworking mode is not possible,

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

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

I can add an informative reference to RFC7092:

OLD:

   "In one model, the gateway performs as an MSRP Back-to-Back User Agent
   (B2BUA) to interwork all the procedures as necessary between the
   endpoints.  No further specification is needed for this model."

NEW:

   "In one model, the gateway performs as an MSRP Back-to-Back User Agent
   (B2BUA) [RFC7092] to interwork all the procedures as necessary between the
   endpoints.  No further specification is needed for this model."

---

Regards,

Christer

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 12 Aug 2020 20:45:17 -0700

Hi Christer,

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

On Wed, Aug 12, 2020 at 1:22 PM Christer Holmberg <
[email-masked]> wrote:

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

Yes.

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Aug 2020 13:34:54 +0000

Hi Yoshi ,

>>   the security considerations associated with non-secured MSRP traffic."

Great.  I will modify as suggested.

---

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

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.

---

> 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

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 13 Aug 2020 10:51:53 -0700

Hi Christer,

On Thu, Aug 13, 2020 at 6:34 AM Christer Holmberg <
[email-masked]> 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.
> >> It is true that "legacy" MSRP allows TCP transport. RFC 4975 describe
> the security issues associated with that.
> >>
> >> 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.
> >
> > But, how about the cases where the gateway uses a non-secured TCP
> 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.

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

Thanks. works for me.
--
Yoshi

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Aug 2020 07:08:34 +0000

Hi Yoshi,

...

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

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

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 14 Aug 2020 13:52:58 -0700

Hi Christer,

On Fri, Aug 14, 2020 at 12:08 AM Christer Holmberg <
[email-masked]> wrote:

> >>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.
The text looks good to me.
I don't have any more comments on the draft. Thanks for the efforts.
--
Yoshi