GEMINI: 101112 gemini_aa.txt

== GEMINI AA Planning ==
101112

This document provides details on the AA workflow diagram created by Guilherme.
Refer to AA-workflow.png. The proposed model remains relatively unchanged from
the diagram.

The following discussion assumes a UNIS implementation using ABAC 0.2.2, the
current stable release from ISI.


==== BOOTSTRAP PROCESS ====

In the context of GENI, the basis for authentication and authorization to an I&M
service (e.g., UNIS) is the user certificate and private key.  These
certificates (cert) are obtained from a trust authority, e.g., Utah or the GPO.

 - user.pem
 - user.key

For each service that interacts within the I&M system, we want to generate a
identity (key pair) to provide access control via proxy certs.  Our original
approach in LAMP generated a dedicated lampcert for this purpose, which allowed
for unrestricted access between services.  A proxy cert per service will
eventually allow the user (i.e., slice owner) to delegate access to I&M services
at different granularities. 

The proxy certs are signed by the user cert, meaning a proxy cert is validated
against the service as if the request was made by the user.  However, attributes
that are assigned to the service identity can restrict authorized use for each
proxy cert.

Example of how to create service identity and proxy certificates:

$ openssl req -new -config csr.conf -out blipp_service.csr -keyout blipp_service.key
$ openssl x509 -req -CAcreateserial -in blipp_service.csr -days 365 \
  -out blipp_service_ID.pem -CA user.pem -CAkey user.key \
  -extfile csr.conf -extensions v3_proxy

We now have a service proxy cert:

 - blipp_service_ID.pem

The proxy cert is concatenated with the user cert to maintain the chain of trust
and is pushed to the service nodes.  The service now uses this proxy cert to ask
for resources on a service like UNIS.

Now that we have proxy certs per service, we need to create ABAC credentials.
We use the slice credential to effectively associate the user with the
experiment slice when defining ABAC roles and to determine the lifetime (up to
slice expiration time) of said roles.  While there are a number of ways to
create and maintain attributes and policies, the following section outlines a
basic approach that is feasible to get working within a relatively short
timeframe.


==== UNIS/ABAC implementation for GEC15 ====

We define two roles for each slice that UNIS tracks:

 - slice_admin (rSA)
 - slice_owner (rSO)

The UNIS service is the principal that creates and maintains these roles using
libabac.  A keystore is maintained that stores the identity and attribute
certificates as they are generated.  These are actual files written to disk.

For a given slice, the first step in the role creation process is when the
bootstrapper pushes (HTTP POST) the slice credential (along with user cert) to
UNIS.  The following attributes are generated:

 1. UNIS.rSO <- user 
This says the UNIS server principle has a role slice_owner (rSO) and the user is
a slice owner.

 2. UNIS.rSA <- UNIS.rSO 
This says all slice owners are slice admins.  Allows the user to present their
own cert when asking for slice admin access.

 3. UNIS.rSA <- UNIS.rSO.rSA
This says anyone who has the slice owner attribute can delegate slice admin to
another entity, an example of a linked role.

NOTE: because we are using RT0, these attributes need to be generated for every
slice credential that gets posted.  RT2 allows for parameterized objects and
could make this more robust, but it's also more complicated and I'm still trying
to get my head around it.  RT0 is sufficient for an initial implementation.

At this point, the keystore contains 4 new entries: 3 attribute files, one for
each described above, and the user certificate.  The roles defined have a
lifespan equal to the slice lifetime, matching what is learned from the slice
credential.

It is easy to imagine additional roles being defined.  Perhaps a read_only (rRO)
role:

 1. UNIS.rRO <- UNIS.rSO
All slice owners are also read only users.

 2. UNIS.rRO <- UNIS.rSO.rRO
This says slice owners can delegate read only attributes to other entities.

Now the user could give some proxy certs read only access instead of slice admin
access, for example.  Defining how many roles we need and how they are managed
will require a broader discussion, and this may be obviated if we defer to a
global policy store.

Now that the roles for the given slice are defined in UNIS, the bootsrap process
can assign attributes to the service proxy certs we generated earlier.

Creddy is used to assign attributes:

$ creddy --attribute --issuer user.pem --key user.key --role slice_admin \
  --subject-cert blipp_service_ID.pem --out blipp_service_proxy_attr.der

The .der file now defines the following attribute:

user.rSA <- blipp_service_ID

What's stored in the file is binary but is represented similar to this:

$ creddy --roles --cert blipp_service_proxy_attr.der 
[keyid:62d12b0dcd5a8a9c3bddb175c8033506bb72a8e4].role:slice_admin_for_<UUID><-[keyid:22f6c982dfaadd9a1ef27d27a5e3ff75e511bf80]

Because we setup the delegation attribute earlier, UNIS can now say that the
BLiPP service has slice admin access because user, who gave the attribute to
BLiPP, is a slice owner.  In a similar fashion, the slice owner could also
delegate slice admin to another user's cert.

The bootstrap process needs to send (HTTP POST) these credentials to UNIS so
they can be added to the keystore.  The new attributes are loaded into the
running ABAC context.  Requests for resources using delegated proxy or user
certs are now checked against this set of attributes. The ABAC resolver will run
queries based on the required level of access.  For GEC15, the primary check
will ask: is slice admin access granted? If so return resource (e.g., topology,
metadata), if not, return error.


==== General Usage Notes ====

1. All communication to UNIS is over an SSL socket.  The server requires a valid
user certificate and checks the issuer against the GENI CA bundle.  If a client
or service uses a certificate signed by a non-GENI CA, the request will be
rejected outright.


==== Outstanding Issues ====

1. Proxy certs are not currently being accepted by creddy in 0.2.2.  ABAC dev
team is looking into problem.  We have tested delegating roles to non-proxy
certs, which does work.

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.


==== Current Status ====

Proof of concept from Guilherme (client/server) code updated to ABAC 0.2.2.  Key
functionality as described above is working.  In-progress tasks include
completing HTTPS interface for accepting slice and ABAC credentials and
integrating completed code into existing UNIS service.  The plan is to have a
test instance up and running so others can experiment by pushing their own slice
credentials and attributes.


==== 9/28 UPDATES ====

1. Worked with ABAC team to allow the use of certs other than self-signed certs.
Issue was with how they were verifying signatures. These changes are making
their way into the next ABAC release.

2. Email exchange with ABAC team about supporting proxy certificates. libabac
uses http://www.strongswan.org/ to handle certificates, which apparently doesn't
recognize x.509 proxy extensions in current releases.  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.  

3. Now that key technical issues with ABAC are addressed, I have been
integrating this AA model into UNIS and the bootstrap process.  UNIS has
endpoints for registering the slice credential and adding ABAC credentials.
AuthZ checks are made on the basis of whether the UNIS resource is associated
with a given slice and if the ABAC query says that the presented user cert has
access to the slice.


==== 9/28 NOTES ====

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. 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.

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.

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).

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.

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: 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.