[Pgi-wg] OGF PGI - Security Strawman

Tue Mar 24 03:41:10 CDT 2009

Looking through this though I would assert that the limitations to just long
lived X509 seems not in keeping with for example the ongoing discussions
about trusting Shibboleth generated certs etc??

I have just been speaking to the security person from our NREN who
specifically mentioned that Shib tokens across national boundaries is
becoming essential and will be subject to an IGTF type body pretty soon.

David

On 23/03/2009 23:09, "Oxana Smirnova" <oxana.smirnova at hep.lu.se> wrote:

> 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