Logical Trustas a basis for

Distributed Naming and Authorization

Jeff ChaseDuke University

Based upon work supported by the US National Science Foundation through the

GENI Initiative and under NSF grants OCI-1032873, CNS-0910653, 1243315, 1330659, and by RENCI.

AuthZ 101

subject action objectreferencemonitorapplies

guard policychecker

policy rules

subj/obj attributes

Authenticated by PKI / SSL / MAC

“subject says action”

service

request

requesterauthorizer(subject)

object

guardcredentialsAlice

identity

Let’s take it from the top• Let’s consider a client talking to a server, e.g., a web server.

• How does the client authenticate the server (“authn”)? How do they talk securely?

– Certificates, SSL/TLS, HTTPS, etc.

– Reasoning about certificates

• How does the server authenticate the client? What does it know about the client?

• How does it decide whether to grant access (“authz”)?– Identities and attributes, attribute-based access control (ABAC)

• Generalizing certificates and ABAC using trust logic (e.g., SAFE)

• Using trust logic: beyond authorization/authz secure naming

– DNSSEC (or STRONG)

• Next: rich authorization and trust structures.

Clients and servers

“GET /images/fish.gif HTTP/1.1”

sd = socket(…);connect(sd, name);write(sd, request…);read(sd, reply…);close(sd);

s = socket(…);bind(s, name);sd = accept(s);read(sd, request…);write(sd, reply…);close(sd);

request

reply

client (initiator) server

Mallory-in-the-Middle attack

“GET fish.gif…”request

reply

client (initiator) server

“GET fish.gif …”request

reply

If an attacker can interpose between two interacting entities, she can read and modify the messages at will without detection by either victim.

Hijacking a connection

sd = socket(…);connect(sd, name);…

client (initiator)The adversary must be able to “take over” the name, so that resolving the name redirects the connection request to some computer controlled by the adversary.

For the connect and bind system calls, the name is an IP address (if IP networking is being used). But to get the server’s IP address, the client first performs a lookup in the Domain Name Service for a DNS name of the server (such as www.cs.duke.edu). This step may be vulnerable.

End-to-end security: HTTPS

• How to authenticate shop.com, even if DNS is insecure?

• How to assure integrity/privacy of communications, even if the net is insecure?

• How to prevent man-in-the-middle attacks?

• Answer: Secure Sockets (SSL) or Transport-Layer Security (TLS), e.g., as used by HTTPS.

https://www.shop.com/shop.html

Symmetric and Asymmetric Crypto: Better Together

• Use asymmetric crypto to “handshake” and establish a secret session key (slow, but allows for key distribution).

• Then use the key to talk with symmetric crypto (fast and cheap)

• Example: Secure Sockets Layer (SSL) or Transport-Layer Security (TLS), used in HTTPS (Secure HTTP), SSH, SCP, etc.

“TCP SYN, etc.”

“My public key is K.”

Client Server“Let’s establish a session key: {S}K .”

{M}S

…

[encrypted data or content]

What are we missing?

• This approach solves the “key distribution problem” for symmetric crypto.– And we want to use symmetric crypto because it

is fast and cheap.

• But it presumes that a participant knows the public key of another.– Does C know (believe) that K really is the public

key of S? It better be, or all bets are off!

• How to authenticate S?

Endorsements: certificates

• A principal may endorse another’s key.

• Issue a signed statement containing the key, and some statement about the key or the key holder (subject).

• We call the signed statement a certificate.

• But how does anyone know the endorser’s key?

CertificateTerm of validity

Issuer’s name (or key)

Signature

Bob’s key is 247E6F1A…

Certificates: a general view • A principal A delegates trust to another (B) by endorsing its

public key as bound to a global name (or any other attribute).

• A delegation is an assertion of fact by the issuer A, and is commonly issued as a certificate that is digitally signed by A.

• In a standard x.509 identity cert (e.g., issued by a PKI CA for Web), the attribute is a distinguished name.

– e.g., “Bob” or “amazon.com”

– PKI- CA: Public Key Infrastructure, Certifying Authority

CertificateTerm of validity

Issuer’s name (or key)

Signature

Payload: statements

Because the certificate is signed, a third party C can validate and use A’s statement about B, if C knows A’s public key and if C trusts A.

Trust management systems use certificates to encode other kinds of attributes and statements, e.g., arbitrary logic statements spoken by issuer.

SSL/TLS: server certificate

• Your browser can verify the server identity if it knows the “real” server’s public key.

• The server presents a certificate signed by a trusted third party (CA) endorsing its public key.

• Your browser can verify the certificate if it knows/trusts the public key of the CA that signed it.

• How does your browser know the CA’s public key? How does your browser know to trust the CA?

The CA’s public key is “baked into your browser”. You trust your browser provider to install a list of CAs that you can trust. Any CA on the list can issue a certificate for any name and any public key, and your browser will believe the asserted binding.

What could go wrong?

Reference: “Certified Lies”, e.g., see the 2010 paper by Soghoian and Stamm.

Spelling it out: HTTPS/SSL/TLS(1) When the server passes its public key K to the client, it also passes a certificate issued by

a CA. The certificate endorses the key K and binds K to a DNS name (e.g., amazon.com). The server’s DNS name is listed as the “distinguished name” in its identity certificate.

(2) The client’s browser validates the server’s certificate and checks to verify that the DNS name matches the DNS name in the https URL that the client is fetching. I.e., the certificate "proves" that the server is the "right" server for the requested URL.

(3) The client can validate the server's certificate iff the client (browser) trusts the issuing CA. How does the client know if it trusts the issuing CA? Answer: the browser has a "baked in" list of trusted CAs and their public keys. The set of CAs and signing protocols and certificate standards (x.509 identity certificates) is called Public Key Infrastructure or PKI.

(4) The client generates a session key and encrypts it with the server’s public key K, which it obtains from the cert. The session key is a secret shared by the client and server: the server can decrypt it (since it has the corresponding private key), but nobody else can.

(5) Now the client and server have a shared secret session key: they can communicate using symmetric crypto, which is fast and cheap.

PKI: What could go wrong?

Who decides if a CA is “trustworthy”? Should you believe them? Should you trust your browser provider to make the list of trusted CAs? Who tells you a CA is trustworthy? Are you sure it’s someone you trust? How can you can be sure that you have the "true" browser code with the "true" list?

What if they’re wrong? What if a CA is subverted or goes rogue? Or loses its private key in an attack?

We can learn about keys from a chain of endorsements rooted in some trust anchor, whose key we “just know”.

Example: root certifying authorities (CAs) whose keys are baked into your Web browser.

Digression: Web security architecture

• At this point I like to go off on a discussion of the fragility of the CA infrastructure.

– News flash: many commercial CAs have been subverted.

– Some CAs are run by (or are legally responsive to) state actors with active espionage/surveillance.

– Anyone with access to your browser configuration (e.g., an employer, a wireless telecom provider) can add “their” CA to your trusted list.

– Anyone who can subvert or control any CA on your browser’s trusted CA list can mount MITM attacks on any of your Web interactions.

– Also, X.509 software has appalling bugs that may cause your browser to accept various malformed “frankencerts” that should be rejected.

– There is an active infrastructure for MITM attacks with special-purpose devices that may be inserted in the network or built into the network.

• But we don’t have time for that now…

Authenticating an HTTPS client

• Browser always authenticates the server with HTTPS.– Server presents certificate signed by a valid PKI CA.

– Domain name must match the name in certificate, etc.

• Server optionally requests to authenticate the browser (client, user or user agent).– Browser presents a user certificate, OR

– Password authentication is much more common. (why?)

• Server may authenticate client using a web sign on protocol, also called single sign on (SSO).– Authenticated statements about client by some trusted authority:

an SSO identity provider (IdP).

Using SSO IdPs

• An IdP is just a trust anchor maintained by an enterprise.

• The IdP authenticates the user agent (login).

• IdP asserts attributes of the user identity.– E.g., signed assertion of attributes of identity bound to an HTTPS

session.

– Might not reveal identity: e.g., just “Duke student”.

• Authorization policy in the server can consider these attributes (e.g., Attribute-Based Access Control).– “Duke students may use this facility on Monday.”

– Subsumes Role-Based Access Control (RBAC).

– Generally, authorization policy is some boolean function of accepted subject attributes and object attributes.

9/29/2015

Authz example

subject action objectreferencemonitorapplies

guard policyinference

policy rules

subj/obj attributes

Authenticated by PKI / SSL / MAC

“subject says action”

service

Alice,Will you marry me? Signed, Bob

Attributes and policies

• More generally, each subject/object is labeled with a list of named attributes with typed values (e.g., boolean).

• Generally, an access policy for a requested access is a boolean (logic) function over the subject and object attributes.

name = “Alice”wizard = true

Name = “obj1”access: wizard

name = “Bob”student = true

Name = “obj2”access: student

Logical trust: safe and sound

Alice,Will you marry me? Signed, Bob

Guard policyalice: accept(Bob) alice: likes(Bob),

alice: mother(Mom, alice),Mom: likes(Bob),

…

This is logic programming.p(B) “Predicate p is true of B”alice: p(B) “Alice says p is true of B”

Atomic logic statements (atoms).

Trust with SAFE logic

• SAFE: Secure Authorization for Federated Environments– Practical minimalist trust logic: low barrier to use

– Custom datalog+says inference engine, <1000 lines of Scala

– “Slang” script to publish/import logic statements as certificates

– Compose policies and statements easily in plain text

• SAFE certificates can carry arbitrary logic content.– A building block for secure networked systems

CertificateTerm of validity

Issuer’s public keySignature

Payload: statementsalice: p(X) alice: trusts(G), G: p(X)

“If Alice trusts G and G says p(X) then Alice believes it.”

Logic and “says”

• Propositional logic example: P Q and R.– P, Q, R are propositions whose value is either true or false.

• Predicate logic example (“first-order calculus”):– p(X) q(X) and r(X, cindy).

– p, q, r are predicates: boolean functions over N parameters.

– E.g., “Cindy is a Duke student”

– “cindy” is a constant: one element of a universe of objects.

– X is a variable: its bound value ranges over the universe.

– “For every X, p of X is true if…”: an inference rule or policy.

• Trust logic adds a says operator:– self: p(X) alice: q(X) and bob: r(X, cindy)

– “I believe p(X) if alice says … and bob says…”

A simple policy rule

accept(X) :- cindy: p(X). alice:

speaker says head is-implied-by body

Variables are universally quantified: “for every X”.“Pure” datalog: every variable in the head must appear in the body.

“Alice accepts any X if Cindy says X has property p.”

With this rule Alice delegates trust and power to Cindy to influence whom Alice accepts.

Logical trust on the network

How does Alice know…

• Did Cindy’s statement really come from Cindy?

• What did Cindy mean by “p” in her statement?

• Did the request really come from Bob?

• Is the requester the same “Bob” that Cindy mentioned?

alice: accept(X) :- cindy: p(X).

cindy: p(bob).

bob: request(…).request

policy

endorsement

Trust logic for secure distributed systems

• More on trust logic for authorization later.

• But we can also use it as a tool to build secure federated distributed services, e.g., at Internet scale.

• We can see how it can model the CA infrastructure:– Browser asserts trusted(CA) facts for CAs in trust list.

– If a “trusted” CA asserts a name-IP binding, browser believes it.

– CA hierarchy: a trusted CA may delegate its certifying privileges within named domains: capture with a recursive policy rule.

• Another example: secure naming– SPKI/SDSI STRONG

– DNSSEC

DNS as a distributed service

• DNS is a “cloud” of name servers

• owned by different entities (domains)

• organized in a hierarchy (tree) such that

• each controls a subtree of the name space.

DNS Lookup

DNSSEC• End-to-end SSL/TLS etc. can defend against DNS level

attacks and network-layer attacks as well.

• But it relies on distribution of certificates, and correct validation of those certificates, and applications built to use SSL/TLS. Yuck (?)

• Can DNS itself be made more secure? Yes!– Give each DNS domain/subdomain (or “zone”) a keypair.

– Sign all entries in the zone database (“Resource Records”/RRs)

– Return signed data in DNS responses

– Each parent domain endorses the public key of each child

– Can validate the whole chain of DNS responses for a lookup, all the way back to the root…

– IF it is fully deployed. (it’s not…yet)

Secure DNS (DNSSEC) Threat Model

• DNSSEC defends against:– Spoofing, cache poisoning

– man-in-middle attacks on DNS requests/responses

• What DNSSEC cannot do– Defend against rogue domain administrators

– Defend against denial-of-service attacks

– Defend against compromise of a server or its key.– Protect against “pharm” attacks on users who don’t

check or care if they are talking to nicebank.com or n1cebank.com

DNSSECHow to make DNS more secure?• Answer: sign all DNS lookup responses and include target’s public key.

• Each parent domain endorses the public key of each child.

• Resolver can validate the response chain, all the way back to the root…

34

Getting the Keys

• Until a resolver gets the DNSKEY(s) for a zone, data can be spoofed

• How can a resolver know that the DNSKEY(s) themselves are not being spoofed?

• DNSSEC zones securely delegate from parents to children

• Zones that have no secure parents are called trust anchors

• When a zone is a trust anchor the zones that it delegates to form an island of security

[Osterweil; Massey; Zhang]

https://www.iana.org/dnssec

DNS Lookup

http://www.cisco.com/web/about/security/intelligence/dns-bcp.html

In DNSSEC, responses at zone cuts contain the public key of the child domain/zone authority, signed by the parent zone authority.

Reinventing/redeploying a global distributed service with many owners is a big job. DNSSEC has been in progress for 15+ years. But it is happening.

http://www.internetsociety.org/deploy360/dnssec/maps/

Trust with SAFE logic

• SAFE: Secure Authorization for Federated Environments– Practical minimalist trust logic: low barrier to use

• “Datalog with says”

– Publish/import sets of logic statements as linked certificates.• Authenticated: signed by the speaker/issuer.

• Conventions for self-certifying principal IDs and object IDs

– A building block for secure networked systems

– Including general access controlCertificateTerm of validity

Issuer’s public keySignature

Payload: statementsalice: p(X) alice: trusts(G), G: p(X)

“If Alice trusts G and G says p(X) then Alice believes it.”

DNSSEC (simplified) in trust logic

dns(Parent, Name, Child) :- Parent: dnsRecord(Parent, Name, Child).

dns(Parent, Name, Child) :- Parent: dnsRecord(Parent, head(Name), D), dns(D, tail(Name), Child).

Certified evaluation vs. name resolution

• This example code certifies a name binding. [SD3]– All name records/statements on the path from the named node

to the root must be present in the context.

• Resolving a name requires dynamic fetch of the name records along the path.– Fetch a record, query for child’s identifying information, query

child’s record for the next hop name component.

b

c

• E.g., for /a/b/c [or c.b.a], first query root for “a” name record, then query a for “b”, then query b for “c”.

• SAFE fetches each name record from a shared key-value store, then uses it to synthesize the token of the next record.

/a

Certificate linking and caching

Server

Issuers put credentials and policies in a shared store.

Get certs to“cache or check”.

Credential sets are passed by reference in requests.

SafeSets

Server caches logic sets indexed by secure tokens. Query context is a union of sets (e.g., for subject, object, policy).

SAFE tools offer scripting support to construct nested logic sets with subset inclusion via link.

Based on scalable K/V store (Riak).

CertificateTerm of validity

Issuer’s public key

Signature

Payload: statement

says

Client

Authority

.edu

unc

duke

cs envZone server may delegate authority for subdomains to children. The children handle queries on those subdomains.

DNS: authority hierarchy

• What if a DNS server goes rogue (or is subverted)?– DNS servers for low-level domains might not be hardened.

• How much damage can a rogue DNS server do?

But what if a DNS root goes rogue?

Trust structure and trust anchors

• DNSSEC is an example of a trust structure.– Each principal/server is delegated limited trust/powers.

• E.g., each DNS server is trusted by other participants only to control names within specific subtrees (zones/domains).

– DNSSEC provides a shared global name space rooted in a global root, a trust anchor that controls everything.

– Every participant is configured to trust the anchor.

• The CA hierarchy is similar, except:– It is a “forest” with many root anchors (independent CAs).

– Each root CA has unconstrained power over the name space.

GENI infrastructure services

Backbone #1

Backbone #2

Campus#3

Campus rack

Access#1

CommercialClouds

CorporateGENI suites

Other-NationProjects

ResearchTestbed

Campus

My “slice” runs acrossthe evolving GENI federation.

My GENI Slice

Slice: an end-to-end virtual execution context with configurable properties, e.g., containment and isolation.

GENI control framework for federated orchestrationOpen Resource Control Architecture

“Make my slice.”

“Instantiate VMs and VLANs x, y, z.”

3rd party network provider

“Link sites with circuits.”

“Enable external SDN controller for x, y, z.”

OpenFlow

ExoGENI: Cartoon Version

Campus A rack Campus B rack

Not shown: dynamic slice adaptation under

automated control

A Short GENI Glossary (from geni-trex)

• Aggregate: An infrastructure hosting (IaaS) provider, provisioning resources on request based on its own policies, priorities and constraints.

• Member: GENI users or tenants who may allocate and control virtual infrastructure elements spanning multiple aggregates, and link them together to form end-to-end topologies for experiments or networked applications.

• Sliver: A virtual resource unit that is provisioned from a single aggregate and is named and managed independently of other slivers. Each sliver is bound to exactly one slice at the time that the sliver is created.

• Slice: A logical container for a set of slivers. The slice abstraction is useful to name, control, and contain groups of virtual resources that span multiple provider sites and are allocated and used for a common purpose. A slice belongs to exactly one project at the time the slice is created.

• Project: A logical grouping of slices, often under the management of a common lead or PI representing the work of a single lab or (virtual) organization. By GENI policy, the project lead is accountable for activities taken on slivers within the project’s slices.

resources

IdP PACreate

project p

SARegister

user

Delegateproject

membership

Create slice s in p

Create sliver in

in s

Verify user identity, obtain

attributes, check that user

is qualified, execute

agreement.

Verify that user is authorized to create project

and act as project leader.

Verify that project p is

valid and user is authorized to create slice in

project p.

Verify that slice s is valid and user is

authorized to request resources for s.

1 2

3

4

5

IdP or “Member Authority”

PA: Project Authority

SA: Slice Authority

Cloud site

GENI trust structure: overview

AM AM

GENI root

GMOC I&M

GENI “clearinghouse”

MA IdP

PA SA

Fed root endorsementsgeni: memberAuthority(ma).geni: projectAuthority(pa).geni: sliceAuthority(sa).geni.aggregate(am{1,2}).

Fed root acceptancema: geniRoot(geni).pa: geniRoot(geni).sa: geniRoot(geni).am{1,2}: geniRoot(geni).

Example policy rule to infer trust structurememberAuthority(X) geniRoot(G), G: memberAuthority(X).

“Self accepts any Member Authority endorsed by a trusted federation root.”

Attribute-based delegation

accept(X) :- Y: p(X), trusted(Y).

goal and goal

“Alice accepts any X if someone Alice trusts says X has property p.”

Enables chains of trust.

If unspecified, speaker is “self”.

IdP

Issue user credentials Users have roles

e.g., student, faculty.

Registeruser

user registered

Identity Portal (IdP) / Member Authority (MA)

ma: geniUser(t).ma: student(t).

ma: enrolled(cs-114, t).

ma: geniUser(d).ma: faculty(d).

d

t

• An IdP asserts facts about users.

• User attributes may include inCommon attributes harvested through indirect delegation to Shibboleth IdPs.

• These attributes may have parameters with simple values (strings or numbers).

Create sliver for

slice s

SA AM

Decentralized policy: a scenario

SA: owner(t, s).idp: geniUser(t).pa: member(t, p).

Anyone can create a sliver for a slice s if s was approved by a qualified SA, and the request conforms to SA’s policies for s.

Only creator(s) may operate on slice s in project p, or a delegate of creator(s), subject to PA’s policies for p.

Any GENI user may create a slice s for a project p if p was approved by a qualified PA, and the request conforms to PA’s policies for p.

Any approved professor may create and lead a GENI project p. Leader(p) may designate approved GENI users as members of p. Any member of p may create a slice s in p.

PA

1 2

34

t

Policy rules: examples

Guard policy to create a sliceSA: createSlice(X, p) SA: projectAuthority(PA), PA: project(p), SA: rootPrincipal(PA, p), PA: createSlice(X, p).

Guard policy to create a projectPA: createProject(X) PA: memberAuthority(MA), MA: geniUser(X), MA: faculty(X).

“The Project Authority PA approves creation of a project if an accepted Member Authority MA says that the requester X is a faculty member who has registered as a GENI user.”

“The Slice Authority SA approves creation of a slice if a Project Authority PA accepted by SA says that the requester X has createSlice rights in a valid project p, where PA is the root of p.”

Guard policy to create a slice in a projectPA: createSlice(X, p) PA.member(X, p, instantiate).

“The Project Authority PA approves creation of a slice in a project p if the requester X is a member of the project p with instantiate privilege.”

SAFE GENI: Capabilities

Credential Store

object root R

R:owner(E,s)R:cap*(E,s)

server

E:cap*(D,s)

E

D:cap(C,s)

Dcreate s

Ccontrol s

2 3 4

1 5

6Fetch certs

Capability delegation rulecap*(X, z) cap*(Y, z), Y:cap*(X, z)

Confined delegation rulecap(X, z) cap*(Y, z), Y:cap(X, z)

Capability guard rulecap(X, z) cap*(X, z)control(X, z) cap(X, z), …

capability(Subject, Object, Priv, Delegatable) :- Delegator: delegateCap(Subject, Object, Priv, Delegatable), capability(Delegator, Object, Priv, true).

Concept: access control matrix

Alice

Bob

obj1 obj2

RW

RWR

---

We can imagine the set of all allowed accesses for all subjects over all objects as a huge matrix.

How is the matrix stored?

Concept: ACLs and capabilities

Alice

Bob

obj1 obj2

RW

RWR

---

How is the matrix stored?

• Capabilities: each subject holds a list of its rights and presents them as proof of access rights. In many systems, a capability is an unforgeable reference/token that confers specific rights to access a specific object.

• Access control list (ACL): each object stores a list of identifiers of subjects permitted to access it.

capability list

ACL

Explicit delegation in SAFE

Server access control using SAFE

SAFE GENI

• Multi-provider cloud with evolving trust structure

• Local autonomy: cloud/transport providers with local trust policies governing interactions with peers

• Delegatable access control for global objects: e.g., groups (projects) and slices.

• Policy mobility: creator/owner of a global object defines access policy applied wherever the object is used.

• Federated identity (SAML identity portal)

• Flexible federation across G*-deployments

• (Secure SDN within/across/to/from slices)

Concept: roles or groups

Alice

Bob

wizard student

yes

yesno

no

• A role or group is a named set S of subjects. Or, equivalently, it is a named boolean predicate that is true for subject s iff s S.

• Roles/groups provide a level of indirection that simplifies the access control matrix, and makes it easier to store and manage.

• From the GENI example: authority roles, projects.

roles, groups

wizard

student

obj1 obj2

objects

RW

RWR

---

Example: Amazon Public Cloud (AWS)AWS Identity and Access Management (IAM)

Alice

Bob

wizard student

yes

yesno

no

roles, groups

wizard

student

obj1 obj2

objects

RW

RWR

---

• An AWS customer creates an account with a payment method.

• The account holder/administrator for an organization may define many users, groups, and/or roles linked to the account.

• Policies may be attached to users, groups, roles, or resources: ACLs (“resource-based policies”) or capabilities (“user-based policies”).

• Users, groups, roles, and resources may have pathnames in a name hierarchy, like the Unix FS: Amazon Resource Names (ARNs).

account

AWS Identity and Access (IAM)

Resources in AWS services: EC2, S3, EBS, …

subjectsusers, roles,

groups

objects

actions

create,describe,

run/launch,stop/start,

attach,destroy

Principals authenticated by access keys etc.

VM instances, images, volumes, buckets, queues,

snapshots

Subjects request actions on objects managed by AWS services. IAM provides a framework for authorizing actions across AWS services. Subjects wield cryptographic security credentials (e.g., access keys) to authenticate their requests to services and to IAM.

account

AWS Identity and Access (IAM)

Access policy documents (JSON) attached to subjects and/or objects contain statements to allow/deny access for named actions by named subjects on named objects. All names may be pathnames: policies may use prefix match/wildcarding. An IAM policy evaluation engine makes the access control decisions.

subjectsusers, roles,

groups

objectsVM instances,

images, volumes, buckets, queues,

snapshots

JSONpolicy

JSONpolicy

actions

create,describe,

run/launch,stop/start,

attach,destroy

Limitations of AWS IAM

• IAM is powerful.

• It is an example of an advanced access control system used in practice in a state-of-the-art cloud service.

• But: it can be used only on the AWS platform, with AWS as a central trusted monitor/authority.

• I would like to create an access control framework for use with many services, operated by different parties.

• And with no central trusted authority.

• We want it decentralized and federated.

Federated groups with nesting inSFS (SOSP 2003)

tagAccess(Tag, User, Delegatable) :- Owner := rootId(Tag), Owner: delegateTagAccess(Tag, User, Delegatable). tagAccess(Tag, User, Delegatable) :- Delegator: delegateTagAccess(Tag, User, Delegatable), tagAccess(Tag, Delegator, true).

tagAccess(Tag, User, false) :- nestedTag(Tag, ContainedTag), tagAccess(ContainedTag, User, Delegatable).

Federated group/tag membership

nestedTag(Tag, ContainedTag) :- SrcOwner := rootId(Tag), SrcOwner: delegateNestedTag(Tag, ContainedTag).

nestedTag(Tag, ContainedTag) :- SrcOwner := rootId(Tag), SrcOwner: delegateNestedTag(Tag, MidTag), nestedTag(MidTag, ContainedTag).

Nested groups/tags

member(User, Project, true) :- owner(User, Project). member(User, Project, Delegatable) :- Delegator: delegateMember(User, Project, Delegatable), member(Delegator, Project, true). memberPrivilege(User, Project, Priv, Delegatable) :- Delegator: delegateMemberPrivilege(User, Project, Priv, Delegatable), memberPrivilege(Delegator, Project, Priv, true).

Project membership with roles

Elements of trust logic

Also known as:

Credentials-BasedLogic-BasedRole-Based

Attribute-Based

Trust ManagementTrust

AuthorizationAccess Control

1. Knowledge about principals is represented as logic statements.

– Principals have secure names (e.g., public key/hash as in SPKI/SDSI).

– Build statements from atomic statements (atoms) and logical operators.

2. Predicates / atoms represent roles, attributes, capabilities, etc.

– Predicates range over principals and/or other named domain elements.

3. Atoms are qualified with says operator: who says or believes it.

4. Statements are authenticated and may be shared over a network.

“Slang” logic set constructor

defcon trustStructure() :- spec('Federation trust structure: adopted by all participants'), { memberAuthority(IdP) :- geniRoot(Geni), Geni: memberAuthority(IdP). sliceAuthority(SA) :- geniRoot(Geni), Geni: sliceAuthority(SA). projectAuthority(PA) :- geniRoot(Geni), Geni: projectAuthority(PA). aggregate(Agg) :- geniRoot(Geni), Geni: aggregate(Agg). label('geni/trust-structure'). }.

Slang supports:

• logic set templates with environment variables and self-substitution

• set linking (union by reference)

• post/fetch, externalize/validate sets as signed certificates

• assemble customized proof context for guard

A SAFE-encoded logic set

'K-3sGe-evxlRgOYu_225ja28wJADQsoqNib9D_f3dK8'(encoding(’safe'),status('active', 'Mon Jul 14 12:24:52 EDT 2014', 'first created'),speakerId('P-OJVA7CrXq4Wd2ij__iEoJbvaLYpQnGiy3RQR1DZHo'),subjectId('P-OJVA7CrXq4Wd2ij__iEoJbvaLYpQnGiy3RQR1DZHo'),notBefore('Mon Aug 14 12:24:52 EDT 2014'),notAfter('Thu Aug 13 12:39:52 EDT 2017'),'endorse()’ {link('P-OJVA7CrXq4Wd2ij__iEoJbvaLYpQnGiy3RQR1DZHo') :- spec(“ihost identity set").runs(qsyPAoGAd8wfPv...FuG7m, kIFJtaA8soeI...ozdUcxJF).},signature('ALtNPgXy5iW-yNrjxLo2bbf1TESdVr-..._ud73JWKcEpxSkmcQcA_EoERlgx-b2Z'), signatureAlgorithm('SHA256withRSA')).

http://152.3.144.16:10018/buckets/safesets/keys/K-3sGe-evxlRgOYu_225ja28wJADQsoqNib9D_f3dK8

- Digitally signed; principal names are public key hashes.- Object and principal names are cryptographically secure.- This example is an attestation of an instance from a cloud provider.

Descriptive complexity (simplified)

TLLTL

MTL

All trust logics“Little Trust Logic”Precisely equivalent to datalog+ (e.g., w/ stratified negation and/or tractable ordered constraint domains and constraint goals).

RTx

“Minimalist Trust Logic”A trust logic we define, drawing from datalog-subset logics. Inference suitable for practical embedding in real systems (SAFE)

Role-based Trust[Li, Mitchell, Winsborough]On which our previous work and prototypes are based (RT0/ABAC).

PCA, DKAL, ABLP, PolicyMaker.E.g., policy scripts, with cardinality, over predicates, arbitrary negation

LTL subsetsQCM/SD3, DelegationLog,SPKI/SDSI,SecPAL, Binder, Grey, NAL, SENDLOG