Is there life after X.509 ? Security Workshop Globus World 2004

1. Is there life after X.509 ?Security WorkshopGlobus World 2004 Frank Siebenlist (PhD) Argonne National Laboratory The Globus Alliance franks@mcs.anl.gov http://www.globus.org/

2. Objective • Provoke discussion • So boring if we all agree • The X509/PKI dream clearly never came thru… • Learn from deployment issues • Maybe alternatives would work better • X509 is used in ways it was never intended… • Our proxy-certs are a good example • Some entertainment for the last talk on Friday late afternoon at the end of a looong conference • … plus it’s therapeutic for me rant on about this… ATI 2004: Grid Security

3. Questions, Questions, Questions… • Why pay $20/EE-cert and 0$ for a Kerberos principal? • Why are lawyers involved with CAs, but not with other authentication/assertion services? • Why are there no armed guards to protect the attribute/authorization servers? • Is the Subject’s DN ever meant to be readable? • Who are the poor people that use DNs? • Why do username/password systems work? • Why doesn’t everyone check revocation in real-time? • How many more RFCs is PKIX going to produce? • What is that “pixie-dust” on those X.509 certs? • Will my children in 20 years still suffer from X.509? ATI 2004: Grid Security

4. Trusted third party (CA) vouches that combination of a public key and some (identity) information applies to the subject that can prove the possession of the associated private key. “Vouching” through signing Implicit trust of CA CA signature “binds” identity information to public key CA responsible for revocation/renewal X.509 Certificate Certificate Identity Info (DN & other stuff) Public Key CA Identifier CA Signature ATI 2004: Grid Security

5. X.509 Identity Certificate • Vetting of the “real” identity by a RA • Binding of the public key to the subject name by CA • Plus some other stuff • Guarantees about uniqueness of name • CAs somehow have to agree on part of name space • CA also responsible for certificate revocation • CRLs, OCSP, ??? • After path validation, relying party can use subject name in place of key • Issuer becomes “X.509” • Expensive to do all of this correctly ATI 2004: Grid Security

6. Need for On-line Certificate Revocation Checking • “Real” deployments need real-time, on-line certificate revocation checking • Business needs to know if a key is compromised • Issuance of CRLs not frequent enough • Off-line PKI turns out to be just a dream… • Deployment no different from Kerberos-like system • Any real-time, mission critical, on-line system is expensive ATI 2004: Grid Security

7. 1. Exchange of Certs/Public-Keys Challenge/Response Proof of Private Key Possession Client Server (there should be an equivalent authentication procedure for the client) 2. Validate CA-Chain 3. Check Certificate Revocation in real-time Public Key Authentication (on-line PKI) Online Certificate Status Protocol (OCSP) Server ATI 2004: Grid Security

8. Key => Subject => userId + Attributes • (almost) nobody uses DN • Not a very friendly format • Already other identifiers in placecustomerId, SS#, drivers-license, ??? • Privacy considerations • Etc., etc. • Plus… any serious application needs user attributes • Group membership, roles, clearance levels, credit card numbers/limits, address, etc. • Real-time, on-line lookup of userId + attributes • Equivalent “vetting” or RA-procedure to map subject to userId+attributes • Differentiate the Bills from the Wills from the Williams from the William III…. ATI 2004: Grid Security

9. 1. Authentication Protocol 6. Business Logic uses all kinds of attributes (NOT AuthenticationId) Client Server 2. Check validity of Authentication 4. Authentication "Id" 5. Attributes (groups/roles, access/audit-Id) 3. Authentication Result Real-World "Authentication” always includes Attribute Acquisition Attribute Server Authentication Server ATI 2004: Grid Security

10. Central Path Validation Service (CPVS) • Path validation is complicated, error-prone, expensive, black magic,… • Centralize its function as a “CPVS” Service • Maybe require registration first • Users authenticate with certificate • Service performs path validation • Registers/caches results • All other services do “key-only” authentication • Query CPVS for validation (+ userId/attributes) • (Redirection protocol for those that forgot to register first…) • (XKMS protocol could be used for this…) ATI 2004: Grid Security

11. 1. Exchange of Public-Keys Challenge/Response Proof of Private Key Possession Client Server 2. Check key validity 0. Register certificates 3. Return relevant attributes Online Central Path Validation Service Check certificate revocations/validity ATI 2004: Grid Security

12. Key => userId + Attributes • We have to make real-time, online lookups anyway… • Revocation check • userId + attributes • Why do we need the x.509/subject name? • Key => userId + attributes • Elimination of extra indirection • Human Resource can “bind” key to userId record • Similar to X.509-RA procedure • Key revocation/renewal is simple • Update of database record • (XKMS could be used for this…) ATI 2004: Grid Security

13. 1. Authentication Protocol based on key only 4. Business Logic uses all kinds of attributes (NOT AuthenticationId) Client Server 2. Key 3. Attributes (groups/roles, access/audit-Id) Direct mapping of Key=> Attributes in Corporate Attribute Svc Attribute Server ATI 2004: Grid Security

14. Key Revocation/Renewal… • Lost or compromised key – who to tell? • Revocation: removal of “key => userId/attributes” mapping • Renewal: new “key => userId/attribute” mapping • Have to go through (alternative) authentication/registration procedure • Not different from x.509… • Every registry that maintains mapping must be updated! • One registry => no issue • Many registries => big issue • May not work well for “very” distributed Grid applications ATI 2004: Grid Security

15. Key Revocation & Many Registries • Use a trusted third party as revocation service • Only revocation, not key renewal… • Less trust involved • Register both key and revocation service with RAs • Key mapping service should check with revocation svc • PGP-like… • Doesn’t solve renewal… • Still has to be done “in person” ATI 2004: Grid Security

16. Master Key & Proxy Key • Master Key will be ultimate “authority” • To empower proxy key • To revoke proxy key • To “renew” by empowering new proxy key • All through assertions • Central revocation service still useful • Similar to PGP without email “identity” • Similar to proxy-cert without subject • But … user has to store/maintain/manage extra key • Arguably incapable to manage any long term key… ATI 2004: Grid Security

17. Non-Identity X.509 Certificate • Use X.509 certificate for that one extra level of indirection… • But not for “identity”! • Subject name just some meaningless unique number • “identity vetting” will be left to key => userId/attribute registration • Use X.509 standard certificate revocation/renewal methods • Registration/revocation/renewal still requires (alternative) authentication with RA/CA • Password/mother’s maiden name/??? • Or … drivers license, passport, finger print, ???not for identity vetting but to ensure that the person who registers/revokes/renews is the same person • Non-Identity CA much cheaper to operate • ESNet opportunity (getting close already…) ATI 2004: Grid Security

18. “Public-Key=Identity” X.509 Certificate • Existing SSL runtime spoils the fun… • Requires exchange of real certs • Baked-in path validation process • Pre-configured list of “trusted” CAs • We could use public key as subject name • (base64 of sha1 digest of key) • Need a real CA to vouch for that binding • Must be “trusted” to bind the right thing • No vetting of identity, though! • Much cheaper to deploy. • Maybe a nice ESNet service… the PK-CA ATI 2004: Grid Security

19. Conclusion • Alternative “CAs” are moving in • MyProxy as a “CA”? That stores private keys… • KX509 • ESNet’s use of DNs is “interesting”… • How to establish the “trust” in these heretic-CAs? • Need “language” to express deployment trust levels • PKIX standardization of proxy-certs… • Absolutely unthinkable five years ago! • Use of X.509 because of revocation not identity… • Slowly the X.509 religion is eroding/enriched… • Equivalent of same-sex marriage, gay Bishops, … • Alternative identity assertions • SAML, LA/WS-Federation… • There are alternatives to X.509 deployment… • Some cheaper, easier to deploy – depends on application • XKMS-like tools allow for migration & enables alternatives ATI 2004: Grid Security