Credential Store: an Overview

1. Credential Store: an Overview Jeff Chase Duke University Thanks: NSF TC CNS-0910653

2. Preface This slide deck is part of a larger series on authorization framework for GENI. The complete series can be found on: http://groups.geni.net/geni/wiki/AuthStoryBoard The other slides in that series deal with how credentials are created and used in GENI if a trust management approach is adopted. A trust management approach presumes that authorization is based on signed assertions (credentials). But it leads to a complex problem of getting the right credentials to the right place at the right time. It also raises challenges of key rotation (loss or retirement) and revocation. These are the challenges we’re trying to address here. But the details are still a little sketchy…

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

4. 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) Payload: assertion Signature

5. All is not sweetness and light • TM approach is based on signed assertions and credentials (certs). • And libabac uses X.509…. • That presents challenges for which there is no perfect solution. • And so there is: • Fear • Uncertainty • Doubt Image used without permission or right from 'Stories of the Gods and Heroes' by Sally Benson, 1940, Dial Press. Reprinted in Colliers Junior Classics, 'Legends of Long Ago', 1962.

6. Summary of GENI Motivation • Signed security assertions enable decentralization • Essential GENI-CH functions distill down to credentialing. • Problem: GENI needs Big Brother, at least for now. • Solution: event logs and CH-endorsed principals • But Big Brother needs the certs to identify other accountable parties. • And Big Brother is nervous about PKI… • Proposal: public always-on credential store • Cert query  context • Short-term caching, configurable TTL • Refresh for renewal • “Poisoning” for revocation

7. Next questionCredential flow What does it really mean?

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

9. 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. Put issued credentials and policies (certs) in the store. Cert Store Get certs to “cache or check”. Pass credentials by reference in request. Server See also: Conchord, CERTDIST

10. Key-value store with access control • Base it on a standard key-value store model. • Every object in the store is indexed by a unique token (key). • Tokens are large, sparse, unforgeable, collision-resistant. • Any entity that knows the token may get the object. • Use a new access control model for cert storage. • Only an owner of the object or token may put or modify. • Must trust the store to enforce access control correctly. • Ownership is based on possession of a keypair. • Each cert in the store is owned by its issuer. • An X.509 identity cert is also owned by its subject. • Other entities may maintain their own sets of certs.

11. Storing a cert • A cert’s token is a secure hash of its contents: H(cert). • The term and issuer key for a cert are visible to the store and verifiable under the cert’s signature. • The store verifies the token. Anyone in possession of a cert may put it in the store under its token. Certificate Issuer Term of validity Signature A stored cert also has a status field, which may be written only by the owner. Anyone who knows the token (or the cert) may read the status.

12. Poisoning a cert • The owner of a cert may poison the cert. • Poisoning places an indelible mark in the cert’s status field. The cert is poisoned forever. Anyone who knows the token (or the cert) may check if it is poisoned. A poisoned cert may be treated as revoked (OCSP).

13. Replacing a cert • The owner of a cert may replace the cert. • The replace operation leaves a token in the status field. • The cert named by that token may be taken as a replacement for the original. Anyone who knows the token (or the cert) may check if it has been replaced, and if so, fetch the replacement. Certificate Issuer Term of validity Signature

14. Sets • Each object in the store is either: • a single cert, or • a set of objects incorporated by reference. This token names a set of four certs. set of 3 tokens token set of 2 tokens Anyone with the set token may fetch the entire set recursively… …including any poison notices or replacements.

15. Set tokens • A principal P may create a set named by a token. • The token must derive from P’s public key: • Token = H(P, v1, …, vn) for some v1, …, vn chosen by P. • P owns the token. set of 3 tokens H(P,v1, …, vn) set of 2 tokens A set owner may add arbitrary tokens to the set. The store can verify that P may control the set: P must produce v1, …, vn and prove its private key.

16. Using the cert store User tools gather subject certs in a set and pass by reference. Store object certs under the domain-qualified object name. H(PA,x) H(SA,s) T IdP.geniUserT IdP.studentT D.in_xT T.proxiesForSM H(PA,x) H(SA,s) SA PA AM Create sliver for slice s

17. Discussion: cert store • The set mechanisms are sufficiently powerful and flexible to group related certs in various useful ways. • We need new user tools for delegation: • Generate a new cert and enter it in the store. • Pass a reference to delegate, e.g., by e-mail. • Click to add new reference to a selected set. • How to prevent users from filling up the credential store? • Garbage-collect expired credentials, and even sets. • Optional: all set tokens must be endorsed by one of a small set of roots (IdPortal, SA, PA). • This option also enables tracking and cert graph mining. • GENI services can also collect/record set tokens they receive, to enable graph mining of certs used in GENI.

18. Key loss and key rotation • ABAC proof engine requires an X.509 identity cert for each key. • If a key is lost or rotated, the identity cert can be poisoned • By the subject if it is self-signed (“suicide note”). • By the issuing CA if there is one. • Replace all certs referencing the old key. • Replace all certs issued by the old key.

19. Backup, for reference

20. ABAC in Context ABAC inference engine trust anchors operator attributes + capabilities authorization policies Query A.COE? Request Command C on Object O Client E Server A query context user delegation credential set for C A’s policies for O Context transfer credential set context store context store GEC-11 Auth Session

21. ABAC in ORCA ABAC inference engine • Integration complete; policies checked out. • Credential management: still “rough edges” • Not yet in production. Query A.COE? Request Command C on Object O Client E Server A query context Direct-injected contexts from unspecified credential sources credential set for C A’s policies for O context store GEC-12 Auth Session