Subject: [Simple] msrp-acm: TLS interaction

From: Ben Campbell <[email-masked]>
Date: Mon, 23 Feb 2009 10:35:10 -0600

Hi,

One other concern that occurred to me after I sent my recent comments  
is how the C-line connection model interacts with TLS. RFC 4975  
encourages the use of TLS for authenticating the next hop, i.e. an  
MSRP relay, or even the MSRP peer when operating p2p. Sections 14.2  
and 14.4 describe how MSRP ensures the connected device has the  
correct certificate.

How would this work in the SBC/ALG scenario, where an SBC repoints the  
MSRP connection to itself? I think it depends on how the SBC treats  
TCP/TLS based media. If it simply relays the TLS handshake (similarly  
to an HTTPS proxy), then this may be okay. But if it terminates the  
TLS handshake itself, then things break.

BTW, I think this concern also applies to the approach of having the  
SBC rewrite the path attribute instead of the C-line that I mentioned  
in a separate thread.

Thanks!

Ben.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 23 Feb 2009 12:38:35 -0500

Presumably it would use RFC 4572, Comedia for TLS.

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ben Campbell
> Sent: Monday, February 23, 2009 11:35 AM
> To: Christer Holmberg
> Cc: Simple WG
> Subject: [Simple] msrp-acm: TLS interaction
>
> Hi,
>
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Mon, 23 Feb 2009 12:21:27 -0600

> Presumably it would use RFC 4572, Comedia for TLS.

RFC 4975 already references 4572 for the fingerprint mechanism. My  
concern was not the passing of the fingerprint, but the introduction  
of an intermediary which is not likely to have a matching cert.

This would be okay if the intermediary is transparent to the TLS  
handshake (which I think turn-tcp is, if I understand correctly), but  
not okay if the intermediary participates in the handshake. I don't  
know how SBCs typically handle TLS for media.

In any case, the msrp-acm draft should probably address this.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 23 Feb 2009 13:25:23 -0500

Today SBC's typically are transparent, and let the TLS go end-end.  They have no incentive to do otherwise, except for Lawful-intercept or content-scanning type reasons.

But there is nothing to prevent them from being in the middle of it, since they can replace the fingerprint all day long.

-hadriel

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Monday, February 23, 2009 1:21 PM
> To: Hadriel Kaplan
> Cc: Christer Holmberg; Simple WG
> Subject: Re: [Simple] msrp-acm: TLS interaction
>
>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 23 Feb 2009 13:14:41 -0600

On Feb 23, 2009, at 12:25 PM, Hadriel Kaplan wrote:

>
> Today SBC's typically are transparent, and let the TLS go end-end.   
> They have no incentive to do otherwise, except for Lawful-intercept  
> or content-scanning type reasons.
>
> But there is nothing to prevent them from being in the middle of it,  
> since they can replace the fingerprint all day long.

Ah, everything keeps coming back to that particular elephant (in the  
herd that has occupied the room) ;-)

 From a pragmatic perspective, I think it would help for the msrp-acm  
draft to capture this discussion in some form.

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 24 Feb 2009 12:44:19 +0100

Hi,

I think we can add some text sayin that an SBC which performes "TCP/IP
level actions", e.g. NAT traversal, gating, bandwidth policing etc, can
be TLS transparent, while an SBC which performs LI, content screening
etc would either have to reject the TLS usage, OR act as a TLS B2BUA.

Regards,

Christer 

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Monday, February 23, 2009 9:15 PM
To: Hadriel Kaplan
Cc: Christer Holmberg; Simple WG
Subject: Re: [Simple] msrp-acm: TLS interaction

On Feb 23, 2009, at 12:25 PM, Hadriel Kaplan wrote:

> They have no incentive to do otherwise, except for Lawful-intercept or

> content-scanning type reasons.
>

>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>> Behalf Of Ben Campbell
>>>> One other concern that occurred to me after I sent my recent 
>>>> comments is how the C-line connection model interacts with TLS. RFC

>>>> 4975 encourages the use of TLS for authenticating the next hop, 
>>>> i.e. an MSRP relay, or even the MSRP peer when operating p2p. 
>>>> Sections 14.2 and 14.4 describe how MSRP ensures the connected 
>>>> device has the correct certificate.
>>>>
>>>> How would this work in the SBC/ALG scenario, where an SBC repoints 
>>>> the MSRP connection to itself? I think it depends on how the SBC 
>>>> treats TCP/TLS based media. If it simply relays the TLS handshake 
>>>> (similarly to an HTTPS proxy), then this may be okay. But if it 
>>>> terminates the TLS handshake itself, then things break.
>>>>
>>>> BTW, I think this concern also applies to the approach of having 
>>>> the SBC rewrite the path attribute instead of the C-line that I 
>>>> mentioned in a separate thread.
>>>>
>>>> Thanks!
>>>>
>>>> Ben.
>>>>
>>>>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 24 Feb 2009 08:31:10 -0600

> etc would either have to reject the TLS usage, OR act as a TLS B2BUA.

I suggest generalizing this, and saying that it applies to TCP level  
intermediary in the media path. Also, in the case of acting as a TLS  
B2BUA, it's worth mentioning that doing this may lead the users to  
believe they have an e2e secure channel when in fact they do not. It  
would be preferable to reject the TLS usage rather than misinform the  
users about the security properties of their session.

>> or

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 24 Feb 2009 21:56:28 +0100

Hi, 

>>level actions", e.g. NAT traversal, gating, bandwidth policing etc, 
>>can be TLS transparent, while an SBC which performs LI, content 
>>screening etc would either have to reject the TLS usage, OR act as a 
>>TLS B2BUA.
>
intermediary in the media path.

Sure, we can do that.

>Also, in the case of acting as a TLS B2BUA, it's worth mentioning that
doing this may lead the users to believe they have an e2e secure channel
when in fact they do not.

Yes.

>It would be preferable to reject the TLS usage rather than misinform
the users about the security properties of their session.

I am not sure we should say so much about the preferred way. First, it
doesn't only affect MSRP. Second, at the end of the day I assume it's
going to be based on operator policy etc whether TLS is rejected or not,
no matter what we write. But, I do think we should mention the fact that
a TLS B2BUA leads users to believe that they have an e2e secure channel,
to make "policy makers" aware of it.

Regards,

Christer