Vahe Poladian 15-712 November 14, 2001 Howell, Kotz: End-to-end authorization This paper presents an approach to providing an end-to-end authorization in systems that span various boundaries, such as network, admin domain, protocol, etc. The main problem tackled is as follows: when applications grow and as a result cross various boundaries, often times authorization information available on one node (e.g. client system) is not translated to another node (e.g. the server system), hence the server system performs actions in a way that is completely ignorant of the authorization extent of the client's user. So choices are (i) to leave it as it is, at the expense of reduced audit capabilities, or (ii) create expensive add-on systems with additional access-controls which translate authorizations of the client to that on the server. This latter approach creates large overheads. The main goal that the authors pursue is: Reduce the number of access-control decisions that programs have to make. At the same time provide more information to the system that has to make a decision to grant or deny access, Some specific ideas that they use to implement such security system are: 1. Use delegated form of authority to enable one user to perform actions on behalf another within some restrictions (this is useful when crossing administrative boundaries. Compare this with one of existing solutions, whereby in order to allow remote user access to local domain, a local user account is created, and new set of access controls are established --> duplication of a lot of information difficult to maintain, etc), 2. Separate policy from mechanism, thereby achieving smaller and cleaner interface to security. This interface can be supported by various underlying mechanisms, depending on need (e.g. interprocess comm vs network comm --> this applies well when systems cross network boundaries), 3. Allow access to a resource to be shared by more than one component. I did not like the example that they bring -- instead I offer my own example. Think of a safe-deposit box in the bank. The owner -- a bank customer -- has a key, and the bank manager has a key. When the owner needs access to the box, she shows the manager an id (e.g. a drivers license), and then both use their keys in order to open the box. Manager alone can't open the box, and the user alone can't open it either. The unified authorization system that authors built is based on SPKI, which is a standard. The model they propose supports the following security objects: principals, representing various identities of a user, statements and proofs. Proofs are presented by principals at the request of the Prover, and the principals use statements to achieve the proof. Proofs are automatically checked using various mathematical derivations (.e.g if A --> B, and B --> C, and A is true, then C must be true). Then authors present Snowflake, their implementation of the model. Specific examples of systems are presented, which have been enhanced with Snowflake. One example is Java RMI. Using pluggable socket factories, authors re-implement RMI to support secure sockets (ssh, to be more precise). Programmer of RMI client app need only establish the identity of the user (caller), and the system takes care of the rest. System is optimized to be fast in case RMI server and client are local to each other (in the same JVM process). Another example is HTTP-based RPC. Using standard HTTP mechanisms, authors plug-in Snowflake to provide support of their model in HTTP client-server envirorment. Then they combine both of this systems to build an email system, which has HTTP-protocol and HTML-based server, which is turn talks to an RMI-based database, which accesses e-mails from a relational database. This example demonstrates various ideas at work. Shortcomings: 1. I thought that authors did not sufficiently discuss the similarities, differences, and advantage / disadvantages of their model/ system versus other unified approaches to security. One example to compare against would be Kerberos. Another set of examples are various single-sign-on solutions (e.g. using LDAP-based directory servers) which attempt to provide a unified approach to security as well. Yet another example is a framework that is part of Standard Java version 2: Java Authorization and Authentication System (JAAS). I think JAAS attempts to achieve the similar goals, albeit restricted to apps written in one language. 2. It was not clear whether this solution is useful for a-priori existing systems at all.