Talk:Virtual Organisation Registration Security Policy
From JSPGwiki
Please sign your posts (http://en.wikipedia.org/wiki/Wikipedia:Sign_your_posts_on_talk_pages).
| Table of contents |
Changes Since v1.7
The currently approved and adopted policy document is called "LCG/EGEE Virtual Organisation Security Policy" (version 1.7, dated 31 October 2005) and may be found at https://edms.cern.ch/document/573348/6. Draft v2.1 contains the following updates:
- The Introduction has been re-written to clarify that this policy defines security-related responsibilities on the Grid, the VO, and the VO managers.
- The Exclusions and Definitions sections have been dropped.
- The VO Community Responsibilities section has been moved to a separate policy (VO Membership Management Policy) (except the VO Members subsection which was deemed redundant with the existing AUPs).
- VOs must register a description of VO procedures meeting requirements of the VO Membership Management Policy.
- VO managers must submit a signed copy of the VO Operations Policy.
- Requirements for VO Naming have been added.
--JimBasney 16:31, 29 Sep 2008 (BST)
OSG Perspective
The information captured by OSG at VO Registration time is documented at https://twiki.grid.iu.edu/bin/view/Operations/RegistrationInstructions#VO_Registration. This information is captured when the VO registers with the OSG Information Management (http://oim.grid.iu.edu/) system. Comparing OSG practice with the JSPG policy:
- VO name conforming to the standard described in Appendix A.
- OSG captures the VO name but doesn't enforce the VO naming standard, and no current OSG VOs conform to this standard, but OSG could do it for new VOs.
- VO Acceptable Use Policy (see example provided in Appendix B).
- OSG captures a link to the VO AUP.
- A description of the VO’s procedures, meeting the requirements of the VO Membership Management Policy (see template in this referenced policy).
- OSG does not record this information today.
- A signed copy of the VO Operations Policy (https://edms.cern.ch/document/853968/) document.
- OSG has not yet implemented the VO Operations Policy but VO operators must agree to the OSG Service Agreement (http://osg-docdb.opensciencegrid.org/cgi-bin/RetrieveFile?docid=87&extension=PDF).
- Contact details and certificates for the VO Manager and at least one Alternate:
- Name
- Employing Institute
- VO Role (Manager or Alternate)
- Email address
- Telephone number
- X.509 certificate from an approved Certification Authority
- OSG records contact details for VO Manager (name, email, phone, address), Operations Contact (name, email), and Security Contact (name, email, phone). It's not clear if certificates are captured.
- Email address of a generic VO contact point for the VO managers
- OSG does not require this.
- A single email address of the security contact point to be used for accepting reports of suspected identity compromises, misuse of resources or other security events related to the VO.
- OSG does this (see above).
- The name of the Site, Infrastructure or other body responsible for running the VO Membership service, together with the URL of one or more VO Membership Servers.
- OSG records the VOMS URL.
--JimBasney 16:46, 29 Sep 2008 (BST)
Oct 9 2008 JSPG Meeting Notes
For the signed VO Operations Policy, is that signed by hand or electronically?
- This is an implementation detail that each Grid would determine. It could be electronic.
- We (EGEE) don't have a procedure to go around to the existing VOs to get them to sign.
The tie to the VO Membership Management Policy may be problematic.
- It will be for OSG, unless we make changes to that policy.
- This is also problematic for EGEE.
- The simplest thing would be to delete this requirement. Agreed.
Today EGEE doesn't collect VO manager phone number.
Migrating to a new VO name can be very painful.
- EGEE did this for one VO and it took a long time.
Some small VOs don't own a DNS domain name.
- EGEE allows VOs to use voname.eu-egee.org. Other Grids could do the same. We don't need to note this in the policy.
Why do we REQUIRE a "generic VO contact point for VO managers"?
- This is currently optional in EGEE.
- OSG isn't doing this today.
- Make it optional. Agreed.
--JimBasney 9 Oct 2008
Jan 21, 2009 - changes made by Dave Kelsey
This is to be discussed at the JSPG meeting on 22 Jan 2009. The only minor changes made were to remove the already "struck out" lines from the last version.
Remaining issues to be discussed:
- Is there a need to italicise any of the terms (e.g. Grid) to make the document general? I suspect not for this document.
- Do we need to distinguish VO Manager from VO Administrator?
- Is there any policy requirement to force a VO to register? The document seems to imply this - or does it?
--David kelsey 11:34, 21 Jan 2009 (GMT)
Jan 22 2009 JSPG Meeting Notes
Agreed: Keep VO Manager term. Defined in Glossary and Membership Management documents. Add a link to the Glossary.
Change title to VO Registration Security Policy? May be confused with other VO operations policy. Agreed.
Do we need to italicize any terms (such as "the Grid")?
- The definition of Grid in the Glossary is specific to LCG/EGEE. We need to revise it.
- Agreed: Not necessary to italicize.
Agreed: This document is ready for wider consultation.
--JimBasney 22 Jan 2009
Feedback received, for discussion at May 2009 JSPG meeting
Rolf Rumler (IN2P3): The policies should also cover de-registration of a VO. How is this done? What needs to be kept? etc etc.
[JSPG response: Agreed. Paragraph added to section 2]
Pete Gronbech (Oxford): In appendix A on VO naming that all VO's must be formatted as a DNS name. I assume this only applies to new VO's and the existing short forms can continue. (eg atlas!)
[JSPG response: Agreed. "For new VOs..." added]
Jeremy Coles (Cambridge): Is there a JSPG document that explains our VOMS responsibilities when we want to deactivate a VO?
[JSPG response: See above comment to Rolf Rumler]
Ursula Epting (Karlsruhe): In section 2, VO Registration Requirements "bullet 4. [...] X.509 certificate approved CA" - I wanted to suggest writing "IGTF-approved CA's" but I think you've left it open by purpose - right? (FermiLab-CA, OSG...) But the sentence as is raises immediately the question "approved by whom?"
[JSPG response: Wording changed to say "approved for use on the Grid". It is not just IGTF; the Grid has the right to trust additional CAs too]
Ruth Pordes (OSG) GDB 11 March: OSG has a policy in draft form that is compatible with the JSPG policy. We will work on making a timeline for approval in the next few months.
Nick West (Oxford/VO MINOS): Why are we asked to provide a VO manager and at least one alternative yet only one email for security! Presumably we are required to setup an email list that people have to subscribe to. The AUP requires: state which VO management body gives authority to the Policy. What does this mean?
[JSPG response: Security operations wants a single contact point. We have added a sentence to say that response must be prompt, which suggests a mail list, but also handled confidentially which means no publicly archived lists. We have changed the wording of the VO AUP requirement to say "who gives authority to the Policy". This could be a person or a committee.]
--David kelsey 12:55, 11 May 2009 (BST)
May 14 2009 JSPG Meeting Notes
Need to deal with de-registration. Dave added a sentence: "If a VO wishes to leave the Grid..."
- When a VO leaves the grid, it should no longer get sensitive security announcements.
- Why keep information after the VO leaves? A security incident comes to light afterward and requires follow-up. Shouldn't be retained longer than period in VO Virtual Organisation Membership Management Policy. Should this be here or in the logging policy and/or incident response policy? Should refer to Grid Incident Response Policy.
- Don't want a new VO to come with the same name as an old VO.
- This policy is talking about VO registration information held by the Grid.
- In France you must release personal information after one year.
- How long to keep VO registration data? 2 years? Period consistent with Traceability and Logging Policy.
DNS names are required only for new VOs?
- Making existing VOs change their names will be very difficult.
- This is a point of confusion for many readers of this policy.
A single email address for security contact?
- That can accept sensitive information and is responded to promptly.
How is the registration policy maintained (kept up-to-date)?
- Policy says "capture and maintain".
- VO Operations Policy also has a statement about maintaining registration information.
- Not necessary to specify how it's maintained.
In AUP section, what does it mean to give authority to the Policy?
- For a large VO, it's a management board.
- Changed to "state who gives authority to the Policy."
Do we keep the DNS naming requirement?
- This is needed for globally-unique naming across grids.
- We've had problems with two "Fusion" VOs with the same name.
- Does it mean VO members have to type in a long name for voms-proxy-init? This policy doesn't specify what the VOMS name has to be. The VOMS configuration can contain local alias names? The VOMS names also appear in grid storage ACLs.
- In the NGI world, we expect this to grow in importance.
- Should we mention the use of a short, convenient name in addition to the globally-unique DNS name?
- Globally-unique names is a security requirement because we use them in ACLs.
We agree that this policy is ready for final call.
--Jim Basney 14 May 2009
Changes Between versions 2.3 and 2.5
Changes included:
- All MUST and SHOULD replaced with lower case.
- Clarify that existing VOs are not required to implement DNS style name.
- Clarify the CAs that are approved.
- Add requirement for confidentiality and speedy response to the security contact point.
- Clarify who gives authority to the VO AUP.
- Add paragraph about a VO leaving the Grid.
--David kelsey 18:02, 18 May 2009 (BST)
Feedback received and JSPG responses on the "final call" version (V2.5, 18 May 2009)
Rolf Rumler (IN2P3):
- It is stated that a VO registration procedure "must capture and maintain" some information, as for example a signed copy of the VO Operations Policy. The current EGEE VO Registration Procedure (see https://edms.cern.ch/document/503245) doesn't foresee such things. If the sense of "signing" is "physical signature" and not a digital one, then this needs some clarification on who is going to receive those signed copies and how exactly this should be sent and with which delays and so on. Even if "only" a digital signature is required, the current procedure must be updated. It is outdated anyway but the information to be updated has been trivial up to now, which is no longer the case if respecting point 3 in section 2 of the VO Registration Security Policy. In addition, the workflow implemented in the CIC portal has to be modified, too. In case of a digital signature this might not be too complicated, whereas working with paper copies is more difficult and creates delays.
- The current document on the VO Registration Procedure contains some information which becomes redundant with the new VO Registration Security Policy, like for example the topic on VO naming.
- If I understand correctly the very last sentence of section 2, the details on what has to be done by a VO when it shuts down or leaves the grid, or by a site when it wants to abandon the support of a VO have now to be defined in the VO Registration Procedure. This is not a complaint from my side but just a request for clarification.
- At the end of section 2 it is stated that "Personal registration information must not be retained for more than 12 months". However, in the other document which you submitted on VO Membership Management Policy, section 4.7, it is said that the VO Membership Management system must keep an audit log for at least two years. As the audit data include personal registration information, this looks as a contradiction to me.
[JSPG response: The implementation of this policy, in particular the way in which a Grid collects signatures, but also other details such as what happens when a VO leaves the Grid, is a deployment issue for the Grid in question. JSPG does not wish to impose any particular solution, but digital signatures (confirming acceptance of the VO Operations Policy) using the same X.509 credentials for the VO manager and alternate(s) as collected in the VO registration process does seem one good approach. On the question of retention of personal registration information, this includes names, institute names, e-mail addresses and phone numbers of the users. This is personal data and many countries tell us that keeping this for longer than a year is a problem. The VO Membership Management policy will be changed to contain the same time limit.]
Jim Basney (NCSA and OSG):
- I received a request (on behalf of USCMS) for further clarification that existing VOs do not need to change their registered name. Does anyone object if, in the VO Registration Security Policy, after "For new VOs this name must conform to the standard described in Appendix A.", I add, "Existing VOs are not required to change their registered VO name."?
- FYI, OSG will not adopt the VO naming requirement. However, I hope OSG will adopt the rest of the VO Registration Security policy.
[JSPG response: Agreed. Change made as requested.]
Frederic Schaer (CEA, FR): One question : isn't this incompatible that there is in the text "VOs [...] MUST conform [...] DNS name" and that OSG doesn't adopt this but still adopts the rest of the policy ? If all Grid projects do the same, what's the point of such a policy (and then, again, what's the point of DNS naming)? I already expressed my concerns about mixing naming and technical requirements, could OSG explain why it would not adopt the DNS naming for new VOs?
Jim Basney (NCSA and OSG): In answer to Fred's question... The JSPG mandate says that policies adopted by WLCG apply to the subset of OSG that participates in WLCG. For the VO policies, this is USATLAS and USCMS, neither of which are "new VOs" so the naming standard doesn't apply to them. OSG makes an independent decision whether to adopt policies developed by JSPG. OSG has decided not to make DNS naming a requirement for new VOs at this time, as part of a general philosophy to minimize requirements and administrative hurdles for participation in OSG. Of course OSG VOs are welcome to choose DNS-based names, and OSG may decide to start recommending DNS-based names at some point in the future. For now, OSG has a small number of VOs (<40), and VO naming has not been an operational security issue for us.
--David kelsey 17:56, 18 Jun 2009 (BST)
