[Pgi-wg] OGF PGI - Security Model

[Etienne URBAH]

Duane,


Thank you for your comments.  Please find the original text and my 
answers inline.


Beyond that :

7.9) Semantics and syntax of VOMS extensions and Restriction attributes
-----------------------------------------------------------------------
I would like to describe (for example in new section 7.9) the semantics 
and syntax of a RESTRICTED list of VOMS extensions and Restriction 
attributes that all grid clients MAY use and that all grid services MUST 
understand.

Does anybody have links to such lists ?

-  For VOMS extension, the example below gives :
    VO,  subject,  issuer,  attribute,  timeleft,  uri

-  For other attributes, here is something springing out from my 
imagination, with semantics and syntax (please criticize) :
    -  Assertion of identity :               ID:<FQAN>
    -  Assertion of belonging to a group :   GROUP:<FQAN>
    -  Authorization to access a resource :  ALLOW:<URI>
    -  Interdiction  to access a resource :  DENY:<URI>
    -  Authorization to read a file (or a folder, recursively :
                                             ALLOW_R:<URI>
    -  Authorization to write into a file (or a folder, recursively :
                                             ALLOW_W:<URI>
    -  Authorization to read and write into a file (or a folder, 
recursively :                               ALLOW_RW:<URI>
    Note that GLUE 2.0 recommends that the URI should be an URN.


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


On Duane Merrill wrote:
> Looks like a good foundation.  A couple of comments/suggestions:
> 
>> 7.1)  The semantics of Authorization tokens MUST be the same for all grid Infrastructures :
>>       7.1.1)  VOMS extensions
>>       7.1.2)  Restriction attributes
>  This section discusses the necessity for shared-semantics amongst 
>  authorization token formats.  Instead of "VOMS extensions", which 
>  is unclear what that means, I think you mean "FQAN-equivalent 
>  semantics for describing VO groups/roles."

VOMS extensions of X509 proxies are NOT a simple FQAN.  See following 
example, extracted from ' voms-proxy-info -all' on a gLite UI :

=== VO vo.lal.in2p3.fr extension information ===
VO        : vo.lal.in2p3.fr
subject   : /O=GRID-FR/C=FR/O=CNRS/OU=LAL/CN=Etienne Urbah
issuer    : /O=GRID-FR/C=FR/O=CNRS/OU=LAL/CN=grid12.lal.in2p3.fr
attribute : /vo.lal.in2p3.fr/Role=NULL/Capability=NULL
timeleft  : 11:59:50
uri       : grid12.lal.in2p3.fr:20000

I agree that we have to describe the full list of VOMS extensions with 
their meaning and syntax (or provide a link to the relevant VOMS 
specification).


>> 7.2)  The Information Service of each grid Infrastructure MUST describe, for each grid Service, the security requirements for access to the grid Service, and which Authorization Tokens this Service expects (potentially several) :
>>       7.2.1)  X509 VOMS extensions
>>       7.2.2)  X509 restriction attributes
>>       7.2.3)  SAML assertions
>  If we have the semantic equivalences described in (7.1), then the 
>  incoming message-processing stack of a PGI-compliant service endpoint 
>  should be able process all three types of client-credentialing 
>  mechanisms equivalently:
> 
>  o Clients supply SAML attributes authenticated by End-Entity 
>    Certificates at the SOAP level (/Idealized Unicore/)
>  o Clients supply SAML attributes authenticated by 
>    Proxy-Certificates at the SOAP level (/Idealized Genesis II/)
>  o Clients supply VOMS-style Attribute Certificates authenticated by 
>    (and embedded within) Proxy Certificates at the SSL/TLS level 
>    (/Idealized gLite/ARC/Naregi/)
> 
>  By the time message-processing reaches a policy-decision module, the 
>  service has distilled an authenticated set of distinguished names, 
>  FQAN groups/roles, and restriction policies that look the same, 
>  independent of how they were supplied.      By mandating 
>  a "receiver-makes-right" strategy (section 7.7), you obviate the 
>  complexity of sections (7.3) and (7.5).  Such reduced complexity 
>  affords us a quicker incremental roadmap in which clients can remain 
>  largely unchanged, while additional infrastructure complexity is 
>  only initially needed at those service endpoints intended for 
>  advertisement within multiple infrastructures. 

You can obviate the complexity of sections 7.3 and 7.5 only if section 
7.7 is mandatory (with a 'MUST' wording), which means you force every 
middleware to implement immediately the 3 types of Authorization tokens.

In fact, you can NOT force that.  This is the reason why I used the 
'SHOULD' wording in section 7.7, and this forces the Information System 
to provide the list of Authorization tokens and transport methods really 
accepted by each grid Service.


>> 7.4)  Each grid Site providing grid Services to grid Users MUST install and keep up to date a robust Authorization Service describing VOMS authorizations, other authorizations, and mapping of known VO members to local UIDs.
>  Be careful with your language: do not mandate the management 
>  of authz/authn information not relevant to inter-grid interaction. 
>  (E.g., Genesis II does not make use of local-UID mappings).   

You are right, I will replace the reference to local-UID mappings by 
something more general.


>  The document is missing a brief consensus on SOAP-over-HTTPS 
>  communication that mandates a specific variant of SSL/TLS (i.e., 
>  anything that implements RFC-2246, The TLS Protocol Version 1.0, 
>  which excludes GSI-OpenSSH.)

I do NOT have enough knowledge about WS, SOAP and RFC-2246 to write 
something sensible.  Can you write it yourself ?


>   -Duane  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4919 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20090325/01fb1a77/attachment.bin