[Pgi-wg] OGF PGI - Security Strawman

[Oxana Smirnova]

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