OGF PGI - Security Strawman
To All, I thank Duane MERRIL for his 'Profile on Secure Communication' strawman. But, since today's mail of Vincenzo CIASCHINI asserting interoperability between recent versions of OpenSSL and GSI, I do NOT think that communication layers are the main isue blocking interoperability. I propose that instead focusing on communication services, we focus on security data defined, on security data transported, and on the interpretation of security data by AUTHN/AUTHZ services. So, I propose to criticize following assertions : 1) Grid Users and Certificate Authorities ----------------------------------------- 1.1) Each grid User is authenticated by a legal body (recognized by a government). 1.2) This legal body uses a Certificate Authority to grant a (long lived) X509 certificate to the grid User. 1.3) Each Certificate Authority is itself or is authenticated by a self-signed Root Certificate Authority. 1.4) All such Root Certificate Authorities trust each other and cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management Authorities). 1.5) These 3 Policy Management Authorities trust each other and cooperate within IGTF. 1.6) IGTF distributes the list of CA Certificates to be trusted. 1.7) Each grid Site providing grid Services to grid Users MUST install this list of CA Certificates and keep it up to date. 1.8) Using its X509 certificate, each grid User can create at any time a (short lived) X509 proxy with permits impersonation / delegation during a short period. 2) Virtual Organizations ------------------------- 2.1) A Virtual Organization (VO) groups grid Users with common goals. A VO is NOT a legal body, can NOT be a Certificate Authority, and can NOT issue X509 certificates. 2.2) Inside DEISA, a Virtual Community also groups grid Users with common goals. The relationships between Virtual Communities and Virtual Organizations has to be precised by Morris RIEDEL. 2.3) Each grid User belongs to 1 ore more VO (Virtual Organization), which grants him access rights to grid Storage and Computing Ressources. 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) 2.4.2) SAML assertions 3) Grid Services : Information, AUTHN, AUTHZ ---------------------------------------------- 3.1) Each grid Infrastucture provides an Information Service, with describes the Infrastructure according the the GLUE2 schema. 3.2) Each grid User can query this Information Service anonymously in order to know which security protocol he has to use to submit requests to grid Services. 3.3) Each grid User can directly access data hosted by grid Storage Services. For Authentication, the grid User can present the public part of his X509 certificate or X509 proxy. For Authorization, the grid User can present : 3.3.1) the public part of his VOMS proxy, or 3.3.2) a bag of SAML assertions. 3.4) Each grid User can submit Jobs to grid Computing Services. If such a Job needs access to data hosted by grid Storage Services, then the grid User must provide a delegation token. This delegation token can be : 3.4.1) a full VOMS proxy, or 3.4.2) a bag of SAML assertions. 4) Consequences for Interoperability ------------------------------------- 4.1) X509 proxies MUST fully comply to RFC 3820. 4.2) VOMS services, which deliver X509 proxies with VOMS extensions, MUST fully comply to RFC 3820. 4.3) The authentication library used by grid Services MUST fully comply to RFC 3820 (for example a recent version of OpenSLL), so that it can accept as well X509 certificates as X509 proxies. 4.4) Each grid Site providing grid Services to grid Users MUST install files describing VOMS authorizations and other authorizations, and keep them up to date. 4.5) The semantics of Authorization tokens MUST be the same for all grid Infrastructures : 4.5.1) VOMS extensions 4.5.2) Restriction attributes 4.6) The Information Service of each grid Infrastructure MUST describe, for each grid Service, which Authorization tokens this Service understands (potentially several) : 4.6.1) VOMS extensions 4.6.2) X509 restriction attributes 4.6.3) SAML assertions 4.7) For SAML assertions, the Information Service of each grid Infrastructure MUST describe, for each grid Service, how they are transported : 4.7.1) As attributes of X509 proxies 4.7.2) Inside a SOAP header Unfinished ... 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@lal.in2p3.fr ----------------------------------
Etienne, Wow, you have reproduced the Strawman document perfectly, albeit in a higher level of description. The intent of the Strawman document is to focus precisely on the security data transported (i.e., issues that affect wire format), including syntax definitions for for attributes (SAML and VOMS-like ACs) so that they may carry the same information. The only differences between your text below and the Strawman are that you discuss several non "data-defined" issues that, while mentioned by Strawman, were considered out of scope: - Strawman abstracted away the notion of an Information Service by describing the format of endpoint reference documents(EPRs) that describe security requirements/expectations. (This EPR information *might *be returned by such hypothetical informational services, or by other means. Hence the Strawman was focusing on security-data defined, as per your outset motivation.) - Strawman considered the establishment of trust roots as out of scope. As you (and the Strawman) mention, such trust must be configured, but is not germane to the data *communicated* during a simple request-response exchange. - Strawman considered the provision of delegation token(s) to a service (e.g., BES) as out of scope. As you (and the Strawman) mention, it generally must be done for certain agent-style services, but through an "application" layer (e.g., through WS-Trust STS interface, etc.). The Strawman discusses how a client (e.g., an agent-BES) would communicate with delegated credentials, not how it obtains them. I just have one question for you: precisely how is (3.4.2) delegation accommodated using SAML assertions? (A delegation chain must exist somewhere, and it could be achieved by using a proxy certificate -- the EEC of which is asserted in the SAML attribute -- to sign SOAP messages bodies. Is this what you were envisioning? Or does Unicore not envision the true delegation of SAML attributes.....) -Duane 2009/3/23 Etienne URBAH <urbah@lal.in2p3.fr>
To All, I thank Duane MERRIL for his 'Profile on Secure Communication' strawman.
But, since today's mail of Vincenzo CIASCHINI asserting interoperability between recent versions of OpenSSL and GSI, I do NOT think that communication layers are the main isue blocking interoperability.
I propose that instead focusing on communication services, we focus on security data defined, on security data transported, and on the interpretation of security data by AUTHN/AUTHZ services.
So, I propose to criticize following assertions :
1) Grid Users and Certificate Authorities ----------------------------------------- 1.1) Each grid User is authenticated by a legal body (recognized by a government).
1.2) This legal body uses a Certificate Authority to grant a (long lived) X509 certificate to the grid User.
1.3) Each Certificate Authority is itself or is authenticated by a self-signed Root Certificate Authority.
1.4) All such Root Certificate Authorities trust each other and cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management Authorities).
1.5) These 3 Policy Management Authorities trust each other and cooperate within IGTF.
1.6) IGTF distributes the list of CA Certificates to be trusted.
1.7) Each grid Site providing grid Services to grid Users MUST install this list of CA Certificates and keep it up to date.
1.8) Using its X509 certificate, each grid User can create at any time a (short lived) X509 proxy with permits impersonation / delegation during a short period.
2) Virtual Organizations ------------------------- 2.1) A Virtual Organization (VO) groups grid Users with common goals. A VO is NOT a legal body, can NOT be a Certificate Authority, and can NOT issue X509 certificates.
2.2) Inside DEISA, a Virtual Community also groups grid Users with common goals. The relationships between Virtual Communities and Virtual Organizations has to be precised by Morris RIEDEL.
2.3) Each grid User belongs to 1 ore more VO (Virtual Organization), which grants him access rights to grid Storage and Computing Ressources.
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) 2.4.2) SAML assertions
3) Grid Services : Information, AUTHN, AUTHZ ---------------------------------------------- 3.1) Each grid Infrastucture provides an Information Service, with describes the Infrastructure according the the GLUE2 schema.
3.2) Each grid User can query this Information Service anonymously in order to know which security protocol he has to use to submit requests to grid Services.
3.3) Each grid User can directly access data hosted by grid Storage Services. For Authentication, the grid User can present the public part of his X509 certificate or X509 proxy. For Authorization, the grid User can present : 3.3.1) the public part of his VOMS proxy, or 3.3.2) a bag of SAML assertions.
3.4) Each grid User can submit Jobs to grid Computing Services. If such a Job needs access to data hosted by grid Storage Services, then the grid User must provide a delegation token. This delegation token can be : 3.4.1) a full VOMS proxy, or 3.4.2) a bag of SAML assertions.
4) Consequences for Interoperability ------------------------------------- 4.1) X509 proxies MUST fully comply to RFC 3820.
4.2) VOMS services, which deliver X509 proxies with VOMS extensions, MUST fully comply to RFC 3820.
4.3) The authentication library used by grid Services MUST fully comply to RFC 3820 (for example a recent version of OpenSLL), so that it can accept as well X509 certificates as X509 proxies.
4.4) Each grid Site providing grid Services to grid Users MUST install files describing VOMS authorizations and other authorizations, and keep them up to date.
4.5) The semantics of Authorization tokens MUST be the same for all grid Infrastructures : 4.5.1) VOMS extensions 4.5.2) Restriction attributes
4.6) The Information Service of each grid Infrastructure MUST describe, for each grid Service, which Authorization tokens this Service understands (potentially several) : 4.6.1) VOMS extensions 4.6.2) X509 restriction attributes 4.6.3) SAML assertions
4.7) For SAML assertions, the Information Service of each grid Infrastructure MUST describe, for each grid Service, how they are transported : 4.7.1) As attributes of X509 proxies 4.7.2) Inside a SOAP header
Unfinished ...
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@lal.in2p3.fr ----------------------------------
_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
Hi, most of the statements are accurate; just some corrections inline:
1) Grid Users and Certificate Authorities ----------------------------------------- 1.1) Each grid User is authenticated by a legal body (recognized by a government).
1.2) This legal body uses a Certificate Authority to grant a (long lived) X509 certificate to the grid User.
1.3) Each Certificate Authority is itself or is authenticated by a self-signed Root Certificate Authority.
1.4) All such Root Certificate Authorities trust each other and cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management Authorities).
1.5) These 3 Policy Management Authorities trust each other and cooperate within IGTF.
1.6) IGTF distributes the list of CA Certificates to be trusted.
1.7) Each grid Site providing grid Services to grid Users MUST install this list of CA Certificates and keep it up to date.
Not exactly: a Grid site installs those certificates it deems necessary. In general, there is no requirement to keep them up-to-date, but typically it is considered a security update and as such is strongly recommended to apply. Some infrastructures issue warnings for sites with outdated CA certs, but normally it does not impede operations.
1.8) Using its X509 certificate, each grid User can create at any time a (short lived) X509 proxy with permits impersonation / delegation during a short period.
This period is not necessarily "short": technically, it is limited only by the life time of the original certificate itself.
2) Virtual Organizations ------------------------- 2.1) A Virtual Organization (VO) groups grid Users with common goals. A VO is NOT a legal body, can NOT be a Certificate Authority, and can NOT issue X509 certificates.
A VO may well be associated with a legal body, nothing prevents it. It may also be a grouping by e.g. geopolitical principle, not necessarily by a common goal. Some VOs are known to run own Certificate Authorities, though they are not a part of IGTF and are trusted only by the VO members and respective resource providers themselves.
2.2) Inside DEISA, a Virtual Community also groups grid Users with common goals. The relationships between Virtual Communities and Virtual Organizations has to be precised by Morris RIEDEL.
2.3) Each grid User belongs to 1 ore more VO (Virtual Organization), which grants him access rights to grid Storage and Computing Ressources.
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) 2.4.2) SAML assertions
It can also be done by more crude means, like plain text mapping of known VO members to local UIDs. Not that it conforms to any standard, of course, but you'll be surprised to learn how widely it is used. The decision is always with the site owner.
3) Grid Services : Information, AUTHN, AUTHZ ---------------------------------------------- 3.1) Each grid Infrastucture provides an Information Service, with describes the Infrastructure according the the GLUE2 schema.
Not true. No Grid deploys Glue2 schema yet (though this is the goal), and very few Grids run any information system at all.
3.2) Each grid User can query this Information Service anonymously in order to know which security protocol he has to use to submit requests to grid Services.
Not necessarily true. Existing information systems are anonymously accessible all the way through; and what will happen to future systems is up to us to decide.
3.3) Each grid User can directly access data hosted by grid Storage Services. For Authentication, the grid User can present the public part of his X509 certificate or X509 proxy. For Authorization, the grid User can present : 3.3.1) the public part of his VOMS proxy, or 3.3.2) a bag of SAML assertions.
It's a bit more complex: quite commonly, data are accessed not directly, but via an SRM interface.
3.4) Each grid User can submit Jobs to grid Computing Services. If such a Job needs access to data hosted by grid Storage Services, then the grid User must provide a delegation token. This delegation token can be : 3.4.1) a full VOMS proxy, or 3.4.2) a bag of SAML assertions.
4) Consequences for Interoperability ------------------------------------- 4.1) X509 proxies MUST fully comply to RFC 3820.
4.2) VOMS services, which deliver X509 proxies with VOMS extensions, MUST fully comply to RFC 3820.
4.3) The authentication library used by grid Services MUST fully comply to RFC 3820 (for example a recent version of OpenSLL), so that it can accept as well X509 certificates as X509 proxies.
4.4) Each grid Site providing grid Services to grid Users MUST install files describing VOMS authorizations and other authorizations, and keep them up to date.
I do not understand what is meant by that. VOMS is a service; a user only needs to know the end-point. It is true however that the sites need to install VOMS server's public key and keep it up-to-date. This is actually the ugliest point, because there is no simple way of locating a VOMS service key, there is no any repository of such, and VOMS service providers themselves often "forget" to advertise the key location. One can easily retrieve it via openssl though.
4.5) The semantics of Authorization tokens MUST be the same for all grid Infrastructures : 4.5.1) VOMS extensions 4.5.2) Restriction attributes
4.6) The Information Service of each grid Infrastructure MUST describe, for each grid Service, which Authorization tokens this Service understands (potentially several) : 4.6.1) VOMS extensions 4.6.2) X509 restriction attributes 4.6.3) SAML assertions
4.7) For SAML assertions, the Information Service of each grid Infrastructure MUST describe, for each grid Service, how they are transported : 4.7.1) As attributes of X509 proxies 4.7.2) Inside a SOAP header
Unfinished ...
Cheers, Oxana
Looking through this though I would assert that the limitations to just long lived X509 seems not in keeping with for example the ongoing discussions about trusting Shibboleth generated certs etc?? I have just been speaking to the security person from our NREN who specifically mentioned that Shib tokens across national boundaries is becoming essential and will be subject to an IGTF type body pretty soon. David On 23/03/2009 23:09, "Oxana Smirnova" <oxana.smirnova@hep.lu.se> wrote:
Hi,
most of the statements are accurate; just some corrections inline:
1) Grid Users and Certificate Authorities ----------------------------------------- 1.1) Each grid User is authenticated by a legal body (recognized by a government).
1.2) This legal body uses a Certificate Authority to grant a (long lived) X509 certificate to the grid User.
1.3) Each Certificate Authority is itself or is authenticated by a self-signed Root Certificate Authority.
1.4) All such Root Certificate Authorities trust each other and cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management Authorities).
1.5) These 3 Policy Management Authorities trust each other and cooperate within IGTF.
1.6) IGTF distributes the list of CA Certificates to be trusted.
1.7) Each grid Site providing grid Services to grid Users MUST install this list of CA Certificates and keep it up to date.
Not exactly: a Grid site installs those certificates it deems necessary. In general, there is no requirement to keep them up-to-date, but typically it is considered a security update and as such is strongly recommended to apply. Some infrastructures issue warnings for sites with outdated CA certs, but normally it does not impede operations.
1.8) Using its X509 certificate, each grid User can create at any time a (short lived) X509 proxy with permits impersonation / delegation during a short period.
This period is not necessarily "short": technically, it is limited only by the life time of the original certificate itself.
2) Virtual Organizations ------------------------- 2.1) A Virtual Organization (VO) groups grid Users with common goals. A VO is NOT a legal body, can NOT be a Certificate Authority, and can NOT issue X509 certificates.
A VO may well be associated with a legal body, nothing prevents it. It may also be a grouping by e.g. geopolitical principle, not necessarily by a common goal. Some VOs are known to run own Certificate Authorities, though they are not a part of IGTF and are trusted only by the VO members and respective resource providers themselves.
2.2) Inside DEISA, a Virtual Community also groups grid Users with common goals. The relationships between Virtual Communities and Virtual Organizations has to be precised by Morris RIEDEL.
2.3) Each grid User belongs to 1 ore more VO (Virtual Organization), which grants him access rights to grid Storage and Computing Ressources.
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) 2.4.2) SAML assertions
It can also be done by more crude means, like plain text mapping of known VO members to local UIDs. Not that it conforms to any standard, of course, but you'll be surprised to learn how widely it is used. The decision is always with the site owner.
3) Grid Services : Information, AUTHN, AUTHZ ---------------------------------------------- 3.1) Each grid Infrastucture provides an Information Service, with describes the Infrastructure according the the GLUE2 schema.
Not true. No Grid deploys Glue2 schema yet (though this is the goal), and very few Grids run any information system at all.
3.2) Each grid User can query this Information Service anonymously in order to know which security protocol he has to use to submit requests to grid Services.
Not necessarily true. Existing information systems are anonymously accessible all the way through; and what will happen to future systems is up to us to decide.
3.3) Each grid User can directly access data hosted by grid Storage Services. For Authentication, the grid User can present the public part of his X509 certificate or X509 proxy. For Authorization, the grid User can present : 3.3.1) the public part of his VOMS proxy, or 3.3.2) a bag of SAML assertions.
It's a bit more complex: quite commonly, data are accessed not directly, but via an SRM interface.
3.4) Each grid User can submit Jobs to grid Computing Services. If such a Job needs access to data hosted by grid Storage Services, then the grid User must provide a delegation token. This delegation token can be : 3.4.1) a full VOMS proxy, or 3.4.2) a bag of SAML assertions.
4) Consequences for Interoperability ------------------------------------- 4.1) X509 proxies MUST fully comply to RFC 3820.
4.2) VOMS services, which deliver X509 proxies with VOMS extensions, MUST fully comply to RFC 3820.
4.3) The authentication library used by grid Services MUST fully comply to RFC 3820 (for example a recent version of OpenSLL), so that it can accept as well X509 certificates as X509 proxies.
4.4) Each grid Site providing grid Services to grid Users MUST install files describing VOMS authorizations and other authorizations, and keep them up to date.
I do not understand what is meant by that. VOMS is a service; a user only needs to know the end-point. It is true however that the sites need to install VOMS server's public key and keep it up-to-date. This is actually the ugliest point, because there is no simple way of locating a VOMS service key, there is no any repository of such, and VOMS service providers themselves often "forget" to advertise the key location. One can easily retrieve it via openssl though.
4.5) The semantics of Authorization tokens MUST be the same for all grid Infrastructures : 4.5.1) VOMS extensions 4.5.2) Restriction attributes
4.6) The Information Service of each grid Infrastructure MUST describe, for each grid Service, which Authorization tokens this Service understands (potentially several) : 4.6.1) VOMS extensions 4.6.2) X509 restriction attributes 4.6.3) SAML assertions
4.7) For SAML assertions, the Information Service of each grid Infrastructure MUST describe, for each grid Service, how they are transported : 4.7.1) As attributes of X509 proxies 4.7.2) Inside a SOAP header
Unfinished ...
Cheers, Oxana _______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
2009/3/24 David Wallom <david.wallom@oerc.ox.ac.uk>:
Looking through this though I would assert that the limitations to just long lived X509 seems not in keeping with for example the ongoing discussions about trusting Shibboleth generated certs etc??
That's how I read it at first but Etienne's writeup (if that's what you're referring to) is restricted to proxies. Clearly(?) a SLC is a PKC as well.
I have just been speaking to the security person from our NREN who specifically mentioned that Shib tokens across national boundaries is becoming essential and will be subject to an IGTF type body pretty soon.
They are currently recommending using self signed certificates for the SPs as trust anchors. I hear slightly different messages from within the NREN in question but they are indicating that SAML assertions are "moving to" being signed by such trust anchors. I think I referred to it in an earlier mail to PGI-WG. --jens
-----Original Message----- From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of Oxana Smirnova Sent: 24 March 2009 00:10 To: Etienne Urbah Cc: pgi-wg@ogf.org; Vincenzo Ciaschini; edges-na3@mail.edges-grid.eu; lodygens@lal.in2p3.fr Subject: Re: [Pgi-wg] OGF PGI - Security Strawman
Hi,
most of the statements are accurate; just some corrections inline:
1) Grid Users and Certificate Authorities ----------------------------------------- 1.1) Each grid User is authenticated by a legal body (recognized by a government).
1.2) This legal body uses a Certificate Authority to grant a (long lived) X509 certificate to the grid User.
1.3) Each Certificate Authority is itself or is authenticated by a self-signed Root Certificate Authority.
1.4) All such Root Certificate Authorities trust each other and cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management Authorities).
1.5) These 3 Policy Management Authorities trust each other and cooperate within IGTF.
1.6) IGTF distributes the list of CA Certificates to be trusted.
1.7) Each grid Site providing grid Services to grid Users MUST install this list of CA Certificates and keep it up to date.
Not exactly: a Grid site installs those certificates it deems necessary. In general, there is no requirement to keep them up-to-date, but typically it is considered a security update and as such is strongly recommended to apply. Some infrastructures issue warnings for sites with outdated CA certs, but normally it does not impede operations.
1.8) Using its X509 certificate, each grid User can create at any
time
a (short lived) X509 proxy with permits impersonation / delegation during a short period.
This period is not necessarily "short": technically, it is limited only by the life time of the original certificate itself.
2) Virtual Organizations ------------------------- 2.1) A Virtual Organization (VO) groups grid Users with common
goals. A
VO is NOT a legal body, can NOT be a Certificate Authority, and can NOT issue X509 certificates.
A VO may well be associated with a legal body, nothing prevents it. It may also be a grouping by e.g. geopolitical principle, not necessarily by a common goal. Some VOs are known to run own Certificate Authorities, though they are not a part of IGTF and are trusted only by the VO members and respective resource providers themselves.
2.2) Inside DEISA, a Virtual Community also groups grid Users with common goals. The relationships between Virtual Communities and Virtual Organizations has to be precised by Morris RIEDEL.
2.3) Each grid User belongs to 1 ore more VO (Virtual Organization), which grants him access rights to grid Storage and Computing Ressources.
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) 2.4.2) SAML assertions
It can also be done by more crude means, like plain text mapping of known VO members to local UIDs. Not that it conforms to any standard, of course, but you'll be surprised to learn how widely it is used. The decision is always with the site owner.
3) Grid Services : Information, AUTHN, AUTHZ ---------------------------------------------- 3.1) Each grid Infrastucture provides an Information Service, with describes the Infrastructure according the the GLUE2 schema.
Not true. No Grid deploys Glue2 schema yet (though this is the goal), and very few Grids run any information system at all.
3.2) Each grid User can query this Information Service anonymously
in
order to know which security protocol he has to use to submit requests to grid Services.
Not necessarily true. Existing information systems are anonymously accessible all the way through; and what will happen to future systems is up to us to decide.
3.3) Each grid User can directly access data hosted by grid Storage Services. For Authentication, the grid User can present the public
part
of his X509 certificate or X509 proxy. For Authorization, the grid User can present : 3.3.1) the public part of his VOMS proxy, or 3.3.2) a bag of SAML assertions.
It's a bit more complex: quite commonly, data are accessed not directly, but via an SRM interface.
3.4) Each grid User can submit Jobs to grid Computing Services. If such a Job needs access to data hosted by grid Storage Services,
This high level summary would seem a useful non-normative preamble to any security document produced by the group. Splitting it into the current established base and where we propose to go (addressing Oxana's comments) would give a VERY SHORT CONCISE roadmap document and illustrate the benefits of this work. Steven Dr Steven Newhouse EGEE Technical Director http://cern.ch/Steven.Newhouse then
the grid User must provide a delegation token. This delegation token can be : 3.4.1) a full VOMS proxy, or 3.4.2) a bag of SAML assertions.
4) Consequences for Interoperability ------------------------------------- 4.1) X509 proxies MUST fully comply to RFC 3820.
4.2) VOMS services, which deliver X509 proxies with VOMS extensions, MUST fully comply to RFC 3820.
4.3) The authentication library used by grid Services MUST fully comply to RFC 3820 (for example a recent version of OpenSLL), so that it can accept as well X509 certificates as X509 proxies.
4.4) Each grid Site providing grid Services to grid Users MUST install files describing VOMS authorizations and other authorizations, and keep them up to date.
I do not understand what is meant by that. VOMS is a service; a user only needs to know the end-point. It is true however that the sites need to install VOMS server's public key and keep it up-to-date. This is actually the ugliest point, because there is no simple way of locating a VOMS service key, there is no any repository of such, and VOMS service providers themselves often "forget" to advertise the key location. One can easily retrieve it via openssl though.
4.5) The semantics of Authorization tokens MUST be the same for all grid Infrastructures : 4.5.1) VOMS extensions 4.5.2) Restriction attributes
4.6) The Information Service of each grid Infrastructure MUST describe, for each grid Service, which Authorization tokens this Service understands (potentially several) : 4.6.1) VOMS extensions 4.6.2) X509 restriction attributes 4.6.3) SAML assertions
4.7) For SAML assertions, the Information Service of each grid Infrastructure MUST describe, for each grid Service, how they are transported : 4.7.1) As attributes of X509 proxies 4.7.2) Inside a SOAP header
Unfinished ...
Cheers, Oxana _______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
Steven and all, Thank you for all your comments. I tried to take them all into account. The new version is attached here as 'PGI-Security-Model.txt', and also available at http://forge.gridforum.org/sf/go/doc15584?nav=1 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@lal.in2p3.fr ---------------------------------- On Tue, 24 Mar 2009, Steven Newhouse wrote:
This high level summary would seem a useful non-normative preamble to any security document produced by the group.
Splitting it into the current established base and where we propose to go (addressing Oxana's comments) would give a VERY SHORT CONCISE roadmap document and illustrate the benefits of this work.
Steven
Dr Steven Newhouse EGEE Technical Director http://cern.ch/Steven.Newhouse
OGF PGI - Security Model ======================== Current Established Base ======================== Chapters 1, 2 and 3 below describe the current security model of Computing Grid Infrastructures. 1) Grid Users and Certificate Authorities ----------------------------------------- 1.1) Each grid User is authenticated by a legal body (recognized by a government). 1.2) This legal body uses a Certificate Authority to grant a (long lived) X509 certificate to the grid User. 1.3) Each Certificate Authority is itself or is authenticated by a self-signed Root Certificate Authority. 1.4) All such Root Certificate Authorities trust each other and cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management Authorities). 1.5) These 3 Policy Management Authorities trust each other and cooperate within IGTF. 1.6) IGTF distributes the list of CA Certificates to be trusted. 1.7) Each grid Site providing grid Services to grid Users installs the CA Certificates it deems necessary. In general, there is no requirement to keep them up-to-date, but typically it is considered a security update and as such is strongly recommended to apply. Some infrastructures issue warnings for sites with outdated CA certs, but normally it does not impede operations. 1.8) Using its X509 certificate, each grid User can create at any time a (usually short lived) X509 proxy with permits impersonation / delegation during a (usually short) period. 2) Virtual Organizations ------------------------- 2.1) A Virtual Organization (VO) groups grid Users (usually with common goals). A Virtual Organization may be a legal body, and may be a Certificate Authority which can issue X509 certificates, but most are NOT. 2.2) Inside DEISA, a Virtual Community also groups grid Users with common goals. The relationships between Virtual Communities and Virtual Organizations have to be explained by Morris RIEDEL. 2.3) Each grid User belongs to 1 or more VO (Virtual Organization), which grants him access rights to grid Storage and Computing Resources. 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) 2.4.2) SAML assertions 3) Grid Services : Information, AUTHN, AUTHZ ---------------------------------------------- 3.1) Some grid Infrastructures provide an Information Service with describes the Infrastructure, for example according to the 'GLUE 1.3' schema. 3.2) If this Information Service exists, then each grid User can query it in order to discover the list, requirements and capabilities of grid Services. 3.3) Each grid User can directly access data hosted by grid Storage Services. For Authentication, the grid User can present the public part of his X509 certificate or X509 proxy. For Authorization, the grid User has to present either (depending on the Infrastructure) : 3.3.1) the public part of his VOMS proxy, or 3.3.2) a bag of SAML assertions. If the grid User accesses data through a interface requiring delegation, then the next subchapter applies. 3.4) Each grid User can submit Jobs to grid Computing Services. If such a Job needs access to data hosted by grid Storage Services, then the grid User must provide a delegation token. This delegation token is either (depending on the Infrastructure) : 3.4.1) a full VOMS proxy, or 3.4.2) a bag of SAML assertions. Morris RIEDEL has to explain if and how delegation of SAML assertions work. 3.5) Each grid Site providing grid Services to grid Users has installed Authorization Files (such as 'gridmap' files) describing VOMS authorizations, other authorizations, and mapping of known VO members to local UIDs. Grid Sites try to keep those Authorization Files up to date. There is a trend to replace these static 'gridmap' files by a robust Authorization Service (SCAS by EGEE, GUMS by OSG). Where we propose to go ====================== Chapters 4, 5, 6 and 7 below describe a security model for short term Interoperability between Computing Grid Infrastructures. 4) Operational Robustness of Security -------------------------------------- 4.1) The number of Certificate Authorities for grid Infrastructures SHOULD be kept as low as possible. 5) Interoperability between X509 certificates and X509 proxies for Authentication ---------------------------------------------------------------------------------- 5.1) For this short term Security Profile aimed at short term Interoperability, we accept Shibboleth as an option, but knowingly exclude Shibboleth from any requirement. 5.2) X509 proxies MUST fully comply to RFC 3820. 5.3) VOMS services, which deliver X509 proxies with VOMS extensions, MUST fully comply to RFC 3820. 5.4) The authentication library used by grid Services MUST fully comply to RFC 3820 (for example a recent version of OpenSLL), so that it can accept as well X509 certificates as X509 proxies. 6) Information Service describing the Infrastructure according the the GLUE2 schema ------------------------------------------------------------------------------------ 6.1) Each grid Infrastructure MUST provide an Information Service, which describes the Infrastructure according the the GLUE2 schema. 6.2) If access to the Information Service is restricted, the grid Infrastructure MUST provide a Bootstrap Information Service, with describes the security requirements for access to the full Information Service according the the GLUE2 schema. 7) Interoperable Grid Services : Information, AUTHN, AUTHZ ------------------------------------------------------------ 7.1) The semantics of Authorization tokens MUST be the same for all grid Infrastructures : 7.1.1) VOMS extensions 7.1.2) Restriction attributes 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) : 7.2.1) X509 VOMS extensions 7.2.2) X509 restriction attributes 7.2.3) SAML assertions 7.3) For SAML assertions, the Information Service of each grid Infrastructure MUST describe, for each grid Service, the transport method that the grid Service expects (potentially several) : 7.3.1) As attributes of X509 proxies 7.3.2) Inside a SOAP header 7.4) Each grid Site providing grid Services to grid Users MUST install and keep up to date a robust Authorization Service describing VOMS authorizations, other authorizations, and mapping of known VO members to local UIDs. 7.5) Each grid Service MUST accept at least : 7.5.1) One of the Authorization Tokens described at chapter 7.2 7.5.2) One of the transport methods described at chapter 7.3 (only if the grid Service accepts SAML assertions) 7.6) As long as it satisfies subchapter 7.5, each grid Service MAY also accept Authentication and Authorization methods based on Shibboleth. 7.7) In order to ease the development and deployment of grid Clients, each grid Service SHOULD accept ALL types of Authorization Tokens described at chapter 7.2 If it accepts SAML assertions, it SHOULD accept that they are transported inside SOAP headers. 7.8) In order to keep middleware complexity and bandwidth usage as low as possible, grid Services should NOT send their full description of their security interface inside each message, but only when specifically requested (for example by the Information Service). To be thoroughly criticized ...
Looks like a good foundation. A couple of comments/suggestions: - Section (7.1.1). This section discusses the necessity for shared-semantics amongst authorization token formats. Instead of "VOMS extensions", which is unclear what that means, I think you mean "FQAN-equivalent semantics for describing VO groups/roles." - Section (7.2). If we have the semantic equivalences described in (7.1), then the incoming message-processing stack of a PGI-compliant service endpoint should be able process all three types of client-credentialing mechanisms equivalently: - Clients supply SAML attributes authenticated by End-Entity Certificates at the SOAP level (*Idealized Unicore*) - Clients supply SAML attributes authenticated by Proxy-Certificates at the SOAP level (*Idealized Genesis II*) - Clients supply VOMS-style Attribute Certificates authenticated by (and embedded within) Proxy Certificates at the SSL/TLS level (*Idealized gLite/ARC/Naregi*) By the time message-processing reaches a policy-decision module, the service has distilled an authenticated set of distinguished names, FQAN groups/roles, and restriction policies that look the same, independent of how they were supplied. By mandating a "receiver-makes-right" strategy (section 7.7), you obviate the complexity of sections (7.3) and (7.5). Such reduced complexity affords us a quicker incremental roadmap in which clients can remain largely unchanged, while additional infrastructure complexity is only initially needed at those service endpoints intended for advertisement within multiple infrastructures. - Section (7.4). Be careful with your language: do not mandate the management of authz/authn information not relevant to inter-grid interaction. (E.g., Genesis II does not make use of local-UID mappings ). - The document is missing a brief consensus on SOAP-over-HTTPS communication that mandates a specific variant of SSL/TLS (i.e., anything that implements RFC-2246, The TLS Protocol Version 1.0, which excludes GSI-OpenSSH.) -Duane
Duane, Thank you for your comments. Please find the original text and my answers inline. Beyond that : 7.9) Semantics and syntax of VOMS extensions and Restriction attributes ----------------------------------------------------------------------- I would like to describe (for example in new section 7.9) the semantics and syntax of a RESTRICTED list of VOMS extensions and Restriction attributes that all grid clients MAY use and that all grid services MUST understand. Does anybody have links to such lists ? - For VOMS extension, the example below gives : VO, subject, issuer, attribute, timeleft, uri - For other attributes, here is something springing out from my imagination, with semantics and syntax (please criticize) : - Assertion of identity : ID:<FQAN> - Assertion of belonging to a group : GROUP:<FQAN> - Authorization to access a resource : ALLOW:<URI> - Interdiction to access a resource : DENY:<URI> - Authorization to read a file (or a folder, recursively : ALLOW_R:<URI> - Authorization to write into a file (or a folder, recursively : ALLOW_W:<URI> - Authorization to read and write into a file (or a folder, recursively : ALLOW_RW:<URI> Note that GLUE 2.0 recommends that the URI should be an URN. 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@lal.in2p3.fr ---------------------------------- On Duane Merrill wrote:
Looks like a good foundation. A couple of comments/suggestions:
7.1) The semantics of Authorization tokens MUST be the same for all grid Infrastructures : 7.1.1) VOMS extensions 7.1.2) Restriction attributes This section discusses the necessity for shared-semantics amongst authorization token formats. Instead of "VOMS extensions", which is unclear what that means, I think you mean "FQAN-equivalent semantics for describing VO groups/roles."
VOMS extensions of X509 proxies are NOT a simple FQAN. See following example, extracted from ' voms-proxy-info -all' on a gLite UI : === VO vo.lal.in2p3.fr extension information === VO : vo.lal.in2p3.fr subject : /O=GRID-FR/C=FR/O=CNRS/OU=LAL/CN=Etienne Urbah issuer : /O=GRID-FR/C=FR/O=CNRS/OU=LAL/CN=grid12.lal.in2p3.fr attribute : /vo.lal.in2p3.fr/Role=NULL/Capability=NULL timeleft : 11:59:50 uri : grid12.lal.in2p3.fr:20000 I agree that we have to describe the full list of VOMS extensions with their meaning and syntax (or provide a link to the relevant VOMS specification).
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) : 7.2.1) X509 VOMS extensions 7.2.2) X509 restriction attributes 7.2.3) SAML assertions If we have the semantic equivalences described in (7.1), then the incoming message-processing stack of a PGI-compliant service endpoint should be able process all three types of client-credentialing mechanisms equivalently:
o Clients supply SAML attributes authenticated by End-Entity Certificates at the SOAP level (/Idealized Unicore/) o Clients supply SAML attributes authenticated by Proxy-Certificates at the SOAP level (/Idealized Genesis II/) o Clients supply VOMS-style Attribute Certificates authenticated by (and embedded within) Proxy Certificates at the SSL/TLS level (/Idealized gLite/ARC/Naregi/)
By the time message-processing reaches a policy-decision module, the service has distilled an authenticated set of distinguished names, FQAN groups/roles, and restriction policies that look the same, independent of how they were supplied. By mandating a "receiver-makes-right" strategy (section 7.7), you obviate the complexity of sections (7.3) and (7.5). Such reduced complexity affords us a quicker incremental roadmap in which clients can remain largely unchanged, while additional infrastructure complexity is only initially needed at those service endpoints intended for advertisement within multiple infrastructures.
You can obviate the complexity of sections 7.3 and 7.5 only if section 7.7 is mandatory (with a 'MUST' wording), which means you force every middleware to implement immediately the 3 types of Authorization tokens. In fact, you can NOT force that. This is the reason why I used the 'SHOULD' wording in section 7.7, and this forces the Information System to provide the list of Authorization tokens and transport methods really accepted by each grid Service.
7.4) Each grid Site providing grid Services to grid Users MUST install and keep up to date a robust Authorization Service describing VOMS authorizations, other authorizations, and mapping of known VO members to local UIDs. Be careful with your language: do not mandate the management of authz/authn information not relevant to inter-grid interaction. (E.g., Genesis II does not make use of local-UID mappings).
You are right, I will replace the reference to local-UID mappings by something more general.
The document is missing a brief consensus on SOAP-over-HTTPS communication that mandates a specific variant of SSL/TLS (i.e., anything that implements RFC-2246, The TLS Protocol Version 1.0, which excludes GSI-OpenSSH.)
I do NOT have enough knowledge about WS, SOAP and RFC-2246 to write something sensible. Can you write it yourself ?
-Duane
Etienne URBAH wrote:
Duane,
Thank you for your comments. Please find the original text and my answers inline.
Beyond that :
7.9) Semantics and syntax of VOMS extensions and Restriction attributes ----------------------------------------------------------------------- I would like to describe (for example in new section 7.9) the semantics and syntax of a RESTRICTED list of VOMS extensions and Restriction attributes that all grid clients MAY use and that all grid services MUST understand.
Does anybody have links to such lists ?
- For VOMS extension, the example below gives : VO, subject, issuer, attribute, timeleft, uri Just for clarity: attribute is indeed a list of attributes. There may be more than one.
Also, information from more than one VO may be present.
- For other attributes, here is something springing out from my imagination, with semantics and syntax (please criticize) : - Assertion of identity : ID:<FQAN> - Assertion of belonging to a group : GROUP:<FQAN> - Authorization to access a resource : ALLOW:<URI> - Interdiction to access a resource : DENY:<URI> - Authorization to read a file (or a folder, recursively : ALLOW_R:<URI> - Authorization to write into a file (or a folder, recursively : ALLOW_W:<URI> - Authorization to read and write into a file (or a folder, recursively : ALLOW_RW:<URI> Note that GLUE 2.0 recommends that the URI should be an URN.
I agree that we have to describe the full list of VOMS extensions with their meaning and syntax (or provide a link to the relevant VOMS specification).
How about this? https://forge.gridforum.org/sf/go/doc13797 (also referenced in the strawman doc) If it is unclear, I'd love to receive comments. Ciao, Vincenzo
These "VOMS extensions" you keep referring to are actually X.509 Attribute Certificates that are well-defined in an IETF RFC and refined by the OGSA-Authz VOMS doc. You should call them "VOMS-style ACs" (since they can be constructed by an authn authority other than an actual VOMS server.). Section 7.1.1 needs to be about defining a shared semantics between attribute documents (specifically VOMS-style ACs and a new PGI definition of equivalent SAML attribute assertions), which is something that the strawman doc already does in gory detail. (Although it needs an updating to reflect the proper authentication of SAML attribute assertions by Proxy Certificates -- the idealized Genesis II credentialing mechanism.) Duane On 3/25/09, Vincenzo Ciaschini <vincenzo.ciaschini@cnaf.infn.it> wrote:
Etienne URBAH wrote:
Duane,
Thank you for your comments. Please find the original text and my answers inline.
Beyond that :
7.9) Semantics and syntax of VOMS extensions and Restriction attributes ----------------------------------------------------------------------- I would like to describe (for example in new section 7.9) the semantics and syntax of a RESTRICTED list of VOMS extensions and Restriction attributes that all grid clients MAY use and that all grid services MUST understand.
Does anybody have links to such lists ?
- For VOMS extension, the example below gives : VO, subject, issuer, attribute, timeleft, uri Just for clarity: attribute is indeed a list of attributes. There may be more than one.
Also, information from more than one VO may be present.
- For other attributes, here is something springing out from my imagination, with semantics and syntax (please criticize) : - Assertion of identity : ID:<FQAN> - Assertion of belonging to a group : GROUP:<FQAN> - Authorization to access a resource : ALLOW:<URI> - Interdiction to access a resource : DENY:<URI> - Authorization to read a file (or a folder, recursively : ALLOW_R:<URI> - Authorization to write into a file (or a folder, recursively : ALLOW_W:<URI> - Authorization to read and write into a file (or a folder, recursively : ALLOW_RW:<URI> Note that GLUE 2.0 recommends that the URI should be an URN.
I agree that we have to describe the full list of VOMS extensions with their meaning and syntax (or provide a link to the relevant VOMS specification).
How about this? https://forge.gridforum.org/sf/go/doc13797 (also referenced in the strawman doc)
If it is unclear, I'd love to receive comments.
Ciao, Vincenzo
Vincenzo, Concerning the full list of VOMS extensions with their meaning and syntax : Thank you very much for the link to the 'VOMS Attribute Certificate Format' document. I have added it inside 'PGI / Input Documents / Security Material'. For the sake of interoperability, I suggest that you reverse the statement written in chapter 4.2 'KeyUsage extension'. I propose : For interoperability of authentication through X509 certificates and X509 proxies, this extension MAY be absent. 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@lal.in2p3.fr ---------------------------------- On Wed, 25 Mar 2009, Vincenzo Ciaschini wrote:
Etienne URBAH wrote:
Duane,
Thank you for your comments. Please find the original text and my answers inline.
Beyond that :
7.9) Semantics and syntax of VOMS extensions and Restriction attributes ----------------------------------------------------------------------- I would like to describe (for example in new section 7.9) the semantics and syntax of a RESTRICTED list of VOMS extensions and Restriction attributes that all grid clients MAY use and that all grid services MUST understand.
Does anybody have links to such lists ?
- For VOMS extension, the example below gives : VO, subject, issuer, attribute, timeleft, uri Just for clarity: attribute is indeed a list of attributes. There may be more than one.
Also, information from more than one VO may be present.
I agree that we have to describe the full list of VOMS extensions with their meaning and syntax (or provide a link to the relevant VOMS specification).
How about this? https://forge.gridforum.org/sf/go/doc13797 (also referenced in the strawman doc)
If it is unclear, I'd love to receive comments.
Ciao, Vincenzo
You can obviate the complexity of sections 7.3 and 7.5 only if section 7.7 is mandatory (with a 'MUST' wording), which means you force every middleware to implement immediately the 3 types of Authorization tokens.
In fact, you can NOT force that. This is the reason why I used the 'SHOULD' wording in section 7.7, and this forces the Information System to provide the list of Authorization tokens and transport methods really accepted by each grid Service.
I *strongly* disagree; PGI does need to force that. The goal is not to demand that *all* middleware endpoints be *fully* interoperable; just those that are advertised outside of that infrastructure. And if a particular endpoint is PGI-compliant, there is no reason it shouldn't be able to accept the two major credentialing mechanisms (SAML, AC), particularly since we're defining them to be equivalent. What you propose does NOT foster interoperability: - If a client wishes to call a remote service, it must somehow translate its credentials into that service's desired format. This is what must be done at present time, and it's *not* interoperable. - Some types of credential-translation are simply not possible (e.g., converting a proxy-cert into an EEC), so whole classes of clients will be unable to use whole classes of services, which is *not* interoperable. We should avoid enabling this situation (because it's what we have at present time, so nothing is gained). It's not that hard to support both credential mechanisms in the message-processing stack. In fact, it's harder to do what you propose: build the logic to detect service-type, perform token exchange, failover if service-type is unsupported, etc., into clients. And you gain virtually NOTHING for the effort. The quickest route to interop is one in which - Inter-grid clients adhere to one (or more) of two profiles: SAML & AC (the idealized-Unicore is a sub-instance of idealized-Genesis II) - Inter-grid services support both, since we've defined the two client profiles to be semantically equivalent. -Duane
Duane Merrill wrote:
You can obviate the complexity of sections 7.3 and 7.5 only if section 7.7 is mandatory (with a 'MUST' wording), which means you force every middleware to implement immediately the 3 types of Authorization tokens.
In fact, you can NOT force that. This is the reason why I used the 'SHOULD' wording in section 7.7, and this forces the Information System to provide the list of Authorization tokens and transport methods really accepted by each grid Service.
I *strongly* disagree; PGI does need to force that. The goal is not to demand that *all* middleware endpoints be *fully* interoperable; just those that are advertised outside of that infrastructure. And if a particular endpoint is PGI-compliant, there is no reason it shouldn't be able to accept the two major credentialing mechanisms (SAML, AC), particularly since we're defining them to be equivalent.
While I agree that a single security model should be the ultimate goal (for all the reasons you already stated), I see technical problems in having it implemented in all infrastructures, at least in the medium term. That was the reason why the initial work within PGI was focused on having a small set (ideally, two) of security profiles and having the clients sustain the burden of supporting both and deciding which one to use--which seems reasonable as it is the client responsibility to acquire the appropriate credentials. Just to describe one of the technical problema I am alluding at, in CREAM we use an external component called gLExec to perform Grid user ID -> Unix user ID mappings. At the moment, gLExec supports X509 (proxy) certificates with VOMS extensions only, and there is no way (apart from rewriting a significant part of it) to make it support anything else. While gLite is going to migrate to a new authorization framework, it is still (very early) work in progress. And to make things worse, CREAM is unable to bypass gLExec easily: gLExec is called once by CREAM, and once by BLAH, which is a batch system abstraction layer which provides a single interface to multiple batch systems (and thus is used by CREAM to support LSF/PBS/SGE/...). Neither gLExec nor BLAH are under our (=CREAM developers) control, and modifying CREAM to get rid of them when submitting jobs through a PGI compliant interface is a nontrivial work which requires some significant effort. I understand that these are gLite-specific, low level details, but maybe other middlewares have similar issues. I also understand that the software and the infrastructures are going to evolve anyway, but in some situations evolution happens quite slowly. In my opinion, having e.g. two well defined PGI security profiles, such that existing infrastructures can easily support at least one of them would be better than the current situation in which everybody implements something different. It would be a compromise, of course, and the ideal long term solution would be to converge to a single profile, but I'm unsure whether aiming right now at this long term solution would be a good idea. Moreno. -- Moreno Marzolla INFN Sezione di Padova, via Marzolo 8, 35131 PADOVA, Italy EMail: moreno.marzolla@pd.infn.it Phone: +39 049 8277103 WWW : http://www.dsi.unive.it/~marzolla Fax : +39 049 8756233
So, what you're saying is that it is, for all intents and purposes, infeasible for the CREAM BES to support an attribute authorization scheme other than VOMS-style-ACs-inside-EECs/PCs. This leads me to draw the following conclusion: *Don't bother advertising CREAM BESs as inter-middleware services*. Unicore/GenesisII/etc. infrastructures don't have the means for clients to obtain PCs or EECs that have VOMS-style ACs signed within them, so in all reality your CREAM BESs will never be used by those middlewares anyway. If you need to share your resource across middleware domains, stand up a BES that can support *both* types of credentialing mechanisms instead. The issue holding the client back is that they have a signed SAML assertion that cannot be traded for a signed VOMS-style AC without the involvment of a hypothetical third-party attribute authority. The implementation work necessary for such infrastructure would be just as substantial (if not more so) than the modifications necessary for CREAM, and would become obsolete as we move towards the "eventual goal". Now, if your CREAM BES could support PGI-SAML embedded within PCs, it would be trivial for the client to create a proxy certificate for itself with the SAML attribute embedded within...... -Duane On Thu, Mar 26, 2009 at 9:24 AM, Moreno Marzolla <moreno.marzolla@pd.infn.it
wrote:
Duane Merrill wrote:
You can obviate the complexity of sections 7.3 and 7.5 only if section 7.7 is mandatory (with a 'MUST' wording), which means you force every middleware to implement immediately the 3 types of Authorization tokens.
In fact, you can NOT force that. This is the reason why I used the 'SHOULD' wording in section 7.7, and this forces the Information System to provide the list of Authorization tokens and transport methods really accepted by each grid Service.
I *strongly* disagree; PGI does need to force that. The goal is not to demand that *all* middleware endpoints be *fully* interoperable; just those that are advertised outside of that infrastructure. And if a particular endpoint is PGI-compliant, there is no reason it shouldn't be able to accept the two major credentialing mechanisms (SAML, AC), particularly since we're defining them to be equivalent.
While I agree that a single security model should be the ultimate goal (for all the reasons you already stated), I see technical problems in having it implemented in all infrastructures, at least in the medium term. That was the reason why the initial work within PGI was focused on having a small set (ideally, two) of security profiles and having the clients sustain the burden of supporting both and deciding which one to use--which seems reasonable as it is the client responsibility to acquire the appropriate credentials. Just to describe one of the technical problema I am alluding at, in CREAM we use an external component called gLExec to perform Grid user ID -> Unix user ID mappings. At the moment, gLExec supports X509 (proxy) certificates with VOMS extensions only, and there is no way (apart from rewriting a significant part of it) to make it support anything else. While gLite is going to migrate to a new authorization framework, it is still (very early) work in progress. And to make things worse, CREAM is unable to bypass gLExec easily: gLExec is called once by CREAM, and once by BLAH, which is a batch system abstraction layer which provides a single interface to multiple batch systems (and thus is used by CREAM to support LSF/PBS/SGE/...). Neither gLExec nor BLAH are under our (=CREAM developers) control, and modifying CREAM to get rid of them when submitting jobs through a PGI compliant interface is a nontrivial work which requires some significant effort.
I understand that these are gLite-specific, low level details, but maybe other middlewares have similar issues. I also understand that the software and the infrastructures are going to evolve anyway, but in some situations evolution happens quite slowly.
In my opinion, having e.g. two well defined PGI security profiles, such that existing infrastructures can easily support at least one of them would be better than the current situation in which everybody implements something different. It would be a compromise, of course, and the ideal long term solution would be to converge to a single profile, but I'm unsure whether aiming right now at this long term solution would be a good idea.
Moreno.
-- Moreno Marzolla INFN Sezione di Padova, via Marzolo 8, 35131 PADOVA, Italy EMail: moreno.marzolla@pd.infn.it Phone: +39 049 8277103 WWW : http://www.dsi.unive.it/~marzolla Fax : +39 049 8756233
The same is true for the interoperability converse: gLite clients have signed VOMS-style ACs (inside their PCs) that cannot be traded for signed SAML assertions without the involvement of a hypothetical third-party attribute authority, the implementation and integration of which is also non-trivial. Thus, for all of our proposed work on profiling service-endpoint-mechanisms, we will have achieved very little in regards to real-world interoperability. -Duane
Hi Duane, BES was proposed as a standard interface for job submission. Our initial aim was to understand how/if we could adopt this interface in our infrastructures. Obviously this interface alone will not make the infrastructure fully interoperable but it would be a step in the right direction. One of the constraints that we have is that our infrastructure is based around VOMS-style-ACs and this will not change this in the short term. I would imagine any other infrastructures using a different AAA scheme would have a similar problem. Adopting the BES interface should not require people to change the AAA scheme that they used in their infrastructure. What we require is a method of using BES with VOMS-style-ACs. We may end up with multiple specification that explain how BES is used with different AAA schemes. This would highlight the real situation and we have different "Grid Islands" which can't interoperability due to the different AAA schemes used. If interoperability between these islands is required we need to address the AAA issue but that should not affect our adoption of BES. Laurence Duane Merrill wrote:
So, what you're saying is that it is, for all intents and purposes, infeasible for the CREAM BES to support an attribute authorization scheme other than VOMS-style-ACs-inside-EECs/PCs. This leads me to draw the following conclusion:
/Don't bother advertising CREAM BESs as inter-middleware services/. Unicore/GenesisII/etc. infrastructures don't have the means for clients to obtain PCs or EECs that have VOMS-style ACs signed within them, so in all reality your CREAM BESs will never be used by those middlewares anyway. If you need to share your resource across middleware domains, stand up a BES that can support /both/ types of credentialing mechanisms instead.
The issue holding the client back is that they have a signed SAML assertion that cannot be traded for a signed VOMS-style AC without the involvment of a hypothetical third-party attribute authority. The implementation work necessary for such infrastructure would be just as substantial (if not more so) than the modifications necessary for CREAM, and would become obsolete as we move towards the "eventual goal".
Now, if your CREAM BES could support PGI-SAML embedded within PCs, it would be trivial for the client to create a proxy certificate for itself with the SAML attribute embedded within......
-Duane
On Thu, Mar 26, 2009 at 9:24 AM, Moreno Marzolla <moreno.marzolla@pd.infn.it <mailto:moreno.marzolla@pd.infn.it>> wrote:
Duane Merrill wrote:
You can obviate the complexity of sections 7.3 and 7.5 only if section 7.7 is mandatory (with a 'MUST' wording), which means you force every middleware to implement immediately the 3 types of Authorization tokens.
In fact, you can NOT force that. This is the reason why I used the 'SHOULD' wording in section 7.7, and this forces the Information System to provide the list of Authorization tokens and transport methods really accepted by each grid Service.
I *strongly* disagree; PGI does need to force that. The goal is not to demand that *all* middleware endpoints be *fully* interoperable; just those that are advertised outside of that infrastructure. And if a particular endpoint is PGI-compliant, there is no reason it shouldn't be able to accept the two major credentialing mechanisms (SAML, AC), particularly since we're defining them to be equivalent.
While I agree that a single security model should be the ultimate goal (for all the reasons you already stated), I see technical problems in having it implemented in all infrastructures, at least in the medium term. That was the reason why the initial work within PGI was focused on having a small set (ideally, two) of security profiles and having the clients sustain the burden of supporting both and deciding which one to use--which seems reasonable as it is the client responsibility to acquire the appropriate credentials. Just to describe one of the technical problema I am alluding at, in CREAM we use an external component called gLExec to perform Grid user ID -> Unix user ID mappings. At the moment, gLExec supports X509 (proxy) certificates with VOMS extensions only, and there is no way (apart from rewriting a significant part of it) to make it support anything else. While gLite is going to migrate to a new authorization framework, it is still (very early) work in progress. And to make things worse, CREAM is unable to bypass gLExec easily: gLExec is called once by CREAM, and once by BLAH, which is a batch system abstraction layer which provides a single interface to multiple batch systems (and thus is used by CREAM to support LSF/PBS/SGE/...). Neither gLExec nor BLAH are under our (=CREAM developers) control, and modifying CREAM to get rid of them when submitting jobs through a PGI compliant interface is a nontrivial work which requires some significant effort.
I understand that these are gLite-specific, low level details, but maybe other middlewares have similar issues. I also understand that the software and the infrastructures are going to evolve anyway, but in some situations evolution happens quite slowly.
In my opinion, having e.g. two well defined PGI security profiles, such that existing infrastructures can easily support at least one of them would be better than the current situation in which everybody implements something different. It would be a compromise, of course, and the ideal long term solution would be to converge to a single profile, but I'm unsure whether aiming right now at this long term solution would be a good idea.
Moreno.
-- Moreno Marzolla INFN Sezione di Padova, via Marzolo 8, 35131 PADOVA, Italy EMail: moreno.marzolla@pd.infn.it <mailto:moreno.marzolla@pd.infn.it> Phone: +39 049 8277103 WWW : http://www.dsi.unive.it/~marzolla <http://www.dsi.unive.it/%7Emarzolla> Fax : +39 049 8756233
------------------------------------------------------------------------
_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
If interoperability between these islands is required we need to address the AAA issue but that should not affect our adoption of BES.
I agree completely. There are two "killer apps" for grid computing: data and compute. We should, by all means, aim to construct standard interfaces for these applications. (Having said that, I should also point out that these "wheels" have been reinvented since time immemorial...) However, failing to construct a *common* credentialing solution will result in, as you mention, "islands of grids" for *any* application standardization effort. And if islands-of-grids is an acceptable ends to our means, I have to question what we are doing in these working groups: we can simply refer the reader to a specific instance of middleware architecture documents (or implementation, even) as the standard for that "island". Problem solved. -Duane
Forgive me for pushing my logic to the extreme; I do realize that ARC/gLite/Naregi are similar enough that they could be congealed to constitute a "grid island" with some degree of effort. My point is that the working group is still faced with a crisis of identity: it is not about "production grid interoperability", but rather about "A-type interoperability", "B-type interoperability", "C-type interoperability" where {A, B, C, etc.} is the set of credentialing schemes that, depending on the effort we are willing to invest, may number as many as there are different middleware implementations (no effort), or as few as one integrated scheme. The operative phrase being "the amount of effort we are willing to invest". Perhaps we should survey *that*. -Duane
Hi Duane, I think that this is going to be the case, at least in the short term. The overall aim is to have interoperable infrastructures, at least to the point which is required by the use cases they have to support. However, if this hasn't happened in over 8 years of OGF, I don't think one working group can achieve it in 18 months. The security model is the fundamental building block that needs to be agreed but we are very far from achieving this goal. What we can do is cluster around certain security models and move forward in other areas. The VOMS-style approach is one such cluster and we need to have a way of using this with BES. Others may need to define a way of working with SAML and BES etc. As you said, we can define these as separate profiles and point the cluster to the respective documents. Job Done. Grid Islands will still be around but they will be larger and closer. We are attempting to bridge these islands one stepping stone at a time. BES is one more stone we would like in the water. Laurence Duane Merrill wrote:
Forgive me for pushing my logic to the extreme; I do realize that ARC/gLite/Naregi are similar enough that they could be congealed to constitute a "grid island" with some degree of effort.
My point is that the working group is still faced with a crisis of identity: it is not about "production grid interoperability", but rather about "A-type interoperability", "B-type interoperability", "C-type interoperability" where {A, B, C, etc.} is the set of credentialing schemes that, depending on the effort we are willing to invest, may number as many as there are different middleware implementations (no effort), or as few as one integrated scheme.
The operative phrase being "the amount of effort we are willing to invest". Perhaps we should survey /that/.
-Duane
Duane Merrill wrote:
Forgive me for pushing my logic to the extreme; I do realize that ARC/gLite/Naregi are similar enough that they could be congealed to constitute a "grid island" with some degree of effort. [...] The operative phrase being "the amount of effort we are willing to invest". Perhaps we should survey *that*.
This "all-or-nothing" attitude was precisely what I was trying to avoid when I (and others like me) initially thought about having a small set of different security profiles. There are simply things which we (and others) can't change overnight, as we work on middlewares whose development is constrained in different ways. There's not much that we can do to change these constraints in the sort term. Sure, we could develope a new (e.g.) CREAM-BES service which is completely unrelated with the legacy CREAM, so that we can get rid of every legacy component and implement whatever security mechanism we agree on. Whether we have the resources to do that is a question I'm not entitled to answer, but my guess is that we don't (again, things may change in the future). So, achieving full interoperability between ARC/glite/naregi would be a success for me. Knowing that, by only getting rid of VOMS proxies and using SAML assertions we could get full interoperability with UNICORE and other similar middlewares is equally a success. Having to build adapters to translate (if possible) credentials in different formats is a compromise which is more reasonable than having to wait for all the middlewares of the world to move towards a common security infrastructure. Maybe this will happen, but I don't know whether I will stil be around by then. Moreno. -- Moreno Marzolla INFN Sezione di Padova, via Marzolo 8, 35131 PADOVA, Italy EMail: moreno.marzolla@pd.infn.it Phone: +39 049 8277103 WWW : http://www.dsi.unive.it/~marzolla Fax : +39 049 8756233
So, achieving full interoperability between ARC/glite/naregi would be a success for me.
Now *that* is a good mission-statement / identity for a Working Group. It's clear, concise, and demonstrates exactly the amount of effort that is willing to be invested. -Duane
To All, I agree with Moreno MARZOLLA : Achieving full interoperability between ARC/glite/naregi would be a success. Taking into account information of Vincenzo CIASCHINI and some comments of Duane MERRIL, I have updated my 'PGI Security Model' below and at http://forge.gridforum.org/sf/go/doc15584?nav=1 OGF PGI - Security Model ======================== Current Established Base ======================== Chapters 1, 2 and 3 below describe the current security model of Computing Grid Infrastructures. 1) Grid Users and Certificate Authorities ----------------------------------------- 1.1) Each grid User is authenticated by a legal body (recognized by a government). 1.2) This legal body uses a Certificate Authority to grant a (long lived) X509 certificate to the grid User. 1.3) Each Certificate Authority is itself or is authenticated by a self-signed Root Certificate Authority. 1.4) All such Root Certificate Authorities trust each other and cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management Authorities). 1.5) These 3 Policy Management Authorities trust each other and cooperate within IGTF. 1.6) IGTF distributes the list of CA Certificates to be trusted. 1.7) Each grid Site providing grid Services to grid Users installs the CA Certificates it deems necessary. In general, there is no requirement to keep them up-to-date, but typically it is considered a security update and as such is strongly recommended to apply. Some infrastructures issue warnings for sites with outdated CA certs, but normally it does not impede operations. 1.8) Using its X509 certificate, each grid User can create at any time a (usually short lived) X509 proxy with permits impersonation / delegation during a (usually short) period. 2) Virtual Organizations ------------------------- 2.1) A Virtual Organization (VO) groups grid Users (usually with common goals). A Virtual Organization may be a legal body, and may be a Certificate Authority which can issue X509 certificates, but most are NOT. 2.2) Inside DEISA, a Virtual Community also groups grid Users with common goals. The relationships between Virtual Communities and Virtual Organizations have to be explained by Morris RIEDEL. 2.3) Each grid User belongs to 1 or more VO (Virtual Organization), which grants him access rights to grid Storage and Computing Resources. 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) 2.4.2) SAML assertions 3) Grid Services : Information, AUTHN, AUTHZ ---------------------------------------------- 3.1) Some grid Infrastructures provide an Information Service with describes the Infrastructure, for example according to the 'GLUE 1.3' schema. 3.2) If this Information Service exists, then each grid User can query it in order to discover the list, requirements and capabilities of grid Services. 3.3) Each grid User can directly access data hosted by grid Storage Services. For Authentication, the grid User can present the public part of his X509 certificate or X509 proxy. For Authorization, the grid User has to present either (depending on the Infrastructure) : 3.3.1) the public part of his VOMS proxy, or 3.3.2) a bag of SAML assertions. If the grid User accesses data through a interface requiring delegation, then the next subchapter applies. 3.4) Each grid User can submit Jobs to grid Computing Services. If such a Job needs access to data hosted by grid Storage Services, then the grid User must provide a delegation token. This delegation token is either (depending on the Infrastructure) : 3.4.1) a full VOMS proxy, or 3.4.2) a bag of SAML assertions. Morris RIEDEL has to explain if and how delegation of SAML assertions work. 3.5) Each grid Site providing grid Services to grid Users has installed Authorization Files (such as 'gridmap' files) describing VOMS authorizations, other authorizations, and mapping of known VO members to local UIDs. Grid Sites try to keep those Authorization Files up to date. There is a trend to replace these static 'gridmap' files by a robust Authorization Service (SCAS by EGEE, GUMS by OSG). Where we propose to go ====================== Chapters 4, 5, 6 and 7 below describe a security model for short term Interoperability between Computing Grid Infrastructures. 4) Operational Robustness of Security -------------------------------------- 4.1) The number of Certificate Authorities for grid Infrastructures SHOULD be kept as low as possible. 5) Interoperability between X509 certificates and X509 proxies for Authentication ---------------------------------------------------------------------------------- 5.1) For this short term Security Profile aimed at short term Interoperability, we accept Shibboleth as an option, but knowingly exclude Shibboleth from any requirement. 5.2) X509 proxies MUST fully comply to RFC 3820. 5.3) VOMS services, which deliver X509 proxies with VOMS extensions, MUST fully comply to RFC 3820. 5.4) The authentication library used by grid Services MUST fully comply to RFC 3820 (for example a recent version of OpenSLL), so that it can accept as well X509 certificates as X509 proxies. 6) Information Service describing the Infrastructure according the the GLUE2 schema ------------------------------------------------------------------------------------ 6.1) Each grid Infrastructure MUST provide an Information Service, which describes the Infrastructure according the the GLUE2 schema. 6.2) If access to the Information Service is restricted, the grid Infrastructure MUST provide a Bootstrap Information Service, with describes the security requirements for access to the full Information Service according the the GLUE2 schema. 7) Interoperable Grid Services : Information, AUTHN, AUTHZ ------------------------------------------------------------ 7.1) The semantics of Authorization tokens MUST be the same for all grid Infrastructures. Examples of Authorization tokens are : 7.1.1) VOMS-style Attribute Certificates 7.1.2) Restriction attributes 7.1.3) Shibboleth 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) : 7.2.1) X509 VOMS-style Attribute Certificates They are defined in 'VOMS Attribute Certificate Format' at http://forge.gridforum.org/sf/go/doc13797?nav=1 7.2.2) X509 restriction attributes 7.2.3) SAML assertions 7.3) The Information Service of each grid Infrastructure MUST describe, for each grid Service accepting SAML assertions, the transport method that the grid Service expects (potentially several) : 7.3.1) As attributes of X509 proxies 7.3.2) Inside a SOAP header 7.4) Each grid Site providing grid Services to grid Users MUST install and keep up to date a robust Authorization Service enforcing VOMS authorizations, other authorizations, and mapping of grid credentials to local credentials. 7.5) Each grid Service MUST accept at least : 7.5.1) One of the Authorization Tokens described at chapter 7.2 7.5.2) One of the transport methods described at chapter 7.3 (only if the grid Service accepts SAML assertions) 7.6) As long as it satisfies subchapter 7.5, each grid Service MAY also accept Authentication and Authorization methods based on Shibboleth. 7.7) In order to ease the development and deployment of grid Clients, each grid Service SHOULD accept ALL types of Authorization Tokens described at chapter 7.2 If it accepts SAML assertions, it SHOULD accept that they are transported inside SOAP headers. 7.8) In order to keep middleware complexity and bandwidth usage as low as possible, grid Services should NOT send their full description of their security interface inside each message, but only when specifically requested (for example by the Information Service). 7.9) There should be a brief consensus on SOAP-over-HTTPS communication that mandates a specific variant of SSL/TLS (i.e., anything that implements RFC-2246, The TLS Protocol Version 1.0, which excludes GSI-OpenSSH.) TO BE DONE. To be thoroughly criticized ... 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@lal.in2p3.fr ---------------------------------- On Thu, 26 Mar 2009, Duane Merrill wrote:
So, achieving full interoperability between ARC/glite/naregi would be a success for me.
Now /that/ is a good mission-statement / identity for a Working Group. It's clear, concise, and demonstrates exactly the amount of effort that is willing to be invested. -Duane
On Thursday 26 March 2009 20:00, Etienne URBAH wrote:
To All,
I agree with Moreno MARZOLLA : Achieving full interoperability between ARC/glite/naregi would be a success.
I understand situation described by Moreno. But I would like to assure that ARC is dedicated to have all islands on its map. At least sane amount of them. This is actaully what we are currently doing. So having those islands bigger and (most important) well defined would be satisfactory outcome from this group. A.K.
To All, In order to handle X509 proxies, we regrettably have to take into account both the OpenSSL and GSI implementations of TLS, which are incompatible. So I have updated my 'PGI Security Model' below and at http://forge.gridforum.org/sf/go/doc15584?nav=1 OGF PGI - Security Model ======================== Current Established Base ======================== Chapters 1, 2 and 3 below describe the current security model of Computing Grid Infrastructures. 1) Grid Users and Certificate Authorities ----------------------------------------- 1.1) Each grid User is authenticated by a legal body (recognized by a government). 1.2) This legal body uses a Certificate Authority to grant a (long lived) X509 certificate to the grid User. 1.3) Each Certificate Authority is itself or is authenticated by a self-signed Root Certificate Authority. 1.4) All such Root Certificate Authorities trust each other and cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management Authorities). 1.5) These 3 Policy Management Authorities trust each other and cooperate within IGTF. 1.6) IGTF distributes the list of CA Certificates to be trusted. 1.7) Each grid Site providing grid Services to grid Users installs the CA Certificates it deems necessary. In general, there is no requirement to keep them up-to-date, but typically it is considered a security update and as such is strongly recommended to apply. Some infrastructures issue warnings for sites with outdated CA certs, but normally it does not impede operations. 1.8) Using its X509 certificate, each grid User can create at any time a (usually short lived) X509 proxy with permits impersonation / delegation during a (usually short) period. 2) Virtual Organizations ------------------------- 2.1) A Virtual Organization (VO) groups grid Users (usually with common goals). A Virtual Organization may be a legal body, and may be a Certificate Authority which can issue X509 certificates, but most are NOT. 2.2) Inside DEISA, a Virtual Community also groups grid Users with common goals. {{{The relationships between Virtual Communities and Virtual Organizations have to be explained by Morris RIEDEL}}} 2.3) Each grid User belongs to 1 or more VO (Virtual Organization), which grants him access rights to grid Storage and Computing Resources. 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) 2.4.2) SAML assertions 3) Grid Services : Information, AUTHN, AUTHZ ---------------------------------------------- 3.1) Some grid Infrastructures provide an Information Service with describes the Infrastructure, for example according to the 'GLUE 1.3' schema. 3.2) If this Information Service exists, then each grid User can query it in order to discover the list, requirements and capabilities of grid Services. 3.3) Each grid User can directly access data hosted by grid Storage Services. For Authentication, the grid User can present the public part of his X509 certificate or X509 proxy. For Authorization, the grid User has to present either (depending on the Infrastructure) : 3.3.1) the public part of his X509 certificate, or 3.3.2) the public part of his X509 proxy (without VOMS extensions), or 3.3.3) the public part of his VOMS proxy, or 3.3.4) a bag of SAML assertions. In order to handle X509 proxies, both the OpenSSL and GSI implementations of TLS are widely used, but they are INCOMPATIBLE. If the grid User accesses data through a interface requiring delegation, then the next subchapter applies. 3.4) Each grid User can submit Jobs to grid Computing Services. If such a Job needs access to data hosted by grid Storage Services, then the grid User must provide a delegation token. This delegation token is either (depending on the Infrastructure) : 3.4.1) an X509 proxy, or 3.4.2) a VOMS proxy, or 3.4.3) a bag of SAML assertions. {{{Morris RIEDEL has to explain if and how delegation of SAML assertions work}}} 3.5) Each grid Site providing grid Services to grid Users has installed Authorization Files (such as 'gridmap' files) describing VOMS authorizations, other authorizations, and mapping of grid credentials to local credentials. Grid Sites try to keep those Authorization Files up to date. There is a trend to replace these static 'gridmap' files by a robust Authorization Service (SCAS by EGEE, GUMS by OSG). Where we propose to go ====================== Chapters 4, 5, 6 and 7 below describe a security model for short term Interoperability between Computing Grid Infrastructures. 4) Operational Robustness of Security -------------------------------------- 4.1) The number of Certificate Authorities for grid Infrastructures SHOULD be kept as low as possible. 5) Interoperability between X509 certificates and X509 proxies for Authentication ---------------------------------------------------------------------------------- 5.1) For this short term Security Profile aimed at short term Interoperability, we accept Shibboleth as an option, but knowingly exclude Shibboleth from any requirement. 5.2) X509 proxies MUST fully comply either to RFC 3820 or to GSI. 5.3) VOMS services, which deliver X509 proxies with VOMS extensions, MUST fully comply either to RFC 3820 or to GSI. 5.4) The authentication library used by grid Services MUST fully comply either to RFC 3820 or to GSI. 6) Information Service describing the Infrastructure according the the GLUE2 schema ------------------------------------------------------------------------------------ 6.1) Each grid Infrastructure MUST provide an Information Service, which describes the Infrastructure according the the GLUE2 schema. 6.2) If access to the Information Service is restricted, the grid Infrastructure MUST provide a Bootstrap Information Service, with describes the security requirements for access to the full Information Service according the the GLUE2 schema. 7) Interoperable Grid Services : Information, AUTHN, AUTHZ ------------------------------------------------------------ 7.1) The semantics of Authorization tokens MUST be the same for all grid Infrastructures. Examples of Authorization tokens are : 7.1.1) DN of the X509 certificate or proxy 7.1.2) VOMS-style Attribute Certificates 7.1.3) Restriction attributes 7.1.4) Shibboleth 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). 7.3) The Information Service of each grid Infrastructure MUST describe the transport method that the grid Service expects (potentially several). In order to handle X509 proxies, we regrettably have to take into account both the OpenSSL and GSI implementations of TLS, which are incompatible. 7.4) Each grid Site providing grid Services to grid Users MUST install and keep up to date a robust Authorization Service enforcing VOMS authorizations, other authorizations, and mapping of grid credentials to local credentials. 7.5) Each grid Service MUST accept at least : 7.5.1) One of the following Authorization Tokens : - DN of the X509 certificate or proxy - X509 VOMS-style Attribute Certificates (VOMS extensions) They are defined in 'VOMS Attribute Certificate Format' at http://forge.gridforum.org/sf/go/doc13797?nav=1 - X509 restriction attributes {{{Please give the reference of a description document}}} - SAML assertions {{{Please give the reference of a description document}}} 7.5.2) One of the following transport methods : - OpenSSL (compliant to RFC 3820) for attributes of X509 proxies - GSI for attributes of X509 proxies - SOAP header for SAML assertions 7.6) As long as it satisfies subchapter 7.5, each grid Service MAY also accept Authentication and Authorization methods based on Shibboleth. 7.7) In order to ease the development and deployment of grid Clients, each grid Service SHOULD accept following types of Authorization Tokens : 7.7.1) X509 VOMS-style Attribute Certificates (VOMS extensions) 7.7.2) X509 restriction attributes. In the 2 previous cases, the grid Service SHOULD accept that they are transported through OpenSSL (compliant to RFC 3820). Transport through GSI is explicitly DEPRECATED. 7.7.3) SAML assertions. In that case, the grid Service SHOULD accept that they are transported inside SOAP headers. 7.8) In order to keep middleware complexity and bandwidth usage as low as possible, grid Services should NOT send their full description of their security interface inside each message, but only when specifically requested (for example by the Information Service). To be thoroughly criticized ... 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@lal.in2p3.fr ----------------------------------
To All, About X509 proxies, I just got confirmation from Vincenzo CIASCHINI that : 1) OpenSSL and GSI are really incompatible as transport layers. 2) But they now accept exactly the same X509 proxies compliant to RFC 3820. 3) Old-style GSI X509 proxies are obsolete, and their usage should be forbidden So I have updated my 'PGI Security Model' below and at http://forge.gridforum.org/sf/go/doc15584?nav=1 OGF PGI - Security Model ======================== Current Established Base ======================== Chapters 1, 2 and 3 below describe the current security model of Computing Grid Infrastructures. 1) Grid Users and Certificate Authorities ----------------------------------------- 1.1) Each grid User is authenticated by a legal body (recognized by a government). 1.2) This legal body uses a Certificate Authority to grant a (long lived) X509 certificate to the grid User. 1.3) Each Certificate Authority is itself or is authenticated by a self-signed Root Certificate Authority. 1.4) All such Root Certificate Authorities trust each other and cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management Authorities). 1.5) These 3 Policy Management Authorities trust each other and cooperate within IGTF. 1.6) IGTF distributes the list of CA Certificates to be trusted. 1.7) Each grid Site providing grid Services to grid Users installs the CA Certificates it deems necessary. In general, there is no requirement to keep them up-to-date, but typically it is considered a security update and as such is strongly recommended to apply. Some infrastructures issue warnings for sites with outdated CA certs, but normally it does not impede operations. 1.8) Using its X509 certificate, each grid User can create at any time a (usually short lived) X509 proxy with permits impersonation / delegation during a (usually short) period. 2) Virtual Organizations ------------------------- 2.1) A Virtual Organization (VO) groups grid Users (usually with common goals). A Virtual Organization may be a legal body, and may be a Certificate Authority which can issue X509 certificates, but most are NOT. 2.2) Inside DEISA, a Virtual Community also groups grid Users with common goals. {{{The relationships between Virtual Communities and Virtual Organizations have to be explained by Morris RIEDEL}}} 2.3) Each grid User belongs to 1 or more VO (Virtual Organization), which grants him access rights to grid Storage and Computing Resources. 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) 2.4.2) SAML assertions 3) Grid Services : Information, AUTHN, AUTHZ ---------------------------------------------- 3.1) Some grid Infrastructures provide an Information Service with describes the Infrastructure, for example according to the 'GLUE 1.3' schema. 3.2) If this Information Service exists, then each grid User can query it in order to discover the list, requirements and capabilities of grid Services. 3.3) Each grid User can directly access data hosted by grid Storage Services. For Authentication, the grid User can present the public part of his X509 certificate or X509 proxy. For Authorization, the grid User has to present either (depending on the Infrastructure) : 3.3.1) the public part of his X509 certificate, or 3.3.2) the public part of his X509 proxy (without VOMS extensions), or 3.3.3) the public part of his VOMS proxy, or 3.3.4) a bag of SAML assertions. In order to handle X509 proxies, both the OpenSSL and GSI implementations of TLS are widely used and accept exactly the same X509 proxies compliant to RFC 3820, but they are INCOMPATIBLE as transport layers. If the grid User accesses data through a interface requiring delegation, then the next subchapter applies. 3.4) Each grid User can submit Jobs to grid Computing Services. If such a Job needs access to data hosted by grid Storage Services, then the grid User must provide a delegation token. This delegation token is either (depending on the Infrastructure) : 3.4.1) an X509 proxy, or 3.4.2) a VOMS proxy, or 3.4.3) a bag of SAML assertions. {{{Morris RIEDEL has to explain if and how delegation of SAML assertions work}}} 3.5) Each grid Site providing grid Services to grid Users has installed Authorization Files (such as 'gridmap' files) describing VOMS authorizations, other authorizations, and mapping of grid credentials to local credentials. Grid Sites try to keep those Authorization Files up to date. There is a trend to replace these static 'gridmap' files by a robust Authorization Service (SCAS by EGEE, GUMS by OSG). Where we propose to go ====================== Chapters 4, 5, 6 and 7 below describe a security model for short term Interoperability between Computing Grid Infrastructures. 4) Operational Robustness of Security -------------------------------------- 4.1) The number of Certificate Authorities for grid Infrastructures SHOULD be kept as low as possible. 5) Interoperability between X509 certificates and X509 proxies for Authentication ---------------------------------------------------------------------------------- 5.1) For this short term Security Profile aimed at short term Interoperability, we accept Shibboleth as an option, but knowingly exclude Shibboleth from any requirement. 5.2) X509 proxies MUST fully comply to RFC 3820. 5.3) VOMS services, which deliver X509 proxies with VOMS extensions, MUST fully comply to RFC 3820. 5.4) The authentication library used by grid Services MUST fully comply either to RFC 3820 or to GSI. 6) Information Service describing the Infrastructure according the the GLUE2 schema ------------------------------------------------------------------------------------ 6.1) Each grid Infrastructure MUST provide an Information Service, which describes the Infrastructure according the the GLUE2 schema. 6.2) If access to the Information Service is restricted, the grid Infrastructure MUST provide a Bootstrap Information Service, with describes the security requirements for access to the full Information Service according the the GLUE2 schema. 7) Interoperable Grid Services : Information, AUTHN, AUTHZ ------------------------------------------------------------ 7.1) The semantics of Authorization tokens MUST be the same for all grid Infrastructures. Examples of Authorization tokens are : 7.1.1) DN of the X509 certificate or proxy 7.1.2) VOMS-style Attribute Certificates 7.1.3) Restriction attributes 7.1.4) Shibboleth 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). 7.3) The Information Service of each grid Infrastructure MUST describe the transport method that the grid Service expects (potentially several). In order to handle X509 proxies, we regrettably have to take into account both the OpenSSL and GSI implementations of TLS, which are incompatible. 7.4) Each grid Site providing grid Services to grid Users MUST install and keep up to date a robust Authorization Service enforcing VOMS authorizations, other authorizations, and mapping of grid credentials to local credentials. 7.5) Each grid Service MUST accept at least : 7.5.1) One of the following Authorization Tokens : - DN of the X509 certificate or proxy - X509 VOMS-style Attribute Certificates (VOMS extensions) They are defined in 'VOMS Attribute Certificate Format' at http://forge.gridforum.org/sf/go/doc13797?nav=1 - X509 restriction attributes {{{Please give the reference of a description document}}} - SAML assertions {{{Please give the reference of a description document}}} 7.5.2) One of the following transport methods : - OpenSSL (compliant to RFC 3820) for attributes of X509 proxies - GSI for attributes of X509 proxies - SOAP header for SAML assertions 7.6) As long as it satisfies subchapter 7.5, each grid Service MAY also accept Authentication and Authorization methods based on Shibboleth. 7.7) In order to ease the development and deployment of grid Clients, each grid Service SHOULD accept following types of Authorization Tokens : 7.7.1) X509 VOMS-style Attribute Certificates (VOMS extensions) 7.7.2) X509 restriction attributes. In the 2 previous cases, the grid Service SHOULD accept that they are transported through OpenSSL (compliant to RFC 3820). Transport through GSI is explicitly DEPRECATED. 7.7.3) SAML assertions. In that case, the grid Service SHOULD accept that they are transported inside SOAP headers. 7.8) In order to keep middleware complexity and bandwidth usage as low as possible, grid Services should NOT send their full description of their security interface inside each message, but only when specifically requested (for example by the Information Service). To be thoroughly criticized ... 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@lal.in2p3.fr ---------------------------------- On Fri, 27 Mar 2009m Etienne URBAH wrote:
To All,
In order to handle X509 proxies, we regrettably have to take into account both the OpenSSL and GSI implementations of TLS, which are incompatible.
So I have updated my 'PGI Security Model' below and at http://forge.gridforum.org/sf/go/doc15584?nav=1
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@lal.in2p3.fr ----------------------------------
Just one clarification: Due to compatibility issues with previous versions of glite, voms-proxy-init by default creates GT2 proxies. to make it create X509 proxies, the --rfc option is needed. Ciao, Vincenzo Etienne URBAH wrote:
To All,
About X509 proxies, I just got confirmation from Vincenzo CIASCHINI that :
1) OpenSSL and GSI are really incompatible as transport layers.
2) But they now accept exactly the same X509 proxies compliant to RFC 3820.
3) Old-style GSI X509 proxies are obsolete, and their usage should be forbidden
So I have updated my 'PGI Security Model' below and at http://forge.gridforum.org/sf/go/doc15584?nav=1
OGF PGI - Security Model ========================
Current Established Base ======================== Chapters 1, 2 and 3 below describe the current security model of Computing Grid Infrastructures.
1) Grid Users and Certificate Authorities ----------------------------------------- 1.1) Each grid User is authenticated by a legal body (recognized by a government).
1.2) This legal body uses a Certificate Authority to grant a (long lived) X509 certificate to the grid User.
1.3) Each Certificate Authority is itself or is authenticated by a self-signed Root Certificate Authority.
1.4) All such Root Certificate Authorities trust each other and cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management Authorities).
1.5) These 3 Policy Management Authorities trust each other and cooperate within IGTF.
1.6) IGTF distributes the list of CA Certificates to be trusted.
1.7) Each grid Site providing grid Services to grid Users installs the CA Certificates it deems necessary. In general, there is no requirement to keep them up-to-date, but typically it is considered a security update and as such is strongly recommended to apply. Some infrastructures issue warnings for sites with outdated CA certs, but normally it does not impede operations.
1.8) Using its X509 certificate, each grid User can create at any time a (usually short lived) X509 proxy with permits impersonation / delegation during a (usually short) period.
2) Virtual Organizations ------------------------- 2.1) A Virtual Organization (VO) groups grid Users (usually with common goals). A Virtual Organization may be a legal body, and may be a Certificate Authority which can issue X509 certificates, but most are NOT.
2.2) Inside DEISA, a Virtual Community also groups grid Users with common goals. {{{The relationships between Virtual Communities and Virtual Organizations have to be explained by Morris RIEDEL}}}
2.3) Each grid User belongs to 1 or more VO (Virtual Organization), which grants him access rights to grid Storage and Computing Resources.
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) 2.4.2) SAML assertions
3) Grid Services : Information, AUTHN, AUTHZ ---------------------------------------------- 3.1) Some grid Infrastructures provide an Information Service with describes the Infrastructure, for example according to the 'GLUE 1.3' schema.
3.2) If this Information Service exists, then each grid User can query it in order to discover the list, requirements and capabilities of grid Services.
3.3) Each grid User can directly access data hosted by grid Storage Services. For Authentication, the grid User can present the public part of his X509 certificate or X509 proxy. For Authorization, the grid User has to present either (depending on the Infrastructure) : 3.3.1) the public part of his X509 certificate, or 3.3.2) the public part of his X509 proxy (without VOMS extensions), or 3.3.3) the public part of his VOMS proxy, or 3.3.4) a bag of SAML assertions. In order to handle X509 proxies, both the OpenSSL and GSI implementations of TLS are widely used and accept exactly the same X509 proxies compliant to RFC 3820, but they are INCOMPATIBLE as transport layers. If the grid User accesses data through a interface requiring delegation, then the next subchapter applies.
3.4) Each grid User can submit Jobs to grid Computing Services. If such a Job needs access to data hosted by grid Storage Services, then the grid User must provide a delegation token. This delegation token is either (depending on the Infrastructure) : 3.4.1) an X509 proxy, or 3.4.2) a VOMS proxy, or 3.4.3) a bag of SAML assertions. {{{Morris RIEDEL has to explain if and how delegation of SAML assertions work}}}
3.5) Each grid Site providing grid Services to grid Users has installed Authorization Files (such as 'gridmap' files) describing VOMS authorizations, other authorizations, and mapping of grid credentials to local credentials. Grid Sites try to keep those Authorization Files up to date. There is a trend to replace these static 'gridmap' files by a robust Authorization Service (SCAS by EGEE, GUMS by OSG).
Where we propose to go ====================== Chapters 4, 5, 6 and 7 below describe a security model for short term Interoperability between Computing Grid Infrastructures.
4) Operational Robustness of Security -------------------------------------- 4.1) The number of Certificate Authorities for grid Infrastructures SHOULD be kept as low as possible.
5) Interoperability between X509 certificates and X509 proxies for Authentication ----------------------------------------------------------------------------------
5.1) For this short term Security Profile aimed at short term Interoperability, we accept Shibboleth as an option, but knowingly exclude Shibboleth from any requirement.
5.2) X509 proxies MUST fully comply to RFC 3820.
5.3) VOMS services, which deliver X509 proxies with VOMS extensions, MUST fully comply to RFC 3820.
5.4) The authentication library used by grid Services MUST fully comply either to RFC 3820 or to GSI.
6) Information Service describing the Infrastructure according the the GLUE2 schema ------------------------------------------------------------------------------------
6.1) Each grid Infrastructure MUST provide an Information Service, which describes the Infrastructure according the the GLUE2 schema.
6.2) If access to the Information Service is restricted, the grid Infrastructure MUST provide a Bootstrap Information Service, with describes the security requirements for access to the full Information Service according the the GLUE2 schema.
7) Interoperable Grid Services : Information, AUTHN, AUTHZ ------------------------------------------------------------ 7.1) The semantics of Authorization tokens MUST be the same for all grid Infrastructures. Examples of Authorization tokens are : 7.1.1) DN of the X509 certificate or proxy 7.1.2) VOMS-style Attribute Certificates 7.1.3) Restriction attributes 7.1.4) Shibboleth
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).
7.3) The Information Service of each grid Infrastructure MUST describe the transport method that the grid Service expects (potentially several). In order to handle X509 proxies, we regrettably have to take into account both the OpenSSL and GSI implementations of TLS, which are incompatible.
7.4) Each grid Site providing grid Services to grid Users MUST install and keep up to date a robust Authorization Service enforcing VOMS authorizations, other authorizations, and mapping of grid credentials to local credentials.
7.5) Each grid Service MUST accept at least : 7.5.1) One of the following Authorization Tokens : - DN of the X509 certificate or proxy - X509 VOMS-style Attribute Certificates (VOMS extensions) They are defined in 'VOMS Attribute Certificate Format' at http://forge.gridforum.org/sf/go/doc13797?nav=1 - X509 restriction attributes {{{Please give the reference of a description document}}} - SAML assertions {{{Please give the reference of a description document}}} 7.5.2) One of the following transport methods : - OpenSSL (compliant to RFC 3820) for attributes of X509 proxies - GSI for attributes of X509 proxies - SOAP header for SAML assertions
7.6) As long as it satisfies subchapter 7.5, each grid Service MAY also accept Authentication and Authorization methods based on Shibboleth.
7.7) In order to ease the development and deployment of grid Clients, each grid Service SHOULD accept following types of Authorization Tokens : 7.7.1) X509 VOMS-style Attribute Certificates (VOMS extensions) 7.7.2) X509 restriction attributes. In the 2 previous cases, the grid Service SHOULD accept that they are transported through OpenSSL (compliant to RFC 3820). Transport through GSI is explicitly DEPRECATED. 7.7.3) SAML assertions. In that case, the grid Service SHOULD accept that they are transported inside SOAP headers.
7.8) In order to keep middleware complexity and bandwidth usage as low as possible, grid Services should NOT send their full description of their security interface inside each message, but only when specifically requested (for example by the Information Service).
To be thoroughly criticized ...
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@lal.in2p3.fr ----------------------------------
On Fri, 27 Mar 2009m Etienne URBAH wrote:
To All,
In order to handle X509 proxies, we regrettably have to take into account both the OpenSSL and GSI implementations of TLS, which are incompatible.
So I have updated my 'PGI Security Model' below and at http://forge.gridforum.org/sf/go/doc15584?nav=1
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@lal.in2p3.fr ----------------------------------
------------------------------------------------------------------------
_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
Vincenzo and All, My preceding mail about X509 proxies contained a FALSE assertion. In fact : - OpenSSL accepts only RFC-3820-compliant X509 proxies, - GSI accepts only GSI-style X509 proxies. Following assertions still have to be verified : - VOMS servers only accept GSI-style X509 proxies See http://forge.gridforum.org/sf/go/doc15591?nav=1 - Delegation of X509 proxies can be performed only by GSI. So I have updated my 'PGI Security Model' below and at http://forge.gridforum.org/sf/go/doc15584?nav=1 OGF PGI - Security Model ======================== Current Established Base ======================== Chapters 1, 2 and 3 below describe the current security model of Computing Grid Infrastructures. 1) Grid Users and Certificate Authorities ----------------------------------------- 1.1) Each grid User is authenticated by a legal body (recognized by a government). 1.2) This legal body uses a Certificate Authority to grant a (long lived) X509 certificate to the grid User. 1.3) Each Certificate Authority is itself or is authenticated by a self-signed Root Certificate Authority. 1.4) All such Root Certificate Authorities trust each other and cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management Authorities). 1.5) These 3 Policy Management Authorities trust each other and cooperate within IGTF. 1.6) IGTF distributes the list of CA Certificates to be trusted. 1.7) Each grid Site providing grid Services to grid Users installs the CA Certificates it deems necessary. In general, there is no requirement to keep them up-to-date, but typically it is considered a security update and as such is strongly recommended to apply. Some infrastructures issue warnings for sites with outdated CA certs, but normally it does not impede operations. 1.8) Using its X509 certificate, each grid User can create at any time a (usually short lived) X509 proxy with permits impersonation / delegation during a (usually short) period. 1.9) Regrettably, there are 2 widely used INCOMPATIBLE types of X509 proxies : 1.9.1) RFC-3820-compliant X509 proxies can only be used by RFC-3820-compliant software, such as OpenSSL, 1.9.2) GSI-style X509 proxies can only be used with the GSI middleware, which permits further delegation. 2) Virtual Organizations ------------------------- 2.1) A Virtual Organization (VO) groups grid Users (usually with common goals). A Virtual Organization may be a legal body, and may be a Certificate Authority which can issue X509 certificates, but most are NOT. Each Virtual Organization can independently define Groups and Roles. 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. 2.3) Each grid User belongs to 1 or more VO (Virtual Organization), which grants him access rights to grid Storage and Computing Resources. 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) VOMS servers only accept GSI-style X509 proxies {{{TO BE VERIFIED}}} 2.4.2) SAML assertions 3) Grid Services : Information, AUTHN, AUTHZ ---------------------------------------------- 3.1) Some grid Infrastructures provide an Information Service with describes the Infrastructure, for example according to the 'GLUE 1.3' schema. 3.2) If this Information Service exists, then each grid User can query it in order to discover the list, requirements and capabilities of grid Services. 3.3) Each grid User can directly access data hosted by grid Storage Services. For Authentication, the grid User can present the public part of his X509 certificate or X509 proxy. For Authorization, the grid User has to present either (depending on the Infrastructure) : 3.3.1) the public part of his X509 certificate, or 3.3.2) the public part of his RFC-3820-compliant X509 proxy (without VOMS extensions), or 3.3.3) the public part of his GSI-Style X509 proxy (without VOMS extensions), or 3.3.4) the public part of his VOMS proxy, or 3.3.5) a bag of SAML assertions. In order to handle X509 proxies : - The OpenSSL implementation of TLS accepts only RFC-3820-compliant X509 proxies, - The GSI implementation of TLS accepts only GSI-style X509 proxies. So these 2 implementations of TLS are totally INCOMPATIBLE. If the grid User accesses data through a interface requiring delegation, then the next subchapter applies. 3.4) Each grid User can submit Jobs to grid Computing Services. If such a Job needs access to data hosted by grid Storage Services, then the grid User must provide a delegation token. This delegation token is either (depending on the Infrastructure) : 3.4.1) an X509 proxy, or 3.4.2) a VOMS proxy, or 3.4.3) a bag of SAML assertions. 3.5) Each grid Site providing grid Services to grid Users has installed Authorization Files (such as 'gridmap' files) describing VOMS authorizations, other authorizations, and mapping of grid credentials to local credentials. Grid Sites try to keep those Authorization Files up to date. There is a trend to replace these static 'gridmap' files by a robust Authorization Service (SCAS by EGEE, GUMS by OSG). Where we propose to go ====================== Chapters 4, 5, 6 and 7 below describe a security model for short term Interoperability between Computing Grid Infrastructures. 4) Operational Robustness of Security -------------------------------------- 4.1) The number of Certificate Authorities for grid Infrastructures SHOULD be kept as low as possible. 5) Interoperability between X509 certificates and X509 proxies for Authentication ---------------------------------------------------------------------------------- 5.1) For this short term Security Profile aimed at short term Interoperability, we accept Shibboleth as an option, but knowingly exclude Shibboleth from any requirement. 5.2) X509 proxies MUST fully comply either to RFC 3820 or to GSI. 5.3) VOMS services, which deliver X509 proxies with VOMS extensions, MUST fully comply to RFC 3820 or GSI, and MAY accept both. 5.4) The authentication library used by grid Services MUST fully comply to RFC 3820 or GSI, and MAY accept both. 6) Information Service describing the Infrastructure according the the GLUE2 schema ------------------------------------------------------------------------------------ 6.1) Each grid Infrastructure MUST provide an Information Service, which describes the Infrastructure according the the GLUE2 schema. 6.2) If access to the Information Service is restricted, the grid Infrastructure MUST provide a Bootstrap Information Service, with describes the security requirements for access to the full Information Service according the the GLUE2 schema. 7) Interoperable Grid Services : Information, AUTHN, AUTHZ ------------------------------------------------------------ 7.1) The semantics of Authorization tokens MUST be the same for all grid Infrastructures. Examples of Authorization tokens are : 7.1.1) DN of the X509 certificate or proxy 7.1.2) VOMS-style Attribute Certificates 7.1.3) Restriction attributes 7.1.4) Shibboleth 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). GSI-style X509 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 GSI-style X509 proxies. 7.3) The Information Service of each grid Infrastructure MUST describe the transport method that the grid Service expects (potentially several). The GSI implementation of TLS is DEPRECATED in favor of RFC-3820-compliant TLS, such as OpenSSL. Each provider of grid middleware MUST establish and publish the list of the components which still require the GSI implementation of TLS. 7.4) Each grid Site providing grid Services to grid Users MUST install and keep up to date a robust Authorization Service enforcing VOMS authorizations, other authorizations, and mapping of grid credentials to local credentials. 7.5) Each grid Service MUST accept at least : 7.5.1) One of the following Authorization Tokens : - DN of the X509 certificate or RFC-3820-compliant X509 proxy - DN of the GSI-syle X509 proxy - X509 VOMS-style Attribute Certificates (VOMS extensions) They are defined in 'VOMS Attribute Certificate Format' at http://forge.gridforum.org/sf/go/doc13797?nav=1 - X509 restriction attributes {{{Please give the reference of a description document}}} - SAML assertions (Attention: there are differences between SAML V1.1 and SAML V2.0) http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAM... 7.5.2) One of the following transport methods : - OpenSSL for X509 certificates and RFC-3820-compliant X509 proxies - GSI for GSI-style X509 proxies - SOAP header for SAML assertions 7.6) As long as it satisfies subchapter 7.5, each grid Service MAY also accept Authentication and Authorization methods based on Shibboleth. 7.7) In order to ease the development and deployment of grid Clients, each grid Service SHOULD accept following types of Authorization Tokens : 7.7.1) DN of the X509 certificate or RFC-3820-compliant X509 proxy (transport by OpenSSL) 7.7.2) X509 VOMS-style Attribute Certificates (transport by GSI) 7.7.3) X509 restriction attributes (transport by OpenSSL) 7.7.4) SAML assertions (transport inside SOAP headers). 7.8) In order to keep middleware complexity and bandwidth usage as low as possible, grid Services should NOT send their full description of their security interface inside each message, but only when specifically requested (for example by the Information Service). To be thoroughly criticized ... 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@lal.in2p3.fr ---------------------------------- On Mon, 30 Mar 2009, Vincenzo Ciaschini wrote:
Just one clarification: Due to compatibility issues with previous versions of glite, voms-proxy-init by default creates GT2 proxies. to make it create X509 proxies, the --rfc option is needed.
Ciao, Vincenzo
Etienne URBAH wrote:
To All,
About X509 proxies, I just got confirmation from Vincenzo CIASCHINI that :
1) OpenSSL and GSI are really incompatible as transport layers.
2) But they now accept exactly the same X509 proxies compliant to RFC 3820.
3) Old-style GSI X509 proxies are obsolete, and their usage should be forbidden
So I have updated my 'PGI Security Model' below and at http://forge.gridforum.org/sf/go/doc15584?nav=1
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@lal.in2p3.fr ----------------------------------
On Fri, 27 Mar 2009m Etienne URBAH wrote:
To All,
In order to handle X509 proxies, we regrettably have to take into account both the OpenSSL and GSI implementations of TLS, which are incompatible.
So I have updated my 'PGI Security Model' below and at http://forge.gridforum.org/sf/go/doc15584?nav=1
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@lal.in2p3.fr ----------------------------------
On Friday 03 April 2009 01:00, Etienne URBAH wrote:
Vincenzo and All,
My preceding mail about X509 proxies contained a FALSE assertion.
In fact :
- OpenSSL accepts only RFC-3820-compliant X509 proxies,
- GSI accepts only GSI-style X509 proxies.
GSI as implemented by Globus since version 4.0 (approximately) supports both pre-RFC proxies (versions 2 and 3 also known as Globus proxies) and RFC proxies (as defined in RFC 3820).
Following assertions still have to be verified :
- VOMS servers only accept GSI-style X509 proxies See http://forge.gridforum.org/sf/go/doc15591?nav=1
- Delegation of X509 proxies can be performed only by GSI.
X.509 proxy delegation at so called transport level can be performed using so called GSI connection. X.509 proxy delegation at transport level can NOT be performed if using SSL/TLS connection. In last case X.509 proxy delegation can be performed at higher level protocol. A.K.
So I have updated my 'PGI Security Model' below and at http://forge.gridforum.org/sf/go/doc15584?nav=1
OGF PGI - Security Model ========================
Current Established Base ======================== Chapters 1, 2 and 3 below describe the current security model of Computing Grid Infrastructures.
1) Grid Users and Certificate Authorities ----------------------------------------- 1.1) Each grid User is authenticated by a legal body (recognized by a government).
1.2) This legal body uses a Certificate Authority to grant a (long lived) X509 certificate to the grid User.
1.3) Each Certificate Authority is itself or is authenticated by a self-signed Root Certificate Authority.
1.4) All such Root Certificate Authorities trust each other and cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management Authorities).
1.5) These 3 Policy Management Authorities trust each other and cooperate within IGTF.
1.6) IGTF distributes the list of CA Certificates to be trusted.
1.7) Each grid Site providing grid Services to grid Users installs the CA Certificates it deems necessary. In general, there is no requirement to keep them up-to-date, but typically it is considered a security update and as such is strongly recommended to apply. Some infrastructures issue warnings for sites with outdated CA certs, but normally it does not impede operations.
1.8) Using its X509 certificate, each grid User can create at any time a (usually short lived) X509 proxy with permits impersonation / delegation during a (usually short) period.
1.9) Regrettably, there are 2 widely used INCOMPATIBLE types of X509 proxies : 1.9.1) RFC-3820-compliant X509 proxies can only be used by RFC-3820-compliant software, such as OpenSSL, 1.9.2) GSI-style X509 proxies can only be used with the GSI middleware, which permits further delegation.
2) Virtual Organizations ------------------------- 2.1) A Virtual Organization (VO) groups grid Users (usually with common goals). A Virtual Organization may be a legal body, and may be a Certificate Authority which can issue X509 certificates, but most are NOT. Each Virtual Organization can independently define Groups and Roles.
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.
2.3) Each grid User belongs to 1 or more VO (Virtual Organization), which grants him access rights to grid Storage and Computing Resources.
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) VOMS servers only accept GSI-style X509 proxies {{{TO BE VERIFIED}}} 2.4.2) SAML assertions
3) Grid Services : Information, AUTHN, AUTHZ ---------------------------------------------- 3.1) Some grid Infrastructures provide an Information Service with describes the Infrastructure, for example according to the 'GLUE 1.3' schema.
3.2) If this Information Service exists, then each grid User can query it in order to discover the list, requirements and capabilities of grid Services.
3.3) Each grid User can directly access data hosted by grid Storage Services. For Authentication, the grid User can present the public part of his X509 certificate or X509 proxy. For Authorization, the grid User has to present either (depending on the Infrastructure) : 3.3.1) the public part of his X509 certificate, or 3.3.2) the public part of his RFC-3820-compliant X509 proxy (without VOMS extensions), or 3.3.3) the public part of his GSI-Style X509 proxy (without VOMS extensions), or 3.3.4) the public part of his VOMS proxy, or 3.3.5) a bag of SAML assertions. In order to handle X509 proxies : - The OpenSSL implementation of TLS accepts only RFC-3820-compliant X509 proxies, - The GSI implementation of TLS accepts only GSI-style X509 proxies. So these 2 implementations of TLS are totally INCOMPATIBLE. If the grid User accesses data through a interface requiring delegation, then the next subchapter applies.
3.4) Each grid User can submit Jobs to grid Computing Services. If such a Job needs access to data hosted by grid Storage Services, then the grid User must provide a delegation token. This delegation token is either (depending on the Infrastructure) : 3.4.1) an X509 proxy, or 3.4.2) a VOMS proxy, or 3.4.3) a bag of SAML assertions.
3.5) Each grid Site providing grid Services to grid Users has installed Authorization Files (such as 'gridmap' files) describing VOMS authorizations, other authorizations, and mapping of grid credentials to local credentials. Grid Sites try to keep those Authorization Files up to date. There is a trend to replace these static 'gridmap' files by a robust Authorization Service (SCAS by EGEE, GUMS by OSG).
Where we propose to go ====================== Chapters 4, 5, 6 and 7 below describe a security model for short term Interoperability between Computing Grid Infrastructures.
4) Operational Robustness of Security -------------------------------------- 4.1) The number of Certificate Authorities for grid Infrastructures SHOULD be kept as low as possible.
5) Interoperability between X509 certificates and X509 proxies for Authentication ---------------------------------------------------------------------------------- 5.1) For this short term Security Profile aimed at short term Interoperability, we accept Shibboleth as an option, but knowingly exclude Shibboleth from any requirement.
5.2) X509 proxies MUST fully comply either to RFC 3820 or to GSI.
5.3) VOMS services, which deliver X509 proxies with VOMS extensions, MUST fully comply to RFC 3820 or GSI, and MAY accept both.
5.4) The authentication library used by grid Services MUST fully comply to RFC 3820 or GSI, and MAY accept both.
6) Information Service describing the Infrastructure according the the GLUE2 schema ------------------------------------------------------------------------------------ 6.1) Each grid Infrastructure MUST provide an Information Service, which describes the Infrastructure according the the GLUE2 schema.
6.2) If access to the Information Service is restricted, the grid Infrastructure MUST provide a Bootstrap Information Service, with describes the security requirements for access to the full Information Service according the the GLUE2 schema.
7) Interoperable Grid Services : Information, AUTHN, AUTHZ ------------------------------------------------------------ 7.1) The semantics of Authorization tokens MUST be the same for all grid Infrastructures. Examples of Authorization tokens are : 7.1.1) DN of the X509 certificate or proxy 7.1.2) VOMS-style Attribute Certificates 7.1.3) Restriction attributes 7.1.4) Shibboleth
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). GSI-style X509 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 GSI-style X509 proxies.
7.3) The Information Service of each grid Infrastructure MUST describe the transport method that the grid Service expects (potentially several). The GSI implementation of TLS is DEPRECATED in favor of RFC-3820-compliant TLS, such as OpenSSL. Each provider of grid middleware MUST establish and publish the list of the components which still require the GSI implementation of TLS.
7.4) Each grid Site providing grid Services to grid Users MUST install and keep up to date a robust Authorization Service enforcing VOMS authorizations, other authorizations, and mapping of grid credentials to local credentials.
7.5) Each grid Service MUST accept at least : 7.5.1) One of the following Authorization Tokens : - DN of the X509 certificate or RFC-3820-compliant X509 proxy - DN of the GSI-syle X509 proxy - X509 VOMS-style Attribute Certificates (VOMS extensions) They are defined in 'VOMS Attribute Certificate Format' at http://forge.gridforum.org/sf/go/doc13797?nav=1 - X509 restriction attributes {{{Please give the reference of a description document}}} - SAML assertions (Attention: there are differences between SAML V1.1 and SAML V2.0)
http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAM...
7.5.2) One of the following transport methods : - OpenSSL for X509 certificates and RFC-3820-compliant X509 proxies - GSI for GSI-style X509 proxies - SOAP header for SAML assertions
7.6) As long as it satisfies subchapter 7.5, each grid Service MAY also accept Authentication and Authorization methods based on Shibboleth.
7.7) In order to ease the development and deployment of grid Clients, each grid Service SHOULD accept following types of Authorization Tokens : 7.7.1) DN of the X509 certificate or RFC-3820-compliant X509 proxy (transport by OpenSSL) 7.7.2) X509 VOMS-style Attribute Certificates (transport by GSI) 7.7.3) X509 restriction attributes (transport by OpenSSL) 7.7.4) SAML assertions (transport inside SOAP headers).
7.8) In order to keep middleware complexity and bandwidth usage as low as possible, grid Services should NOT send their full description of their security interface inside each message, but only when specifically requested (for example by the Information Service).
To be thoroughly criticized ...
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@lal.in2p3.fr ----------------------------------
On Mon, 30 Mar 2009, Vincenzo Ciaschini wrote:
Just one clarification: Due to compatibility issues with previous versions of glite, voms-proxy-init by default creates GT2 proxies. to make it create X509 proxies, the --rfc option is needed.
Ciao, Vincenzo
Etienne URBAH wrote:
To All,
About X509 proxies, I just got confirmation from Vincenzo CIASCHINI that :
1) OpenSSL and GSI are really incompatible as transport layers.
2) But they now accept exactly the same X509 proxies compliant to RFC 3820.
3) Old-style GSI X509 proxies are obsolete, and their usage should be forbidden
So I have updated my 'PGI Security Model' below and at http://forge.gridforum.org/sf/go/doc15584?nav=1
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@lal.in2p3.fr ----------------------------------
On Fri, 27 Mar 2009m Etienne URBAH wrote:
To All,
In order to handle X509 proxies, we regrettably have to take into account both the OpenSSL and GSI implementations of TLS, which are incompatible.
So I have updated my 'PGI Security Model' below and at http://forge.gridforum.org/sf/go/doc15584?nav=1
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@lal.in2p3.fr ----------------------------------
Yes, that is in line with my understanding as well. Although, I don't believe there is anything preventing the higher-level application layer delegation of "GSI-style" proxies as well. I mean, if we're going to go to the effort for RFC proxies..... Duane On 4/5/09, Aleksandr Konstantinov <aleksandr.konstantinov@fys.uio.no> wrote:
On Friday 03 April 2009 01:00, Etienne URBAH wrote:
Vincenzo and All,
My preceding mail about X509 proxies contained a FALSE assertion.
In fact :
- OpenSSL accepts only RFC-3820-compliant X509 proxies,
- GSI accepts only GSI-style X509 proxies.
GSI as implemented by Globus since version 4.0 (approximately) supports both pre-RFC proxies (versions 2 and 3 also known as Globus proxies) and RFC proxies (as defined in RFC 3820).
Following assertions still have to be verified :
- VOMS servers only accept GSI-style X509 proxies See http://forge.gridforum.org/sf/go/doc15591?nav=1
- Delegation of X509 proxies can be performed only by GSI.
X.509 proxy delegation at so called transport level can be performed using so called GSI connection. X.509 proxy delegation at transport level can NOT be performed if using SSL/TLS connection. In last case X.509 proxy delegation can be performed at higher level protocol.
A.K.
So I have updated my 'PGI Security Model' below and at http://forge.gridforum.org/sf/go/doc15584?nav=1
OGF PGI - Security Model ========================
Current Established Base ======================== Chapters 1, 2 and 3 below describe the current security model of Computing Grid Infrastructures.
1) Grid Users and Certificate Authorities ----------------------------------------- 1.1) Each grid User is authenticated by a legal body (recognized by a government).
1.2) This legal body uses a Certificate Authority to grant a (long lived) X509 certificate to the grid User.
1.3) Each Certificate Authority is itself or is authenticated by a self-signed Root Certificate Authority.
1.4) All such Root Certificate Authorities trust each other and cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management Authorities).
1.5) These 3 Policy Management Authorities trust each other and cooperate within IGTF.
1.6) IGTF distributes the list of CA Certificates to be trusted.
1.7) Each grid Site providing grid Services to grid Users installs the CA Certificates it deems necessary. In general, there is no requirement to keep them up-to-date, but typically it is considered a security update and as such is strongly recommended to apply. Some infrastructures issue warnings for sites with outdated CA certs, but normally it does not impede operations.
1.8) Using its X509 certificate, each grid User can create at any time a (usually short lived) X509 proxy with permits impersonation / delegation during a (usually short) period.
1.9) Regrettably, there are 2 widely used INCOMPATIBLE types of X509 proxies : 1.9.1) RFC-3820-compliant X509 proxies can only be used by RFC-3820-compliant software, such as OpenSSL, 1.9.2) GSI-style X509 proxies can only be used with the GSI middleware, which permits further delegation.
2) Virtual Organizations ------------------------- 2.1) A Virtual Organization (VO) groups grid Users (usually with common goals). A Virtual Organization may be a legal body, and may be a Certificate Authority which can issue X509 certificates, but most are NOT. Each Virtual Organization can independently define Groups and Roles.
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.
2.3) Each grid User belongs to 1 or more VO (Virtual Organization), which grants him access rights to grid Storage and Computing Resources.
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) VOMS servers only accept GSI-style X509 proxies {{{TO BE VERIFIED}}} 2.4.2) SAML assertions
3) Grid Services : Information, AUTHN, AUTHZ ---------------------------------------------- 3.1) Some grid Infrastructures provide an Information Service with describes the Infrastructure, for example according to the 'GLUE 1.3' schema.
3.2) If this Information Service exists, then each grid User can query it in order to discover the list, requirements and capabilities of grid Services.
3.3) Each grid User can directly access data hosted by grid Storage Services. For Authentication, the grid User can present the public part of his X509 certificate or X509 proxy. For Authorization, the grid User has to present either (depending on the Infrastructure) : 3.3.1) the public part of his X509 certificate, or 3.3.2) the public part of his RFC-3820-compliant X509 proxy (without VOMS extensions), or 3.3.3) the public part of his GSI-Style X509 proxy (without VOMS extensions), or 3.3.4) the public part of his VOMS proxy, or 3.3.5) a bag of SAML assertions. In order to handle X509 proxies : - The OpenSSL implementation of TLS accepts only RFC-3820-compliant X509 proxies, - The GSI implementation of TLS accepts only GSI-style X509 proxies. So these 2 implementations of TLS are totally INCOMPATIBLE. If the grid User accesses data through a interface requiring delegation, then the next subchapter applies.
3.4) Each grid User can submit Jobs to grid Computing Services. If such a Job needs access to data hosted by grid Storage Services, then the grid User must provide a delegation token. This delegation token is either (depending on the Infrastructure) : 3.4.1) an X509 proxy, or 3.4.2) a VOMS proxy, or 3.4.3) a bag of SAML assertions.
3.5) Each grid Site providing grid Services to grid Users has installed Authorization Files (such as 'gridmap' files) describing VOMS authorizations, other authorizations, and mapping of grid credentials to local credentials. Grid Sites try to keep those Authorization Files up to date. There is a trend to replace these static 'gridmap' files by a robust Authorization Service (SCAS by EGEE, GUMS by OSG).
Where we propose to go ====================== Chapters 4, 5, 6 and 7 below describe a security model for short term Interoperability between Computing Grid Infrastructures.
4) Operational Robustness of Security -------------------------------------- 4.1) The number of Certificate Authorities for grid Infrastructures SHOULD be kept as low as possible.
5) Interoperability between X509 certificates and X509 proxies for Authentication ---------------------------------------------------------------------------------- 5.1) For this short term Security Profile aimed at short term Interoperability, we accept Shibboleth as an option, but knowingly exclude Shibboleth from any requirement.
5.2) X509 proxies MUST fully comply either to RFC 3820 or to GSI.
5.3) VOMS services, which deliver X509 proxies with VOMS extensions, MUST fully comply to RFC 3820 or GSI, and MAY accept both.
5.4) The authentication library used by grid Services MUST fully comply to RFC 3820 or GSI, and MAY accept both.
6) Information Service describing the Infrastructure according the the GLUE2 schema ------------------------------------------------------------------------------------ 6.1) Each grid Infrastructure MUST provide an Information Service, which describes the Infrastructure according the the GLUE2 schema.
6.2) If access to the Information Service is restricted, the grid Infrastructure MUST provide a Bootstrap Information Service, with describes the security requirements for access to the full Information Service according the the GLUE2 schema.
7) Interoperable Grid Services : Information, AUTHN, AUTHZ ------------------------------------------------------------ 7.1) The semantics of Authorization tokens MUST be the same for all grid Infrastructures. Examples of Authorization tokens are : 7.1.1) DN of the X509 certificate or proxy 7.1.2) VOMS-style Attribute Certificates 7.1.3) Restriction attributes 7.1.4) Shibboleth
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). GSI-style X509 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 GSI-style X509 proxies.
7.3) The Information Service of each grid Infrastructure MUST describe the transport method that the grid Service expects (potentially several). The GSI implementation of TLS is DEPRECATED in favor of RFC-3820-compliant TLS, such as OpenSSL. Each provider of grid middleware MUST establish and publish the list of the components which still require the GSI implementation of TLS.
7.4) Each grid Site providing grid Services to grid Users MUST install and keep up to date a robust Authorization Service enforcing VOMS authorizations, other authorizations, and mapping of grid credentials to local credentials.
7.5) Each grid Service MUST accept at least : 7.5.1) One of the following Authorization Tokens : - DN of the X509 certificate or RFC-3820-compliant X509 proxy - DN of the GSI-syle X509 proxy - X509 VOMS-style Attribute Certificates (VOMS extensions) They are defined in 'VOMS Attribute Certificate Format' at http://forge.gridforum.org/sf/go/doc13797?nav=1 - X509 restriction attributes {{{Please give the reference of a description document}}} - SAML assertions (Attention: there are differences between SAML V1.1 and SAML V2.0)
http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAM...
7.5.2) One of the following transport methods : - OpenSSL for X509 certificates and RFC-3820-compliant X509 proxies - GSI for GSI-style X509 proxies - SOAP header for SAML assertions
7.6) As long as it satisfies subchapter 7.5, each grid Service MAY also accept Authentication and Authorization methods based on Shibboleth.
7.7) In order to ease the development and deployment of grid Clients, each grid Service SHOULD accept following types of Authorization Tokens : 7.7.1) DN of the X509 certificate or RFC-3820-compliant X509 proxy (transport by OpenSSL) 7.7.2) X509 VOMS-style Attribute Certificates (transport by GSI) 7.7.3) X509 restriction attributes (transport by OpenSSL) 7.7.4) SAML assertions (transport inside SOAP headers).
7.8) In order to keep middleware complexity and bandwidth usage as low as possible, grid Services should NOT send their full description of their security interface inside each message, but only when specifically requested (for example by the Information Service).
To be thoroughly criticized ...
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@lal.in2p3.fr ----------------------------------
On Mon, 30 Mar 2009, Vincenzo Ciaschini wrote:
Just one clarification: Due to compatibility issues with previous versions of glite, voms-proxy-init by default creates GT2 proxies. to make it create X509 proxies, the --rfc option is needed.
Ciao, Vincenzo
Etienne URBAH wrote:
To All,
About X509 proxies, I just got confirmation from Vincenzo CIASCHINI that :
1) OpenSSL and GSI are really incompatible as transport layers.
2) But they now accept exactly the same X509 proxies compliant to RFC 3820.
3) Old-style GSI X509 proxies are obsolete, and their usage should be forbidden
So I have updated my 'PGI Security Model' below and at http://forge.gridforum.org/sf/go/doc15584?nav=1
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@lal.in2p3.fr ----------------------------------
On Fri, 27 Mar 2009m Etienne URBAH wrote:
To All,
In order to handle X509 proxies, we regrettably have to take into account both the OpenSSL and GSI implementations of TLS, which are incompatible.
So I have updated my 'PGI Security Model' below and at http://forge.gridforum.org/sf/go/doc15584?nav=1
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@lal.in2p3.fr ----------------------------------
_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
Aleksandr, Duane and All, Concerning the PGI Security Model : Lot of thanks to Aleksandr and Duane for their explanations about different types of proxies, versions of GSI, and delegation. I know understand that : - NEW versions of GSI (since version 4.0 approximately) accept both RFC-3820-compliant X509 proxies and Globus proxies. - Delegation of any security token can be performed at higher level, for example by the 'GridSite Delegation' service. Important is that old versions of GSI, which do NOT accept RFC-3820-compliant X509 proxies, block interoperability, and are then STRONGLY DEPRECATED. Therefore, each provider of grid middleware using such an old version of GSI : - MUST establish and publish the list of the components which still uses it, - SHOULD migrate to a new version of GSI which also accepts RFC-3820-compliant X509 proxies. Still to be verified is that VOMS servers only accept GSI-style X509 proxies http://forge.gridforum.org/sf/go/doc15591?nav=1 Anyway, I have updated my 'PGI Security Model' below and at http://forge.gridforum.org/sf/go/doc15584?nav=1 OGF PGI - Security Model ======================== Current Established Base ======================== Chapters 1, 2 and 3 below describe the current security model of Computing Grid Infrastructures. 1) Grid Users and Certificate Authorities ----------------------------------------- 1.1) Each grid User is authenticated by a legal body (recognized by a government). 1.2) This legal body uses a Certificate Authority to grant a (long lived) X509 certificate to the grid User. 1.3) Each Certificate Authority is itself or is authenticated by a self-signed Root Certificate Authority. 1.4) All such Root Certificate Authorities trust each other and cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management Authorities). 1.5) These 3 Policy Management Authorities trust each other and cooperate within IGTF. 1.6) IGTF distributes the list of CA Certificates to be trusted. 1.7) Each grid Site providing grid Services to grid Users installs the CA Certificates it deems necessary. In general, there is no requirement to keep them up-to-date, but typically it is considered a security update and as such is strongly recommended to apply. Some infrastructures issue warnings for sites with outdated CA certs, but normally it does not impede operations. 1.8) Using its X509 certificate, each grid User can create at any time a (usually short lived) X509 proxy with permits impersonation / delegation during a (usually short) period. 1.9) Regrettably, there are 2 widely used INCOMPATIBLE types of X509 proxies : 1.9.1) RFC-3820-compliant X509 proxies can only be used by RFC-3820-compliant software, such as OpenSSL, or NEW versions of the GSI middleware (since version 4.0 approximately) 1.9.2) Globus proxies can only be used with the GSI middleware, which permits direct delegation. 2) Virtual Organizations ------------------------- 2.1) A Virtual Organization (VO) groups grid Users (usually with common goals). A Virtual Organization may be a legal body, and may be a Certificate Authority which can issue X509 certificates, but most are NOT. Each Virtual Organization can independently define Groups and Roles. 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. 2.3) Each grid User belongs to 1 or more VO (Virtual Organization), which grants him access rights to grid Storage and Computing Resources. 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, VOMS servers only accept Globus proxies {{{TO BE VERIFIED}}} 2.4.2) SAML assertions 3) Grid Services : Information, AUTHN, AUTHZ ---------------------------------------------- 3.1) Some grid Infrastructures provide an Information Service with describes the Infrastructure, for example according to the 'GLUE 1.3' schema. 3.2) If this Information Service exists, then each grid User can query it in order to discover the list, requirements and capabilities of grid Services. 3.3) Each grid User can directly access data hosted by grid Storage Services. For Authentication, the grid User can present the public part of his X509 certificate or X509 proxy. For Authorization, the grid User has to present either (depending on the Infrastructure) : 3.3.1) the public part of his X509 certificate, or 3.3.2) the public part of his RFC-3820-compliant X509 proxy (without VOMS extensions), or 3.3.3) the public part of his Globus proxy (without VOMS extensions), or 3.3.4) the public part of his VOMS proxy, or 3.3.5) a bag of SAML assertions. In order to handle X509 proxies : - The OpenSSL implementation of TLS accepts only RFC-3820-compliant X509 proxies, - Old GSI implementations of TLS accepts only Globus proxies. So the 2 previous implementations of TLS are totally INCOMPATIBLE. - New GSI implementations of TLS (since version 4.0 approximately) accepts both RFC-3820-compliant X509 proxies and Globus proxies. If the grid User accesses data through a interface requiring delegation, then the next subchapter applies. 3.4) Each grid User can submit Jobs to grid Computing Services. If such a Job needs access to data hosted by grid Storage Services, then the grid User must provide a delegation token. This delegation token is either (depending on the Infrastructure) : 3.4.1) an X509 proxy, or 3.4.2) a VOMS proxy, or 3.4.3) a bag of SAML assertions. Delegation can be performed : - Directly by GSI, but only with Globus proxies, - At a higher level, for example by the 'GridSite Delegation' service described at http://www.gridsite.org/wiki/Delegation_protocol 3.5) Each grid Site providing grid Services to grid Users has installed Authorization Files (such as 'gridmap' files) describing VOMS authorizations, other authorizations, and mapping of grid credentials to local credentials. Grid Sites try to keep those Authorization Files up to date. There is a trend to replace these static 'gridmap' files by a robust Authorization Service (SCAS by EGEE, GUMS by OSG). Where we propose to go ====================== Chapters 4, 5, 6 and 7 below describe a security model for short term Interoperability between Computing Grid Infrastructures. 4) Operational Robustness of Security -------------------------------------- 4.1) The number of Certificate Authorities for grid Infrastructures SHOULD be kept as low as possible. 5) Interoperability between X509 certificates and X509 proxies for Authentication ---------------------------------------------------------------------------------- 5.1) For this short term Security Profile aimed at short term Interoperability, we accept Shibboleth as an option, but knowingly exclude Shibboleth from any requirement. 5.2) X509 proxies MUST fully comply either to RFC 3820 or to GSI. 5.3) VOMS services, which deliver X509 proxies with VOMS extensions, MUST fully comply to RFC 3820 or GSI, and MAY accept both. 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, each provider of grid middleware using such an old version of GSI : - MUST establish and publish the list of the components which still uses it, - SHOULD migrate to a new version of GSI which also accepts RFC-3820-compliant X509 proxies. 6) Information Service describing the Infrastructure according the the GLUE2 schema ------------------------------------------------------------------------------------ 6.1) Each grid Infrastructure MUST provide an Information Service, which describes the Infrastructure according the the GLUE2 schema. 6.2) If access to the Information Service is restricted, the grid Infrastructure MUST provide a Bootstrap Information Service, with describes the security requirements for access to the full Information Service according the the GLUE2 schema. 7) Interoperable Grid Services : Information, AUTHN, AUTHZ ------------------------------------------------------------ 7.1) The semantics of Authorization tokens MUST be the same for all grid Infrastructures. Examples of Authorization tokens are : 7.1.1) DN of the X509 certificate or proxy 7.1.2) VOMS-style Attribute Certificates 7.1.3) Restriction attributes 7.1.4) Shibboleth 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. 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, each provider of grid middleware using such an old version of GSI : - MUST establish and publish the list of the components which still uses it, - SHOULD migrate to a new version of GSI which also accepts RFC-3820-compliant X509 proxies. 7.4) Each grid Site providing grid Services to grid Users MUST install and keep up to date a robust Authorization Service enforcing VOMS authorizations, other authorizations, and mapping of grid credentials to local credentials. 7.5) Each grid Service MUST accept at least : 7.5.1) One of the following Authorization Tokens : - DN of the X509 certificate or RFC-3820-compliant X509 proxy - DN of the GSI-syle X509 proxy - X509 VOMS-style Attribute Certificates (VOMS extensions) They are defined in 'VOMS Attribute Certificate Format' at http://forge.gridforum.org/sf/go/doc13797?nav=1 - X509 restriction attributes {{{Please give the reference of a description document}}} - SAML assertions (Attention: there are differences between SAML V1.1 and SAML V2.0) http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAM... 7.5.2) One of the following transport methods : - OpenSSL (or new GSI) for X509 certificates and RFC-3820-compliant X509 proxies, - GSI for Globus proxies (migration to new GSI is STRONGLY RECOMMENDED), - SOAP header for SAML assertions. 7.6) As long as it satisfies subchapter 7.5, each grid Service MAY also accept Authentication and Authorization methods based on Shibboleth. 7.7) In order to ease the development and deployment of grid Clients, each grid Service SHOULD accept following types of Authorization Tokens : 7.7.1) DN of the X509 certificate or RFC-3820-compliant X509 proxy (transport by OpenSSL) 7.7.2) X509 VOMS-style Attribute Certificates (transport by GSI) 7.7.3) X509 restriction attributes (transport by OpenSSL) 7.7.4) SAML assertions (transport inside SOAP headers). 7.8) In order to keep middleware complexity and bandwidth usage as low as possible, grid Services should NOT send their full description of their security interface inside each message, but only when specifically requested (for example by the Information Service). To be thoroughly criticized ... 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@lal.in2p3.fr ---------------------------------- On Mon, 6 Apr 2009, Duane Merrill wrote:
Yes, that is in line with my understanding as well. Although, I don't believe there is anything preventing the higher-level application layer delegation of "GSI-style" proxies as well. I mean, if we're going to go to the effort for RFC proxies.....
Duane
On 4/5/09, Aleksandr Konstantinov <aleksandr.konstantinov@fys.uio.no> wrote:
On Friday 03 April 2009 01:00, Etienne URBAH wrote:
Vincenzo and All,
My preceding mail about X509 proxies contained a FALSE assertion.
In fact :
- OpenSSL accepts only RFC-3820-compliant X509 proxies,
- GSI accepts only GSI-style X509 proxies. GSI as implemented by Globus since version 4.0 (approximately) supports both pre-RFC proxies (versions 2 and 3 also known as Globus proxies) and RFC proxies (as defined in RFC 3820).
Following assertions still have to be verified :
- VOMS servers only accept GSI-style X509 proxies See http://forge.gridforum.org/sf/go/doc15591?nav=1
- Delegation of X509 proxies can be performed only by GSI.
X.509 proxy delegation at so called transport level can be performed using so called GSI connection. X.509 proxy delegation at transport level can NOT be performed if using SSL/TLS connection. In last case X.509 proxy delegation can be performed at higher level protocol.
A.K.
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@lal.in2p3.fr ----------------------------------
On Mon, 30 Mar 2009, Vincenzo Ciaschini wrote:
Just one clarification: Due to compatibility issues with previous versions of glite, voms-proxy-init by default creates GT2 proxies. to make it create X509 proxies, the --rfc option is needed.
Ciao, Vincenzo
Etienne URBAH wrote:
To All,
About X509 proxies, I just got confirmation from Vincenzo CIASCHINI that :
1) OpenSSL and GSI are really incompatible as transport layers.
2) But they now accept exactly the same X509 proxies compliant to RFC 3820.
3) Old-style GSI X509 proxies are obsolete, and their usage should be forbidden
So I have updated my 'PGI Security Model' below and at http://forge.gridforum.org/sf/go/doc15584?nav=1
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@lal.in2p3.fr ----------------------------------
On Fri, 27 Mar 2009m Etienne URBAH wrote:
To All,
In order to handle X509 proxies, we regrettably have to take into account both the OpenSSL and GSI implementations of TLS, which are incompatible.
So I have updated my 'PGI Security Model' below and at http://forge.gridforum.org/sf/go/doc15584?nav=1
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@lal.in2p3.fr ----------------------------------
Etienne raises a valid point...
Important is that old versions of GSI, which do NOT accept RFC-3820- compliant X509 proxies, block interoperability, and are then STRONGLY DEPRECATED.
These are still being used and supported (to provide legacy compatibility) but alongside support for the newer X509 proxy system.
Therefore, each provider of grid middleware using such an old version of GSI : - MUST establish and publish the list of the components which still uses it, - SHOULD migrate to a new version of GSI which also accepts RFC-3820- compliant X509 proxies.
This group has no right to mandate what middleware providers should or should not do! But if no provider is JUST using old versions of GSI and intend to migrate away from them I see no point in trying to define a profile around something that has no clear specification (just the GT implementation) and everyone intends to remove in the future. Surely its better to focus our energies on defining a profile around the new style proxies that groups intend to support going forward? Steven
Hi PGI team, looking at the latest conversations I see a demand to discuss how we can actually profile/specify the security plumbings basically agreed from the group so far (maybe aligned with information plumbings describing the security setup). Unfortunately, there will be no telcon on Friday this week due to eastern holidays, but next week as usual. However, we should start a discussion how we can specify the three plumbings for authN and two plumbings for authZ we agreed on so far. Addressing the comment from Steven around specifying the GSI elements: pro # MWSG means we could specify it although its not a real standard # A xyz PGI profile would support our production legacy systems contra # we have a PGI profile that includes already elements that are deprecated (GSI et al.) - plan was to just remove these plumbings over time... # it's harder to standardize instead of focusing on RFC elements However, from the most recent work in PGI I got the strong feeling that we have to stick to the three authN plumbings and two authZ plumbings - maybe people still disagree here, but I got a response from Alex Sim (SRM collaboration) mentioning that GSI is still all over the place and non-GSI versions (i.e. 3.0) will maybe deployed in the next 3-4 years... so out of scope of our work. The question arises how we specify these plumbings exactly. (1) Approach 1 (like WS-RF that consists of n specifications) # PGI data/job/security (our first document from the charter) ## PGI - AuthN - GSI ## PGI - AuthN - RFCProxy ## PGI - AuthN - EE ## PGI - AuthZ - SAML ## PGI - AuthZ - AC ## PGI - Data - ... Each of it would be a specification element part of the overall PGI standard. Adopters refer to it as specifying a server being PGI-AUTHN - RFCProxy Compliant, etc. (2) Approach 2 (similar like Duane's approach) We define everthing in one specification and combine our elements with # MANDATORY to support at least one of... # MANDATORY to support ...or / and # etc. Here adopters refer to Tags like PGI_COMM_XYZ within the PGI specification to indicate whether a system supports proxies or not. Any other approach I missed? Take care, Morris ------------------------------------------------------------ Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel "We work to better ourselves, and the rest of humanity" Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender)
------Original Message----- -From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of -Steven Newhouse -Sent: Wednesday, April 08, 2009 8:02 AM -To: Etienne Urbah; aleksandr.konstantinov@fys.uio.no; Duane MERRIL; pgi- -wg@ogf.org -Cc: edges-na3@mail.edges-grid.eu; lodygens@lal.in2p3.fr -Subject: Re: [Pgi-wg] OGF PGI - Security Model - NEW versions of GSI acceptRFC- -3820-compliant X509 proxies - -Etienne raises a valid point... - -> Important is that old versions of GSI, which do NOT accept RFC-3820- -> compliant X509 proxies, block interoperability, and are then STRONGLY -> DEPRECATED. - -These are still being used and supported (to provide legacy -compatibility) but alongside support for the newer X509 proxy system. - -> Therefore, each provider of grid middleware using such an old version -> of GSI : -> - MUST establish and publish the list of the components which still -> uses it, -> - SHOULD migrate to a new version of GSI which also accepts RFC-3820- -> compliant X509 proxies. - -This group has no right to mandate what middleware providers should or -should not do! But if no provider is JUST using old versions of GSI and -intend to migrate away from them I see no point in trying to define a -profile around something that has no clear specification (just the GT -implementation) and everyone intends to remove in the future. - -Surely its better to focus our energies on defining a profile around the -new style proxies that groups intend to support going forward? - -Steven - -_______________________________________________ -Pgi-wg mailing list -Pgi-wg@ogf.org -http://www.ogf.org/mailman/listinfo/pgi-wg
Steven, Vincenzo and All, Concerning the PGI Security Model : - Steven is right about middleware providers of old versions of GSI. So, in the text, I have replaced 'MUST' and 'SHOULD' by 'we advise'. - Vincenzo has explained that VOMS servers with version older than 2.0 only accept 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. So, inside EGEE, all VO managers MUST verify the content of their 'vomses' file, and fix it if necessary. Therefore, I have updated my 'PGI Security Model' below and at http://forge.gridforum.org/sf/go/doc15584?nav=1 For the next OGF PGI Security telephone conference next Friday, I would like that we reach a consensus on this document, and on the Vocabulary at http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/Vocabula... So please read them, criticize them, and improve them. OGF PGI - Security Model ======================== Current Established Base ======================== Chapters 1, 2 and 3 below describe the current security model of Computing Grid Infrastructures. 1) Grid Users and Certificate Authorities ----------------------------------------- 1.1) Each grid User is authenticated by a legal body (recognized by a government). 1.2) This legal body uses a Certificate Authority to grant a (long lived) X509 certificate to the grid User. 1.3) Each Certificate Authority is itself or is authenticated by a self-signed Root Certificate Authority. 1.4) All such Root Certificate Authorities trust each other and cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management Authorities). 1.5) These 3 Policy Management Authorities trust each other and cooperate within IGTF. 1.6) IGTF distributes the list of CA Certificates to be trusted. 1.7) Each grid Site providing grid Services to grid Users installs the CA Certificates it deems necessary. In general, there is no requirement to keep them up-to-date, but typically it is considered a security update and as such is strongly recommended to apply. Some infrastructures issue warnings for sites with outdated CA certs, but normally it does not impede operations. 1.8) Using its X509 certificate, each grid User can create at any time a (usually short lived) X509 proxy with permits impersonation / delegation during a (usually short) period. 1.9) Regrettably, there are 2 widely used INCOMPATIBLE types of X509 proxies : 1.9.1) RFC-3820-compliant X509 proxies can only be used by RFC-3820-compliant software, such as OpenSSL, or NEW versions of the GSI middleware (since version 4.0 approximately) 1.9.2) Globus proxies can only be used with the GSI middleware, which permits direct delegation. 2) Virtual Organizations ------------------------- 2.1) A Virtual Organization (VO) groups grid Users (usually with common goals). A Virtual Organization may be a legal body, and may be a Certificate Authority which can issue X509 certificates, but most are NOT. Each Virtual Organization can independently define Groups and Roles. 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. 2.3) Each grid User belongs to 1 or more VO (Virtual Organization), which grants him access rights to grid Storage and Computing Resources. 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 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. - 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. 2.4.2) SAML assertions 3) Grid Services : Information, AUTHN, AUTHZ ---------------------------------------------- 3.1) Some grid Infrastructures provide an Information Service with describes the Infrastructure, for example according to the 'GLUE 1.3' schema. 3.2) If this Information Service exists, then each grid User can query it in order to discover the list, requirements and capabilities of grid Services. 3.3) Each grid User can directly access data hosted by grid Storage Services. For Authentication, the grid User can present the public part of his X509 certificate or X509 proxy. For Authorization, the grid User has to present either (depending on the Infrastructure) : 3.3.1) the public part of his X509 certificate, or 3.3.2) the public part of his RFC-3820-compliant X509 proxy (without VOMS extensions), or 3.3.3) the public part of his Globus proxy (without VOMS extensions), or 3.3.4) the public part of his VOMS proxy, or 3.3.5) a bag of SAML assertions. In order to handle X509 proxies : - The OpenSSL implementation of TLS accepts only RFC-3820-compliant X509 proxies, - Old GSI implementations of TLS accepts only Globus proxies. So the 2 previous implementations of TLS are totally INCOMPATIBLE. - New GSI implementations of TLS (since version 4.0 approximately) accepts both RFC-3820-compliant X509 proxies and Globus proxies. If the grid User accesses data through a interface requiring delegation, then the next subchapter applies. 3.4) Each grid User can submit Jobs to grid Computing Services. If such a Job needs access to data hosted by grid Storage Services, then the grid User must provide a delegation token. This delegation token is either (depending on the Infrastructure) : 3.4.1) an X509 proxy, or 3.4.2) a VOMS proxy, or 3.4.3) a bag of SAML assertions. Delegation can be performed : - Directly by GSI, but only with Globus proxies, - At a higher level, for example by the 'GridSite Delegation' service described at http://www.gridsite.org/wiki/Delegation_protocol 3.5) Each grid Site providing grid Services to grid Users has installed Authorization Files (such as 'gridmap' files) describing VOMS authorizations, other authorizations, and mapping of grid credentials to local credentials. Grid Sites try to keep those Authorization Files up to date. There is a trend to replace these static 'gridmap' files by a robust Authorization Service (SCAS by EGEE, GUMS by OSG). Where we propose to go ====================== Chapters 4, 5, 6 and 7 below describe a security model for short term Interoperability between Computing Grid Infrastructures. 4) Operational Robustness of Security -------------------------------------- 4.1) The number of Certificate Authorities for grid Infrastructures SHOULD be kept as low as possible. 5) Interoperability between X509 certificates and X509 proxies for Authentication ---------------------------------------------------------------------------------- 5.1) For this short term Security Profile aimed at short term Interoperability, we accept Shibboleth as an option, but knowingly exclude Shibboleth from any requirement. 5.2) X509 proxies MUST fully comply either to RFC 3820 or to GSI. 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. 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. 6) Information Service describing the Infrastructure according the the GLUE2 schema ------------------------------------------------------------------------------------ 6.1) Each grid Infrastructure MUST provide an Information Service, which describes the Infrastructure according the the GLUE2 schema. 6.2) If access to the Information Service is restricted, the grid Infrastructure MUST provide a Bootstrap Information Service, with describes the security requirements for access to the full Information Service according the the GLUE2 schema. 7) Interoperable Grid Services : Information, AUTHN, AUTHZ ------------------------------------------------------------ 7.1) The semantics of Authorization tokens MUST be the same for all grid Infrastructures. Examples of Authorization tokens are : 7.1.1) DN of the X509 certificate or proxy 7.1.2) VOMS-style Attribute Certificates 7.1.3) Restriction attributes 7.1.4) Shibboleth 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. 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. 7.4) Each grid Site providing grid Services to grid Users MUST install and keep up to date a robust Authorization Service enforcing VOMS authorizations, other authorizations, and mapping of grid credentials to local credentials. 7.5) Each grid Service MUST accept at least : 7.5.1) One of the following Authorization Tokens : - DN of the X509 certificate or RFC-3820-compliant X509 proxy - DN of the GSI-syle X509 proxy - X509 VOMS-style Attribute Certificates (VOMS extensions) They are defined in 'VOMS Attribute Certificate Format' at http://forge.gridforum.org/sf/go/doc13797?nav=1 - X509 restriction attributes {{{Please give the reference of a description document}}} - SAML assertions (Attention: there are differences between SAML V1.1 and SAML V2.0) http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAM... 7.5.2) One of the following transport methods : - OpenSSL (or new GSI) for X509 certificates and RFC-3820-compliant X509 proxies, - GSI for Globus proxies (migration to new GSI is STRONGLY RECOMMENDED), - SOAP header for SAML assertions. 7.6) As long as it satisfies subchapter 7.5, each grid Service MAY also accept Authentication and Authorization methods based on Shibboleth. 7.7) In order to ease the development and deployment of grid Clients, each grid Service SHOULD accept following types of Authorization Tokens : 7.7.1) DN of the X509 certificate or RFC-3820-compliant X509 proxy (transport by OpenSSL) 7.7.2) X509 VOMS-style Attribute Certificates (transport by GSI) 7.7.3) X509 restriction attributes (transport by OpenSSL) 7.7.4) SAML assertions (transport inside SOAP headers). 7.8) In order to keep middleware complexity and bandwidth usage as low as possible, grid Services should NOT send their full description of their security interface inside each message, but only when specifically requested (for example by the Information Service). To be thoroughly criticized ... 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@lal.in2p3.fr ---------------------------------- On Wed, 8 Apr 2009, Steven Newhouse wrote:
Etienne raises a valid point...
Important is that old versions of GSI, which do NOT accept RFC-3820- compliant X509 proxies, block interoperability, and are then STRONGLY DEPRECATED.
These are still being used and supported (to provide legacy compatibility) but alongside support for the newer X509 proxy system.
Therefore, each provider of grid middleware using such an old version of GSI : - MUST establish and publish the list of the components which still uses it, - SHOULD migrate to a new version of GSI which also accepts RFC-3820- compliant X509 proxies.
This group has no right to mandate what middleware providers should or should not do! But if no provider is JUST using old versions of GSI and intend to migrate away from them I see no point in trying to define a profile around something that has no clear specification (just the GT implementation) and everyone intends to remove in the future.
Surely its better to focus our energies on defining a profile around the new style proxies that groups intend to support going forward?
Steven
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
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
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/Vocabula... 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@lal.in2p3.fr ---------------------------------- On Thu, 16 Apr 2009, Oxana Smirnova wrote: 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
Hi Etienne, Etienne URBAH wrote:
Still to be verified is that VOMS servers only accept GSI-style X509 proxies http://forge.gridforum.org/sf/go/doc15591?nav=1 VOMS accepts and generates both type of proxies. However, there is a caveat, which explains the failures you get:
Pre VOMS 2.0: Server-side, VOMS uses GSI for validation. This means that if you run voms against gt2, contacting it with a gt4 proxy will fail. There is a final argument in the vomses file which specifies which version of GT the service uses, and adapts the proxies used to contact it accordingly. Many VOs distribute an incorrect vomses file. The final proxy obtained as output by voms-proxy-init will always be what you requested, in this case a rfc proxy. VOMS 2.0 onwards: Globus dependencies on the server will be dropped too (They are corrently removed from both the clients and the APIs). This will mean that any kind of proxy, or even a bare certificate, will become acceptable for contacting the service. The whole vomses config business above will no longer be relevant. VOMS 2.0 is due to be out during autumn this year. Ciao, Vincenzo
Hi, very valuable information - probably another reason for sticking to GSI unfortunately in the production space...
- VOMS 2.0 is due to be out during autumn this year.
What is the chance that this VOMS 2.0 get a huge deployment in EGEE then?! Thanks, Morris ------------------------------------------------------------ Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel "We work to better ourselves, and the rest of humanity" Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender)
------Original Message----- -From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of -Vincenzo Ciaschini -Sent: Wednesday, April 08, 2009 12:07 PM -To: Etienne URBAH -Cc: aleksandr.konstantinov@fys.uio.no; edges-na3@mail.edges-grid.eu; -lodygens@lal.in2p3.fr; pgi-wg@ogf.org -Subject: Re: [Pgi-wg] OGF PGI - Security Model - NEW versions of GSI acceptRFC- -3820-compliant X509 proxies - -Hi Etienne, -Etienne URBAH wrote: -> Still to be verified is that VOMS servers only accept GSI-style X509 -> proxies http://forge.gridforum.org/sf/go/doc15591?nav=1 -VOMS accepts and generates both type of proxies. However, there is a -caveat, which explains the failures you get: - -Pre VOMS 2.0: -Server-side, VOMS uses GSI for validation. This means that if you run -voms against gt2, contacting it with a gt4 proxy will fail. - -There is a final argument in the vomses file which specifies which -version of GT the service uses, and adapts the proxies used to contact -it accordingly. Many VOs distribute an incorrect vomses file. - -The final proxy obtained as output by voms-proxy-init will always be -what you requested, in this case a rfc proxy. - -VOMS 2.0 onwards: -Globus dependencies on the server will be dropped too (They are -corrently removed from both the clients and the APIs). This will mean -that any kind of proxy, or even a bare certificate, will become -acceptable for contacting the service. The whole vomses config business -above will no longer be relevant. - -VOMS 2.0 is due to be out during autumn this year. - -Ciao, - Vincenzo -_______________________________________________ -Pgi-wg mailing list -Pgi-wg@ogf.org -http://www.ogf.org/mailman/listinfo/pgi-wg
Having to build adapters to translate (if possible) credentials in different formats is a compromise which is more reasonable than having to wait for all the middlewares of the world to move towards a common security infrastructure.
In the short term... documenting and defining the 2 or 3 security models is real progress. If a service only supports one of these I do not see this as a problem - for all the reasons given. Providing credential translation services to provide 'shims' (or bridges between these islands) as an interim solution makes this work. Its a low risk to individual services - they maintain their current stability - and can migrate over time to support both or the most 'popular' one - let the market decide! Each service can then advertise the mechanisms it supports and clients can locate credential translation services as required.
Hi interop-friends, firstly sorry again for missing the last days. I have seen many comments since then and unfortunately see that the different threads had been united again mixing things up a bit (maybe it was nevertheless useful). Finally Steven made a good point with 2-3 sec. models out of n^n ones. So finally we have reached to the ideas of my suggestions of having well-defined different security 'plumbings' (aka 2-3 well-defined security models). I don't care about its precise name... I just used this term 'plumbings' because it had no pre-definition in security, please compare the vertical lines in the interoperability reference model - they are just more simpler defined in terms of AUTHN and ATTRIBUTE-AUTHZ than the long list presented by Etienne but very much of its content is the same. I presented this since OGF23&OGF24 within GIN with the two ways (left AC and right SAML) and the open issues to work on, but never had chance to write it down in written text yet: http://www.ogf.org/OGF24/materials/1409/2008-09-16_GIN_SessionTwo_OGF24_Ried el_v1.pdf Slide 6 and others... :-) Especially on this slide 6, even outsiders of our production Grids (like Chris Smith) understood the meaning of the slide and I got positive feedback on this from numerous sides. We all want to reach interoperability here in this group. We want to do this for certain interop applications. We shouldn't underestimate the power of the combination of the different security elements - nailing down the currently typical ways of using TLS with certs, Attr-Authz, Attributes, Constraints/Restrictions in conjunction are already powerful. We will have precise PGI definition of aligning such building blocks even if there are two ways in the end - but there are less than n^n ways that are currently out there in the security field combining different blocks, profiles, etc.... Also, what the middleware supports and what is then deployed in turn on particular production Grids are both different stories! For instance, UNICORE can be used with the proxy-style (plumbing) enabling interoperability with gLite, ARC, NAREGI. We have done this for many interop use cases, for instance with portals requiring proxies. However, there should be also another full X.509 (plumbing) available where other common approaches can be used and then expressed correctly via GLUE in interops as well used other infrastructures with different policies. I even foresee that there could be used more than one plumbing in parallel. We may have still single islands in a way - but we also come closer together, which is a good first step towards the right direction and my suggestion to move forward in this complex security discussion since its beginning. Which particular plumbings of both common approaches are then used in production Grids is policy of the respective deployments of the middlewares and may even depend on the underlying interop application use cases which should be our most significant drivers (!) - BUT the main point is that we know where we talking about in interop work without having n ^ n different security setups available! Only one short example: # There is one DB with attribute information about of end-users (used by VOMS) # Agreeing on the attribute semantics&Structure is important # VOMS support interface for retrieving AC and also SAML assertions # There are two ways of transporting the attributes that come out of the same DB (used for later attr-authZ) # Both transports have correct AuthN mechanisms (clarifies AuthN+ID-authZ) # In the end using different plumbings, but the same attributes are then evaluated against a policy describing maybe having equal policies based on the same transported attributes of the same DB (re-alignment!) # In the end what matter are the attributes a user has and what the policy decides to do with them (if its XACML, ACLs, etc. is unimportant here), but we should talk about the same things once we evaluate attributes. I try to provide you more figures, etc. hopefully tomorrow - but on my slides a lot of it has been already presented numerous times... we just have to nail it down - but in a more KISS style = Keep in Simple and Sweet/Stupid! Your co-chair, Morris ------------------------------------------------------------ Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel "We work to better ourselves, and the rest of humanity" Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender)
------Original Message----- -From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of -Steven Newhouse -Sent: Thursday, March 26, 2009 7:16 PM -To: Moreno Marzolla; Duane Merrill -Cc: pgi-wg@ogf.org; edges-na3@mail.edges-grid.eu; lodygens@lal.in2p3.fr -Subject: Re: [Pgi-wg] OGF PGI - Security Model - -> Having to build -> adapters to translate (if possible) credentials in different formats -is -> a compromise which is more reasonable than having to wait for all the -> middlewares of the world to move towards a common security -> infrastructure. - -In the short term... documenting and defining the 2 or 3 security models -is real progress. If a service only supports one of these I do not see -this as a problem - for all the reasons given. Providing credential -translation services to provide 'shims' (or bridges between these -islands) as an interim solution makes this work. Its a low risk to -individual services - they maintain their current stability - and can -migrate over time to support both or the most 'popular' one - let the -market decide! - -Each service can then advertise the mechanisms it supports and clients -can locate credential translation services as required. -_______________________________________________ -Pgi-wg mailing list -Pgi-wg@ogf.org -http://www.ogf.org/mailman/listinfo/pgi-wg
On Thu, Mar 26, 2009 at 7:16 PM, Steven Newhouse <Steven.Newhouse@cern.ch>wrote:
Having to build adapters to translate (if possible) credentials in different formats is a compromise which is more reasonable than having to wait for all the middlewares of the world to move towards a common security infrastructure.
In the short term... documenting and defining the 2 or 3 security models is real progress. If a service only supports one of these I do not see this as a problem - for all the reasons given.
I do agree with this point here. But I would propose a question: What is the purposed of PGI? Does it only conclude all of the popular middlewares and propose a few conclusive profiles? Or does it give some proposal which is as general as possible, and needs those middlewares to change as minimal as possible? If the former one is the case, I agree with the "bridging" idea. And it is also what ARC has done and is doing: Trying to implementing some specific clients which can interoperate with those services hosted by different kinds of middlewares that require different security mechanisms. For instance, for interoperability with CREAM service, the client developed in ARC need firstly to contact the CREAM delegation service and delegate a proxy credential to that service, and secondly send real BES message to CREAM service together with the delegation ID which is got from the first step. The CREAM service itself will implicitly get the proxy credential by using the delegation ID, and then act on behalf of the client. Weizhong Qiang
Providing credential translation services to provide 'shims' (or bridges between these islands) as an interim solution makes this work. Its a low risk to individual services - they maintain their current stability - and can migrate over time to support both or the most 'popular' one - let the market decide!
Each service can then advertise the mechanisms it supports and clients can locate credential translation services as required. _______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
Etienne, As you alluded to, some applications (such as the CREAM BES and some types of Genesis II BESes) require that some operations (e.g., "submit job") be preceded by an application-level delegation operation. The ability for a client implementation to detect and then perform a delegation pre-step will be a significant departure for infrastructures that do not initiate chained delegation. To assist this, we should include in the roadmap steps for: - Standardizing on a delegation interface (e.g., something that resembles WS-Trust STS, or ARC delegation service, etc.) - Devising a way of advertising whether or not a resource needs a delegation pre-step. We could do this via EPRs (which would then possibly be distributed via information services). -Duane
On Monday 23 March 2009 19:57, Etienne URBAH wrote:
To All,
I thank Duane MERRIL for his 'Profile on Secure Communication' strawman.
But, since today's mail of Vincenzo CIASCHINI asserting interoperability between recent versions of OpenSSL and GSI, I do NOT think that communication layers are the main isue blocking interoperability.
I propose that instead focusing on communication services, we focus on security data defined, on security data transported, and on the interpretation of security data by AUTHN/AUTHZ services.
So, I propose to criticize following assertions :
1) Grid Users and Certificate Authorities ----------------------------------------- 1.1) Each grid User is authenticated by a legal body (recognized by a government).
1.2) This legal body uses a Certificate Authority to grant a (long lived) X509 certificate to the grid User.
1.3) Each Certificate Authority is itself or is authenticated by a self-signed Root Certificate Authority.
1.4) All such Root Certificate Authorities trust each other and cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management Authorities).
1.5) These 3 Policy Management Authorities trust each other and cooperate within IGTF.
1.6) IGTF distributes the list of CA Certificates to be trusted.
1.7) Each grid Site providing grid Services to grid Users MUST install this list of CA Certificates and keep it up to date.
1.8) Using its X509 certificate, each grid User can create at any time a (short lived) X509 proxy with permits impersonation / delegation during a short period.
2) Virtual Organizations ------------------------- 2.1) A Virtual Organization (VO) groups grid Users with common goals. A VO is NOT a legal body, can NOT be a Certificate Authority, and can NOT issue X509 certificates.
2.2) Inside DEISA, a Virtual Community also groups grid Users with common goals. The relationships between Virtual Communities and Virtual Organizations has to be precised by Morris RIEDEL.
2.3) Each grid User belongs to 1 ore more VO (Virtual Organization), which grants him access rights to grid Storage and Computing Ressources.
I would bery much like to criticize this statement as there will always be some small user groups or individual users who wouldn't want take care of burden of setting up a VO.
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) 2.4.2) SAML assertions
3) Grid Services : Information, AUTHN, AUTHZ ---------------------------------------------- 3.1) Each grid Infrastucture provides an Information Service, with describes the Infrastructure according the the GLUE2 schema.
3.2) Each grid User can query this Information Service anonymously in order to know which security protocol he has to use to submit requests to grid Services.
I disagree with "anonymously". Some infrastructures may rate that information as confidential.
3.3) Each grid User can directly access data hosted by grid Storage Services. For Authentication, the grid User can present the public part of his X509 certificate or X509 proxy. For Authorization, the grid User can present : 3.3.1) the public part of his VOMS proxy, or 3.3.2) a bag of SAML assertions.
I see no reason why only these 2 options should be allowed for authorization decisions. I do support idea of attribute based authorization. But can't understand why other information authenticating the client should be disallowed from making authorization decision.
3.4) Each grid User can submit Jobs to grid Computing Services. If such a Job needs access to data hosted by grid Storage Services, then the grid User must provide a delegation token. This delegation token can be : 3.4.1) a full VOMS proxy, or 3.4.2) a bag of SAML assertions.
What is "full ... proxy" ? And why only VOMS? Why can't my users use ordinary proxies? Or restricted proxies with for example policies embedded (as defined in RFC3820)?
4) Consequences for Interoperability ------------------------------------- 4.1) X509 proxies MUST fully comply to RFC 3820.
4.2) VOMS services, which deliver X509 proxies with VOMS extensions, MUST fully comply to RFC 3820.
4.3) The authentication library used by grid Services MUST fully comply to RFC 3820 (for example a recent version of OpenSLL), so that it can accept as well X509 certificates as X509 proxies.
4.4) Each grid Site providing grid Services to grid Users MUST install files describing VOMS authorizations and other authorizations, and keep them up to date.
What are "files describing ... authorizations"?
4.5) The semantics of Authorization tokens MUST be the same for all grid Infrastructures : 4.5.1) VOMS extensions 4.5.2) Restriction attributes
4.6) The Information Service of each grid Infrastructure MUST describe, for each grid Service, which Authorization tokens this Service understands (potentially several) : 4.6.1) VOMS extensions 4.6.2) X509 restriction attributes 4.6.3) SAML assertions
4.7) For SAML assertions, the Information Service of each grid Infrastructure MUST describe, for each grid Service, how they are transported : 4.7.1) As attributes of X509 proxies 4.7.2) Inside a SOAP header
Unfinished ...
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@lal.in2p3.fr ----------------------------------
Aleksandr, could you give me one example for this:
- I do support idea of attribute based authorization. But can't understand why other information authenticating the client should be disallowed from making authorization decision.
I seek to understand what you mean. Thanks, Morris ------------------------------------------------------------ Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel "We work to better ourselves, and the rest of humanity" Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender)
------Original Message----- -From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of -Aleksandr Konstantinov -Sent: Friday, March 27, 2009 11:02 AM -To: pgi-wg@ogf.org -Subject: Re: [Pgi-wg] OGF PGI - Security Strawman - -On Monday 23 March 2009 19:57, Etienne URBAH wrote: -> To All, -> -> I thank Duane MERRIL for his 'Profile on Secure Communication' strawman. -> -> But, since today's mail of Vincenzo CIASCHINI asserting interoperability -> between recent versions of OpenSSL and GSI, I do NOT think that -> communication layers are the main isue blocking interoperability. -> -> I propose that instead focusing on communication services, we focus on -> security data defined, on security data transported, and on the -> interpretation of security data by AUTHN/AUTHZ services. -> -> -> So, I propose to criticize following assertions : -> -> -> 1) Grid Users and Certificate Authorities -> ----------------------------------------- -> 1.1) Each grid User is authenticated by a legal body (recognized by a -> government). -> -> 1.2) This legal body uses a Certificate Authority to grant a (long -> lived) X509 certificate to the grid User. -> -> 1.3) Each Certificate Authority is itself or is authenticated by a -> self-signed Root Certificate Authority. -> -> 1.4) All such Root Certificate Authorities trust each other and -> cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management -> Authorities). -> -> 1.5) These 3 Policy Management Authorities trust each other and -> cooperate within IGTF. -> -> 1.6) IGTF distributes the list of CA Certificates to be trusted. -> -> 1.7) Each grid Site providing grid Services to grid Users MUST install -> this list of CA Certificates and keep it up to date. -> -> 1.8) Using its X509 certificate, each grid User can create at any time -> a (short lived) X509 proxy with permits impersonation / delegation -> during a short period. -> -> -> 2) Virtual Organizations -> ------------------------- -> 2.1) A Virtual Organization (VO) groups grid Users with common goals. -> A VO is NOT a legal body, can NOT be a Certificate Authority, and can -> NOT issue X509 certificates. -> -> 2.2) Inside DEISA, a Virtual Community also groups grid Users with -> common goals. The relationships between Virtual Communities and Virtual -> Organizations has to be precised by Morris RIEDEL. -> -> 2.3) Each grid User belongs to 1 ore more VO (Virtual Organization), -> which grants him access rights to grid Storage and Computing Ressources. - -I would bery much like to criticize this statement as there will always be some -small user groups or individual users who wouldn't want take care of burden -of setting up a VO. - -> -> 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) -> 2.4.2) SAML assertions -> -> -> 3) Grid Services : Information, AUTHN, AUTHZ -> ---------------------------------------------- -> 3.1) Each grid Infrastucture provides an Information Service, with -> describes the Infrastructure according the the GLUE2 schema. -> -> 3.2) Each grid User can query this Information Service anonymously in -> order to know which security protocol he has to use to submit requests -> to grid Services. - -I disagree with "anonymously". Some infrastructures may rate that information -as confidential. - -> -> 3.3) Each grid User can directly access data hosted by grid Storage -> Services. For Authentication, the grid User can present the public part -> of his X509 certificate or X509 proxy. For Authorization, the grid User -> can present : -> 3.3.1) the public part of his VOMS proxy, or -> 3.3.2) a bag of SAML assertions. - -I see no reason why only these 2 options should be allowed for authorization -decisions. -I do support idea of attribute based authorization. But can't understand why other -information authenticating the client should be disallowed from making authorization -decision. - -> -> 3.4) Each grid User can submit Jobs to grid Computing Services. If -> such a Job needs access to data hosted by grid Storage Services, then -> the grid User must provide a delegation token. This delegation token -> can be : -> 3.4.1) a full VOMS proxy, or -> 3.4.2) a bag of SAML assertions. - -What is "full ... proxy" ? And why only VOMS? Why can't my users use ordinary -proxies? -Or restricted proxies with for example policies embedded (as defined in RFC3820)? - -> 4) Consequences for Interoperability -> ------------------------------------- -> 4.1) X509 proxies MUST fully comply to RFC 3820. -> -> 4.2) VOMS services, which deliver X509 proxies with VOMS extensions, -> MUST fully comply to RFC 3820. -> -> 4.3) The authentication library used by grid Services MUST fully comply -> to RFC 3820 (for example a recent version of OpenSLL), so that it can -> accept as well X509 certificates as X509 proxies. -> -> 4.4) Each grid Site providing grid Services to grid Users MUST install -> files describing VOMS authorizations and other authorizations, and keep -> them up to date. - -What are "files describing ... authorizations"? - -> -> 4.5) The semantics of Authorization tokens MUST be the same for all -> grid Infrastructures : -> 4.5.1) VOMS extensions -> 4.5.2) Restriction attributes -> -> 4.6) The Information Service of each grid Infrastructure MUST describe, -> for each grid Service, which Authorization tokens this Service -> understands (potentially several) : -> 4.6.1) VOMS extensions -> 4.6.2) X509 restriction attributes -> 4.6.3) SAML assertions -> -> 4.7) For SAML assertions, the Information Service of each grid -> Infrastructure MUST describe, for each grid Service, how they are -> transported : -> 4.7.1) As attributes of X509 proxies -> 4.7.2) Inside a SOAP header -> -> Unfinished ... -> -> -> 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@lal.in2p3.fr -> ---------------------------------- -> -_______________________________________________ -Pgi-wg mailing list -Pgi-wg@ogf.org -http://www.ogf.org/mailman/listinfo/pgi-wg
participants (12)
-
Aleksandr Konstantinov -
David Wallom -
Duane Merrill -
Etienne URBAH -
Jens Jensen -
Laurence Field -
Moreno Marzolla -
Morris Riedel -
Oxana Smirnova -
Steven Newhouse -
Vincenzo Ciaschini -
weizhong qiang