GEMINI: 092812_gemini_aa_continued.txt

File 092812_gemini_aa_continued.txt, 3.9 KB (added by, 9 years ago)
1== GEMINI/AA Status ==
31. Worked with ABAC team to allow the use of certs other than self-signed certs.  Issue was with how they were verifying signatures.
4These changes are making their way into the next ABAC release.
62. Email exchange with ABAC team about supporting proxy certificates.
7libabac uses to handle certificates, which apparently doesn't recognize x.509 proxy extensions in current releases.
8  It's possible to disable the strongswan check for critical extensions, and this works fine from the perspective of ABAC, but it's not an ideal solution.  Yesterday I got an email from Ted Faber where he indicated curiosity about our workflow and use of ABAC.  I might suggest that this could be an opportunity to discuss the broader AA concerns in GEMINI with those who are interested.
103. Now that key technical issues with ABAC are addressed, I have been integrating this AA model into UNIS and the bootstrap process.  We also have non-AA instances running and working with the MS and BLiPP.  I don't expect this to happen, but worst case is we can use the non-AA version for GEC15.
13I wanted to try and clarify a couple things from the last call.  If I recall correctly, one of Jim's points was that ABAC doesn't really care about who signed the certificates, if they they are proxied, etc.  and we could make things simpler with services generating their own certs.
15That's completely valid, and ABAC does only care about generating proof graphs using identities and the given attributes.  However, the ABAC implementation itself (libabac) has responsibility for deciding how to verify the x.509 certificates used to build those identities and attributes.  As I noted above, the 0.2.2 libabac implementation only accepted self-signed certs when I started on this, which I really didn't understand, and the ISI ABAC team was happy to fix their verification methods.
17My point is, ABAC is one thing, how we deal with certificates and chain of trust in GEMINI AA is another.  For example, the GEMINI services we are building are accessed via SSL/TLS, and this includes the existing LAMP portal and old UNIS.  To even establish a secure connection, we currently require that the client (i.e. "user") certificate be signed by a trusted authority.  The service verifies the user cert against a CA store, or "genica.bundle", that you can pull from a clearing house like  At this level, this has nothing to do with ABAC.
19One of the main reasons proxy certificates came up, is that you can't do the above check with self-signed certificates unless you add every new "issuer" (the self-signer) cert to the CA store.  With a proxy cert, the service verifies that the proxy cert was signed by the GENI user cert, which was in turn signed by a trusted root (e.g. Utah).
21Of course, this is not the only way to do things.  We could have our SSL/TLS services in GEMINI accept any certificate, no matter who signed it, and let ABAC figure out if it's valid or not for a particular GEMINI role.  I think this would work as well, but the caveat is we would not have a way to verify who those certs are really identifying since they would not be signed by an authority.  A middle-ground approach could introduce a GEMINI CA for signing service certs used in our workflow.
23What we don't get from the above approaches is the services acting on behalf of the slice owner who created the experiment, the service certs would only mean something to ABAC.  You can't have a service with its auto-generated cert say to another service outside of GEMINI "you can trust me, I'm really Harry making this request" because there's no chain of trust outside of what's defined in GEMINI ABAC.  The real question is, do we need to make those kinds of requests?  My current answer is:
24maybe this is not required because no other external service will even accept proxy certs at the moment, but why not do it and have that flexibility if we can.