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

From: Ben Campbell <[email-masked]>
Date: Tue, 2 Feb 2010 15:13:57 -0600

Christer, can you point out the text in 4975 to which you refer? If you are talking about the last 3 paragraphs of section 14.4, the point of this was not to specify that the offerer must send the fingerprint, but simply to show how RFC 4474 interacts with a fingerprint in the offer.

In fact, that section talks about TLS in peer-to-peer mode--that is, mutual authentication with self-signed certs on both ends. In this case _both_ parties are likely to send fingerprints. In the case where one end uses a self-signed cert and the other uses a CA-signed cert, the party with the self-signed cert would need to send a fingerprint--regardless of which party was active.

As far a reference to RFC 4572, my concern is that we don't accidentally institute a requirement to send fingerprints when using a CA-signed certificate, instead of a self-signed one. If I recall correctly, RFC 4572 assumes you are always using self-signed certs. If we do reference it, we need to make sure we scope the reference to include "how fingerprints work" and not the "requirement to _always_ use a fingerprint".

On Jan 29, 2010, at 5:23 AM, Christer Holmberg wrote:

>  
> 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
>  
>  
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Feb 2010 22:56:06 +0100

Hi Ben,

>Christer, can you point out the text in 4975 to which you refer? If you are talking about the last 3 paragraphs of section 14.4,

Yes.

>the point of this was not to specify that the offerer must send the fingerprint, but simply to show how RFC 4474 interacts with a fingerprint in the offer.
>
>In fact, that section talks about TLS in peer-to-peer mode--that is, mutual authentication with self-signed certs on both ends. In this case _both_ parties are likely to send fingerprints.

Where is that specified?

The beginning of the section does talk about sending fingerprints in SDP, but is it clear that both parties send it?

>In the case where one end uses a self-signed cert and the other uses a CA-signed cert, the party with the self-signed cert would need to send a fingerprint--regardless of which party was active.

Correct. I am only talking about the case when both parties use self signed certs.

>As far a reference to RFC 4572, my concern is that we don't accidentally institute a requirement to send fingerprints when using a CA-signed certificate, instead of a self-signed one. If I recall correctly, RFC 4572 assumes you are always using self-signed certs. If we do
>reference it, we need to make sure we scope the reference to include "how fingerprints work" and not the "requirement to _always_ use a fingerprint".

I don't think 4572 requires the usage of self-signed certs. It describes what you do (sending fingerprint) IF you use self-signed certs.

But, we could add clarification text saying that the 4572 procedures are followed if the UA is using a self-signed cert.

However, IF 4975 already specifies that both endpoints include fingerprint attributes then I am not sure we need to refer to 4572. But, it is at least not very clear to me when reading 4975 :)

Regards,

Christer

Hi,

OR

----------

4.3.  TLS

----------

----------

Regards,

Christer

_______________________________________________
Simple mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Tue, 2 Feb 2010 16:31:41 -0600

<as individual>

> The beginning of the section does talk about sending fingerprints in SDP, but is it clear that both parties send it?

Well, it could certainly be more clear. But, the first sentence of the section says, "TLS can be used with a self-signed certificate as long as there is a mechanism for _both_ sides_ to ascertain that the other side used the correct certificate."  (emphasis added)

The rest of the section describes how an endpoint sends the information to do this for a self-signed cert. So I think it's reasonable to assume that each party that is providing a self-signed cert would send the fingerprint attribute.

> I don't think 4572 requires the usage of self-signed certs. It describes what you do (sending fingerprint) IF you use self-signed certs.

It presents itself as what you do if you want to use TLS on sessions established via SDP. And it specifically requires mutual authentication, and does not support a mode where one side is self-signed and the other is not. (Or at least, in that mode, it requires the device with a CA-signed cert to still send a fingerprint)

> But, we could add clarification text saying that the 4572 procedures are followed if the UA is using a self-signed cert.

That would probably be okay.

> However, IF 4975 already specifies that both endpoints include fingerprint attributes then I am not sure we need to refer to 4572. But, it is at least not very clear to me when reading 4975 :)

RFC 4975 Section 14.4, third paragraph, already says the endpoint MUST use the fingerprint attribute according to 4572. From the context , I interpret this as meaning an endpoint that wants to authenticate itself with a self-signed cert must do this, but that is not explicit.

BTW, I fully agree that that section is vague in places, and unclear on what the normative language actually applies to. A clarification draft might be a good thing, but I don't think we want to add that baggage to the ACM draft this late in the process.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Feb 2010 20:42:30 +0100

Hi,

>It presents itself as what you do if you want to use TLS on sessions established via SDP. And it specifically requires mutual authentication, and does not support a mode where one side is self-signed and the other is not. (Or at least, in that mode, it requires the device with a 
>CA-signed cert to still send a fingerprint)
>
>>

I agree, but if we choose to refer to the 4975 procedures we can at least make it clear in the ACM spec.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Wed, 3 Feb 2010 14:42:19 -0600

> I agree, but if we choose to refer to the 4975 procedures we can at least make it clear in the ACM spec.

Okay, I guess it's reasonable to add something to the effect of "If either endpoint wishes to use a self-signed TLS certificate to authenticate itself to its peer, it MUST include the certificate fingerprint in a fingerprint attribute as described in RFC 4975. This is true whether for both the active and passive party. 

Do we need to say something about the TLS server requesting a client-cert if the peer provided a fingerprint? 

We also might want a disclaimer that this only applies for peer-to-peer MSRP. If MSRP relays are present, they will not see the SDP payloads, and therefore not see the fingerprint. This limits them to using CA-certified certs. A client of the relay will authenticate with the AUTH method. A peer connecting to the relay would merely need to prove it had possession of the correct session URI by presenting it in the To-Path header field of an initial SEND request.