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

From: Marshall Rose <[email-masked]>
Date: Sun, 23 Jun 2002 19:21:03 -0700

> Hi,
> 
> Please publish the attached document as an Internet Draft.
> 
> 	draft-srinivas-opes-threats-00.txt

folks - people who want to publish individual I-D submissions do not have to ask the permission of the chairs. nor should they, we get quite enough email already and we already subscribe to all the relevant mailing lists...

/mtr

---

From: <[email-masked]>
Date: Sun, 23 Jun 2002 22:17:55 -0400

Hi,

Thank you.

Best regards,
B. Srinivas
Senior Research Engineer
NRC Boston

 <<draft-srinivas-opes-threats-00.txt.txt>>

---

From: "Hilarie Orman, Purple Streak Development" <[email-masked]>
Date: Wed, 26 Jun 2002 15:11:35 -0600

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.

        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.

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

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

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

     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.

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.

     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.

     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.  

     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.

     3.6. Data Confidentiality 

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

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.

     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.

     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.

Hilarie