JSPG Meeting 22/23 June 2006, CERN D P Kelsey Decisions and Actions -------------------------------------------------------------------------------- 1. Globus_TCP_Port_Range To allow coherent configuration of outbound firewall rules, this range should be the same at all sites. It is also important for strengthening access control on data servers communicating over any high performance channels which cannot use firewalls. JSPG agrees that it would be very useful to agree a common port range which should be as small as is consistent with stable operations. Would like to see at least a default configuration or strong recommendation. OSCT will do a survey to see the current status and scale of the problem. Also important to include OSG and other Grids. -------------------------------------------------------------------------------- 2. Read access to VO information in VOMRS Today in VOMRS, only the VO manager can see the full list of VO members. This is too restrictive and CMS (for example) wants this changed. JSPG agreed that this is a reasonable request. Because of personal data privacy issues, this information should not be exposed to people outside of the VO. The VO must have a clear policy on this and the user needs to be informed of this during registration (e.g. via the VO AUP). CMS also needs VO members to be able to see their Group and Role managers' names in VOMRS. JSPG agrees this is also reasonable. -------------------------------------------------------------------------------- 3. Use of CERN ID number and Date of Birth in LHC User Registration Today during registration with an LHC VO, the user is required to enter either his/her CERN ID number or Date of Birth. If these do not match the data stored in the CERN HR database, the VO Manager is sent a warning message. There are several problems with this: the CERN ID is not present in HR DB for external users; the CERN ID will now be "published" in the new CERN CA certificate DN; the VO managers find the warning annoying (is always there each time they look at entry in VOMRS); reports suggest they ignore the warnings any way! JSPG decided to recommend to the User Registration Task Force: no further use of the CERN ID check; force the match of Date of Birth (with a small number of allowed attempts); if it does not match, registration fails. (n.b. it is realised that use of date of birth is not a perfect confirmation of identity, but no other suitablle second factor identification has yet been found. This additional check at least prevents trivial abuse.) -------------------------------------------------------------------------------- 4. VOMS Proxy Lifetime and blocking of user access Regarding the period of validity of AuthZ attributes in a VOMS proxy certificate. JSPG agrees that the maximum lifetime should be 24 hours (from time of issue). VO's SHOULD not issue AuthZ attributes with lifetimes longer than this or MUST request approval (from OSCT) if this needs to be exceeded. OSCT needs to notify sites if longer lifetimes are being used - some may refuse to allow this. Regarding the period of validity of AuthN attributes in a Grid proxy certificate. JSPG agrees that the maximum lifetime should be 24 hours (from time of issues). Users (or MyProxy) SHOULD not create Grid proxy certificates with lifetimes longer than this except when storing proxies in approved services like MyProxy. JSPG agrees that sites SHOULD enforce these policy upper limits. Grid middleware MUST provide the ability to do this. (AuthN = Authentication, AuthZ = Authorization) -------------------------------------------------------------------------------- 5. Site blocking of individual users JSPG would like to see a single point of control (one per site) for the configuration of an urgent user block. -------------------------------------------------------------------------------- 6. Audit Policy/Requirements Existing (old) policy document needs updating. JSPG agrees we continue to need "policy" to require services to produce suitable audit logs and "policy" to require sites to retain these. ACTION: on Ian N/Romain W to produce new version of the draft policy document (aim to present this and example implementation to SA1 in the EGEE'06 Conference - September) -------------------------------------------------------------------------------- 7. Pilot jobs and gLexec As is well known and being discussed in several EGEE bodies, sites are concerned about the security implications of this method of workload management. JSPG agrees that we REQUIRE suitable auditing and traceability at the individual user level both on the WN and the VO Scheduler available on demand Sites may hold the submitter of the Pilot Job responsible for all actions of that job VO's should be aware that the controls to ban users will result in the blocking of the whole VO, instead of just one user. -------------------------------------------------------------------------------- 8. Incident Response Reciprocal Agreement (EGEE/OSG) OSCT proposes to exchange EGEE incident response information with OSG (following bi-lateral arrangements specified in the Policy) This will be done by EGEE entering all OSG registered site security contacts in the EGEE lists and OSG entering all EGEE registered sites in their lists. JSPG agreed to this approach as long as the agreement works equally in both directions. -------------------------------------------------------------------------------- Policy Documents -------------------------------------------------------------------------------- a. CA Approval The document will be reworded to more general (applies to "Grid") with a single explanation of WLCG, EGEE and OSG in the Introduction. ACTION: Ian N to produce next version -------------------------------------------------------------------------------- b. VO Naming Still no final decision as to whether the text describing the dns-style VO naming should be a separate document or included as part of VO Security Policy. There had been an advantage in having a stand-alone document (for use in GGF GIN), but a GGF paper is reported to being written for GGF. ACTION: Ian N to investigate (with Maria D) the scale of any update to the VO Security Policy. If possible to easily include new VO naming text, then to produce next version. JSPG agrees that this naming policy should be for NEW VO's. The changing names of existing VO's needs more thought. -------------------------------------------------------------------------------- c. OSG VO AUP (see slides at MWSG meeting, SLAC, 5/6 June 2006 - Keith Chadwick) Keith was not able to attend to present these interesting slides so DPK presented them (as shown at MWSG meeting). JSPG was not yet fully convinced of the need for such an approach in EGEE. The VO Security Policy document addresses many of the issues anyway and JSPG was concerned about the feasibility of VO's being responsible for the actions of its members. We need to revisit this when OSG is able to attend (there was no representative this time). We also need to explore how JSPG policy and the new OSG work will fit together. --------------------------------------------------------------------------------