[Pgi-wg] OGF PGI - Security Model - X509 proxies are really incompatible
Aleksandr Konstantinov
aleksandr.konstantinov at fys.uio.no
Sun Apr 5 16:50:00 CDT 2009
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-SAMLTokenProfile.pdf
>
> 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 at 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 at 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 at lal.in2p3.fr
> >>> ----------------------------------
>
More information about the Pgi-wg
mailing list