EU Grid PMA 2005-01-28 ====================== Guidelines document developed in TAGPMA almost identical to EU Grid PMA except when discussing end-entity certs and lifetime. > WW: Is MyProxy acceptable under rules of PMA. > > DG: Normal use is OK. Storing a short-lived proxy. > > DK: RPs or this group should define best practices for running MyProxy > service. Are any CAs considering offering such a service? > > MH: FusionGrid MyProxy/CA. Following NERSC MyProxy guidelines. When a service is running online availability becomes important. VO or other operator needs to budget for support. People will expect a 24x7 service. > MH: Wondering about support for RADIUS and one-time password. Talking to > vendor about 802.1x. Wouldn't be able to generate proxies at first but > should be possible in future. RADIUS server with account DB built in. http://www.infoblox.com/ Certs generated automatically. > > MS: Could develop Open Source version. Alternatively we buy commercial > software with some validation, but we can't see inside. > > MH: How's cryptographic engine certified? > > TG: Windows 2003 provides these services and is validated for government and > financial uses, etc. MH to send details to the list. > DG: Should we make a profile? > > MS: Somebody has to > > MH: Need some interested people > > JJ: We plan to use MyProxy like this. Users put longer term proxies in > Credential store. MyProxy uses MySQL DB to store credentials. > > MH interested in distributing credentials > > DG: Develop srevice and requirements in parallel > > AW: Do these ideas require new CAs, and hence new minimum requirements? > > DG: Several guidelines documents. All CAs accredited as appropriate. RPs > can accept all accredited CAs, or just certain profiles. Three categories: * Short lived cert is 1 megasecond (SIPS) * Long-lived held by user (Classic) * Long-lived held in certificate store (ACS) Can have multiple ACS with one CA in the background: decreases proliferation of CAs. ACS is probably quicker to implement. ACS need not be linked to a site, could accept multiple CAs. > MS: Why have a long-term credential? You have to authenticate for access to > the store anyway. Does store do crypto operations for you? It signs new > keypair with your private key. > > BC: Anybody can setup MyProxy without talking to us, and it should just > work. This is a relying party issue. > > MS: No, I must revoke certs that I know the private keys are stored on these > services. So this is a policy issue. > > BC: Not different to storing on NFS, etc. > > JJ: BC's reason is why I need ACS. Want users to have more secure remote > credential store than NFS. > > DG: Will there be a document on this in TAGPMA by May? > > TG: DS has been working on this. Software and Distribution Issues -------------------------------- Rekeying. If you change DN and hash then there is no problem. If you wish to preserve it, there may be problems. With OpenSSL there are .0, .1 files. CRLs in .r0, .r1 Has anybody tried this with Globus? This may not have been included in GSI. Need to work on updating CRLs. fetch-crl cannoth handle anything but .r0 files. .crl_url contains URL of CRL. > LS: Can cert extensions be used for specifying CRL. > > Not defined for root cert, intended for EE certs. > Is there a standard extension for OCSP location? yes. Again EE certs. Easy solution for a site is to delete CRLs. Most grid sw don't do CRL checking on the client side. > DG: Should encourage CAs to have CRL and OCSP locations in certs. > > AW: Who should install certs and CRLs? In some cases the user. > > MH: Software designed with network directory in mind. Out-source service to > XKMS to evaluate if cert is trustable by you. > Easier to subscribe to LBL XKMS service. > > AW: it shouldn't be up to the site manager to decide who you should talk to. > yum repository auto-updating and dependencies helps. > > MH: a lot of complexity. people don't always get it right. > Outsourcing to a service seems like a good idea. OCSP is a wedge... > Imagine a cert that I "think" I should trust but how do I know? Back to the CRL problem: Can you add more URLs to crl_url file? Anyone due for a change soon: AW, MS, DQ. Anyone willing to experiment: no! What's the ususal period to get new CAs iinstalled? Up to 6 months, maybe less than 1 month. Also needs to update fetch-crl scripts at sites. Un-fork fetch-crl script and host at EU Grid PMA. * Name * Dependencies * Perl * Wget/Curl > SN: why does LCG distribute CA/CRL through Marcus Schultz home page? > > DK: LCG includes additional CAs > > DG: sites should *mirror* eugridpma repository Do we need multiple tools for different dependencies? > DG: happy to host at EU Grid PMA. Personal Identity Verification -- FIPS 201 ------------------------------------------ HSPD-12 * Standard identitiy card -- US fed * PKI smart card + photo ID + other protocols * Very aggressive deployment calendar * Standard finished by 28 Feb 2005 * Deployment 01 Oct 2005 * Good news * Strong identity * PKI smart card * Less good news * technology * Includes photo and proximity stuff * Doesn't suit USB * International collaboratiosn * Unclear about non-national staff and others who should have access * Cost * Rumours * Who it will apply to * Adjustment to calendar Minimum Requirements -- Cert Extensions --------------------------------------- Should strongly-recommended extensions be listed in min reqs? (Modifications were made to Min Reqs during this session) Sun Java JCE, at least, cannot support 4096 bit CA keys. Problem in DEISA but not sure which JCE provider. Globus uses BouncyCastle. Until this problem is resolved is resolved keys should have 2048 bits. 4000 bits not tested. Make requirement that EE must have OID to identify. Put a timeline on this. New certs should have this starting in 6 months. In 1 year all issued certs should have it. CRL distribution point in EE certs. Require this? > MH: Originally extensions weren't included because tests had not been done. Standard extensions in RFC 3280. > TG: Possible that distribution points could get blocked by firewalls, etc. What protocol should we use for CRLDistributionPoints? Must at least provide HTTP (not HTTPS) URL. Standard says not to put basicConstraints in End Entity certs. > MH: Our CA software doesn't support basicConstraints in it. > Could say "basicConstraints MUST NOT be set to 'CA: true'". > RC: "Should" needs to be explained better in the preamble. If you run OCSP then MUST contain AuthorityInfoAccess. OCSP RFC 2560. Format is URI. Details in RFC shouldn't be duplicated in Min Reqs NSCertType must be compatible with keyUsage. > JJ: Added SSLClient to NSCertType and allowed different behaviour for renewing. > > MH: would like to get rid of them > > MS: No NS* extensions in Grid context > > RC: No NS* extensions for last 6 months RFC 2595 -- SubjectAltName Support for multiple DNS hostnames in browsers: > MS: can also be useful to have ipAddress in SubjectAltName Message digests must change to trustworthy hash mechanisms like SHA1, and avoid MD5. Minimum Requirements Update --------------------------- (Min reqs updated live) Discussion of requirement that CAs should not be bound to a specific projects and should be operated as a long-term commitment. Discussion of hierarchies: no longer such a key issue. Modified Section 1. Secure environments: CAs have to document or audit. Names: want entities to "own" the names. Come back to 3.2 after discussion Discussion on persistence of name bindings to entities. End Entity Certs * Change lifetime to 1 year + 1 month * Maybe have 2 years for server certs? Revocation * Trade off between "denial of service" and revocation of large numbers of certs * Attacks * Suspend would be useful * Easier to suspend authorisation Changes should take force 6 months after acceptance, and at most 1 year after. Minimum Requirements Future Directions and Research -- Jens Jensen ------------------------------------------------------------------ Trying to encode *intent*. * Trust * quantifiable risks * fuzzy risks Trust is axiomatic. Private Key Risks: * Traditional approach to private keys spreads risks across the Grid. * Online service concentrates risk: failure could be more catastrophic. At the moment the assests aren't that interesting. High-value cert protected by 6-digit passphrase or 16-digit on a sticky note. OTP adds extra factor, but out-sourced tokens might move risk. Software implemented OTP also possible: another set of risks. Credential repositories seem popular because big sites can run them. But big sites don't necessarily have great security record. Important to have threat analysis, intent, etc. > BC: If we did risk analysis we might find that we're wasting a lot of time > on CA stuff when it's a mess at the user level > DQ describes USB key with autorun Java application to provide proxy > creation, delegation, etc. Can enforce key hygiene, etc. Guarantees on Certificates -- Bob Cowles ---------------------------------------- ### Issue 1 ### Key is compromised. Attacker renews. Revocation doesn't catch new cert. > MS: User should be informed that a new certificate has been issued and > should have to accept the process. > > BC: Should renewals be allowed, say, 6 months before expiry? That should > raise a flag. May need to revoke certs with same DNs if renewed before revocation. EE can revoke cert without RA contact. > MH: But user could decide the cert is compromised, renew and revoke old one > in good faith. ### Issue 2 ### User claims to have lost old cert/keys. Will you re-issue cert with same DN? Social engineering opportunity. CA promises they will not issue to same person. This is an RA issue. The RA needs to check. > JJ: fine, until we need to handle two people with the same name. Do we have min. reqs. to hold onto identity documents? Not possible in some places? ### Issue 4 ### Disagreement about how multiple certs per DN and per user should be issued. ### Issue 6 ### Keys should only be signed once. If one user has a keypair, and a second user comes along with a new request/keypair that's the same, it is possible for them to find that they have the same keypair (i.e. they can see the existing cert) and then to impersonate the first user. First user should be informed and asked to renew? (Impersonator could attack this) > MH: Users like to renew with same keys. Convenient. > > DK: Same argument as asking users to change passwords. > > MS: 1024 bit public key available for 5 years is a risk > > MH: even if private key is in hardware? > > BC: If you're not going to change the key then what's the reason for renewal? > > MH: Lifetime of people, jobs, institutions, etc. > > BC: threat of replacing software users are using to generate keys by some > virus to reduce keyspace. ### Issue 5 ### A lot of software depending on DN being unique. RPs relying on CAs not to have overlapping namespace, and not to have unique DNs. RPs should log serial number as well as the DN. > DK: as more CAs come along, namespace coordination of CAs is getting more > difficult. VOMS stores CA DN, and cert DN. This is a problem for CA renewal. Existing software doesn't seem to log serial numbers. Authorization done on string comparison. Service Name Ownership -- Mike Helm ----------------------------------- Not quite like automated clients. Use same approach as OU=robots, which is not allowed by signing policy. > TG: can't run multiple services with the same name on the same host. service/ tags in CN don't have meaning to the clients or servers. Next Meeting ------------ Discuss dates of next meeting in Tallinn over mailing list.