[Pgi-wg] OGF PGI - Security Strawman

Fri Mar 27 05:24:51 CDT 2009

Aleksandr,

  could you give me one example for this:

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

I seek to understand what you mean.

Thanks,
Morris

------------------------------------------------------------
Morris Riedel
SW - Engineer
Distributed Systems and Grid Computing Division
Jülich Supercomputing Centre (JSC)
Forschungszentrum Juelich
Wilhelm-Johnen-Str. 1
D - 52425 Juelich
Germany

Email: m.riedel at fz-juelich.de
Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel
Phone: +49 2461 61 - 3651
Fax: +49 2461 61 - 6656

Skype: MorrisRiedel

"We work to better ourselves, and the rest of humanity"

Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), 
Dr. Ulrich Krafft (stellv. Vorsitzender)

>------Original Message-----
>-From: pgi-wg-bounces at ogf.org [mailto:pgi-wg-bounces at ogf.org] On Behalf Of
>-Aleksandr Konstantinov
>-Sent: Friday, March 27, 2009 11:02 AM
>-To: pgi-wg at ogf.org
>-Subject: Re: [Pgi-wg] OGF PGI - Security Strawman
>-
>-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
>-> ----------------------------------
>->
>-_______________________________________________
>-Pgi-wg mailing list
>-Pgi-wg at ogf.org
>-http://www.ogf.org/mailman/listinfo/pgi-wg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3550 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20090327/407c474a/attachment.bin 