This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "". The branch, master has been updated via 7e5bfcb3cee9e69803e0615ecb9f29528ef6f5f2 (commit) from defb97b794f5400d9dd531a727b18fc8534415b3 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 7e5bfcb3cee9e69803e0615ecb9f29528ef6f5f2 Author: Phil Carns <[email protected]> Date: Tue Mar 17 12:39:12 2015 -0400 add draft text and figure for security deliverable ----------------------------------------------------------------------- Summary of changes: .../2015.03.30/2.1.1-security-diagram.png | Bin 0 -> 102325 bytes .../triton-quarterly/2015.03.30/2.1.1-security.txt | 38 ++++++++++++++++++++ 2 files changed, 38 insertions(+), 0 deletions(-) create mode 100644 reports/triton-quarterly/2015.03.30/2.1.1-security-diagram.png create mode 100644 reports/triton-quarterly/2015.03.30/2.1.1-security.txt Diff of changes: diff --git a/reports/triton-quarterly/2015.03.30/2.1.1-security-diagram.png b/reports/triton-quarterly/2015.03.30/2.1.1-security-diagram.png new file mode 100644 index 0000000..38bd1a9 Binary files /dev/null and b/reports/triton-quarterly/2015.03.30/2.1.1-security-diagram.png differ diff --git a/reports/triton-quarterly/2015.03.30/2.1.1-security.txt b/reports/triton-quarterly/2015.03.30/2.1.1-security.txt new file mode 100644 index 0000000..5ad97a7 --- /dev/null +++ b/reports/triton-quarterly/2015.03.30/2.1.1-security.txt @@ -0,0 +1,38 @@ +60% complete + +[2.1.1-security-diagram.png] + +This work is being carried out in collaboration with Richard Brooks' team +at Clemson University and Lee Ward's team at Sandia National Laboratories. +Figure [TODO:ref] illustrates the basic protocol sequence diagram to be +used for authentication and authorization in the Triton storage system. +One of the key features of this architecture is that the storage +system itself is decoupled from the security infrastructure to the +extent possible in order to simplify the storage system and allow for +more flexibility. Clients will interact with authentication servers to +retrieve credentials and clients will interact with authorization servers +to retrieve capabilities. The object permission information used to +generate capabilities will be stored on the storage system itself, but +authorization servers will access this information on behalf of clients +using existing APIs. The primary role of a storage server in this model +is to verify capabilities, which it will do using a well defined API. + +The Clemson University team has produced a preliminary prototype which uses +the same network communication infrastructure as Triton (i.e., the Mercury +[TODO: cite] RPC framework) for communication. We have reviewed the security +APIs in this prototype and have begun work on integrating them into the +Triton storage system prototype. + +We are also continuing discussions with Clemson University and Sandia +National Laboratories to reach a consensus on key design elements in a way +that is beneficial to both the Triton and Sirocco storage systems. We have +reached agreement on the component model (as previously shown in Figure +[TODO:ref]), a communication abstraction method (so that other RPC systems +besides Mercury could be used if needed), and a revocation protocol (based on +the LWFS model [TODO:cite). We are continuing discussions on details such as +security granularity (should permissions apply just to objects or forks +within an object) and how exactly the permission metadata should be +represented in the ASG object storage data model. + +We hope to host one of Richard Brooks' students over the summer as a research +aide to work on finalizing the security prototype integration with Triton. hooks/post-receive --