[Pgi-wg] OGF PGI - Security Model - X509 proxies are really incompatible
Duane Merrill
dgm4d at virginia.edu
Sun Apr 5 23:26:23 CDT 2009
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 at 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-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
>> >>> ----------------------------------
>>
> _______________________________________________
> Pgi-wg mailing list
> Pgi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/pgi-wg
>
More information about the Pgi-wg
mailing list