Re: draft-ietf-simple-msrp-cema-05 WGLC comments - Section 7 (Ben)

On May 15, 2012, at 4:12 AM, Christer Holmberg wrote:

> Hi,
> 
> Reply to Ben's comments on section 7 (Security Considerations).
> 
>> -- 7.1, and general:
>> 
>> I'm still uncomfortable with the language that says (or
>> implies) that CEMA enables e2e security in general. In fact, it 
>> enables it in a some very specific use cases, namely when you have 
>> middleboxes that behave exactly as described in this document--in 
>> particular, when they transparently forward TLS, _and_ where direct 
>> e2e TLS connections are prevented by some aspect of the provider's 
>> architecture (e.g. the middlebox use is required by policy, e2e 
>> connections are prevented by NATs, etc.)
> 
> In my opinion, the text in section 7.1 is quite clear on this: 
> 
> 	"In deployments where Middleboxes are always used, which is the main
> 	use case for the CEMA extension, the CEMA extension increases the
> 	security by enabling the use of end-to-end TLS between the two
> 	endpoints."

Okay, I see that you constrained the benefit to the case where "Middleboxes are always used". The problem I still have is, these middleboxes may or may not choose to allow an e2e security association. And as far as I can tell, without adding some other layer of e2e security, the endpoints have no way of knowing if the SA is e2e or hop-by-hop (and that's really only for the first hop, as the endpoint can't know what a middlebox does for downstream hops.) Since the middleboxes are not standardized devices, we can't even point to normative language indicating that they SHOULD tunnel TLS.

I 'd argue that if an endpoint can't be reasonably sure it has an e2e SA, then it doesn't. And I suspect that, in practice, a lot of these middleboxes are going to be there for reasons other than just firewall and NAT traversal. If any of those reasons require access to cleartext (and they almost certainly will), then the middlebox is never going to just tunnel TLS. 

Keep in mind this draft is about _endpoint_ behavior, and the security considerations are from the endpoint's perspective. I think, from the endpoint's perspective, the assertion that CEMA enables e2e TLS is overstated, unless we are very explicit about what sort of assumptions the endpoint might make. So I'd like to see this change to something to the effect of the following:

"CEMA enables middleboxes to allow end-to-end TLS security considerations in some cases. MIddleboxes may or may not allow end-to-send SAs, as a matter of local policy. Therefore a CEMA endpoint MUST NOT assume that it has an end-to-end SA with it's peer unless it can confirm this using some other mechanism", perhaps with a reference to the section(s) discussing some potential methods for that. 

I think I mentioned that it would be nice to see the security considerations opening with a  discussion of trust implications and what assumptions an endpoint might make. This sort of thing might go there.


> 
> 
> -------------
> 
> 
>> But even then, the fact that the endpoints have no way of telling 
>> whether the middlebox actually tunnels TLS vs acting as a TLS b2bua 
>> makes me very skeptical of any claim of enabling e2e protection. I 
>> think  that, if the endpoints can't _prove_ the protection is e2e, 
>> then it has to assume that it is _not_ e2e.
> 
> True end-to-end security requires a key management protocol that does not depend on secure signalling, e.g. name based certificates. 

I do not understand that assertion. Why would a key management protocol that requires trusted signaling not be end to end, assuming you have trusted signaling? I understand that you pretty much can't have trusted signaling over the sorts of middleboxes CEMA contemplates, but that's not the same thing.

> 
> Whether such a protocol (together with the necessary infrastructure) is available or not is a deployment issue, and is independent of CEMA.
> 
> The statement that CEMA enables end-to-end security is true under following conditions:
> 
> (1) The deployment is such that it requires the use of Middleboxes; and
> 
> (2) A key management protocol is available that does not depend on 
>    secure signalling.
> 
> In my opinion the text is quite clear on the above.

I don't think it is unclear per se, I just don't think it provides enough discussion for (potentially naive) implementers to fully understand the implications of their choices. So, here's some suggested text:

"The purpose of CEMA is to enable communication over middleboxes. These middleboxes are commonly deployed by SIP network operators, who also commonly deploy firewall and routing policies that prevent media sessions from working unless they traverse the middleboxes. Endpoints that are not willing to trust such middleboxes SHOULD NOT enable CEMA. 

CEMA makes it possible for middleboxes to tunnel TLS to allow end-to-end security associations between endpoints. This is an improvement over the status quo, since without CEMA, the middleboxes would be forced to both read and modify the cleartext MSRP messages, which would make end-to-end confidentiality and integrity protection impossible. However, middleboxes may still choose to act as TLS B2BUAs, which would be undetected by endpoints unless they use some additional mechanism to authenticate that the TLS SA is in fact end-to-end. Endpoints enabling CEMA MUST NOT assume end-to-end TLS protection of an MSRP without such a mechanism. 

Since the middleboxes described in this draft operate by modifying the contents of SDP offers and answers, mechanisms that depend on end-to-end integrity or confidentiality protection of the SIP message payloads will fail. Therefore, endpoints using CEMA need to use a key management or authentication mechanisms that does not require end-to-end trust in the SIP signaling channel. Section [xxx] discusses some such mechanisms. 

<indented>
These are issues are not specific to  CEMA, as the same issues occur when using middleboxes without CEMA. Security mechanisms that provide end-to-end protection of SIP message payloads, such as RFC 4744 [informational reference], will detect the fact that an intermediary modified the payloads. Such mechanisms cannot distinguish between an authorized middlebox and a man-in-the-middle attacker. But since CEMA is specifically intended for use with middleboxes, CEMA implementors should carefully consider the trust implications.
</indented> "  


> 
> 
> -------------
> 
> 
>> -- 7.1, last sentence "If the key management depends on trust in the 
>> signaling plane, the Middlebox is by definition trusted, but the 
>> security is still increased as the cleartext is not available in the 
>> Middlebox."
>> 
>> The first half of that sentence needs elaboration, particular in light 
>> of the other assertions that fingerprint based authentication implies 
>> trust in the signaling plane. Are you talking about trust that the 
>> signaling plane authentication of endpoints is in fact true, or trust 
>> in whether the offer/answer has not been tampered with? It seems to me 
>> that something like RFC4474 can use fingerprint authentication of the 
>> media session with at least minimal trust in middleboxes.
>> 
>> I think it would help to open the security considerations section with 
>> a subsection that explains the trust assumptions for CEMA in more 
>> detail
> 
> It's actually both. If self-signed certificates is to be considered secure then both endpoints and the intermediate nodes must be authenticated and the fingerprint attribute cannot be tampered with by the intermediaries.

The sentence in question starts with "If key management depends on trust in the signaling plane...". But aren't we saying that the key management mechanism used with CEMA _cannot_ depend on trust in the signaling plane? Or by "trust in the signaling plane" do we mean trusting that the middleboxes will only use their powers for good?

There's probably a place for a level of trust that means something like "I trust that only the phone company and maybe the government can see my cleartext messages", for which just using SIPS may be good enough. That's not that different from the current status with SMS/MMS. But it's _very_ different than an assumption of end-to-end message confidentiality. 



> 
> I do agree that, if RFC 4474 is used, then it is not necessary to trust all the intermediate nodes. However, RFC 4474 would not work well together with media anchoring since the entire SIP body is signed, which means that the c/m lines can't be modified. 

Right. I guess the point is (and I hope my proposed text above covers it), is that, in order to assume e2e TLS protection of the MSRP channel in the presence of middleboxes, you have to use an authentication/key-binding mechanism that doesn't break when the middleboxes tamper with the SDP.

> 
> AFAIK, it is not possible to sign certain parts of the SIP body (e.g. only the fingerprint attribute).

AFAIK, you are correct. That is, we don't have a standardized mechanisms for it.
> -------------
> 
> 
>> -- 7.2: "For backward compatibility, a CEMA-enabled MSRP endpoint MUST 
>> implement TLS."
>> 
>> Why is this for "backwards compatibility"? Seems like you want it 
>> whether or not you care about backwards compatibility.
> 
> Section 14.2 in RFC 4975 (MSRP) states that "MSRP elements MUST implement TLS".
> 
> Having said that, I agree with you that the text could be modified.
> 
> I suggest:
> 
> 	"According to RFC 4975, MSRP endpoints are required to support TLS. This also apply to CEMA-enabled endpoints." 
> 

WFM.

> 
> -------------
> 
> 
>> -- 7.4, 2nd paragraph: "This can e.g. be hop-by-hop cryptographic 
>> protection or cryptographic access protection combined with physical 
>> trust in other parts of the signaling plane."
>> 
>> I'm not sure what you intend by this sentence. Should I infer that a 
>> hard shell soft center model of protection is good enough? What are 
>> the trust implications for hop by hop? What do you mean by access 
>> protection?
>> 
>> It seems like the real point is you _can't_ use end to end integrity 
>> protection for signaling across middleboxes, with or without CEMA.
> 
> If you want to use fingerprint based authentication then you have to somehow ensure yourself that the fingerprint attributes won't be manipulated by intermediate nodes. 
> 
> That can be accomplished in many different ways, but it is completely independent of the use of CEMA. I therefore think the current level of detail is sufficient.
> 
> Access protection means that the signalling from the user to the first SIP Proxy is protected by TLS (i.e. SIPS), IPsec, or by some other means (e.g., encryption and integrity protection of the air interface in 3G/4G). 
> 
> The trust implications of using hop-by-hop security and fingerprint based authentication are as explained in RFC 5763 (see especially Section 8.2).

My objection was specifically to the idea of "physical trust". If that means something like IPSec, then great. If it means I trust that that the network is in a locked room, then any such assertion needs lots of disclaimers that this is not the general case.


> 
> 
> -------------
> 
> 
>> -- 7.4, 3rd and 4th paragraphs:
>> 
>> How can a user determine which case (e2e TLS vs TLS b2bua) is in 
>> effect, and decide whether to allow it?
> 
> If fingerprint based authentication is used, then it is not possible for the user to determine whether the TLS connection is end-to-end or terminated by a B2BUA.
> 
> If this is required by the user then he has to use some other key management protocol.
> 
> Whether this is possible or not is an implementation/deployment issue.

I hope my comment here will become moot based on the larger discussion of the first two items.


> 
> 
> -------------
> 
> 
>> -- 7.4, last paragraph: "But this is not an issue as the signaling 
>> network is considered trusted by the endpoint (a requirement to use 
>> fingerprint based authentication)."
>> 
>> I don't think I accept that statement in general. (see previous 
>> comment for 7.1 about trust in middleboxes)
> 
> See my reply on your comment on section 7.1. 
> 
> The statement is true for fingerprint based authentication without RFC 4474. If RFC 4474 is used then you only need to trust parts of the signaling network, but you won't be able to do media anchoring (the main purpose of CEMA). 

For a fingerprint based mechanism without integrity protection, I agree with you. But the sentence states it as if were true in general. In any case, it seems like this section says something like "You can't do fingerprint based key management unless you trust the network, since you can't integrity protect the SDP across middleboxes. But that's not a problem, because you if you wanted to do fingerprints, you must already trust the network." If that's what you mean, then it's a circular argument.

I _think_ the point is really along the lines of "Even though you can't integrity-protect your fingerprints across middleboxes, the fingerprint across may be better than nothing. If you are willing to trust the (possibly both) service providers, you can reasonably be sure no malicious third parties can mess with your fingerprints by using SIPS."

But that's still very different from e2e media protection.

(Your previous mention of RFC5763 might be relevant here, as I think we're trying to say the same thing it did).

> 
> 
> -------------
> 
> 
>> I think the way this is being presented involves some 
>> dog-wagging. It's not so much that the end user wants to 
>> trust the middleboxes as much as it is an operator that won't 
>> let calls complete if they don't anchor on a middlebox. This 
>> is a fairly coercive definition of trust.
> 
> I don't think you ever *want* to trust anyone. 
> 
> The user has to make a decision whether he thinks the benefits 
> of using the service outweighs the associated risk. If the 
> answer is yes, then he trusts the service provider.

I doubt the average user is aware he needs to make such a decision, much less competent to make it. And in many cases, the user may have no choice in the matter, other than to carefully watch what they say over the media channel. (But I hope this concern is covered in my proposed text early in this email.)

The bigger issue is that the user may not have enough information to make informed trust decisions. The user does not know if middleboxes are going to be used or not, or what policies the middleboxes might have. If he cares, he needs to take the aforementioned steps to ensure (or at least detect the lack of) e2e media protection.

That all being said, I would be okay with this section if it clarified what it means to trust the network. I think in this case, it means the user understands that the service provider has access to and can modify the cleartext of his messages, and trusts the provider not to do anything inappropriate. This may be sufficient for normal, day-to-day communication, but might not be sufficient for banking, medical information, trade secrets, etc.

> 
> In some cases it is not possible to setup a call without inserting a 
> Middlebox (e.g. IPv4 user to IPv6 user). One could try to determine when 
> an end-to-end TCP connection can be established but that is often complex.
> 

There are a number of approaches to that other than using middleboxes. If a session can't be set up without a middlebox, it's because the service provider chose to make it so. The real problem with middleboxes is that they are, or at least try to be, invisible to endpoints. 

> 
> -------------
> 
> 
>> -- 7.5, 2nd to last paragraph: "Alternate key distribution 
>> mechanisms...may become ubiquitous enough to solve the key 
>> distribution problem in the future."
>> 
>> Do we believe RFC 6072 is that ubiquitous _now_? This seems 
>> like a dodge to avoid a normative downref. If so, lets not 
>> hide it behind "ubiquity". Perhaps the text should read "may 
>> become sufficiently standardized..."
> 
> The lack of standards is not always the problem. It's also about deployment.
> 
> So, we could say: "sufficiently standardized and deployed"

I'm not sure you get my point. Do you believe RFC 6072 is sufficiently deployed? More deployed than the other choices?

> 
> 
> -------------
> 
> 
>> -- 7.5, last paragraph: "Some of these options require 
>> trusting the service provider, but those issues are beyond 
>> the scope of this document."
>> 
>> Isn't this entire document predicated on the idea of 
>> endpoints trusting the provider?
> 
> Whether the service provider needs to be trusted or not depends on the 
> chosen key management, and this is entirely independent of CEMA.

Not really, since you use CEMA because you expect middleboxes, and the presence of middleboxes constrains our key-management mechanisms to things that don't use e2e integrity protection of the SDP. A lot of this discussion so far has been about that very point.


> 
> 
> -------------
> 
> 
>> -- 7.7, 3rd paragraph: "Signaling over a local or closed 
>> network MAY be trusted."
>> 
>> That's a broad statement to make without a considerably 
>> longer and more nuanced discussion. As it stands, it seems to 
>> encourage a hard-shell-gooey-center approach to security.
> 
> Yes, you're right that this is an imprecise statement. 
> 
> But I don't understand why we should describe it further in 
> this document. Again, the selection of key management protocol 
> and the restrictions it imposes is independent of CEMA.

A normative "MAY" implies some degree of approval. Assuming a network is secure because it's somehow locked away from the rest of the world is dangerous. Disgruntled employees with "secure" network access are the source of a great many security failures. We may recognize that many carriers and SDOs choose to depend on physical security alone. That doesn't mean we should suggest it.


> 
> 
> -------------
> 
> 
>> -- 7.7, 4th paragraph: "It should however be noted that using 
>> fingerprint based authentication over an insecure network 
>> increases the security compared to unencrypted MSRP as this 
>> makes it harder to perform an man-in-the-middle attack."
>> 
>> You don't even need a MiTM attack if MSRP is used without protection
> 
> I disagree. 
> 
> Even if unencrypted MSRP is used, the attacker still 
> need to intercept the traffic somehow. This means that you have some level of security (the 
> level depends on the network you're on).

That's not necessarily MiTM. With unprotected MSRP, you are vulnerable to passive attacks as well.

> 
> -------------
> 
> Regards,
> 
> Christer