User must have account at SLAC.
Once the user authenticates, generate a proxy (but without any long term cert): very similar to KCA. As long as the CA cert is accepted by VOs, this just works.
User doesn't have access to private key if server stores it. User has to provide a pass-phrase to the VSC server. With SSL strengthened by server cert. If the server is compromised, pass-phrases can be intercepted.
An attacker still has to authenticate before using the pass-phrase.
Is primary server superior to others? It signs for the optional servers. It is the root of trust for the system. The optional servers provide secure replicas.
Problems with trust of local authentication scheme? Easier to trust system managers in a small number of Tier A sites than all the users.
In LCG, Tier 2 resources larger in total than Tier 1 and users at a Tier 2 site, would wonder why they would have to authenticate at Tier 1.
There is code to put proxy cert in web browser cert stores. It's a PKCS11 module.
It's in fact a short-lived full cert.
Based on RSA entrust repository model.
VO Management: does LCG want other sites involved. This could involved having 140 sites... Minimum requirements could help.
If PMAs manage common practices, then there could be a PMA specifically for Online CAs.
These services are 7/24, so not suitable for smaller sites. This takes a lot of resources and this will rule out sites with less resources.
Supports multiple VOs. Will need HSM as this encompasses an online traditional CA.
Maybe a credential repository could be run outside of these experiments, as many of the CAs are. Repositories act like automatic RAs. The automatic RA uses the same requirements as a human RA.
Nice way to add already registered users to the Grid. Also use it for easy web authentication.
KCA is a freely distributed, so it's quite conceivable to modify it for using with HSM.
Apparently no major site using similar technology has had a compromise of the central authentication system.
Possible issue is that the key is sitting there. In KCA, there are redundant servers. These presumably use the same key. Putting them the same one in HSMs is tricky. So why not have multiple keys.
Helps that we're not introducing new infrastructure including user interface.
Others are working on a general solution that allows the use of other authentication mechanisms. xCA.
It's important to quantify risk.
Should CN be related to the entities real name? It is not wise to place any significance in a match between a CN and a real name.
We all have to trust authentication used on the Grid.
There appears to be some interest in deploying KCA services. It would be possible to have a meeting of interested people at GGF, including other online services. MyProxy, VOMS, etc.
There must be some minimum requirements for an online system, including running services, open ports. This is more detailed than existing min requirements.
The role of a PMA should include detailed configuration discussion. With separate PMAs it's important that there is interoperation between them.
It's important that the relying parties are represented in the meetings.
In CrossGrid there is an interest in MyProxy and in handling proxy certificates. Planning to follow DataGrid regarding authorization.
It seems that small sites are not well represented, and there is a danger that big sites will decide everything.
There have been discussions at CESNET regarding traditional and online CAs. There has been discussion of message formats, authorization information. There is a meeting planned for autumn. Currently different from online CA proposals here, so not useful to have formal meeting. Informal discussion in Seattle.
LCG has requirements to solve these issues. Need to contact Tier 2/B security people.
How do we get to discussion about acceptable authentication for LCG once this group finishes in December.
LCG has to decide who to accept authentication from, and persuade others to accept them. Maybe a task force should assess trustworthiness. Or is it enough to know who to blame when something goes wrong. LCG has to call out and invite general participation.
If private key is the responsibility of a user then when that key is misused the user can be blamed. If the same thing happens with a KCA issued cert, then there is no private key.
Although these online systems work OK for big sites, the Grid is a
lot more democratic
and small sites comprise the bulk. They must
be represented, and should not have to trust just the big sites.
The result has to be acceptable to all the users for all the resources.
What are the requirements of the small sites. If they have lots of resources why should they have to authenticate with a big site.
It seems clear that there should be a mix.
Within OGSA, we may well not be using PKI, and the infrastructure may not go out all the way to the end users.
Perhaps scope of this groups has to be more generally authentication.
What is responsibility. What is the meaning of taking responsibility
for a compromise? With the KCA Dane is willing to clean up the mess
by disabling the user account, reporting back on complaints, etc.
What will EDG do as regards taking responsibility?
Some of the responsibility should be with the VO. If the VO will take the responsibility for security of user key holding, etc. If the user is somehow authenticated with the VO, challenge-response style, then you get some sort of verification of the VO. Some sort of pass-phrase authentication with VOMS.
A poorly run online service may be more of a risk than the odd compromised key. If lots of sites want to run these online services, this may cause problems.
Big sites have experience dealing with large numbers of users.
At a single site it is possible to scan for misuse of passwords on the network.
How does this translate to EDG or PKI in general? If there is a problem with a cert it should be reported to the relevant CA.
Current CP/CPS deny liability for misuse.
We still need to investigate min requirements for online ca.