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
4. Accept
2. Some familiarity
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.
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.
2. Weak reject
1. No familiarity
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.
Overall, the paper deals with an interesting topic: that is, decentralized authorization. Comments/concerns are outlined below:
> DeFIRED eliminates these processes to improve scalability andThat'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?
> decentralization, by using a DHT instead.
3. Weak accept
2. Some familiarity
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.
3. Weak accept
2. Some familiarity
This paper is on a decentralized authorization framework and allows revocation. It also supports delegation which is interesting.
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.