[Pgi-wg] OGF PGI - Security Strawman

Tue Mar 24 04:31:28 CDT 2009

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

> -----Original Message-----
> From: pgi-wg-bounces at ogf.org [mailto:pgi-wg-bounces at ogf.org] On Behalf
> Of Oxana Smirnova
> Sent: 24 March 2009 00:10
> To: Etienne Urbah
> Cc: pgi-wg at ogf.org; Vincenzo Ciaschini; edges-na3 at mail.edges-grid.eu;
> lodygens at 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,
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 at ogf.org
> http://www.ogf.org/mailman/listinfo/pgi-wg