D u k e S y s t e m s Some tutorial slides on ABAC Jeff Chase Duke University

Preface This slide deck has some introductory slides useful for understanding role-based trust delegation logic: ABAC. Its purpose is to lay some foundations for a longer series on how to use ABAC as a foundation for trust management in GENI. See

IdP.faculty  D SA Reading the slides IdP.student  T GENI users Test Tube Guy and Dr. D, and some of their credentials A coordination service implementing some clearinghouse function, such as a Slice Authority Indicates trust of one principal in another, often associated with some kind of formal agreement: Indicates a request Indicates credential flow A A generic principal AM Aggregate

Basic concepts A principal is any entity that may: – Request an action – Respond to a request – Assert or receive a statement – Know a secret Trust is that which a principal must have in order to: – Honor a request – Accept a response – Believe a statement – Reveal a secret trusts Trust is usually limited to a particular function or purpose, which we would like to specify rigorously. A AB

Trust graph Trust may derive from a trust path through one or more intermediate principals that endorse another party. ClientServer Each step in the trust path follows a delegation of trust from a principal to its successor in the path, specified by its policy. We would like to constrain each delegation and specify rigorously and exactly what trust is delegated.

Certificates and credentials Each principal has at least one keypair that it may use to issue signed assertions. – Assertions represent delegations, policies, name bindings. Any such signed assertion is a certificate or “cert”. – Certificates reference other principals by their public keys. – A credential is a certificate used for authorization. Given knowledge of a public key, it is easy to secure communication with the principal who is using that keypair (authentication). We focus instead on authorization or trust management: how authenticated principals use credentials to establish trust. Certificate Term of validity Issuer’s name (or key) Signature Payload: assertion

IEEE Symposium on Security and Privacy,

Entities and attributes Entities (principals) have roles, powers, rights. – These are represented as attributes. – An entity may have multiple roles/attributes. Attributes of an entity are asserted by other entities. – Attributes are not permanent. – Attributes are not inherent or absolute. Each actor has policy rules to infer belief in attributes, e.g., based on assertions made by other entities. – An actor bases decisions about trust and authorization on inferences and beliefs about entities and their attributes. – E.g., “Alice is the operator for server S” is an attribute of Alice accepted by S as a consequence of its local policy.

A simple example Client EServer A Request Command c on Object o Credentials representing policies Credentials representing attributes + capabilities Query A.c o  E? ABAC inference engine query context To authorize the request, A gathers relevant credentials to “prove” it believes that entity E possesses an attribute c o required to issue command c on object o.

Constrained delegation in ABAC A principal delegates trust to another by endorsing its public key for possession of an attribute or role. The delegation is limited to the powers conferred by that attribute or role. The delegation is written as a logic statement and issued in a credential. trusts AB A.trusts  B Note that the arrows in ABAC syntax run “backwards” from the delegation: they indicate membership of one or more entities in a set associated with a given role.

ABAC: facts and rules A.r  {E} “A believes:”“These entities {E} have the role r.” A.r  (A.king).r “A says:” “If my king decrees E has role r, then I accept it.” These facts/rules are encoded in credentials signed by A. Libabac uses X.509 as a transport: a convenient implementation choice.

ABAC in GENI ABAC is a powerful declarative representation that can capture the GENI authorization/trust model. It saves a lot of code, provides a rigorous foundation, and preserves flexibility for future innovation. It can be easy for users, with some new user tools for delegation. Declarative policies can evolve “easily”. Signed credentials introduce interesting new challenges for credential management. – But we can solve them with a distributed service for credential storage, revocation, renewal: an early application of a networked cloud! We return to this topic later…

Aaron’s namespace of roles Chip’s namespace of roles Each entity (principal) has its own namespace of roles (attributes).

Aaron’s namespace of roles Chip’s namespace of roles Each entity (principal) has its own namespace of roles (attributes). Reader beware: the arrows in this sequence of ABAC tutorial slides follow the ABAC set membership flow: they run backwards from the trust delegations!

Aaron’s namespace of roles Bob’s namespace of roles Chip’s namespace of roles Entities may issue credentials (certs) to assert facts and rules about who wields attributes in issuer’s namespace.

Aaron’s namespace of roles Bob’s namespace of roles Chip’s namespace of roles E A.r1 B.r2 A.r1  E Type 1: Role definition credential B.r2  E

Aaron’s namespace of roles Bob’s namespace of roles Chip’s namespace of roles A.r1 A.r1  B.r2 Type 2: Linked delegation (Restricted delegation) B.r2

Aaron’s namespace of roles Bob’s namespace of roles Chip’s namespace of roles A.r1 A.r1  B.r2 Type 2: Linked delegation (Restricted delegation) E B.r2  E B.r2

Aaron’s namespace of roles Bob’s namespace of roles Chip’s namespace of roles A.r1 A.r1  B.r2 Type 2: Linked delegation (Restricted delegation) A.r1  E (inferred) E B.r2  E B.r2

Aaron’s namespace of roles Bob’s namespace of roles Chip’s namespace of roles A.c o Example access policy: A.c o  B.r2 B.r2

Aaron’s namespace of roles Bob’s namespace of roles Chip’s namespace of roles A.r1 Example access policy: A.c o  B.r2 E B.r2  E B.r2

Aaron’s namespace of roles Bob’s namespace of roles Chip’s namespace of roles A.r1 Example access policy: A.c o  B.r2 E Access granted. A.c o  B.r2 B.r2  E B.r2

Aaron’s namespace of roles Bob’s namespace of roles Chip’s namespace of roles A.r1 B.r2 C B.k Type 3: Attribute-based delegation B.k  C A.r1  (B.k).r3 C.r3

Aaron’s worldview Bob’s worldview Chip’s worldview A.r B.k By convention, we may agree on a global namespace of roles. Then ABAC facts become statements of belief by principals. ABAC rules declare trust structure. B.k  C A.r  (B.k).r A.r  B.r E A.r  E B.r  E C.r B.r2

The RT family of ABAC logics RT (ABAC) logics are trust management languages extending SPKI/SDSI with RBAC concepts and support for attribute delegations and delegation of attribute authority. – See also: Delegation Logic RT0 – Role names are atomic strings. RT1 – Roles may have simple parameters – e.g., literals, integers, enumerated types RT2 – There are objects, which may have attributes with parameters. Attribute parameters may be objects or object-valued variables.

ABAC and Extensions Libabac implements basic role-based trust: RT0. RT1 extends RT0 with parameterized roles. – E.g., property lists and policies that consider properties – These extensions seem tractable and will be valuable for capturing Shibboleth identity attributes (e.g., inCommon). RT2 extends RT1 with objects. – Seductive, but the details are out of scope. – RT2 literature seems to presume global object names. – I am skeptical that RT2 can be made practical. Show me! Can we embrace/accept the limits of RT0 or RT1?

“Design patterns” for RT0 The purpose of a declarative framework is to specify stuff declaratively, instead of in code. But the framework is too weak to say what we want. – We need global objects: slices and projects. Solution: sprinkle “just a little” code around RT0 to do what we want. Here’s a look ahead: – Global objects rooted in coordination services (SA, PA) – Simple Object Definition Credentials for global objects – Object Specific Roles (OSRs) – Templated rules with fast, practical inference – Support for global objects in server-side guards

Next question Credential flow What does it really mean?

Credential management Each principal possesses many certs. – Which ones are relevant to a given request? Where are they? Some of those certs are delegated. – Server needs even more certs to validate delegation chain. – Those certs belong to someone else. Server gets them…how? Credentials expire. – How to automate renewal? People change…and people lose their keys. – Revocation: how to do it fast and make it stick? – How to rebuild credentials with new keys? – How to keep the system safe in the real world?

Cloud-based credential storage Concept: always-on, highly available credential store. The store is lightly trusted: it cannot forge credentials, but we must trust it not to “forget” them. Server Put issued credentials and policies (certs) in the store. Get certs to “cache or check”. Pass credentials by reference in request. Cert Store See also: Conchord, CERTDIST