Subject: Some comments on draft-ietf-opes-threats-00

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 25 Oct 2002 11:05:25 -0700

a)I propose a little bit of rewording on this paragraph

   "These threats affect the quality and integrity of data that the
   applications either produce or consume.  On the other hand, the
   security risks can also be categorized into trust within the system
   (i.e.  OPES service providers) and protection of the system from
   threats imposed by outsiders such as hackers and attackers.  Insiders
   are those parties that are part of the OPES system.  Outsiders are
   those entities that are not participating in the OPES system."

   These threats affect the quality and integrity of data that the
   applications either produce or consume.  -->On the other hand, the
   security risks can also be categorized into those originating  
   inside the system (i.e.  OPES service providers) and those 
   originated by outsiders such as hackers and attackers<--  Insiders
   are those parties that are part of the OPES system.  Outsiders are
   those entities that are not participating in the OPES system.

With the rewording the last 3 sentences  flow better since the inside and
outside 
words are used in the sentence to categorize the threats.

b) Correct if I'm wrong here but it seems to me the (original?) idea of this
document was to document the *additional/specific* security threats the
addtion of an OPES impose. The document as it stands today basically lists
more or less all attacks known to man. 

Take eavesdropping for example (2.1.4). The additional risk IMO is only when
somebody breaks into the OPES system and use that to eavesdrop the traffic.
Otherwise eavesdropping a network was and is always possible. 

Other examples such as a malign device impersonating a callout server seems
a little bit far-fetched since I would assume mutual authentication and the
like would make this a configuration error instead of a threat...oh
well...everything is posssible.

c) "A serious problem is posed by the very fact that the OPES
   architecture is based on widely adopted protocols (HTTP is used as an
   example)."

Is this really a problem? It seems to me it would be problem is it is
(widely deployed + not mature and/or not open), such as some P2P protocols.
Widely deployed alone does not make it a security problem.

---

From: "Oskar Batuner" <[email-masked]>
Date: Fri, 25 Oct 2002 17:03:59 -0400

-----Original Message-----
>From: [email-masked]
[mailto:[email-masked]]On
>Behalf Of Reinaldo Penno
>Sent: Friday, October 25, 2002 2:05 PM
>To: OPES Group
>Subject: Some comments on draft-ietf-opes-threats-00
>
>
>a)  I propose a little bit of rewording on this paragraph
outside
>words are used in the sentence to categorize the threats.

Looks good, thanks.

>b) Correct if I'm wrong here but it seems to me the (original?)
>idea of this document was to document the *additional/specific*
>security threats the addition of an OPES impose. The document as
>it stands today basically lists more or less all attacks known
>to man.
>Take eavesdropping for example (2.1.4). The additional risk IMO
>is only when somebody breaks into the OPES system and use that to
>eavesdrop the traffic. Otherwise eavesdropping a network was and
>is always possible.
>Other examples such as a malign device impersonating a callout
>server seems a little bit far-fetched since I would assume mutual
>authentication and the like would make this a configuration error
>instead of a threat...oh well...everything is possible.

The problem you are pointing to does exist, but I hope it is
limited to a few subsections in section 2, namely 2.1.1 - 2.1.5.

It's unfortunate if these subsections have a negative impact on the
reader's attitude as they come before description of specific
OPES-related threats. Maybe these subsections should be compressed
into one that emphasizes OPES-related aspect of these generic
threats.

>Widely deployed alone does not make it a security problem.

The problem is posed by the fact that we intend to use not only the
HTTP but also the existing user agents (browsers). This seriously
limits system abilities to mitigate threats by adding protocol
extensions - like special message structure, tracing/notification
headers, signatures that are transparent to non-OPES aware
counterparts and other similar things.

Existing browsers are not aware of such additions and
will simply ignore any discrepancies caused by security
violations.

Oskar

---

From: Markus Hofmann <[email-masked]>
Date: Sat, 26 Oct 2002 13:58:47 -0400

Oskar Batuner wrote:

>> it stands today basically lists more or less all attacks known to
>> man. [...]
> 

I agree with both, the problem exists, in particular in Section 2.1. 
This section should be structured in a way that it talks only about 
network level threats *introduced by the new OPES components*, rather 
then explaining tnetwork level threats in general.

Example in Section 2.1.4: It isn't necessary to explain what 
eavesdropping is, and it isn't necessary to explain that this is an 
issue for transmitting information between a client and a server. But 
it is important to point out that the introduction of OPES processors 
and callout servers opens new possibilities for eavesdropping, namely 
on the link between OPES processor and callout server. This is a *new* 
threat compared to non-OPES environments, and has direct implications 
on the OPES requirements. The section - and the document in general - 
should focus on threats introduced by the new OPES elements, and 
explicitely spell those out.

I think this can easily be fixed.

-Markus