[Pgi-wg] OGF PGI - Security Strawman

Mon Mar 23 15:47:31 CDT 2009

Etienne,

Wow, you have reproduced the Strawman document perfectly, albeit in a higher
level of description.  The intent of the Strawman document is to focus
precisely on the security data transported (i.e., issues that affect wire
format), including syntax definitions for for attributes (SAML and VOMS-like
ACs) so that they may carry the same information.

The only differences between your text below and the Strawman are that you
discuss several non "data-defined" issues that, while mentioned by Strawman,
were considered out of scope:

   - Strawman abstracted away the notion of an Information Service by
   describing the format of endpoint reference documents(EPRs) that describe
   security requirements/expectations.  (This EPR information *might *be
   returned by such hypothetical informational services, or by other
   means.  Hence the Strawman was focusing on security-data defined, as per
   your outset motivation.)
   - Strawman considered the establishment of trust roots as out of scope.
   As you (and the Strawman) mention, such trust must be configured, but is not
   germane to the data *communicated* during a simple request-response
   exchange.
   - Strawman considered the provision of delegation token(s) to a service
   (e.g., BES) as out of scope.  As you (and the Strawman) mention,
   it generally must be done for certain agent-style services, but through
   an "application" layer (e.g., through WS-Trust STS interface, etc.).  The
   Strawman discusses how a client (e.g., an agent-BES) would communicate with
   delegated credentials, not how it obtains them.

I just have one question for you: precisely how is (3.4.2) delegation
accommodated using SAML assertions?  (A delegation chain must exist
somewhere, and it could be achieved by using a proxy certificate -- the EEC
of which is asserted in the SAML attribute -- to sign SOAP messages bodies.
Is this what you were envisioning?  Or does Unicore not envision the true
delegation of SAML attributes.....)

-Duane

2009/3/23 Etienne URBAH <urbah at lal.in2p3.fr>

> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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 --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/pgi-wg/attachments/20090323/5263e9f1/attachment-0001.html 