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

[Christer Holmberg <[e-mail]>]

Hi,

>>> -- 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 am happy to add text, as long as it doesn't give the impression that CEMA somehow lowers
security. An MSRP endpoint - CEMA enabled or not - should never assume that it has an end-to-end SA
 with it's peer unless it can confirm this using some other mechanism.

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

How would it be any different from legacy, non-CEMA, MSRP?

A signalling proxy will always be able to insert a covert middlebox and intercept the traffic as long as the key management technique used depends on trusted signalling.


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


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

Assume fingeprint based key managment. If the signalling is trusted then by definition the fingerprints won't be modified
 along the signalling path. Regardless of whether CEMA is used and middleboxes are inserted, the TLS tunnel has to be
end-to-end or else there will be a certificate mismatch.

OTOH, if the signalling is not trusted and the fingerprints and the rest of the SDP can be modified, then a covert middlebox
that terminates the TLS tunnel can be inserted regardless of whether CEMA is used or not. The only difference between the
CEMA and the non-CEMA case is that in the latter case the middlebox has to modify the URLs in the MSRP messages.

I don't understand what it meant by "proving" that the protection is end-to-end. As long as you rely on secure signalling you (as an end-user) can never verify that the TLS tunnel is end-to-end.


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


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

As you do mention in the last paragraph, these issues are not specific to CEMA-enabled MSRP endpoints. Again, as long as the key exchange
depends on secure signalling (such as fingerprint based certificate verification) it is always possible to insert a middlebox and terminate the
TLS tunnel, regardless of whether the endpoints support CEMA or not.

I don't entirely agree with the final paragraph since I find the usefulness of RFC 4744 slighlty exagerrated. Assume that an MSRP session is
being established from A to B and that AS_A and AS_B are the RFC 4744 Authentication Service for user A and user B, respectively. AS_* and P are SIP proxies.

A <--> P <--> P <--> AS_A <--> P <--> P <--> AS_B <--> P <--> P <--> B

There is no way for user A to know whether the TLS tunnel is really end-to-end since it cannot be certain that any of the proxies in the start/end of the
path hasn't modified the fingerprint and the c and m lines in the offer/answer SDP.

Even if RFC 4744 was extended to allow for signing parts of the SDP I don't think it would greatly improve security. The user would still be
required to trust some of the signalling nodes.


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


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

In my opinion, "trust in the signalling plane" means that the service provider can access the media if it wants to (but no one else) and the
user accepts this. I don't see why this definition would change when CEMA is introduced.

> 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 don't see how this is related to CEMA.

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

Yes.


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


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

It is up to the service provider to make sure the core network is sufficiently protected. This involves securing the physical nodes as well
 as the links between them. How this is accomplished is a deployment issue. You could put the all the nodes in a single locked room or
you have the nodes in separate locked rooms and use IPSec or TLS in between. Physical security is always an issue but it is often not
mentioned.


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


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


I think my answer still holds. The only restriction in the choice of key management protocol is that it must be possible for an intermediate signalling proxy to modify the c/m lines.


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


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

But, isn't the sentence true in general? Currently the only way of integrity protecting fingerprint is via SIPS, RFC 4474, or S/MIME. Both SIPS and RFC 4474
requires that the signalling network is trusted (at least parts of it). End-to-end S/MIME requires client certificates and if you have that you
wouldn't use fingerprints to begin with (or they are still used but they have no purpose).

To me at least, "fingerprint based authentication" without any further precision implies that the signalling network is trusted.


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


>>> 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 the user would be able to control this via his UA. He could configure the UA to only use a specific key management
protocol and reject all others. But of course the service provider could choose to reject such clients.

I think your definition of "trust in the signalling network" sounds good and is reasonable.

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

If the other choices were easier/cheaper than I would assume that the service provider would implement them. If all the service provider
wants is to be able to interecept the traffic, then there are other ways of doing that as well.


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


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

I have no idea of how widely deployed RFC 6072, I don't even know who could provide such information. The current text is based
on feedback and discussions with the security area ADs.



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


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

The only way of integrity protecting the SDP end-to-end that I know of is S/MIME which requires client certificates. But if you have
client certificates then you might as well use them directly in the TLS handshake. See my earlier comments regarding RFC 4474.


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


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

Perhaps we should change the "MAY" to a non-normative "may".


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


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

That's a matter of definition. AFAIK a MitM attack can be both passive and active. What passive really means can also be
debated since basically all attacks requires some sort of conscious act.


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

Regards,

Christer