[Pgi-wg] OGF PGI - Security Model - NEW versions of GSI accept RFC-3820-compliant X509 proxies
Etienne URBAH
urbah at lal.in2p3.fr
Thu Apr 16 11:28:47 CDT 2009
Oxana,
Concerning my 'PGI Security Model' document :
I thank you very much for your efforts to read it, understand it, and
provide remarks to it.
All your remarks are relevant, and most are appropriate, so I have
updated my document accordingly. I also provide my updates interspersed
below.
I you still have suggestions for any part, or even the full structure of
this document, please send them to me.
Inside PGI, my general goal is to describe accurately what is really
currently used, and to achieve consensus about what could be achieved in
short term.
I wish that SEVERAL members of PGI perform the same reviewing effort as
you, for following documents :
'PGI Security Model' at http://forge.gridforum.org/sf/go/doc15584?nav=1
'Data Staging - Concepts and Scenarios' at
http://forge.gridforum.org/sf/go/doc15607?nav=1
'Vocabulary' at
http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/Vocabulary
Thank you in advance.
Best regards.
----------------------------------
Etienne URBAH IN2P3 - LAL
Bat 200 91898 ORSAY France
Tel: +33 1 64 46 84 87
Mob: +33 6 22 30 53 27
Skype: etienne.urbah
mailto:urbah at lal.in2p3.fr
----------------------------------
On Thu, 16 Apr 2009, Oxana Smirnova wrote:
> 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!
You are right. New formulation :
When necessary, a Virtual Community could perhaps be mapped to a Group
of a Virtual Organization.
>
>> 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.
New formulation :
Each grid User belongs to 1 or more VO (Virtual Organization), which
grants him access rights to various Services (Information, Storage,
Computing, File transfer, Data indexing, Monitoring, Accounting,
Collaborative tools, ...) provided or not by grid middleware. Inside
PGI, we focus on following Services provided by grid middleware :
Information, Storage and Computing.
>
>> 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.
You are right.
>
>> 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?
New formulation :
VOMS servers with version older than 2.0 only accept Globus proxies. The
'vomses' configuration file can contain, at the end of each line, the
Globus version used by the VOMS server, so that the 'voms-proxy-init'
command adapts the proxy format when needed. But many VO managers
distribute an incorrect 'vomses' file, which is installed 'as it' by
system engineers, and best practices such as ITIL forbid us to require
that each end user fixes the content of this file himself.
>
>> - 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 formulation :
VOMS servers with version 2.0 onwards are able to accept any kind of
proxy, even an X509 certificate. EGEE plans to deploy them before the
end of this year.
>
>> - 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".
Thank you very much for the link, which I have included in chapter 1.9
New formulation :
GSI implementations of TLS since version GT4 accepts both
RFC-3820-compliant X509 proxies and Globus proxies.
>
>> 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.
Best practices such as ITIL forbid us to require that each end user
fixes the content of this file himself. These best practices require
that each 'vomses' file must be fixed ONLY by its creator (the VO
manager), and then deployed. New formulation :
Inside EGEE, each VO manager MUST verify the content of his 'vomses'
file, append "2" at the end if necessary, and deliver it for deployment.
>
>> 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.
As far as I know, EGEE and NAREGI are stuck with old versions of GSI for
the foreseeable future. So, if we follow you, EGEE and NAREGI can NOT
be PGI-conforming. Therefore, I keep my advice unchanged. You can
propose a better formulation.
>
>> 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 ;-)
You are right. I have replaced 'MUST' by 'we advise to'.
>
>> 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.
Same problem and same answer as for chapter 5.4).
>
> Cheers,
> Oxana
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5060 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20090416/98a78862/attachment.bin
More information about the Pgi-wg
mailing list