EuroSec '22 Paper #13 Reviews and Comments

Paper #13 DeFIRED: decentralized authorization with receiver-revocable and refutable delegations

Submitted: 28 January 2022
Accepted: 1 March 2022

Review A: 4. Accept
Review B: 2. Weak reject
Review C: 3. Weak accept
Review D: 3. Weak accept

Review A

Overall merit

4. Accept

Reviewer expertise

2. Some familiarity

Paper summary

DeFIRED examines the problem of revoking or refusing permissions and access to assets from the delegetee's point of view. In essence it provides a methodology that enables the, commonly passive, awardees of privileges' in decentralized access control schemes to revoke or refute those rights. The entire scheme is built on a decentralized peer-to-peer alike system that utilizes distributed cryptographic operations to facilitate the revocation and refute process.

Comments for author

I find the overall problem interesting, complementing related work and specifically the Wave system quite nicely. Granting the delegetee the right to revoke/refute assigned privileges is an overlooked issue that, in my opinion, is an important aspect of decentralized access control systems. The paper is well organized and easy to follow, and I think it is useful for the community. As a note for future work (or ideally a discussion in the camera ready version), it would be interesting to see if and how your methodology could be altered to augment Wave that seems to be lacking this ability but it is otherwise a well equipped architecture.

Review B

Overall merit

2. Weak reject

Reviewer expertise

1. No familiarity

Paper summary

This paper deals with decentralized authorization. More specifically, the authors present DeFIRED: a framework for decentralized authorization that allows users to both generate and revoke chains of resource delegations, in a secure manner.

The main issue that DeFIRED tries to tackle is the delegation of specific content, from malicious issuers, to unaware receivers (_e.g.,_ the delegation of content/data related to criminal activities). DeFIRED, which stands for Decentralized FIle-oriented REsource Delegation framework, allows users to generate, revoke, prove, and verify resource delegations securely and transitively. In particular, it employs IBE (identity-based encryption) as the underlying cryptographic framework to facilitate invitations, attestations, revocations, and proof of delegation (or no delegation) of certain resources, while the whole scheme is assisted by a DHT that stores attestations, revocations, _etc._

The paper, after presenting the necessary formalisms for DeFIRED, proceeds with a describing various scenarios that involve creating a new user, delegating a resource, delegating a revocation, proving and disproving delegations, and verifying proofs re: objects.

Lastly, the authors benchmark the proposed scheme a report numbers re: the aforementioned tasks, which are all in the order of milliseconds.

Comments for author

Overall, the paper deals with an interesting topic: that is, decentralized authorization. Comments/concerns are outlined below:

  1. Although the topic that the paper deals-with is interesting, the proposed solution lacks in terms of novelty. All in all, DeFIRED is a straightforward application of certain cryptographic primitives (_e.g.,_ IBE) for engineering a solution for the subject matter. What exactly is new here? What are the corresponding challenges? What is the difficult problem attempted and what is the novel and intuitive solution proposed?
  2. Given the existence of WAVE, why doesn't it make sense to add the missing capabilities to it -- by extending the framework accordingly -- but rather the authors are proposing a whole new framework, just for the mere issue of proving and disproving the delegation of certain resources?
  3. The paper includes various unsubstantiated claims, like:
    > DeFIRED eliminates these processes to improve scalability and
    > decentralization, by using a DHT instead.
    That's great, but the authors need to provide evidence to back up such claims. Why not performing a specific measurement to actually prove the truthfulness of the statement above?
  4. The essence of this work is the security assessment in Sec. 6. The paper would benefit more from additional details and discussion re: this issue, rather than detailed walk-throughs about the steps involved to generate a user, perform the delegation of a resource, _etc._

Review C

Overall merit

3. Weak accept

Reviewer expertise

2. Some familiarity

Paper summary

This paper proposes DeFIRED, a decentralized authorization framework that apart from allowing issuers to generate and revoke resource delegations, it also allows the receivers to decline incoming delegations, revoke the existing ones, and prove or disprove them. In that way, the proposed framework enables users to prove that they never accepted delegations for certain unwanted resources in the first place. It also presents a comparison between the proposed framework and WAVE, a state of the art authorization system, and shows that the overhead introduced by DeFIRED is minimal, and thus acceptable.

Comments for author

Review D

Overall merit

3. Weak accept

Reviewer expertise

2. Some familiarity

Paper summary

This paper is on a decentralized authorization framework and allows revocation. It also supports delegation which is interesting.

Comments for author

It may be hard to understand the details of DeFIRED within the 6 page format. The threat model seems quite level, it is hard to understand what is the security gurantees of DeFIRED. For example, it relies on DHT. However there are numerous attacks on DHTs so what are the assumptions here. I believe there are many unstated assumptions to fully understand what is the threat model.

The revocation mechanism is not very clear. In conventional PKI-based revocation, scalability is a problem and also trust issues. It is unclear if resorting to IBE is sufficient on the trust issues. It would be nice to have a comparison with more traditional revocation like PKI-styled ones.

The experiments do not show anything about scalability. Surely that is important in any decentralized systems.

Overall, this paper does seem interesting as a workshop paper but it may be hard to understand the details due to space constraints.