CS 739 Reviews - Fall 2014

Summary:

In this paper the authors presented an unified approach to end to end authorization that allows applications that span administrative, network, abstraction and protocol boundaries to understand the end-to-end authority that justifies and given request. The resulting distributed systems are more secure and easier to audit. The implementation details of so system built for this purpose is also provided.

Problem:

When systems grow complex, they are often grown by affixing one system to another using some form of gateway to bridge boundaries between systems. Frequently in systems assembled in this fashion, the authorization information available at the client system cannot be translated to the terms of authorization at the server. Therefore the gateway often ends up making access-control decisions on behalf of the server system and the the server is ignorant of any authorization information beyond a blind trust in the gateway. The end-to-end authorization systems proposed here aims to solve this problem.

Contribution:

• The authors provide a very clear scope and definition of the various boundaries such as Administrative domains, Network Scales, Abstraction levels and protocols
• Implementation of a Proof class and Prover
• Actual implementation and measurement of the end-to-end system

What I learnt:

I found it very interesting to looks at the various boundaries and the issues they caused. Also the way theses issues was addressed.

What I found confusing:

The authors did not compare their approach to other unified approaches such as kerberos. Also I was wondering if this is still used today.

summary:
- they describe a system for end-to-end authorization across boundaries.

problem:
- when different existing systems connect together, it would be a problem to share resources from one system to another system.
- one way to solve this is putting gateways in the boundaries. gateway authorize the incoming requests and servers accept it.
- they want to provide an end-to-end authorization. the gateway wouldn't authorize the request, the server does.

solution:
- they consider different boundaries: administrative domains, network scales, different levels of abstraction, and different protocols.
- they expanded an existing implementations of simple public key infrastructure (SPKI).
- the requests would be in form of logical proofs and servers will process them to accept the requests.
- clients use "prover" to generate proofs.
- they also implemented some mechanisms so that servers can make sure that a request is coming from a client.
- they measured the performance of the system.

learned:
- I haven't seen the use of logical proofs for authorization before. the idea was interesting for me.

confused:
- I didn't understand why they can't use a centralized authentication system like kerberos.

Summary:
- The paper presents a unified approach for authorization. End-to-end authorization increases security by 1) increasing information using Statements and Proofs, 2) decreasing the number of programs that makes access-control decisions with a Prover, and 3) providing useful audit trails.

Problem:
- Gateways use an access-control list when bridging systems. This approach is a blind access control decisions because the authorization information cannot be translated from client system to the server system.

Contributions:
- Statements are authorization tags that perform intersection operations. Principals are subjects that can speak for others. Proofs contain statements that can be verified by the Prover. This ensures that every message says what it means, using objects to verify each component. Furthermore, this allows the Prover to cache delegations for faster message transversals.
- Secure channels, local channels, and signed requests are used to verify the client’s request to the server.
- The end-to-end approach integrates multiple hop-by-hop mechanisms. Although the Snowflake authorization model is slower than SSL, Snowflake can be optimized with a different encryption scheme and faster libraries. This allows users to trade off performance and security.

Confusing:
- I found Figure 4 and how channels work to be a bit confusing. It takes a lot of effort to follow requests because there are multiple arrow choices in the figure. Furthermore, the paper only describes how the RMI/ssh channel works in general, but does not provide a specific example.

Learned:
- Authentication can be expressed using statements and proofs instead of an access-control list. Although creating the proofs may take time, the results can be cached and there is information for audits to quickly fix security breaches.

Summary
The authors proposed a system for unified cross domain authorization. Application that impede administrative, network, abstract level or protocol boundaries can authorize and communicate securely through their system called SnowFlake. The paper is very well articulated and presented.

Problem they address
Cross domain authorization did not have a elegant mechanism and in most cases it is a bad trade off between security and performance. Howell and Kotz tries to find a authorization mechanism that can span across different boundaries.

Contributions

• Defining the problem in gory details -- describing spanning domains, infrastructural components for authorization makes the problem and the situation clear to the reader and benefits subsequent researchers in this area.
• Authorization through a conjunction of logic and cryptographic verifiability is another nice idea.
• Use of Java remote object for message passing is good, but will have cross platform or cross version support implications
• They measured the overhead on resources due to security and proposed good (and unavoidable) trade offs among performance and security in a constrained resource scenario.
• End-to-end approach lets SnowFlake connect systems with different gateways and still preserve the auth information, adding hop-by-hop mechanisms they claim to achieve freedom of performance-security easy trade off.

Confusing
This system seems to have pretty nice architecture. I could not find any follow up work on this to improve the performance. The paper has only 63 citation since its publication in 2000 (according to google.scholar). I don't understand is this field settled down or so?

Summary:
This paper summarize in detail the four boundaries (administration, scalability, abstraction and protocols) that impede the authorization information flow in a complex network. Traditional ways deal with the four boundaries by hop-by-hop authentication, in which the two ends does not know each other's detailed information (unreliable). To deal with it, the author introduces a unitied end-to-end authorization layer.

Problem:
As the distributed system and network becomes more and more complex and heterogeneous, authentication have to span the boundaries:
1.Administrative domains: a user accounts in one domain want to access another domain in which he has no account.
2.Scalability.
3.Abstraction levels: to authenticate different level of abstraction separately.
4.Protocols: users using different protocol can authenticate eath other.

Contribution:
1) Summarize the four kinds of boundaries in a complex network, and analyze the traditional solutions to each of them. They point out the a unified secure authorization system is still lacking and end-to-end authorization can over come drawbacks of hop-by-hop approach.

2) A compact logic of authorization, the key of the unified authorization. It contains statements, principals (nodes), and proofs (edges). Authors extend SPKI so that principals can send statements and proofs over the network. The principals (nodes) and proofs (edges) establish a chain of delegation for prover to verify the end-to-end authority. If a traversal over the chain is verified (by a prover), a shortcut is added between two ends.

3) Extension of RPC and HTTP protocols based on the cryptographic such as signed-certificates, hash identities and logical transitivity properties forms the building element of authorization.

Learned:
The neat idea to make the authorization as a compact logic so that each client in the system can prove itself and server can direct dicide.

Discussion:
This prototype gives gateways more power to collect and to run logic verification on the client's information. So is it really efficient and secure when the network becomes so large (too many verification for gateways) and there are compromised gateways (maliciously collect and give wrong verification)?

SUMMARY: The authors provide a mechanism which allows servers to perform end-to-end authorization of clients across many types of boundaries, including administrative and protocol.

PROBLEM: Because systems are commonly built out of smaller components, the components will need to interface with each other using their provided APIs. However, at each edge between components, there are potentially several types of boundaries that can make the flow of authorization more difficult. These include 1) Spanning administrative domains, in which there is no mapping from the user in Domain A to a user in Domain B, 2) Moving from single-machine IPC to a LAN to a WAN, in which different security characteristics are needed corresponding to the level of trust in the underlying network, 3) Different levels of abstraction such as disk blocks, files, volumes, namespaces, where multiple users may wish to securely share access to some resource, and 4) Protocol boundaries, in which the requests of one component are translated into a different protocol for use by the next component. At each of these points, authorization information can be reduced or lost completely, and the authors' unified system aims to preserve the fully chain of authority so the server can make decisions based on this richer information.

CONTRIBUTIONS: They take a formalized system of "principals" and "statements" and extended the SPKI framework with this logic. They generalize SPKI to allow different forms of principal and methods of authorization (public key, secret key, inherent trust of the local kernel). They define and formalize many types of principals, notably a channel or cryptographic key, that "say" things about the information they have encoded and/or signed, and using those primitives combined with an on-line (within the process) "Prover" to both create and validate authorization statements. Finally, they allow relatively efficient implementation by caching subtrees of proofs for reuse, avoiding the need to recurse deeply on every request.

LEARNING: One thing I found particularly confusing was the precise flow of messages and handlers in Figure 4, where they show a client and server communicating over an ssh RMI channel. Yes, the components are labeled and they walk through it in section 5.1.1, but there are a lot of pieces here and I wouldn't claim to understand them all without quite a bit more study. Something I learned, which perhaps wasn't the main point of the paper, is the general design principal of using end-to-end semantics for correctness first, and hop-by-hop only to improve the end-to-end performance. It was this idea applied to authorization in particular that provides for most of their design, and a lot of the rest naturally falls out from there.

Summary:
This paper presents a unified system that supports end-to-end authorization.

Problem:
As systems grow more complex, they are often grown by affixing one system to another using some form of gateway to bridge boundaries between the systems. The gateway often ends up making access-control decisions on behalf of the server system, and the server system is ignorant of any authorization information beyond a blind trust in the gateway.

Contributions:
(1) Span administrative domains by delegating user authority with restriction. Span network scales by separating policy from mechanism. Span levels of abstraction by allowing multiple mutually untrusting gateways to share a single lower-level resource. Design a data structure robustly and efficiently encode the authorization information.
(2) Use logic to represent authority. Generalize SPKI by allowing other forms of principal, allows conjunction and quoting. Implement the Proof class to describe the statement and verify itself upon request. Uses Prover object to collect delegations, cache proofs and construct new delegations.
(3) Implement mechanisms: a secure network RMI/ssh channel, a local channel vouched for by a trusted authority in the same machine, and a signed request.

Learned:
The system uses logic to present authority, instead of using ACL. The expressiveness of logic is stronger while the storage is smaller. I think this mechanism is especially useful if the object is very fine-grained.

Confused:
In this paper, the author says "While Proof objects may be received from untrusted parties, their methods are loaded from a local code base, so that the results of verification are trustworthy." I don't fully understand this. What does "methods" mean? Why the untrusted Proof objects doesn't matter? Can we use a wrong proof to authorize a wrong user?

Summary
The paper discusses end- to end authorization spanning administrative, network, abstraction and protocol boundaries with the use of principals, statements and proofs to convey authority.

Problems to solve
The authority information can flow across administrative boundaries in which case a server would not be aware of the client which resides in another domain and has to trust gateways to make access control decisions. The paper discusses a remedy for this problem while spanning boundaries that impede authorization flow from client to server.

Contributions
The separation of policy from mechanism allows for multiple mechanism support.
Provides the server with authority information of clients.
Describe a unified system to support end- to end authorization which with the help of statements which principals use to prove their authority.
Proofs are structured as opposed to SPKI sequences. This helps as it exhibits valuable meaning, doesn’t require any extra mapping or maintain state and it is easier to extract sub proofs.
Implemented mechanism to prove to the server the validity of client request.

Found confusing
How are proofs generated? What are S-expressions?

Learnings
The use of Mathematical models to help with end- to end authorization.

Summary
Barriers impede authorization by hop-by-hop approaches.Gateways are then used to bridge those bounderies making them authorization controllers. The authors of the paper try to build an authorization with end to end semantics called snowflake.

Problem
The only way server could authorize client in system with bounderies is hop by hop approach with normally gateway taking authorization control decisions. End to end authorization reduces the number of components that take authorization decisions. It spans all barriers. It also provide greater control to server and greater security by providing more information to the server about the client. In addition to the above it provides a way for dynamic and scalable authorization.

Contributions
Provided the concept of proof based authorization.
Reduces the role of the gateway by making it to delegate the identity of the client.
Implements proof so that its structure is preserved.This provides a way to reuse subproofs.
Caches proofs. Uses it to provide shortcuts in graph traversal.
Uses channels to exchange information for authorization.
Used signed request protocol to perform authorization.
Uses applications to show its working.

Learned
It provides concept for proof based authorization.

Confused
The paper provides a way to understand the abstract concepts behind the system. But it is not clear to me how they are actually implemented.

Summary,
In this paper the authors apply the end-to-end argument for network design to authorization. The authors aim to design a system where the two ends of the communication, the client and the server, to be aware and authorize each other without running the authorization at one of the hops in between them like a gateway, and trusting the gateway blindly.

Problem,
In scenarios where a large system is formed by aggregating smaller systems, there arise many boundaries between the systems like administrative boundaries, difference in abstraction, protocol used etc which necessitates the use of intermediate gateways to authorize the client of the server that communicate across these boundaries. In this work, the authors aim to develop methodologies to enable the end points in the communication to achieve end-to-end authorization by transcending these boundaries. The authors also aim to simplify the security auditing through this approach.

Contributions,
-The authors clearly define various boundaries like administrative domains, protocol differences that will impede the authorization flow and develop methods to implement simple end-to-end authorization.

-The authors extend an existing authorization framework, SPKI and implement the snowflake system for faster development and interoperability.

-The ability to setup secure channels to exchange messages and also send signed messages using this end-to-end authorization approach.

-Use of delegation and quoting to enable the server to reach the correct access control decision for the client accessing the server resource through an intermediary like a protocol gateway.

Learned,
How using existing frameworks and building on top of those could not only reduce the development time for the prototype system but also help in interoperability and easy adoption.

Confused,
-The working of the Prover module and the caching of the partial proofs were unclear to me.

-Also one of the example applications demonstrated by the authors, the quoting protocol gateway that delegates the authorization checks to the email database is comparable to the traditional setup of a web server running the web application for the email front end talking to the database backend. How is the authors approach of delegating the authorization checks to the database backend better than doing them at the web server. Also in cases where the protocol gateway has to combine resources from multiple backends, wouldn't quoting and delegating the checks to all of those backends be slower?

Summary:
The paper discusses an end-to-end authorization using a proof-based mechanism in a system that may comprise of boundaries – administrative, network, abstraction and protocol. The authors discuss the main issues with the traditional approaches, and then go on to explain their unified authorization approach, a part of the Snowflake project. They use protected web server, database, and quoting protocol gateway as applications to prove the credibility of their approach.

Problem:
In case of a large network of systems with boundaries defined for the regions, the service request from the client to the server has to cross several gateways which should ideally not be authoritative. But the server is unaware of the client information and hence is forced to rely on the gateways to make the decision. 4 types of boundaries are particularly dealt with in this paper.

Contributions:
• Key idea is to avoid the decision process at the gateway and instead pass/delegate information to the server to make the decision by itself. This helps overcome the boundary issues.
• The unified approach separates policy and mechanism, uses – can support multiple mechanisms for same policy, and creation of gateway in case new mechanism is required.
• End-to-end authorization allows multiple gateways (abstraction) to share the same lower-level resource.
• The encoding used in this approach allows the adaptation to multiple existing network protocols (authors describe HTTP and RMI)
• The authors introduce statements (assertions) and principals (who can make statements). The proof of authority is consolidation of the statements that together converge on a conclusion.
• The “proofs” objects are exchanged between the client and the server to both, make service request (client), and to grant access (server).
• Channels act as principals and provide proof on behalf of the client for authorization. 3 mechanisms are supported: secure channels, local channel, and signed requests.
• Once the proofs are derived, they can be cached for faster access in the future.

Confusion:
I am still not completely clear as to how the delegated information is being kept protected in the gateway and how the gateway would have access to certain portion of the information. The next doubt is regarding the scalability, is this approach scalable to systems used today ?

Learning:
It had not occurred to me before this paper as to how boundaries can hinder the implementation of end to end authorization process forcing other approaches that compromise several securities. I learnt how the issues were alleviated with the proof-based approach and their implementation of the mechanism is well explained.

Summary: This paper presents a scheme for end-to-end authorization that can span across different domains, networks, and protocols.

Problem: If a service is provided by a single machine, authorization can be done easily. However if the service requires the collaboration of many nodes, how can every node involved in the processing of the request validate the identity of the client? One solution is to authenticate the client in the local domain, by passing the client's password. However this is not secure enough.

Contribution:
1. The system provides unified authorization that spans across administrative domains, network scales, levels of abstraction, and different protocols.

2. The system used formal logic to prove things. It also introduced many terminologies: statements, principals, proofs, prover.

3. Solve the authorization across many nodes by delegation. That is, a node will do things on behalf of another node. However, such delegation is restricted.

4. Extended the existing SPKI framework.

5. Demonstrated the usability of their system by running some simple applications.

Things confused me: A lot of things in this paper confused me. I actually don't know how this protocol works. My confusion started with the appearing of the various terminologies.

Things I learned: I learned how the system is supposed to work (what's the goal). I also learned that this goal is actually achievable.

The paper talks about an end-to-end authorization scheme that spans across boundaries of administration, network scale and levels of abstraction. This is done using the gateways that lie across these boundaries. They use the concepts of delegation with restriction and the principals establish authority by means of proofs. The protocol works using the simple public key infrastructure. This authorization protocol has been implemented in the Snowflake project.

Contributions :

1. The protocol reduces the number of different programs that need to make access control decisions.
2. Proofs are used to verify the authority of the client/server. The proofs are stated formally using statements. Clients/Servers send instances of the Proof class to prove their authority. Prover objects collect the delegations, cache proofs and construct new delegations.
4. Channels transfer information for authorization and act as principals. They are implemented using three different mechanisms : Secure channel, local channel and a signed request.
5. Secure channels are implemented using ssh with remote method invocation.
Local channels are used if the client and server are colocated in the same virtual machine and are implemented using IPC pipes. Signed Request protocol is the snowflake’s way of performing HTTP authorization.
6. They demonstrate the authorization protocol for applications including a web server, a relational e-mail database and a quoting protocol gateway.

Confusing : I did not understand the comparison between structured proofs and SKPI’s sequence objects and the advantage of one over the another.

Learning : I learnt the mechanism of delegation in order to pass the information required for authorization from end-to-end. Using proofs and formal logic to establish authority was quite new to me.

Summary:
Authors discuss the problem of authorization across different types of system boundaries. They then present an end-to-end authorization system called Snowflake which remove the need to perform access control decisions at intermediate hops or at gateways over the boundaries.

Problem:
Large, complex systems may have administrative or other boundaries. To extend authorization to users outside of a server’s locality, there are a few techniques. One is to have gateways at the boundaries which authenticate a user and perform access control, requiring the server to trust the gateway. Another is to allow the owner of server resources to explicitly grant permissions to remote users by delegating authority to them.
It is desirable to instead maintain access control only within the administrative domain of the resource, and to allow end-to-end authentication of a user from client to server, not between.

Contributions:
- Proof approach based on the Logic of Authentication from prior works. A proof is generated of a user’s authority, built from statements between principals, and server can verify the proof’s veracity.
- Relieves network and protocol hops from making access control decisions.
- Structured proofs were used, allowing partial proofs to be cached for re-use, and still valid sub-proofs to be used after other statements expire.

Learned:
This is an implementation of a formalization of authority as a logic, which was pretty interesting and not something I had heard of before.

Confused:
A simple (perhaps trivial if necessary for succinctness) proof would have been nice to demonstrate the idea.

End-to-End Authorization

Summary:
The many boundaries that exist between the clients and the servers in a distributed system, make the servers trust the clients blindly based on the authorization provided by the gateways. Snowflake provides a unified end-to-end authentication service across the boundaries of administration, network, abstraction and protocol. This can be used to build distributed systems in a more secure manner.

Problem:
The authorization information in a distributed system needs to cross multiple boundaries which makes it hard for the server to authorize the client who is using the service. Since the process of authorization is split across multiple points only a hop-by-hop authentication is possible. Also, since there is no mechanism for the server to authenticate the client directly, it needs to trust the gateway. These problems can be solved using the unified approach proposed by Snowflake where the server can directly authenticate the client without any intermediaries.

Contributions:
1. The main contribution of the paper is to figure out that there is a problem with using the hop-by-hop authorization in distributed systems due to the various boundaries that exist between the systems.

2. The ability given to the server to verify client's authority by challenging it when needed. The client when challenged by the server sends it's proof to the server, which uses it to authorize the client's future requests. Using this model, the server has the power to directly authorize the client and the client has the ability to directly prove it's authorization without depending upon multiple intermediates for authorization.

3. One more contribution of the paper was to formalize the problem using the B=>A, B speaks for A statement. Using this formalism, they have shown that how the server can deduce that if the client actually says something for real.

Things I learnt:
The important thing I learned from today's paper is the definition of various boundaries that cause issue with authorization. Also, I learned how it is possible for servers to verify it's client's identity and vice versa across these boundaries without the need of gateways.

Things I found confusing:
I really didn't understand many details about proofs since I think they have not gone into the details of it. I also didn't understand how authorization can happens in systems where the server doesn't have complete information about who the clients are.

Summary:

This paper proposes a more secure and scalable solution for end-to-end authorization systems which spans across different administrative domains, protocols, network scales and abstraction. They have built the system as part of Snowflakes project, which aids in naming and sharing across administrative domains. In the conventional systems, when a message has to be passed between different administrative domains, a hierarchical domain will ask for the resource on behalf of the requester to the domain holding the information. This will obscure the identity of the client to server, which can be solved by Snowflakes by using gateways.

Problem:

End-to-end authorization, which involves access control by different administrative domains or by delegating the authority with restrictions to others. Authorization also depends on what kind of verification needs to be done. And the access control of a low level resource needs a level of abstraction, they also need to be developed on top of other known protocols such as HTTP and RMI. All these kinds of boundaries impede authorization mechanisms. This has to be implemented for correctness as well as performance.

Contributions:

1. They have came up with the new unified approach to implement end-to-end authorization across spans of administrative, network, protocols and abstraction boundaries.
2. They have proposed a separable policy and mechanism for the network scale problem, where different policies are implemented using different mechanism, which in turn is modular and scalable.
3. A mechanism to prove the identity of client and server using proofs. These proofs are developed on the fly, which was also cached during the access.
4. They have developed the model on the snowflakes, which is a proof of real-time implementation.

Confusing:

I am still not clear about how the delegation information collected from client applications are used to construct the proof graph and verify its correctness.

Learning:

I learned how to build a proof system which will prove the identity of client and server.

Summary: Paper presents a way to achieve end-to-end authorization that can transcend beyond boundaries. It does this with a unified proof passing and verifying mechanism that is able to send authorization information past a boundary (such as a gateway) and thus, this server or client can be able to make decisions.

Problem: Achieving security within a closed system is fairly easy; it is when you have a distributed system that spans multiple boundaries (for instance, administrative, abstraction, protocol, or scale) that security becomes difficult. Usually it is achieved by having gateways between the boundaries translate and make security decisions. Under this scheme, however, no end-to-end security is achieved. Ideally, we would want to put less than blind trust into a gateway; we want to be able to verify trust from one end of the system to the other.

Contribution: The main contribution was a description on the principals behind end-to-end authorization and the implementation of Snowflake that is able to use RMI or HTTP for its authentication.

The basic idea behind the system is first and foremost to be unified (obviously) and it relies on logic and proofs in order to support end-to-end authorization. Basically, there are statements (just an assertion) and principals (those who make statements). The proofs themselves are a series of statements that, taken together, verify the truth of some claim upon request. The “prover” module of snowflake collects and caches proofs. The cache is somewhat different than what we would normally think of as a cache. What it is in the context of this system is proof shortcuts. Their system use structured proofs that are set up in a graph structure. These shortcuts allow for one to quickly verify a proof that has already been verified without traversing down a potentially deep graph.

The authors implemented their authorization scheme and showed that there is a security and performance tradeoff, but their system achieves the goals that it set out to achieve. This tradeoff can be lessened with better libraries.

Confusion: I think I get the general idea, but it isn’t really making intuitive sense in my head. I don’t really understand how statements themselves are verified and trusted.

Learned: Learned how a structured proof based mechanism can be applied to get some form of end-to-end security that crosses boundaries. Security is one of the areas where I lack a lot of knowledge and this paper helped illustrate problems that I haven’t really thought of (i.e. security issues when the issue of boundaries comes into play).

Summary

This paper discusses the problem of end to end authorization in a system that can span many kinds of boundaries. The authors propose an unified approach to provide an end-to-end authorization in systems that span boundaries. They design and implement the ideas in a system called SnowFlake. The authors also present measurements of the system.

Problem

Many boundaries affect how authorization information flows through the system. These boundaries can be administrative domains, parts of networks that use different protocols or a boundary that separates different abstractions of resources. These boundaries force applications to rely on hop-by-hop authorization. Generally in hop-by-hop protocols, the gateways make access control decisions and server doesn't know the actual identity of the client. To solve this problem, the authors propose an unified approach that can work across boundaries and provide end-to-end authorization.

Contributions

1. The logic of authority and how authorization information is passed across - A client sends an instance of Proof to the server to prove its authority. Provers in servers and gateways collect delegations, cache proofs and construct new delegations. The prover traverses this graph to find the appropriate proof to prove.

2. Use of structured proofs that enables extracting sub lemmas for reuse.

3. The applications (webserver, db and quoting gateway) that demonstrate the viability of SnowFlake in real systems.

What I didn’t understand

I didn't completely understand how proofs are generated and how does a real proof look like? A simple example of these basic ideas might have been helpful.

What I learned

1. Problems in hop-by-hop authorization systems and why we need a end-to-end approach.
2. I learned how proofs and provers can be used to model and implement end to end authorization.

Summary:
This paper mainly introduces a unified approach that span administrative, network, abstraction and protocol boundaries to understand the end-to-end authority that justifies any given request. The author also gives some overhead measurement when using some applications with their end-to-end authorization system.

Problem:
As systems get more and more complex, authentication information from one end to end is hard to translate on various network gateways. In this case, gateways sometimes make decision on behalf of users and servers have no idea about authentication information beyond the gateway either.

Contributions:
1. Analyze four boundaries among traditional end-to-end authentication ways, includes spanning administrative domains, spanning network scales, spanning levels of abstractions and spanning protocols.
2. Propose a unified end-to-end authorization system. A detailed design of their system is presented, includes infrastures, channels and its associated flow chart.
3. Exploit three applications to demonstrate the availability of Snowflake architecture for sharing. Some performance measurements are gave out when using Snowflake system for sharing.

Confusings:
The gateway seems to have too much power to do operations on behalf of users. Can some malicious users attack gateways to get the rights belong to other users?

Learned:
What the major thing I learned from this paper is the four boundaries in distributed systems. The mechanism that proposed in this paper might can be integrated with current public cloud platforms to solve some authentication and authorization problems between different users.

Summary:
In this paper authors describe implementation of Snowflake, an end-to-end authorization system which removes necessity of authorization step from intermediate gateways/boundaries and the authorization information available at the client can be directly translated to the terms of authorization at the server. The system uses a proof-based mechanism instead of the common hop-by-hop approach to achieve end-to-end authorization. By adopting this end-to-end authorization approach, applications can easily overcome multiple administrative, network, abstraction and protocol boundaries.

Problem:
With growth of complexity in systems, there is an increased number of intermediate gateways/boundaries between the client and the end-server. At that time, the boundaries/gateways translated the authorization information from one side to other. Due to this the gateways made the access control decision for the server and the server had to blindly trust the gateways for authorization decisions. Also with server being ignorant of authorization information, a good audit trail for the authorization decision was not available.

Contributions:
-The approach of delegation with restriction to share information across the gateways/boundaries.
-The idea for not making access control decision at intermediate gateways, but delegating sufficient information to the server to take access control decisions.
-The idea for use of proof based approach to arrive on authorization decisions.
-Decision to transmit proofs in a structured form which enables simple extraction of sub-proofs allowing reuse.
-Prover using "shortcuts" in the graph for derived proofs to reduce graph traversal time for future authorization steps.
-Use of Message Authentication Code(MAC) by signed request for performance improvement.

Confusing:
-With growth in number of intermediate gateways the size of the graph can grow too, this can impact performance. How scalable is this approach with continually increase in complexity of systems?
-Since the system depends on the intermediate gateways delegating the authorization information, I am not clear if this end-to-end authorization approach can handle compromised gateways.

Learned:
I learned about the concept of delegation with restrictions which is used to share information across boundaries. And how this information is sufficient enough that end-server can reason about the client and make authorization decisions.

Summary:
The paper presented an system "Snowflake" which can handle end-to-end authorization. It first discusses four different kinds of boundaries (administrative domains, network scales, abstractions, protocols) that make it difficult of end-to-end authorization. Then it describes a authorization scheme based on delegations with restrictions which can handle end-to-end authorization.

Problem:
In a distributed system, different boundaries, for eg, administrative domains impedes with authorization. The server in one administrative domain is not fully aware of requester in another domain, and therefore has to depend upon untrusted gateways for authorization. The goal of the paper is to pass authorization information across boundaries so that server can properly authorize the clients.

Contributions:
1. Snowflake used delegation with restrictions to pass the authorization information to the server. The delegations are created by client (maybe upon request by the server for authorization information) by creating a Proof object using Prover. The proof object is passed to the server, which can verify the proofs and then determine authority. The role of gateway is to delegate the identity of the client.
2. The system adhere to the principle of least privileges by using the intersection of restrictions passed to the server.
3. This approach can be used in variety of protocols such as ssh, http. The paper describe how end-to-end authorization can be implemented with HTTP protocol and suggest some optimizations such as using MAC code which speaks for public key of client.
4 The paper also nicely explained the working example of how the snowflake system implemented end-to-end authorization.

Confusion: I got the bit and pieces of the information mentioned in the paper, but it's difficult for me to comprehend the whole concept, specially the part about statement and proofs.

Learned: I learned the concept of delegation and how it can be used to provide authorization. Also, the use of restrictions provide limited access to the shared resource (principle of least privilege).

Summary:
The paper presents an end-to-end authorization protocol that is able to cross admin, network, protocol, and abstraction boundaries. This is done by allowing principals to present structured proofs that verify their identity.

Problem:
The problem is that traditional hop by hop authorization services suffer from the issue of scope. Specifically, most are unable to gracefully (if at all) cross boundaries without the use of some intermediary gateway acting on the behalf of a boundary. For instance, a server remote to a client cannot authorize that client.

Contributions:
- The end-to-end authorization protocol built of principals and a tree based logic system of statements that allows proofs to be derived, verified, and reused as needed.
- The implementation of the end-to-end authorization system (prover and proof) in Snowflake.
- An analysis and testing of the performance of two architectures (RMI and HTTP) with and without their end-to-end authorization service being utilized.

Learned:
I found the decision to build proofs in a tree based style to be quite clever. It seems very naturally as trees are easy to logically reason about and it lends itself well to the goal of being able to use sub-components of a proof because a sub-component as simply a sub-tree in the proof tree.

Confused:
It is slightly unclear to me how a proof is generated and built up to provide end-to-end authorization. I think a guiding example will clear this up very quickly, but the paper seemed to skim over this rather quickly (although they do mention other papers that have more detail).

Summary:
The paper proposes Snowflake architecture as a unified approach for end to end authorization in applications that span across multiple boundaries (administrative/network/abstraction/protocol). End to end authorization is import to have as it reduces the number of programs that make access-control decisions, gives more information/useful audit trails to programs that do access control, making it more secure. The architecture has been implemented on protected web server, protected database and quoting protocol gateway to demostrate the concept.

Problem:
When multiple systems are integrated together, the authorization information cannot be translated from one sytem to another. As a result, authorization checks need to be done on every boundary/or hop. The server systems have to blindly trust the access-control decisions made in the gateway. The paper discusses four types of boundaries in a distributed system that could impede end-to-end authorization flow and how adding extra capability to clients and servers to form and verify proofs can support end to end authorization.

Contributions:
1. Authorization decisions deferred to final resource server and ensure that resource servers have a full explanantion for the authority of requests they service.
2. Extension of SPKI framework to provide unified approach to authorization across different boundaries.
3. Delegating authority with restriction; provide sufficient information to resource server to make access-control decision irrespective of membership of requestor in the local domain.
4. Unified authorization: Principals combine logical assumptions and theorems to produce proofs of authority.
5. Provers to create proofs and stores them in form of graphs. Traverse the graph to find delegations required. Various optimizations have been done such as caching proofs through shortcut edges to eliminate deep traversals and also construct new delegations.
6. Mechanisms (secure channel, local channel with trusted authority, signed requests) for authorization information propagation and ensure the request came from client.

Learning:
End to end authorization using a proof-based approach and delegating authority with restrictions.
I liked the way authors interleaved implementation details (various class implementations) with the overall concept, helped me in clearer understanding.

Unclear concept:
While reading the paper, I felt that only ideal scenarios were considered. What if a gateway is compromised or buggy? What are the limitations of spending large time in proofs in a large distributed system? Also, I could not completely understand the working of secure channel.

Summary:
This paper introduces the authentication service that is Snowflake that provides mutual authentication, authorization, and, depending on the implementation, message encryption. Instead of a centralized certificate authority as with SSL/TLS or the ticket granting service and authentication service as with Kerberos, this service is decentralized and relies on a proof network to verify identities and authorize.
Problems:
There are four problems the authors attempted to solve with this system so that end-to-end authorization could take place.
• Providing authentication across administrative domains where a unique user accounts doesn’t exist in both domains, but needs access.
• Scalability, so that the system has a pluggable interface which can operate securely process to process, within a private network, or across the public Internet.
• Crossing abstraction levels, so that one abstraction level isn’t fully trusted and the principle of least privilege is incorporated.
• Crossing protocols, in order for the system to be useful it must remain agnostic to protocols by providing an interface for them to utilize.
Contributions:
Although the authors implemented and tested a system in Java which could communicate over their version of SSH and HTTP, the theoretical contributions in this paper were much more substantial. They laid out a framework of proofs, which represented as objects could verify themselves given the underlying assumptions. These proofs relied on cryptographic primitives such as signed-certificates and hash identities coupled with logical transitivity properties to form a graph of authorization and authentication. Paths along this graph could be cached to simplify proofs as long as the underlying (parent nodes) didn’t expire. In this way access could be decentralized.
Unclear:
Although the protocol was well thought out, I was confused why after authenticating the client with checkAuth() the message m is resent from the client (Section 5.1.1 How channels work). Can the server not cache the message as it could be potentially large, or do I not understand fundamentally where the invoker is?
Another question I have is why the author’s chose to benchmark their framework at all (Section 7 Measurement), when they discount poor performance because their “implementation is unoptimized and built on top of slow libraries” (Section 7.4 Observations). Perhaps a more theoretical measurement would have been useful instead of machines running prototype code.
Learned:
I learned a novel way of enabling end-to-end authorization by modeling with simple, yet formal mathematical logic. The discussion of Snowflake with its internal Prover was an interesting and dynamic solution to the problems and goals of the system.

Summary
Requests that span administrative boundaries pass through gateways. The intermediate hop inhibits the flow of authorization between the provider of the service and the consumer of service, forcing the authorization decisions to be placed at the gateway. The goal of the end to end authorization system is have the gateways defer authorization decisions to the provider of the service, and have the server reason out the authorization for itself.

Problem
Flow of authorization across boundaries is inhibited by differences across administrative, network, abstraction and protocol differences. This leads authorization approaches to generally be hop to hop, rather than between the consumer and the producer of the service. The goal of this paper is to construct a feasible approach to have the two concerned parties negotiate the authorization themselves, by compacting the logic of authority in a manner understood by both the client and the server.

Contributions

• The biggest contribution of this paper is the neat way in which they have compacted the logic of authority into proofs that can be shared between the two parties that are attempting to authenticate. By having the client ‘prove’ itself to the server when challenged, by passing on it’s proof object, that the server can plug into it’s proof tree, it can validate messages sent from the client, without depending on the levels of abstraction in the middle ever having to perform any negotiation.


• Using verifiable proofs as the data structure that is passed between the client and server to perform authorization.


• Implementations of RPC and HTTP protocols based on the Snowflake proofs demonstrates applicability in real settings.

What I learnt
The choice of using proofs as a means to exchange authorization information is an interesting and a novel approach to solve the end to end authorization problem.

What I found confusing
How can quoting gateways be trusted to not be compromised? Doesn’t this weaken the end to end authorization argument being made in the rest of the paper?

Summary:
The authors present an end to end mechanism for authorization as opposed to a hop-by-hop mechanism and implement the same on snowflake.

Problem:
The end to end argument says that most of the semantics and complexity need to reside at the end-points and that the network should only be medium of fast transport between them. With authorization, there are different boundaries like administrative, network, abstraction and protocol boundaries, and this forces authorization to be implemented using hop-by-hop approaches and thus do not conform to the end to end principle of system design. To come up with an effective mechanism for end-to-end authorization is the problem being solved in this paper.

Solution from the paper/Contribution:
- They cleanly separate out policy from mechanism. Applications reason about policy without being concerned about the mechanism used to realize it; the mechanism differs based on factors such as the boundaries between the end-points etc.
- They make use of restricted delegation which is like making a statement on behalf of someone else regarding a particular thing. The statements are made by principals – a channel, a program etc. Proofs are used to verify the statements.
- The modelling of the system in terms of the above is a contribution.
- They maintain their delegations in a graph structure with nodes representing principals and edges representing a proof of authority from one principal to the next. A prover can say things only in terms of ‘final’ principals which is arrived at from the original principal using a breadth first traversal. Also, caching is used to avoid deep traversals by adding shortcut edges whenever a derived proof is received or computed which is composed of smaller components.
- They provide implementations on top of HTTP and Java RMI.
- They demonstrate the mechanism on the snowflake architecture using three applications – Protected Web Server, Protected database and a quoting protocol gateway.
In summary, they have effectively provided a mechanism for end-to-end authorization across administrative, network, abstraction and protocol boundaries.

What was not clear:
A user’s application collects delegations from other users; gateways collect delegations directly from client applications. They are maintained in a graph as explained above. Is there a trust issue here, in collecting the delegations? What if the gateway is compromised?
My Key takeaway:
The whole concept of structured proofs was new to me and that’s what I would take away from this.

Summary:
This paper describes Snowflake, an authentication service that can be used in distributed systems that cross administrative, network, protocol, or abstraction boundaries.

Problem:
When designing a secure distributed system, it is easiest to reason about security solely within the constraints of the system. But as organizations and systems grow more complex, often these individual secure distributed systems will be bound together using a gateway. These create boundaries in the system, making authorization extremely difficult. For example, getting a file from a distributed file system in which you are a user is easy; but getting one from a distributed file system in which you are not is difficult. How can the other domain verify you as a client?

Contributions:
The first important contribution is a description of what boundaries actually are. A thorough description of each one gives an intuitive sense of what the problem really is.

The next contribution is a system which bridges these boundaries in order to provide a secure authentication service. The abstraction of any specific authentication to the nature of a proof is what caught my eye.

Learned:
What I really learned about were the difficulties in providing a service that crosses these boundaries, and what those boundaries are. The only one I have ever even considered was administrative.

Difficult to Understand:
At this point I don’t entirely understand how proofs work. It seems they’ve put much of the semantics about them in a separate paper, but nonetheless any sections about the proofs are difficult to understand. In addition, it was hard to follow because I didn’t know what SPKI was.

Summary:
This paper describes the various boundaries that influence end-to-end authorization in a system with hosts spanning across various administrative domains, protocols, etc. The authors have implemented a system as a part of project called Snowflakes in order to achieve end-to-end authorization mechanism. As opposed to conventional approaches this mechanism does not obscure the identity of the client to the server and vice versa. The entire authorization information flows between client and server.The system uses Simple Public Key Infrastructure built using ssh and RMI.

Problem:
Passing the authorization information across network, protocol boundaries is a challenge. The end server which serves the resource should know about the identity and authority of the actual client requesting the information and vice versa. Existing solutions that install a gateway to access the resource on behalf of the user obscure the identity of the user to the server.

Contributions:
1. Access Control decisions are not made at the gateways anymore. The server has all the information that is required to verify the identity of the client. This also reduces the number of machines involved in the access control decisions.

2. Developed an entire architecture based on Java’s RMI and SSH to handle authorization between client and server.

3. The delegation of a statement is restricted. Hence a gateway cannot denote anything on behalf of the server which is beyond the restriction.

4. Transmitting proofs in structured form helps to reuse the sub-proofs.

5. Encoding the expiration time along with each proof thereby requiring that the proof be verified only one time.

6. Prover caches the proofs by adding shortcuts.

One thing I found confusing:
I did not quite understand where in authorization service they had used the channel key (kch). The paper talks about K2 being associated with the channel and not kch.

One thing I learnt:
The structured proof mechanism is something which I have learnt through this paper to build an end-to-end authorization mechanism.

Summary:
This paper discusses the four boundaries that impede the flow authorization information in the distributed systems and the traditional solutions to them. Then it introduces a unified, end-to-end authorization system, which can make systems more secure by 1) reducing the number of programs that make access-control decisions, 2) giving those programs more thorough information, 3) providing more useful audit trails.

Problem:
In the distributed system, there are many boundaries impede the flow of authorization, for example, administrative, network, abstraction, and protocol boundaries. The traditional approach for the applications that span those boundaries is hop-by-hop, which means the decision making functionalities are distributed along the path between two endpoints. That approach is not secure and hard to audit, because the credential information spreads in many entities, so both endpoints doesn’t have full knowledge about the authorization information. That approach also has more points for attackers than the end-to-end approach.

Contribution:
This paper has contributions in problem analysis and prototype system design
1) Discusses four forms boundaries in distributed system, and the corresponding solutions. The problems of traditional approaches like hop-by-hop approach motivate the end-to-end approach.
2) Introduces the infrastructure of an end-to-end authorization: principals, statements, and proofs. And also introduces the implementation of “prover”, which reflects the main idea behind the end-to-end authorization - a compact logic of authority.
3) Implements the end-to-end authorization system, and evaluates the performance of the system in RMI authorization and HTTP authorization.

Learned:
The end-to-end authority approach, which compacts logic of authority, can make the distributed systems with boundaries more secure.

Discussion:
I am confused about the discussion about the role of gateway in the paper, considering the topic of this paper is end-to-end approach. Is it possible to avoid deploying logic in gateway in the system? And I feel the highlight of the end-to-end authorization approach is about the logic and semantic of authorization, which is explained in authors’ another paper however. This paper focus on the overall design of the authorization system. The proposed architecture is nice, but the application of the system is restricted by the implementation, which is based on improper libraries and tools. Authors also admit that the measurement results don’t support their hypothesis (Snowflake authorization model is not prohibitively expensive).
I don’t understand why the authors claim that part of the purpose of Snowflake is to enable performance-security tradeoff.

Summary :
This paper introduces SnowFlake, an end to end authorization mechanism which overcomes the problems with authorizations using intermediate gateways. The authors discuss the infrastructure, implementation and measurements of this system.

Problem :
Complex systems are usually built by connecting smaller systems together using some gateways to connect them. In such a system, the authorization decisions are made at this gateway and is completely oblivious to the server. The server has to blindly trust the gateway here. The authors propose an approach to avoid this kind of oblivion. Also, when there are a lot of boundaries inside an application, the authorization has to span hop-by-hop. Thus, a unified approach is needed which takes care of end-to-end authorization.

Contributions :
1. Allowing multiple, non trusting gateways to communicate with a server by dividing the authorization between both the underlying server and the gateway instead of just doing it at the gateway.
2. Interoperability for many clients by using the SKPI protocol.
3. Defining a statement as A=>B over some restriction which enables users, which they call “subjects”, to speak on behalf of other users called “principals” to perform some operations on a given resource.
4. Authorization was implemented using a prover-proof class method. The proof describes the statement that it proves and can verify itself. These proofs also have expiration times. The prover collects delegations, caches proofs and constructs new delegations.

What I found confusing :
I don’t understand how compromised gateways can be handled in this scenario. I also don’t understand how this system can be made scalable.

What I learnt :
I learnt how we can build proof based security mechanism and use them to implement end-to-end authorization.

Summary: end-to-end authorization allows for authorization of clients that cross multiple system boundries when using the end system. This means that a unified authorization system can be used, which is easier to administer, interface with, and thus has stronger security guarantees.

Problem: as we saw with Kerberos, it can be difficult to bridge two authorization domains. One way of doing it is having gateways between domains that make requests on behalf of clients. The problem with this is that you have to administer the gateway and there is no central authorization control that spans the multiple domains, meaning that it is harder to reason over authorization rules. This is also similar to the end to end argument for packet switching: the hops should not be responsible for providing any security mechanisms; they should just act like dumb proxies. Otherwise, too much responsibility is placed on the hops, which may not meet everyone's security requirements.
Contributions:

• brings the end to end argument to the context of distributed security; the hops should not make decisions


• proofs are used as part of the authorization scheme


• a secure channel can be used to abstract away the security to higher levels

Confusing: is it essential for end-to-end authorization to have a structured proof? Would it be possible to use a simpler public-key encryption scheme? How scalable is it to have a structured proof?
Learned: this is another neat application of the end-to-end argument. The scope of the project seems pretty ambitious though: how do you bridge all authorization domains, especially different implementations? To what extent do we use what this paper proposed?

Summary:

The paper describes how to implement end-to-end authorization systems using a proof-based mechanism, instead of relying on the traditional approaches that use hop-to-hop authorization. These are applied to a web-server, a database and a quoting protocol gateway.

Problem:

Many boundaries lie between the client and the service it is requesting. Traditionally systems address this issue by placing gateways between boundaries that translate authorization information from one side to another. As a result, access control decisions are made by the gateway on behalf of the server system, and the server system has a blind trust in the gateway. The server doesn't have thorough information on what transpired in the process to make the most informed authorization decision, and the audit trails are not as good as they should be.

Contributions:

- Provides a mechanism that offers end-to-end authorization across administrative, network, abstraction and protocol boundaries.
- Reduces the number of programs that make access-control decisions.
- Proof based approach to verify legality of access. We can see similar ideas being used in Bitcoin's and HashCash's Proof-of-Work to prevent abuse.
- Gives the server more authorization information to make a decision.
- More detailed audit trails.
- Structured proof optimization that allows caching of the intermediate steps of a proof, so that the entire proof doesn't need to be reconstructed.
- Shortcut edge in proof graph for optimizing subsequent verification.
- Using Java IPC pipe on same host JVM (that can be trusted) to do away with system call and encryption overheads.

One thing I found confusing:

Can a compromised quoting gateway be detected? If a set of users use a gateway, and that gateway is compromised, how would one detect that the gateway is not masquerading as one of the users it is was originally authorized to quote?

One thing I learned from paper:

I learned how structured proof-based approaches work.

Summary:

This paper presents a project called Snowflake, which propose
an infrastructure to provide ``end-to-end'' authorization when
the system has boundaries and gateways across boundaries. The
Snowflake system is built on solid logic, and the authorization
is modeled as proofs with well-defined logical semantic

Problem:

The key problem that this paper tries to solve is the end-to-end
authorization with the presence of boundaries. Here, the boundaries
mean that the whole system is built with multiple subsystems, each
of which might have its own assumption on authorization and
mechanism of authorization. This requires one to consider how
to implement the end-to-end way of authorization, otherwise,
different components might have false assumption on each other
and breaks the guarantee the user requires.

Contributions:

I think there are two main contributions of this work.

First, it presents a solid logic-based approach for end-to-end
authorization. By only passing statements and proofs across
boundaries, each client (subsystem) can generate its own
proof of authorization. This sound logical way is beautiful,
and make authorization a testable task.

Second, a key point the author makes is that ``policy'' should
be separated with ``mechanism''. As a concrete example, as
shown in Section 5, the author teases apart the guarantee
that a channel should provide (i.e., the set of statements
available to a proof), and how they are implemented (i.e.,
whether they are implemented via ssh, local channel, or http).
This point is elegant because this separation allows optimization
of performance, and allows both the flexibility of the system
and the soundness of the authorization protocol.

What I Found Confusing:

One thing I found confusing is the comparison between the proposed
semantic and SPKI. This probably requires me to read the SPKI paper
and the author's other paper.

What I Learned:

The separation between policy and mechanism. The separation between
the ``logical'' and ``physical'' is a good design principle.

Summary:

The paper presents architecture, implementation and measurement analysis of SnowFlake, an end-to-end(E2E) authorization system which removes authorization step from intermediate gateways so that the authorization information can flow between the two communicating end nodes. By providing an E2E means of authorization the system is able to overcome administrative, network, abstraction and protocol differences between the nodes.

Problem:

• E2E arguments(Function placement on end nodes or on intermediate network) are very prominent in field of networking due to rapidly increasing interconnection between heterogenous networks using any L2-L3 device; authorization is one such function where E2E arguments can be applied.
• Without E2E end nodes have to trust the intermediate network to do the function of authorization across boundaries, thereby preventing the nodes from knowing appropriate authorization info about the communicating node.

Contributions:

• Support for delegation of principal authorization thereby providing restrictions.
• Allowing any entity to become a principal: making the channel principal provides the flexibility for quoting operations.
• The ability to be able to extract valid sub-proofs from a proof whose other parts might be expired; this ensures longevity of some of the authorizations.
• Inferring and adding shortcut edges would aid in speeding up the future authorization process.
• Supporting both secure channels and local channels for propagation of authorization information; using local channel reduces costs considerably by reducing expense of encryption.
• Optimization of signed requests by using Message Authentication Code seems to have considerable performance improvement(backed up by their measurement analysis).
• Ability to support authentication by just adding a delegation.
• Allows client flexibility by letting it manipulate the group memberships rather than letting the server handle the ACL's.

Unclear concept:

The SnowFlake architecture does not seem to be completely E2E as the gateway still needs to generate the "HTTP 401" response. Although they claim that their E2E reference is to the fact that authorization information passes from the client to the server, I am not clear if that alone is sufficient to call this architecture E2E(technically E2E means the gateway just acts as a L2 forwarder and nothing more).

Learning:

I learnt about the concept of delegation and also how the end nodes can receive complete information about authorization, so that they can completely trust their client/server.

Summary:
Project Snowflake: facilitates naming and sharing to allow end to end authentication and secure delegation of authority across administrative, network, abstraction and protocol boundaries (decentralized trust management). A compact logic of authority is built into an extended SPKI system that has provers and secure channels which can grant and revoke authority based on a chain of delegation (e.g. that one principal has the right to speak for another).

Problem:
Generally systems grow by connecting smaller systems together, and frequently there’s situations where the client system authorization information can’t be effectively conveyed to some other arbitrary server system. There’s 4x key kinds of boundaries that need to be spanned in a secure, scalable way that preserves the principle of least privilege and establishes “rights”: 1-administrative domains (independent enterprise intranets), 2-network scales (local machine, WAN, LAN), 3-levels of abstraction (multiple untrusting gateways can share a resource), & spanning protocols (gateways that impede information flow).

Contributions:
1-Unified Authorization: SPKI is extended to allow principals to send statements that will allow one to speak for another & send a proofs over the network. This system allows multiple parties to exercise joint authority and grant restricted delegation.

2-Prover: connect statements, principals, & proofs with a graph structure that can be traversed. Nodes are principals and edges are proofs which can be traversed to establish a chain of delegation. Once a traversal is completed to verify a proof, a shortcut edge is added. New proofs can also be created as required (based on existing chains of delegations).

3-Secure Network Channels: they built a java implementation of SSH that is compatible with the unix SSHD service & they build their own socket classes to create secure connections. Describing the flow requires half the alphabet (A to N). The short version is: a server defines K_S, and the RMI listener (associates SSHContext) captures incoming requests & defines public key K_1 to establish SSH sessions (to access the remote object). The client gets a stub for the remote object and establishes SSHContext and a Prover that hold private K_c. The client invokes method “m” on the stub and establishes an SSH socket. A call to the remote object invokes checkAuth() which initially fails & the exception triggers the prover to demonstrate required authority & it constructs a statement to delegate, the “proofRecipient”. Then in future calls to the object will result in checkAuth() success as long as the proof remains valid.

4-Signed Request Optimization: Snowflake extends HTTP digest authentication so that the Authorization header includes a proof. This signed request protocol is slow, so they optimize this by using an encrypted secret message authentication code (MAC) and hashes of this code.

What I Found Confusing:
They state using MAC & hashes of it effectively amortize communication costs and speed things up. However, it seems there’s some theoretical reasons that can justify this which I’m missing.

What I Learned:
It’s interesting to see how a system can create, and analyze proofs and use them in a practical way that allows principals to seamlessly obtain end-to-end authority regardless of the various underlying administrative, network, and protocol-based boundaries which normally impede authentication flow.