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