Subject: RE: Publish Draft: draft-srinivas-opes-threats-00.txt

From: <[email-masked]>
Date: Thu, 27 Jun 2002 17:09:36 -0400

Hi,

> This is a reasonable start, and thanks for kicking off this important
> discussion.  I find it very hard to consider the threats without
> understanding the roles of the various participants, and this has
> influenced my comments in a negative way, which I've tried to explain.
> If this were expanded to include more information about 
> roles, purposes,
> and mitigations, it would help to formulate the security architecture.

Thank you for your comments! Re. the description of the roles of the various participants, we would direct your attention to the OPES architecture draft. We felt that, rather than repeating the material from the architeture draft, citing it would be sufficient.

> 
>         Either the application entities, referred to in the 
> preceding text, 
>         may be collocated with either of the two ends of the 
> data stream or 
>         it may be a discrete entity situated elsewhere within 
> the network. 
>         The last scenario comprises a data stream scenario, which is 
>         referred to as Open Pluggable Edge Services (OPES). 
> Several such 
>         provisioning scenarios are described in [OPES-SCENE].  
>          
> I think OPES encompasses all the scenarios.

Yes, we do agree that OPES does encompass all the scenarios referred to in the draft. In other words, the OPES functionality may be located in either a discrete entity [draft-ietf-opes-architecture-00.txt] or it may be collocated in either the data provider or data consumer end. We believe that our document does address both the scenarios though!

>         New functionality when added to a networking 
> architecture invariably 
>         creates new possibilities for tampering with some signaling 
>         communications, as well as user data traffic. In other words, 
>         various forms of protection including physical and/or 
> programmatic 
>         means are lowered, resulting in new security vulnerabilities.
> 
> I don't think that it is obvious that "protection" is 
> "lowered" anytime new functionality is added.

In general, Murphy's law can be appealed to, to make our point! In most cases, more the parts in a system, greater is the chance for something to "break" or equivalently for security to be compromised. Hence the claim.

>         In the traditional non-OPES scenario, the 
> communicating end-points 
>         (the content producer and consumer) have a direct one-to-one 
>         association between them (see Figure 1).
> 
> This seems to ignore the very common traditional scenario that uses a
> surrogate or caching proxy intermediary.  There has been very 
> little discussion
> of the security threats and diminished protection introduced by
> these devices, yet they are essential to timely delivery.

We assumed in our draft, as was discussed and initially concluded on the OPES mailing list, that surrogates or caching proxies were equivalent to OPES intermediaries. So the traditional non-OPES scenario, described in Figure 1, does not hold for the case of Surrogates or caching proxies. However, if surrogates or caching proxies cannot be considered as OPES intermediaries, then additional text will have to be inserted to discuss the related security threats.

>     3.1. OPES device false registration/deregistration 
> 
> The architecture does not define any registration/deregistration
> mechanism, for better or worse.  I agree that there should be one, 
> and of course it should be authenticated.  But with respect to what
> policy?  

We are unclear as to what the implication of your question was? "With respect to what policy" meaning?

> An entity might be fully authenticated and authorized by
> *something*, but it still might be malicious.  So, whose judgment
> should the OPES data processor trust?  I submit that this is the
> question that needs elucidation, wrt to the type of transformation;
> the scenarios document has a good dissection of the possibilities.

The OPES device, as required by RFC3238, needs to be authenticated/authorized by at least one of the application layer end hosts (the producer or consumer). Furthermore, we have assumed that the end hosts are (innately) trustworthy. In other words, the end hosts are not malicious! 

However, if the OPES device is authorized by a malicious or spurious end host (meaning that the end-device hijacks the transformed data and prevents it from being sent to the actual end host), the actual (non-malicious) end host could communicate with the content producer (by some non-OPES means) to indicate that something is wrong! Something along these lines might be included in the draft.

> As for accepting traffic transformed by an "un-"anything intermediary,
> you'd have to detect it before refusing.

Absoutely!

>      3.2. OPES device spoofing 
> 
> I'm confused about this scenario; the device is authenticated and
> authorized, and yet someone can spoof it.  The solution requires
> cryptographic or physical protection of the communication channel, but
> the subsequent text doesn't mention this.

We meant here that a malicious node could falsely authenticate an intermediate device as an OPES device. Thus, the malicious node could hijack the traffic and have it pass through the spurious OPES intermediar! In other words, the malicious node "spoofs" the identity of the genuine OPES intermediary and thus causes damage.

> Wrt to auth(enication,orization) of the callout servers, who 
> is performing
> the check?  The OPES data processor or some endpoints?  I 
> think the OPES
> intermediary should do this, but the endpoints can indicate 
> what policy
> they want enforced.

Agreed! We too felt that the callout server can be authenticated/authorized by the OPES interediary based on a policy recommended by the endpoints.

>      3.3. Malicious node performs a replay attack
> 
> I'm not clear on the problem or its solution.  If you've got 
> a bad OPES
> box, and it is doing something like replaying user requests 
> repeatedly,
> perhaps racking up huge bills for unwanted transformations, you can't
> stop it by using sequence numbers.  It's an auditing issue.  Auditing
> is part of security, certainly, but about all one can do is compare
> logs.

What we were referring to is the following. A malicious node (say, an OPES intermediary) eavesdrops on a prior OPES signaling request and stores it for future use. Then, in a subsequent OPES session, the malicious node relays the stored message and thus compromises the session.
We suggested that, by using sequence numbers, one can detect the occurance of a replay attack and then stop the session (or take other remedial actions).

>      3.4. Re-establishing end-device - OPES device security during failover
> 
> It is completely possible to failover securely from A to B without
> notifying the endpoints.  However, if it was a secure connection and
> a malicious intermediary tries to co-opt it, it should fail.  If it
> doesn't, there wasn't a secure connection in the first place.  

Here, the intent was that when a secure session between the end-device and OPES intermediary A fails, a new connection between the end-device and a new OPES intermediary B will not be automatically secure. The user must set up a secure connection between the end-device and B explicitly.
 
>      3.5. Message Integrity 
> 
> In general, the OPES data processor cannot check the 
> integrity of content
> messages, because of the difficulty of sharing the cryptographic
> information.  Yes, the endpoints can use public key digital 
> signatures,
> and OPES can check, but this is a severe requirement that is unlikely
> to take hold.

Our main objective is to investigate the threats and their possible consequences. If content integrity is considered as important, then we may need to look for ways to realize that.

>      3.6. Data Confidentiality 
> 
> This section refers mysteriously to the transmittal of shared 
> encryption
> keys.  What channel, what keys?

In here, we are considering a scenario whereby the content is encrypted with a shared key owned by the content producer and the consumer. In order for the OPES device to tranform the content, it should have the shared key as well. Therefore, how this shared key is distributed to the OPES device has to be carefully considered such that it will not be compromised.

> The IAB considerations included an item about "end-to-end 
> confidentiality
> compatibility", which we might want to discuss now.  This 
> imposes a signal
> that requires encryption of the messages at each hop.  We 
> need to consider
> whether or not this includes callout servers, how the data gets
> encapsulated in its encryption shielding, whether or not separate keys
> must be used for separate endpoint pairs, etc.

Yes, we agree with your thoughts on this matter. Either a common shared key could be used for all the segments (producer to OPES intermediary, OPES intermediary to call-out server etc.), or a separate shared key could be used for each segment with a corresponding increase in the set-up complexity. 

Furthermore, to ensure data confidentiality, separate sets of keys need to be used for separate endpoint pairs.

> 
>      3.7. Denial-of-Service (DoS)
> 
> I'd thought this would deal with situations where an OPES 
> data processor
> is turned into a DoS component.  An ugly problem to detect and fix.

This is possible, and we could also include this attack scenario into the document. We had considered the case where the DoS attack is launched by a different node and not the opes  intermediary itself.

>      3.8.Authorized entity later repudiates a request 
> 
> This is important for endpoints that authorize OPES services; 
> this ties
> in with audit and accounting logs, their integrity, 
> protection, transmittal,
> etc.

We have no objections to this.

> Hilarie