Subject: [Simple] MSRP ACM: Usage of COMEDIA-TLS needed after all?

From: Christer Holmberg <[email-masked]>
Date: Fri, 29 Jan 2010 12:23:49 +0100

Hi,

A while ago, it was agreed that we will not refer to COMEDIA-TLS in the ACM draft, based on the argument that the TLS procedures in 4975 already covers all we need.

However, when reading the 4975 text we've spotted an issue with using only the 4975 TLS procedures in ACM:

4975 says that the "SDP offerer" provides the fingerprint. The text does NOT talk about the "active party" providing the fingerprint, which I guess is due to the 4975 definition that the SDP offerer is always the active party.

But, when COMEDIA is used, the SDP answerer can become the active party. But, there is no text in 4975 about the SDP answerer providing the fingerprint.

Now, there are two ways of solving this:

1. In ACM we specify that an SDP offer with active and actpass shall contain the fingerprint, and that an SDP answer with active shall contain the fingerprint.

OR

2. In ACM we refer to the COMEDIA-TLS procedures, that species the usage of mutual authentication, which means both the SDP offer and SDP answer will always contain the fingerprint.

My preference is option 2. Since we use COMEDIA, I think it is much more feasible to also use COMEDIA-TLS, instead of specifying new additional MSRP specific TLS procedures.

So, if we go for option 2, I propose the following changes/additions to the ACM draft:

----------

4.3.  TLS

   If MSRP UAs negotiate a TLS transport connection for MSRP, the Uas SHALL follow the procedures defined in [RFC4975]. The
   active MSRP UA will take the role of the TLS client, and the passive UA will take the role of the TLS server.

----------

6.  Security Considerations

   Use of the COMEDIA procedures changes the connection model described in RFC 4975 in that any MSRP endpoint might set up the TCP or
   TCP/TLS connection, and not only the client sending the SDP offer.

   TLS security is not compromised by this fact, since mutual authentication [RFC4572] is used - both endpoints provides certificate fingerprints
   in SDP and certificates in TLS independent of if they are active or passive. The endpoint that receives the TLS connection can always verify the source
   of the connection, independent of if the connection is set up from the SDP offerer or answerer.

----------

If people are ok with this, I will add the text to the draft.

Regards,

Christer