1 | Ezra:
|
---|
2 | ==== Outstanding Issues ====
|
---|
3 | 1. Proxy certs are not currently being accepted by creddy in 0.2.2.
|
---|
4 | ABAC dev team is looking into problem. We have tested delegating roles to non-proxy certs, which does work.
|
---|
5 | 2. Current libabac implementation is designed to work with self-signed certs only, for no apparent reason. libabac code has been modified (read hacked) to accept CA-signed certs. ABAC dev team is also aware and looking into solutions.
|
---|
6 | Regarding strongswan, we can disable the critical extension checks at least initially. The libabac team relies on that dependency but they don't have any control over whether or not it accepts proxy certs. The best solution would be to add support into strongswan. For OpenSSL, at least, you have to set OPENSSL_ALLOW_PROXY_CERT=1, and I have found no equivalent for strongswan.
|
---|
7 |
|
---|
8 | Harry:
|
---|
9 | Exactly what do you hope to have working by GEC15?
|
---|
10 | Ezra:
|
---|
11 | I hope to have the AA workflow working with the new UNIS as described in previous email and per Guilherme's diagram. What has slowed the realization of that goal are the issues in using libabac as described above. I think all the key technical issues have been resolved to the extent that the described workflow will work, and I just hope no other surprises pop up.
|
---|
12 |
|
---|
13 | Harry:
|
---|
14 | However, I'm not sure that I understand what will be happening from your points 1. and 2.
|
---|
15 | a) It sounds like the current ABAC code depends upon strongswan for such checks; true?
|
---|
16 | b) Is the ABAC code/ strongswan being modified to handle certs other than self-signed certs, or not? (sounds like yes)
|
---|
17 | c) Is the ABAC code. strongswan being modified to handle proxy certs? (sounds like no)
|
---|
18 | Ezra:
|
---|
19 | You are correct on the above items. My intention was to update the issues I outlined in my email from last week.
|
---|
20 |
|
---|
21 | Harry
|
---|
22 | From my point of view, the server must start by verifying identity with a proper chain of trust. A proxy cert seems like the right way to do it, because an experimenter's identity can then be temporarily assigned to a service.
|
---|
23 | Or, using a GEMINI CA to produce certs would work, one for each service.
|
---|
24 | Next, the credentials with attributes can be considered, for authorization.
|
---|
25 | We can certainly discuss this in Louisville, and consider a larger discussion at GEC15.
|
---|
26 | Ezra:
|
---|
27 | I agree with the above, and I look forward to talking this through next week.
|
---|
28 |
|
---|
29 | == GEMINI/AA Status ==
|
---|
30 |
|
---|
31 | 1. Worked with ABAC team to allow the use of certs other than self-signed certs. Issue was with how they were verifying signatures.
|
---|
32 | These changes are making their way into the next ABAC release.
|
---|
33 |
|
---|
34 | 2. Email exchange with ABAC team about supporting proxy certificates.
|
---|
35 | libabac uses http://www.strongswan.org/ to handle certificates, which apparently doesn't recognize x.509 proxy extensions in current releases.
|
---|
36 | 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.
|
---|
37 |
|
---|
38 | 3. 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.
|
---|
39 |
|
---|
40 |
|
---|
41 | I 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.
|
---|
42 |
|
---|
43 | That'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.
|
---|
44 |
|
---|
45 | My 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 boss.emulab.net. At this level, this has nothing to do with ABAC.
|
---|
46 |
|
---|
47 | One 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).
|
---|
48 |
|
---|
49 | Of 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.
|
---|
50 |
|
---|
51 | What 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:
|
---|
52 | maybe 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.
|
---|