[Pgi-wg] OGF PGI - Security Model - NEW versions of GSI accept RFC-3820-compliant X509 proxies

[Oxana Smirnova]

Hi Etienne,

I am not easy at all with purely operational requirements being presented as a PGI recommendation. We define what is a standard profile, and it is up to m/w providers and VOs to decide whether they should conform to it or no. I am also sure that PGI is not in a position to define procedures and policies - only best practices, at most. Specifically:

> 
> 2.2)  Inside DEISA, a Virtual Community also groups grid Users with 
> common goals.  It should be possible to map each Virtual Community to a 
> Group of a Virtual Organization.
> 

Why should it be possible at all? I suppose you meant to say that a Virtual Community is similar to a VO, or for all practical reasons can be characterized as a VO, but I don't think it should be necessary to perform any mapping!

> 2.3)  Each grid User belongs to 1 or more VO (Virtual Organization), 
> which grants him access rights to grid Storage and Computing Resources.

... and many other services - why single out these two? There are information services, file transfer services, accounting services, monitoring services, data indexing services and even collaborative documentation development and agenda services - my VO membership grants me access to such services already today.

> 
> 2.4)  Access rights are granted by VOs to grid Users through either :
>       2.4.1)  VOMS extensions of X509 proxies (this makes a VOMS proxy).
>               Currently, inside EGEE :
>               -  VOMS servers with version older than 2.0 only accept 

This has nothing to do with EGEE; old VOMS servers are used by many other projects.

> Globus proxies. The 'vomses' configuration file theoretically contains 
> information about this version, so that the 'voms-proxy-init' command 
> adapts the proxy format when needed, but many VOs distribute an 
> incorrect 'vomses' file.

There's certainly nothing "theoretical" with the configuration file: it is well documented, and it is up to every user to fix it, because it actually resides in his/her home directory and can be easily fixed (or messed up, for that matter) without intervention of VO managers. This paragraph has nothing to do with a standard definition. We are not going to write down configuration instructions for every single tool here, are we?

>               -  VOMS servers with version 2.0 onwards will be able (at 
> the end of this year) to accept any kind of proxy, even an X509 
> certificate.
> 

This is also a minor detail which will have no practical meaning very soon (even now it is hardly relevant)

>       -  New GSI implementations of TLS (since version 4.0 
> approximately) accepts both RFC-3820-compliant X509 proxies and Globus 
> proxies.

I would recommend to read this fine paper, dated July 2005:

  http://www.globus.org/toolkit/docs/4.0/security/GT4-GSI-Overview.pdf

Does anybody think that a technology of 2005 is "new"?.. And it is not "approximately", it is GT4. Even if some projects still use GT2, it is not a reason to call GT4 "new".


> 5.3)  VOMS services, which deliver X509 proxies with VOMS extensions, 
> MUST fully comply to RFC 3820 or GSI, and MAY accept both.
>       Inside EGEE, all VO managers MUST verify the content of their 
> 'vomses' file, and fix it if necessary.

No way we can require this, really. Besides, like I wrote before, vomses files are easily overwritten by users local vomses, so this recommendation is completely void. And knowing that the latest VOMS version is actually compliant with this requirement, it becomes redundant.

> 
> 5.4)  The authentication library used by grid Services MUST fully comply 
> to RFC 3820 or GSI, and MAY accept both.
>       Old versions of GSI, which do NOT accept RFC-3820-compliant X509 
> proxies, block interoperability, and are STRONGLY DEPRECATED.
>       Therefore, we advise each provider of grid middleware using such 
> an old version of GSI to :
>       -  establish and publish the list of the components which still 
> uses it,
>       -  migrate to a new version of GSI which also accepts 
> RFC-3820-compliant X509 proxies.

No need to advise this publishing and migration, we do not define policies and procedures here. If any Grid m/w provider does not accept both, it is simply not PGI-conforming, period. It may still serve users happily.

> 
> 7.2)  The Information Service of each grid Infrastructure MUST describe, 
> for each grid Service, the security requirements for access to the grid 
> Service, and which Authorization Tokens this Service expects 
> (potentially several).
>       Globus proxies are DEPRECATED in favor of RFC-3820-compliant X509 
> proxies.  Each provider of grid middleware MUST establish and publish 
> the list of the components which still require Globus proxies.

See above. We can not require m/w providers to report to PGI what they do and what they don't - we are not that kind of an authority. Unless we are going to issue "PGI certified" stickers, or give away "PGI product of the year" awards, of course ;-)

> 
> 7.3)  The Information Service of each grid Infrastructure MUST describe 
> the transport method that the grid Service expects (potentially several).
>       We repeat here what we have written in chapter 5.4 :
>       Old versions of GSI, which do NOT accept RFC-3820-compliant X509 
> proxies, block interoperability, and are STRONGLY DEPRECATED.
>       Therefore, we advise each provider of grid middleware using such 
> an old version of GSI to :
>       -  establish and publish the list of the components which still 
> uses it,
>       -  migrate to a new version of GSI which also accepts 
> RFC-3820-compliant X509 proxies.

See above, we are not this kind of an authority. If a m/w provider chooses to produce a non-PGI-compliant software, it is their choice entirely.

Cheers,
Oxana