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

From: Adam Roach <[email-masked]>
Date: Tue, 06 Apr 2010 13:26:32 -0500

Sorry it took me so long to get back to this.

On 3/24/10 12:55, Mar 24, Christer Holmberg wrote:
> 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):
>>
>>
>>       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.
>>      
> 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?
>    

A little bit. Allow me to try to clarify it further.

    MSRP entities do not use the MSRP URL domain part to perform session
    matching. If intermediaries modify the "a=path" attribute in the
    SDP, but do not modify the corresponding information in the
    associated MSRP messages, then the endpoints can determine that such
    modifications have been performed by comparing the domain
    information in the SDP with the domain information in the MSRP messages.

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

Perhaps a new sentence at the end of the paragraph. "This mismatch would 
cause the MSRP session setup to fail."

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 06 Apr 2010 13:29:06 -0500

On 3/25/10 14:39, Mar 25, Christer Holmberg wrote:
>>>>>>> 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?
>>>>>>>                
>>>>>> >>>>>
>>>>>> >>>>>  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?
>>>>>> >>>>>
>>>>>> >>>>>  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.
>>>>>>              
>>>>> >>>>
>>>>> >>>>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?
>>>>>            
>>>> >>>
>>>> >>>It can be, when you have more than one relay on behalf of the same endpoint.
>>>>          
>>> >>
>>> >>Ok.
>>> >>
>>> >>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.
>>      
> That is my understanding, yes.
>
> Adam, are you ok with that explanation also?
>    

Mostly. Based on Ben's comments, my understanding is that the connection 
will actually be verified using the To-Path (by the TLS client) any 
using the From-Path (by the TLS server). Perhaps "...and use the To-Path 
and From-Path hosts for certificate matching purposes."

/a

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Apr 2010 23:08:12 +0200

Hi Adam,

>Sorry it took me so long to get back to this.

No problem - I know you're busy with the stuff going on in MARTINI etc :)

Anyway, I am ok with your text suggestions below, and will incorporate them in the next version of the draft.

Thanks!

Regards,

Christer

Hi,

Is  that more clear?

MSRP entities do not use the MSRP URL domain part to perform session matching. If intermediaries modify the "a=path" attribute in the SDP, but do not modify the corresponding information in the associated MSRP messages, then the endpoints can determine that such modifications have been performed by comparing the domain information in the SDP with the domain information in the MSRP messages.

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

Perhaps a new sentence at the end of the paragraph. "This mismatch would cause the MSRP session setup to fail."

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2010 15:07:36 +0200

Hi, 

>Mostly. Based on Ben's comments, my understanding is that the 
>connection will actually be verified using the To-Path (by 
>the TLS client) any using the From-Path (by the TLS server). 
>Perhaps "...and use the To-Path and From-Path hosts for 
>certificate matching purposes."

I will add that.

Thanks!

Regards,

Christer