CA Statistics: 221 total certs issued.
Signed applets. delivered to browser. because of signing applet can perform activities outside the sandbox. Planned to use as a replacement for grid-cert-*, grid-proxy-*, myproxy-*. Cert & key generated by applet.
Back-end scripts based on Globus CA scripts. Looking for collaboration to use and harden these. Will be freely available on the web
Structure changed to meet future needs.
SeeGrid (one of 3 FP6 EU Grid projects). Bootstrap south-eastern Europe on the Grid.
CA machine rebuilt over summer. 130 certs issued, around 30 expired. Expect an increase (~100 new users, plus clusters, etc.) from new projects.
New CPS. Set maximum length on CN and OU fields in subject. Auto delete requests if they have not have been verified.
Using signed-applets.
Update CPS for data-protection act.
Condor service certs. use “condor” as the service even though there’s no condor protocol.
Anders: Does OpenCA provide access to users? Jens: limited browser support. hard to upgrade because of modifications.
Recent OpenCA problem needs to be investigated.
Firb project: Now issuing certs for institutions other than INFN. Number of RAs expanding. 800 certs. Request tracker used by CA for tracking cert requests and all correspondance from RA, CA.
Would like to use applets for interoperability with Windows, Mac OS, etc.
Reissued root cert.
200 server certs on bootstrap CA.
Trying to get services to use DOEgrids service certs.
New testbed with NorduGrid software.
Will require a new CA. Planning to use OpenCA.
CERN CA cert expired in November. Most users rolled over successfully starting in September.
User no longer has to make request from a single machine.
New website.
Nothing to report
Recently expired CA cert. Plans for future expansion.
Wants more scalable system. Something better than current bunch of scripts.
(presentation online)
If not every CA runs OCSP then there will be a mixture of CRLs and OCSP. Anyone can publish CRL data in an OCSP service.
Experimental service downloads CRLs from EDG CAs.
Could OCSP service apply for service certs from each CA and sign OCSP responses with these?
CA includes OCSP URL in certs. OCSP attached to CA. Doesn’t scale.
Multiple CAs and central OCSP which takes CRLs. Signing keys don’t match.
OCSP responder should be able to get CRLs and contact other OCSPs and cache responses.
Grid tools will have to contact OCSP server, but could cache. DNS-like system. Data carries its lifetime optionally. Not required by RFC. Need to get all clients and servers to work with this. May not be implemented in future as it’s not required by the RFC standard.
OCSP response not bound to a cert. identified by name or key hash. Responder can be multiply certified.
OCSP chaining requires response verification policy to be specified. certified on one private key.
Major problem is support from clients. Prospects of having Globus 3 out not before one year. Need to specify what is required from clients and servers.
Have OCSP as a value-added service. Important that we can fall back to CRLs.
With experimental service, OCSP URL will be in cert, but server can’t handle multiple requests.
Privacy issue: OCSP responses corresponding to incoming SSL requests can provide information about who’s making the requests.
Community practise document at GGF. Milan Sova, Mike Helm
Specify that OCSP is secondary to CRLs? Don’t want dependency on the service.
Should service have a whitelist? OCSP rejected this. “Good” in OCSP means “not necessarily bad”.
Identity certificates for automated clients, with OU=Robots but not allowed by current policies. Certs will be shared which violates policies.
With a separate CA for robots relying parties can more easily distinguish between robots and other end entities.
If a services cert is revoked on a host should all robot certs be revoked as well?
How is a robot cert protected? not encrypted so it needs to be tied to some network entity, for example. Would CN=”robot/hostname” be better.
CESNET cannot modify CP so would have to run another CA.
These certs will have privileges of admin/daemon users.
Something like this is clearly necessary within LCG at RAL.
Basing trust on OU field makes things difficult. But another CA requires CRLs, etc. Yesterday we didn’t like subordinate CAs.
One robot CA for the whole community. Namespaces would be odd. Instead of using OU field, have a completely seperate namespace. O=grid-robots…
IF C and Java services use signing-policy file adding a robot signing-policy file would provide support transparently.
Critical ExtendedKeyUsage extension would be rejected by unsupporting clients. But clients are currently run by real people and won’t be modified for robots. No applications understand it now. Services that are to be monitored need to change.
Will DOE use signing policy file? But some groups don’t use these.
Should just be a configuration change for software (but it may require code changes).
(presentation online)
IETF group PKIX working for years, now getting wound up. Has worked well for interoperability.
Certificate management protocols CMP and CMC which do the same things in pointlessly different ways. Not used very often but are used internally in some CA software.
CRLs are bad so various online systems were proposed. Possibilities for delta CRLs, etc. In OCSP “good” means “not bad” which might be the case if a cert was never issued!
SCVP tries to catch more corner cases, etc. You can effectively do away with certs, CAs and have one SCVP for the universe. You can request public keys from the service.
Attribute Certificate like a cert where you take out the key and put in the attributes. ACs would not be used today and something XML-ish instead.
SACRED has no known implementation. Intended to hold credentials online. Based on BEEP which is an application protocol (not XML-ish)
OASIS very vendor driven.
SAML will provide authorisation tools and XACML provides the ACLs. Standardising access controls may not be a good idea. Domain-specific versions may be more sensible.
W3C XMLENC and XMLSIG equivalent to PKCS7. Quite possible to write a complex signed doc that no-one could verify. Sig block can contain programmatic statement in XMLPATH. But there are de facto standards for using these.
XKMS (instead of OCSP) without so many points of failure. XKMS can provide a frontend for X509 PKI but legacy X509 stuff shouldn’t leak into XKMS.
XKISS Can locate keys for an entity. Part of sig block can be sent to server and get back a response “it’s a good key”.
It may seem a good idea to standardise policy but others will then have to understand and interpret the policy. It could be quite reasonable to ignore revocations if, for example, certs were revoked as a denial of service attack.
X-KRSS is the registration part.
Better spedning time on accounting and auditing. Use RADIUS (and now Diameter) It’s important to know what’s going on.
Authentication based on network sources: find out who is the foreign institution. Don’t care who it is as long as we can find bad people.
Is it necessary to tie key management to authentication?
Authorization using token-passing can be slow, have problems with network. Delegation using AC: 109 certs per purchase at Canadian DoD. Authorization server with a query protocol is arguably better.
Accounting has lots of denial of service possibilities. Audit Identity: In german law can’t put real name in audit logs. Use pseudonyms to avoid breaching privacy. Could use hash-chains for this.
What systems should be used? What analysis should be done?
Less than PKI did. Only standardise for run-time interoperability. No policy-mappings.
Security levels: Don’t need the best mechanisms everywhere
http://middleware.internet2.edu/pki04 papers due: end Jan
http://www.aegean.gr/EuroPKI2004 papers due: mid Feb
Authentication: Peer IP addres may be good enough or use IPSec. Remote credential service better than having private key available on the local harddisk all the time!
Entity Recognition (ER) “someone makes a particular request at 9am” and it’s always the same guy.
Authn checking with XKMS. Change server with HTTP redirect.
Delegation don’t need delegation at intermediate delegation steps.
Find out how to include kerberos (and win2000) for interoperability
Authorisation should use mapping from Grid authenticated ID to OS authorization. SAML for other cases. Don’t need to standardise ACLs, etc. because all that’s seen in the protocol is “yes” or “no”
Accounting: probably RADIUS.
Other security services. Use IPSec but requires application awareness to know something can be sent “in the clear” over IPSec. We could provide Grid PKI for IPSec. Maybe cheaper to setup tunnels between sites rather than deal with identities…
Write sample code for integrity and confidentiality that can be incorporated into apps. Flexibility in changing level of security by apps or admin.
Analyse performance of token based authorisation mechanisms.
Important to provide for maximum security but use minimal acceptable security.
(presentation online)
Grid Administrator is a registration agent for a site or cluster of machines. Can only issue service certificates.
Why not have DNS Admin be the reg agent? Not possible at most sites. DNS Admin usually knows who is responsible for individual machines.
Based on min requirements 16 out of 22 failing default ruleset, therefore failing min requirements!
Extract info from certs, also from CP/CPS.
(slides from Sophie Nicoud)
What happens when DataGrid CA finishes?
Will not provide catch-all in future. David G: it may be possble to get EGEE SA1 to run a CA.
CNRS Catch-all RAs are assigned a name space, but the CA will sign any namespace.
Suggestion: Have a single Catch-all CA.
Do we still need one? Previous was for a project with users who need to join but don’t have a suitable CA.
The catch-all means that there is little pressure to setup smaller CAs. But this may be a good thing.
What is the charter of the catch-all? Why not use Verisign?
Needs to make entry easy for new user communities. With a catch-all new countries can come in if they setup an RA.
David G will draft a document to send to SA1
(presentation online)
Responsibilities discussion should go into PMA charter.
How will relying parties be represented in the PMA?
Relations with other regions: Americas, Asia-Pacific
When Online Cert Checking tools are designed they could possibly be implemented as a student project. Licensing will be important.
Produce some guidelines for running OpenCA. Why not buy a CA product? Money allocated to manpower.
Repository has a master list of CAs. Similar to IANA. gridpma.org seems the obvious place. There should be checking for namespace overlap in the repository. Why not ask IANA? GGF do not want to do it. GGF asked previously but they may have a better chance now.
Should PMAs be organised geographically? Good to have groupings where we don’t spend too much time talking/arguing about technologies.
David Groep is the interim chair to lead this PMA effort. The most important job of the PMA is to keep things working. If there are no objections, charter will be based on minimum requirements.
National Grid projects represented through national CA: not applicable to some countries (Czech Republic).
TERENA is building PK Infrastructures and we are seeing multiple PKIs in some countries. And there may be conflicts.
Repository of CA roots. Complex policy document to say how CAs are accepted. http://www.terena.nl/tech/task-forces/tf-aace/CArepository/doc/CACRepository-draft-5.pdf
No assessment or approval. But implicit approval: “these are Terena’s CAs”.
TERENA is a member of EGEE. Christos: Some NRENs are getting into running CAs.
http://www.pd.infn.it/einfrastructures/program.html
EU policies should encourage (enforce?) sharing of resources. Working with “cyberinfrastructure committee” in the US. Part of the EU official calendar.
Delegations from each country with representatives from funding body and from trade & industry.
Was to be a talking shop but redirected to be more pragmatic. They have chosen the area of authentication and authorisation to investigate.
NRENs may promote their AA policies and we should give input as well. Something to be done before April.
Want to collect exisitng policies and a registry. Registry of associated resources. Minimum requirements would be a good document, also CP/CPSs. Put into a repository. AUPs would also be included.
For any responsibilities that CAs don’t take someone has to. VOs are interested to do this in the US but may not be aware what this means.
Q1: Who is responsible for assuring that each subject is unique
A: Should get sorted out by change in catch-all and by RA practices
Q2: Who is responsible Assuring cert is issued to appropriate entity
A: Again covered by CP/CPS and RA duties
Q3: Who assures CAs private key is well enough protected
A: CAs
Q4: Who is responsible for assuring that compromised identities are revoked
A: CAs
Q5: Who is responsible for assuring that private key is held only by subject
A:
Q6: Who is responsible for assuring that proxies aren;t stolen
A: Managers of services
Scanned for bad permissions on .globus dirs. 80% (of 20) wrong on AFS cell. OpenSSL checks for the unix permissions of these files and doesn’t know about AFS permissions but this is too complicated. Then again, this is on a shared network fs, so key is exposed on the network. Stephen: There are in memory attacks also.
Policies don’t consider exposure of the encrypted private key to be a compromise.
Concern of DoS. “I think this encrypted private key is Dane’s. Revoke it.” Anyone who has an password encrypted key could crack it and then could revoke.
Who’s responsible for correcting this problem. Many sites have keys on a machine which has another administrator.
Anyone hosting home directories is taking responsibility to scan and fix permissions on keys.
Stephen: grade RAs based on the behaviour of the users who get certs.
VSC: issue into a repository where user never has access to private key.
Applets for grid cert stuff will check passphrases, permissions, etc. but nothing stops a user doing something with the files later.
If you have evidence that the policy has been breached (passphrase too short, etc.) then revoke.
User with key exposure may not be at a particular site. Key on grid store for example.
Suggestion: Instead of revoking just delete the file! But it could have been copied.
Encrypted Key will usually be with a cert. Cert can be traced to user. But the key could be cracked and then revoked.
CA has to know who the RA was for each user. Should it be passed back to the RA who can then deal with user?
Dane: I can disable authorisation for a user but can’t do much to help other sites.
Only possibility is to have some relationships between CAs and VOs. Who takes responsibility for stopping an experiment?!
May be simpler to crack it and revoke it. Person requesting for revocation takes responsibility for revocation? Who takes responsibility/gets sued. Encrypted documents lost, etc.
But aim should be to improve behaviour of users. It may not be legal to crack keys.
Anyone can report exposed certs to the CA. Feedback for training RAs.
Aside: Cracking could be distributed on the Grid!
So, RA or owner of key can revoke. No, anyone who has the private key. No, RA acts on report from holder of the private key.
What is the legality of crakcing? Dane: if I find a key on my filesystem I can crack it.
Dane found a CERN cert on FermiLab. Without cracking a key then if a user has multiple certs should we revoke all of them?
We report to the CA for informational purposes and they do whatever they would like.
So far there hasn’t been a break in from this exposure.
What do CPSs say about this?
Tools to search and report would be useful. SACRED requirements RFC provides some useful info on threats to online repositories.
Report to peers at users local site for education.
Jobs may break for users who see jobs failing in one site… VOs need to be involved.
CPS says that Users have responsibility. RAs should convey this information. May require RA training.
Interesting to investigate at other sites.
Credential repositories avoid these but have their own problems. KCA doesn’t require any private keys to be held by user or repository,
Christos gets his users to sign an email with the CP/CPS attached.
The Journal of Grid Computing.
Looking for contributions from EDG
Intro in Feb, Paper in May.
CA paper should have final version of minimum requirements. Coverage of CAs and table of features. At least one CA of each particular variety.
Discussion of open issues.
Demonstration of OCSP.
Should be one flagship paper. Perhaps others on specific issues.
David O’Callaghan will look after managing this.
Minimum requirements should be firmed up.
Interaction with VOs to decide what are the trusted sources of authenticaiton.
Review of first meeting by Dave Kelsey.
First meeting of EGEE PMA in Florence, perhaps. Deciding soon would be advisable.
Need a domain for a new group, mailing list, etc.