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

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


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

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

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.


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

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

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. 

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


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


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


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


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


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


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


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


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


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


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

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.


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


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


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

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


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

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


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


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

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

Regards,

Christer