[Pgi-wg] OGF PGI - Security Strawman

[Aleksandr Konstantinov]

On Monday 23 March 2009 19:57, Etienne URBAH wrote:
> To All,
> 
> I thank Duane MERRIL for his 'Profile on Secure Communication' strawman.
> 
> But, since today's mail of Vincenzo CIASCHINI asserting interoperability 
> between recent versions of OpenSSL and GSI, I do NOT think that 
> communication layers are the main isue blocking interoperability.
> 
> I propose that instead focusing on communication services, we focus on 
> security data defined, on security data transported, and on the 
> interpretation of security data by AUTHN/AUTHZ services.
> 
> 
> So, I propose to criticize following assertions :
> 
> 
> 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.
> 
> 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.
> 
> 
> 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.
> 
> 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.

I would bery much like to criticize this statement as there will always be some
small user groups or individual users who wouldn't want take care of burden
of setting up a VO.

> 
> 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)  Each grid Infrastucture provides an Information Service, with 
> describes the Infrastructure according the the GLUE2 schema.
> 
> 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.

I disagree with "anonymously". Some infrastructures may rate that information
as confidential.

> 
> 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.

I see no reason why only these 2 options should be allowed for authorization decisions.
I do support idea of attribute based authorization. But can't understand why other 
information authenticating the client should be disallowed from making authorization
decision.

> 
> 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.

What is "full ... proxy" ? And why only VOMS? Why can't my users use ordinary proxies?
Or restricted proxies with for example policies embedded (as defined in RFC3820)?

> 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.

What are "files describing ... authorizations"?

> 
> 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 ...
> 
> 
> 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
> ----------------------------------
>