[Pgi-wg] OGF PGI - Security Model
Aleksandr Konstantinov
aleksandr.konstantinov at fys.uio.no
Sat Mar 28 10:10:13 CDT 2009
On Saturday 28 March 2009 06:34, Duane Merrill wrote:
> If the PGI working group wants to describe "compliance with GSI" (as
> is mentioned in several places above, e.g., 5.3, 5.4, 7.3, etc.), then
> the working group MUST reference or produce a publication that defines
> what GSI Compliance means.
>
> Also, you may have to spend a lot of political capital to get
> agreement on the GLUE schema as a way of describing and discovering
Glue schema is for describing only. It is not meant for discovering.
A.K.
> secure communication requirements, particularly since
> WS-SecurityPolicy exists as an OASIS recommendation for doing just
> that. You may want to reconsider the mandates of a 6, as it will
> likely turn into a sticking point.
>
> Duane
>
>
>
> > On 3/27/09, Etienne URBAH <urbah at lal.in2p3.fr> 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
> >>
> >>
> >> 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 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