Subject: Re: [Simple] MSRP-ACM/SessMatch: Security Considerations and TLS usage

From: Adam Roach <[email-masked]>
Date: Tue, 16 Mar 2010 18:05:12 -0500

On 3/8/10 1:19 PM, Ben Campbell wrote:
> Could I get each of you to make a quick sanity check on the security considerations and TLS mutual authentication related sections of the latest msrp-ACM and session matching drafts? There were a number of updates from the WGLC, and I want to make sure we've not broken anything. The text in question is pretty short.
>    

I could just be running low on sleep, but I can't begin to parse this 
sentence (from the security section of the sessmatch draft):

>     Even if MSRP entities do not use the MSRP URI domain part to perform
>     session matching, if the domain information is different in the SDP
>     a=path attribute and the associated MSRP messages the MSRP entities
>     might be able to determine whether one or more intermediaries have
>     been inserted in the message path.
>    

I get lost in the stacked (very long) clauses. I'm not even certain what 
the main verb of the sentence is intended to be. Perhaps it would be 
clearer if it were broken up into several smaller sentences.

In terms of what I would expect in a security considerations section, 
this is far too vague, and mostly involves hand-waving:

>     If public certificates are used, a modification of the host part
>     (without performing similar modifications in the associated MSRP
>     messages) would in most cases trigger a certificate matching error,
>     since the host part is used in order to match the certificate.

Okay... and then? I think you need to point out that the MSRP session 
setup attempt fails under these circumstances. It is certainly outside 
the purview of this document to suggest that we discard the security 
properties of TLS wholesale.

>     This
>     does not apply if the host part is modified between two MSRP relays,
>     since relays do not have access to the SDP information and use the
>     From-Path URI host for the certificate matching.
>    

Shouldn't this say "To-Path"? It's the entity forming the outgoing 
connection that verifies the server identity, right?

/a

---

From: Adrian Georgescu <[email-masked]>
Date: Sun, 14 Mar 2010 17:59:26 +0100

Hello,

This analysis belongs to the AG Projects developer of our MSRP UA stack:

Related to the TLS mutual authentication, the draft is ambiguous. It's  
rather a discussion, than a clear set of rules. There are things which  
are left to deduction. The discussion barely touches the cases when a  
relay is used. An endpoint having a non-NATed address is not the same  
as an endpoint using a relay (though the draft sort of suggests this)  
since the relay does not get its hands on the SDP payloads exchanged.  
There are 16 possible scenarios: each of the two endpoints can be  
behind a NAT or not (resulting in 4 possibilities), and each of them  
can use a relay or not (resulting in 4 more possibilities). Finally  
and each end point can support COMEDIA or not. In total there are 32  
possibilities, which need to be inspected (although some of them are  
really similar).

It is too complex to be reliable mechanism when it comes to  
interoperability between multiple vendors, this will rather work well  
with a single vendor.

Hope this helps improving the draft.

Kind regards,
Adrian

On Mar 9, 2010, at 1:29 AM, Paul Kyzivat wrote:

> I looked, and nothing leaped out at me as being problematic.
> But I have not looked at any of these drafts for ages, so I'm sure  
> I'm not groking the totality of the security mechanism.
>
> 	Thanks,
> 	Paul
>
> Ben Campbell wrote:
>> Hi Adam, Paul, and Adrian,
>> Could I get each of you to make a quick sanity check on the  
>> security considerations and TLS mutual authentication related  
>> sections of the latest msrp-ACM and session matching drafts? There  
>> were a number of updates from the WGLC, and I want to make sure  
>> we've not broken anything. The text in question is pretty short.
>> We'd like to move this forward as quickly as possible.
>> Thanks!
>> Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Mar 2010 18:55:59 +0100

Hi,

>>Could I get each of you to make a quick sanity check on the security considerations and TLS mutual authentication related 
>>sections of the latest msrp-ACM and session matching drafts? There were a number of updates from the WGLC, and I want to 
>>make sure we've not broken anything. The text in question is pretty short.
>
>
>I could just be running low on sleep, but I can't begin to parse this sentence (from the security section of the sessmatch draft):
>
>
>I get lost in the stacked (very long) clauses. I'm not even certain what the main verb of the sentence is intended to be. Perhaps it 
>would be clearer if it were broken up into several smaller sentences.

I agree the text is a little difficult to understand. I suggest replacing it with the following:

"Since MSRP entities do not use the MSRP URI domain part to perform session matching, if intermediaries modify the SDP a=path attribute, but do not modify the corresponding information in the asscoiated MSRP messages, MSRP entities can by comparing the domain information determine that one or more intermediareis have been inserted in the message path." 

Is  that more clear?

-------------

>In terms of what I would expect in a security considerations section, this is far too vague, and mostly involves hand-waving:
>
>Okay... and then? I think you need to point out that the MSRP session setup attempt fails under these circumstances. It is certainly 
>outside the purview of this document to suggest that we discard the security properties of TLS wholesale. 

True. That is not the intention.

What about adding the following text to the end of the paragraph:

        ", and the MSRP session setup would fail.

-------------

>     This does not apply if the host part is modified between two MSRP relays,
>Shouldn't this say "To-Path"? It's the entity forming the outgoing connection that verifies the server identity, right?

My understanding is that the From-Path is used, but I can double check that.

Ben, can you verify whether the From-Path is used?

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Mar 2010 11:06:38 -0700

> "Since MSRP entities do not use the MSRP URI domain part to perform session matching, if intermediaries modify the SDP a=path attribute, but do not modify the corresponding information in the assco…

I think both are used. The TLS client authenticates the server is the server it wants to talk to. That's done based on the To-Path. 

4976 also talks about receiving an _AUTH_ request over a mutually authenticated TLS connection, in which case the TLS _server_ compares the client cert against the from-path. It seems to me that this should apply to the first request received on a connection, regardless of type--but I don't see any similar language for non-AUTH requests.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Mar 2010 07:51:13 +0100

Hi,

>I think both are used. The TLS client authenticates the server is the server it wants to talk to. That's done based on the To-

Section 6.3 of 4976 says the following:

   "When a relay receives an AUTH request, the first thing it does is to
   authenticate and authorize the previous hop and the client at the far
   end.  If there are no other relays between this relay and the client,
   then these are the same thing.
   
  When the previous hop is a relay, authentication is done with TLS
   using mutual authentication.  If the TLS client presented a host
   certificate, the relay checks that the subjectAltName in the
   certificate of the TLS client matches the hostname in the first From-
   Path URI." 

>4976 also talks about receiving an _AUTH_ request over a mutually authenticated TLS connection, in which case the TLS 
>_server_ compares the client cert against the from-path.

Correct. That is the text I am referring to above.

>It seems to me that this should apply to the first request received on a connection, regardless of type--but I don't see any 
>similar language for non-AUTH requests.

AUTH isn't sent between relays, is it?

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Mar 2010 23:52:55 -0700

> AUTH isn't sent between relays, is it?

It can be, when you have more than one relay on behalf of the same endpoint.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Mar 2010 09:01:33 +0100

Hi,

>>>4976 also talks about receiving an _AUTH_ request over a mutually authenticated TLS connection, in which case the 
>>>TLS _server_ compares the client cert against the from-path.
>>

Ok.

But, regarding the From-Path issue, do you share my understanding (based on the text above)?

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Thu, 25 Mar 2010 10:58:40 -0700

> But, regarding the From-Path issue, do you share my understanding (based on the text above)?

I think so, but let me restate to make sure I understand your intent correctly: When performing mutual authentication between MSRP relays, the TLS server authenticates the TLS client by comparing the client certificate against the first URI in the From-Path header field of the first MSRP request it received.

I'm starting to think we need am MSRP TLS clarification draft separate from the ACM and session-match drafts.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Mar 2010 20:39:21 +0100

Hi,

>I think so, but let me restate to make sure I understand your intent correctly: When performing mutual authentication between MSRP relays, the TLS server 
>authenticates the TLS client by comparing the client certificate against the first URI in the From-Path header field of the first MSRP request it received.

That is my understanding, yes.

Adam, are you ok with that explanation also (and, the modifications I suggested based on your other comments)?

>I'm starting to think we need am MSRP TLS clarification draft separate from the ACM and session-match drafts.

I have nothing against that, but I don't think that should stop us from moving ACM and sessmatch forward :)

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Thu, 25 Mar 2010 13:29:53 -0700

> I have nothing against that, but I don't think that should stop us from moving ACM and sessmatch forward :)

Agreed. That was an off-hand comment that has nothing to do with ACM and sessmatch, even if we do it.