Subject: [Simple] MSRP ACM and TLS

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 2 Apr 2009 23:07:11 -0400

[This email is just thinking out loud to try to understand the issue - no matter what we'll need to get some guidance from a security expert (ekr?)]

The subject has been raised that an ACM model impacts the ability to do TLS using the SAN (subjectAltName) of a public server host.  I believe this was based on the idea that ACM would let a middlebox not only change the c/m lines, but in fact have it replace the host portion of the top path attribute, right?  In such a case, the original host portion would be lost.

If I understand the model 4975/4976 had in mind, as a UA when you're given an MSRPS URI to use, you connect using TLS and verify the SAN of the far-end matches the hostname portion of the MSRPS URI you were given in SDP.  When you offer a MSRPS URI, the hostname you put in the URI must likewise match the SAN in your cert.  As a Relay, when you're told to send an MSRP message to a MSRPS URI next-hop, you do a similar matching check to that next-hop, etc. 

What's not clear to me is what actual security binding property is achieved.  For example, if I send a SIP Invite to sip:[email-masked], and the SDP answer has an MSRPS URI of "msrps://foobar.com:1234/pwned4ever", then does verifying that my MSRP connection to foobar.com really is to foobar.com mean anything?  Is there some language in the RFC's that say the SIP target AoR's domain has to match the SAN as well? (I can't find it)  Sans that (ooh, a pun), then you're already believing the SIP layer isn't lying to you - because anyone can just make a box be a b2bua-sip + b2bua-msrp and give you a cert with a SAN of whatever, so long as the MSRPS URI matches it and you have a common CA. (yes it would have to be a cert with a common CA, but all the common CA says is "that sure is foobar.com", though at least then you'd have non-reputable record of it)

Another good property is your UA client can show you that it's foobar.com, or prompt you for confirmation that's ok.  And that's a good property to have.  You don't actually need the msrps URI to match anything to do that, of course.  But it's good to have a match solely because at least it keeps just any old MITM from intercepting MSRP connections - it would have to be more than just a snooper, it would have to be a malicious SIP and MSRP MITM.  

So, in summary, I think the property we'd like to keep is that if the SDP layer said foobar.com, that the MSRP layer really connects to foobar.com, whatever that may or may not imply.  With ACM, if foobar.com is not left in the path attribute, that can't be achieved without some other means.

The options as I see them are:
1) Use the fingerprint attribute, even for public SANs.  A server with a real SAN can create a fingerprint just as any, and send that in its SDP.  The problem with that is a 4976bis-Relay can't be asked for its fingerprint, nor be told to check one against a next-hop, afaict, without some real changes. (right?)  That's really an issue with using fingerprints period with Relays.  If we were to add such support for Relays, however, it would provide the ability to connect to self-signed certs on UA's in general, even without ACM.
2) Do ACM differently to begin with - for example by having middleboxes insert (instead of modify) a path attribute which has the same cookie portion, but with a URI param that means something like "for the TCP connection but not for the to/from-path URI".  That way the original ones are left intact and used for cert matching, while the inserted one is used for connection ip/port.  That would still require changes on Relays, but a smaller change I guess.  Would that work?

-hadriel

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 3 Apr 2009 10:16:08 +0300

On Friday 03 April 2009 06:07:11 ext Hadriel Kaplan wrote:
> [This email is just thinking out loud to try to understand the issue - no
> matter what we'll need to get some guidance from a security expert (ekr?)]

As was noted in my earlier & defunct COMEDIA-MSRP draft, COMEDIA-TLS can 
anyway not work, at least not end-to-end through a SBC.

COMEDIA-TLS ties the direction of TLS to the direction of TCP. Practically, he 
who sends the TCP/SYN sends the TLS/ClientHello, and he who sends the TCP/SYN-
ACK sends the TLS/ServerHello. In my understanding, with an SBC in the middle, 
both endpoints are COMEDIA "active", meaning they both sends TCP/SYN, and both 
sends ClientHello. *caboom*

> If I understand the model 4975/4976 had in mind, as a UA when you're given
> an MSRPS URI to use, you connect using TLS and verify the SAN of the
> far-end matches the hostname portion of the MSRPS URI you were given in
> SDP. When you offer a MSRPS URI, the hostname you put in the URI must
> likewise match the SAN in your cert.  As a Relay, when you're told to send
> an MSRP message to a MSRPS URI next-hop, you do a similar matching check to
> that next-hop, etc. 

My understanding is the opposite - hop-by-hop TLS. Or rather, every body does 
hop-by-hop, clients and relays alike. In fact, I don't see how you can do end-
to-end TLS (without tunneling).

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 3 Apr 2009 12:07:18 +0200

Hi, 

>>[This email is just thinking out loud to try to understand the issue - 
>>no matter what we'll need to get some guidance from a security expert 
>>(ekr?)]
> 
>As was noted in my earlier & defunct COMEDIA-MSRP draft, 
>COMEDIA-TLS can anyway not work, at least not end-to-end 
>through a SBC.
> 
>COMEDIA-TLS ties the direction of TLS to the direction of 
>TCP. Practically, he who sends the TCP/SYN sends the 
>TLS/ClientHello, and he who sends the TCP/SYN- ACK sends the 
>TLS/ServerHello. In my understanding, with an SBC in the 
>middle, both endpoints are COMEDIA "active", meaning they 
>both sends TCP/SYN, and both sends ClientHello. *caboom*

True. And, if both endpoints are "active" you of course may (depending on the TCP stacks in the endpoints) have an end-to-end issue even without TLS, for any protocol which uses TCP.

To deal with this, SBCs sometimes act as TCP B2BUAs, and in the TLS case the SBC would act as a TLS B2BUA (which it may have to do anyway, depending on what functions it performs).

Many SBCs (not only Hadriel's :) already support this, since it is not MSRP specific.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Fri, 3 Apr 2009 15:54:30 -0500

On Apr 2, 2009, at 10:07 PM, Hadriel Kaplan wrote:

> [This email is just thinking out loud to try to understand the issue  
> - no matter what we'll need to get some guidance from a security  
> expert (ekr?)]
>
> The subject has been raised that an ACM model impacts the ability to  
> do TLS using the SAN (subjectAltName) of a public server host.  I  
> believe this was based on the idea that ACM would let a middlebox  
> not only change the c/m lines, but in fact have it replace the host  
> portion of the top path attribute, right?  In such a case, the  
> original host portion would be lost.

That was the proposal in the room in SF. It's not yet in the ACM draft.

>
>
> If I understand the model 4975/4976 had in mind, as a UA when you're  
> given an MSRPS URI to use, you connect using TLS and verify the SAN  
> of the far-end matches the hostname portion of the MSRPS URI you  
> were given in SDP.  When you offer a MSRPS URI, the hostname you put  
> in the URI must likewise match the SAN in your cert.  As a Relay,  
> when you're told to send an MSRP message to a MSRPS URI next-hop,  
> you do a similar matching check to that next-hop, etc.
>
> What's not clear to me is what actual security binding property is  
> achieved.  For example, if I send a SIP Invite to  
> sip:[email-masked], and the SDP answer has an MSRPS URI of "msrps:// 
> foobar.com:1234/pwned4ever", then does verifying that my MSRP  
> connection to foobar.com really is to foobar.com mean anything?  Is  
> there some language in the RFC's that say the SIP target AoR's  
> domain has to match the SAN as well? (I can't find it)  Sans that  
> (ooh, a pun), then you're already believing the SIP layer isn't  
> lying to you - because anyone can just make a box be a b2bua-sip +  
> b2bua-msrp and give you a cert with a SAN of whatever, so long as  
> the MSRPS URI matches it and you have a common CA. (yes it would  
> have to be a cert with a common CA, but all the common CA says is  
> "that sure is foobar.com", though at least then you'd have non- 
> reputable record of it)

MSRP security is very much based on the assumption that the signaling  
path is secure. This is discussed in the applicability statement in  
section 3. So in your example, you know that foobar.com is the right  
party because the signaling channel told you it was.

>
>
> Another good property is your UA client can show you that it's  
> foobar.com, or prompt you for confirmation that's ok.  And that's a  
> good property to have.  You don't actually need the msrps URI to  
> match anything to do that, of course.  But it's good to have a match  
> solely because at least it keeps just any old MITM from intercepting  
> MSRP connections - it would have to be more than just a snooper, it  
> would have to be a malicious SIP and MSRP MITM.
>
> So, in summary, I think the property we'd like to keep is that if  
> the SDP layer said foobar.com, that the MSRP layer really connects  
> to foobar.com, whatever that may or may not imply.  With ACM, if  
> foobar.com is not left in the path attribute, that can't be achieved  
> without some other means.

I agree that the best we can hope for is that we really connect to the  
device listed in the SDP.

> 1) Use the fingerprint attribute, even for public SANs.  A server  
> with a real SAN can create a fingerprint just as any, and send that  
> in its SDP.  The problem with that is a 4976bis-Relay can't be asked  
> for its fingerprint, nor be told to check one against a next-hop,  
> afaict, without some real changes. (right?)  That's really an issue  
> with using fingerprints period with Relays.  If we were to add such  
> support for Relays, however, it would provide the ability to connect  
> to self-signed certs on UA's in general, even without ACM.

That's interesting. As you say, it would require some non-trivial  
changes to RFC 4976. I agree this sort of thing would need careful  
security review.

(Elephant in room: We're still arguing over whether middleboxes can  
meddle with SDP payloads in the other working groups. Until that is  
resolved, we can't even really trust the fingerprints.)

>
> 2) Do ACM differently to begin with - for example by having  
> middleboxes insert (instead of modify) a path attribute which has  
> the same cookie portion, but with a URI param that means something  
> like "for the TCP connection but not for the to/from-path URI".   
> That way the original ones are left intact and used for cert  
> matching, while the inserted one is used for connection ip/port.   
> That would still require changes on Relays, but a smaller change I  
> guess.  Would that work?

I think it would require non-trivial changes to both RFC 4975 and  
4976. (I think it would be cleaner to find a way to markup a single  
URI to carry both addressing and cert matching data, so a device  
doesn't have to guess which URI is for which purpose.  But it is the  
same thing in principle.)

I have not yet formed an opinion as to whether that level of change is  
reasonable. But if we did go that route, I wonder if this would not  
have architectural implications at a greater-than-just-MSRP scope.

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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 3 Apr 2009 15:59:25 -0500

On Apr 3, 2009, at 5:07 AM, Christer Holmberg wrote:

> True. And, if both endpoints are "active" you of course may  
> (depending on the TCP stacks in the endpoints) have an end-to-end  
> issue even without TLS, for any protocol which uses TCP.
>
> To deal with this, SBCs sometimes act as TCP B2BUAs, and in the TLS  
> case the SBC would act as a TLS B2BUA (which it may have to do  
> anyway, depending on what functions it performs).

Note that the TLS name matching issue (which I attempted to describe  
in a separate email), should not be a problem if the SBC actively  
terminates TLS for both legs, assuming that the rewritten URIs match  
the certificates the SBC presents   in each direction.

There is a risk, though, of giving endpoints a good-faith belief that  
they have achieved an end-to-end TLS association when they have in  
fact not done so.

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 3 Apr 2009 23:41:05 +0200

Hi, 

>>> As was noted in my earlier & defunct COMEDIA-MSRP draft, COMEDIA-TLS 
>>> can anyway not work, at least not end-to-end through a SBC.
>>>
>>> COMEDIA-TLS ties the direction of TLS to the direction of TCP. 
>>> Practically, he who sends the TCP/SYN sends the TLS/ClientHello, and 
>>> he who sends the TCP/SYN- ACK sends the TLS/ServerHello. In my 
>>> understanding, with an SBC in the middle, both endpoints are COMEDIA 
>>> "active", meaning they both sends TCP/SYN, and both sends 
>>> ClientHello. *caboom*
>>
>> True. And, if both endpoints are "active" you of course may (depending 
>> on the TCP stacks in the endpoints) have an end-to-end issue even 
>> without TLS, for any protocol which uses TCP.
>>
>> case the SBC would act as a TLS B2BUA (which it may have to do anyway, 
>> depending on what functions it performs).
>
>Note that the TLS name matching issue (which I attempted to describe in a separate email), should not be a problem if the 
>SBC actively terminates TLS for both legs, assuming that the rewritten URIs match  

Correct. And based on Remii's e-mail I think we can assume that will happen quite often.

>There is a risk, though, of giving endpoints a good-faith belief that they have achieved an end-to-end TLS association 
>when they have in fact not done so.

I think that is the reality, and it is not specific to MSRP. People will have to trust the intermediates. 

Because, couldn't the endpoints have that good-faith belief even for the SIP signalling, for which you won't have an end-to-end TLS association either?

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 4 Apr 2009 00:54:13 +0200

Hi, 

>> believe this was based on the idea that ACM would let a middlebox not

>> only change the c/m lines, but in fact have it replace the host 

It would need to be added. And, even without TLS, that is needed in
order to make the propsed session mapping change in 4975 to work.

>>given an MSRPS URI to use, you connect using TLS and verify the SAN of

>>the far-end matches the hostname portion of the MSRPS URI you were 
>>given in SDP.  When you offer a MSRPS URI, the hostname you put in the

>>URI must likewise match the SAN in your cert.  As a Relay, when you're

>>told to send an MSRP message to a MSRPS URI next-hop, you do a similar

>>matching check to that next-hop, etc.
>>
>>achieved.  For example, if I send a SIP Invite to sip:[email-masked], 
>>and the SDP answer has an MSRPS URI of "msrps:// 
>>there some language in the RFC's that say the SIP target AoR's domain 
>>has to match the SAN as well? (I can't find it)  Sans that (ooh, a 
>>pun), then you're already believing the SIP layer isn't lying to you -

>>because anyone can just make a box be a b2bua-sip + b2bua-msrp and 
>>give you a cert with a SAN of whatever, so long as the MSRPS URI 
>>matches it and you have a common CA. (yes it would have to be a cert 
>>with a common CA, but all the common CA says is "that sure is 
>>foobar.com", though at least then you'd have non- reputable record of 
>>it)
>
>
path is secure. This is discussed in the 
>applicability statement in section 3. So in your example, you know that
foobar.com is the right party because the 
>signaling channel told you it was.

I guess that "Signaling path is secure" would also assume that any
possible intermediate in the signalling path is trusted?

>>good property to have.  You don't actually need the msrps URI to match

>>anything to do that, of course.  But it's good to have a match solely 
>>because at least it keeps just any old MITM from intercepting MSRP 
>>connections - it would have to be more than just a snooper, it would 
>>have to be a malicious SIP and MSRP MITM.
>>
>>So, in summary, I think the property we'd like to keep is that if the 
>>SDP layer said foobar.com, that the MSRP layer really connects to 
>>foobar.com, whatever that may or may not imply.  With ACM, if 
>same thing in principle.)

I think I proposed something similar at one point. But, a 4975 endpoint
would of course have to understand the new markup.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 4 Apr 2009 00:51:59 -0400

> -----Original Message-----
> From: Rémi Denis-Courmont [mailto:[email-masked]]
> Sent: Friday, April 03, 2009 3:16 AM
> 
> Practically, he

Good point.  It seems to work right now, but that's with the SBC not setting both to active - the use cases of comedia-TLS we see in use right now are mostly BFCP, afaict, and the SBC has an unencumbered path to the conference server. (the server is in a private network, but the SBC has an interface in that private network, effectively bypassing one NAT side)  So it's just setting the direction such that the endpoint is always establishing the TCP connection to the SBC, which relays it to the conference server which has the cert.

I don't think I've ever seen endpoint-NAT-SBC-NAT-endpoint by TCP-splicing using comedia-TLS, because the endpoints don't seem to have certs (even self-signed ones).  How was TLS going to be done end-to-end with TURN-tcp?

-hadriel

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 6 Apr 2009 09:31:43 +0300

On Saturday 04 April 2009 07:51:59 ext Hadriel Kaplan wrote:
> I don't think I've ever seen endpoint-NAT-SBC-NAT-endpoint by TCP-splicing
> using comedia-TLS, because the endpoints don't seem to have certs (even
> self-signed ones).

> How was TLS going to be done end-to-end with TURN-tcp?

My understanding is that normal COMEDIA negotiation takes place then, since 
the TURN server can provide a virtual listening socket to the TURN client.