[Pgi-wg] OGF PGI - Security Model - NEW versions of GSI accept RFC-3820-compliant X509 proxies
Etienne URBAH
urbah at lal.in2p3.fr
Tue Apr 14 13:13:36 CDT 2009
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/Vocabulary
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-SAMLTokenProfile.pdf
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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5060 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20090414/a5cf67b8/attachment.bin
More information about the Pgi-wg
mailing list