[Pgi-wg] Security Models for Grid Infrastructures : IGTF, InCommon, XCG

Mon Nov 15 12:35:55 CST 2010

Duane, Andrew and David,

Concerning security models for grid infrastructures :

In her today's mail concerning 'OGF PGI - Chart of priorities', Oxana 
SMIRNOVA complains that inside OGF PGI, 'we reduced security and ... to 
non-priority areas' and 'we still have no common security frameworks'.

A basic requirement for any client-server operation is that clients have 
to know which credentials they have to present to each service.

So, when writing down the detailed specifications for PGI requirements 
1, 4 and 163, which impact ALL grid functionalities, it is immediately 
clear that each service MUST publish the detailed client interface of 
its security setup.

So, the fact that 'we still have no common security frameworks' is 
simply BLOCKING, and I agree with Oxana that WE have to solve this issue.

Currently, I have heard of 3 security models for grid infrastructures :

For real world-wide grid interoperation, we must take into account NOT 
ONLY the well known IGTF security model, BUT ALSO the InCommon and XCG 
security models (which are less known, especially in Europe).

IGTF  (International Grid Trust Federation)
-------------------------------------------
The IGTF security model is used by all grid infrastructures powered by 
at least Globus, ARC, gLite and Unicore.

It is perhaps rigid and heavyweight, but it really works, and is so 
widespread all around the earth that I personally see it as a de facto 
standard.

Therefore, I have worked in order to understand it well, and I present 
it as a PGI use case at http://forge.gridforum.org/sf/go/doc16010?nav=1 
(including a collaboration diagram).

Can David KELSEY please check the accuracy of this document ?

InCommon
--------
 From the presentations available at 
http://indico.rnp.br/getFile.py/access?contribId=4&amp;sessionId=2&amp;resId=0&amp;materialId=slides&amp;confId=85 
http://indico.rnp.br/getFile.py/access?contribId=1&amp;sessionId=2&amp;resId=0&amp;materialId=slides&amp;confId=85 
and further oral explanations, I understand that :

-  Like IGTF, InCommon is a FEDERATION based on common trust.

-  InCommon is a CA able to issue SSL and personal X509 certificates, 
and the own X509 certificate of InCommon is accepted as CA certificate 
by InCommon members.

-  Shibboleth permits to convert the campus identity of an user into 
standard SAML assertions,

-  InCommon permits to convert these SAML assertions into an 
'Silver-grade InCommon' X509 certificate, which is directly accepted 
across all InCommon participants,

-  CILogon (probably as MICS) permits to convert an InCommon 
Silver-grade certificate to an X.509 certificate, which will be accepted 
by all Grid infrastructures trusting IGTF when CILogon will obtain 
accreditation by TAGPMA.

Can you please check if this is accurate ?

XCG  (Cross Campus Grid, using Genesis II)
------------------------------------------
Currently, I do NOT know if the XCG security model is exactly the same 
as the InCommon security model, or if there are differences.

As stated in my mail below dated 21 September 2010, I do NOT fully 
understand the 'Genesis-II Security Implementation' document available 
at http://forge.gridforum.org/sf/go/doc15435?nav=1

XCG clearly uses a Genesis II security middleware stack based on 
WS-Security, but the trust anchor is NOT clear.

During oral discussions, I heard that Genesis II is able to :

-  Receive the campus identity of a user as credentials,

-  From these credentials, extract, calculate or guess the adequate URL 
+ protocol of the security server of the user's campus, and contact it 
in order to verify the credentials,

-  If OK, generate a delegated credential which will be correctly 
recognized by the security setup of the resource where the user job is 
scheduled to be executed.

Andrew and Duane, can you PLEASE check the accuracy of this, and provide 
workable information ?

Human software engineers need to see at least following information :
-  Operational model :  who is responsible for what ?
-  Data model :  which messages are exchanged, and what is their meaning ?
-  Sequence model :  what is the sequence of exchanged messages and 
operations ?
-  Detailed protocol artifacts, such as WSDL files (usable only by 
SOAP), are much less useful.

Conclusion
----------
European stakeholders really want real world-wide grid interoperation, 
and would really like to take into account NOT ONLY the well known IGTF 
security model, BUT ALSO the InCommon security model (which is less 
known, especially in Europe) and the XCG security model (which is NOT 
understood in Europe).

This requires that US stakeholders take the pain of precisely explaining 
their security model(s).

Thank you very much in advance for your help.

Best regards.

-----------------------------------------------------
Etienne URBAH         LAL, Univ Paris-Sud, IN2P3/CNRS
                       Bat 200   91898 ORSAY    France
Tel: +33 1 64 46 84 87      Skype: etienne.urbah
Mob: +33 6 22 30 53 27      mailto:urbah at lal.in2p3.fr
-----------------------------------------------------

On Fri, 08/10/2010 03:04, Etienne URBAH wrote:
> Alan, Duane and Andrew,
>
> Concerning Cloud / Grid Security,
>
> Lot of thanks to Alan SILL for the link
> http://indico.rnp.br/conferenceDisplay.py?confId=85 to the Symposium on
> Authentication Technologies held at Texas Tech University on 04 October
> 2010.
>
> I have read the presentations, and I hope to have understood most of them.
>
> In particular, I have been most interested by the 2 following
> presentations :
>
> - InCommon
> http://indico.rnp.br/getFile.py/access?contribId=4&amp;sessionId=2&amp;resId=0&amp;materialId=slides&amp;confId=85
>
>
> - CILogon
> http://indico.rnp.br/getFile.py/access?contribId=1&amp;sessionId=2&amp;resId=0&amp;materialId=slides&amp;confId=85
>
>
>
> As far as I understand :
>
> - The trust anchors are :
> - InCommon for SSL and personal certificates
> - IGTF for X509 certificates
>
> - Shibboleth permits to convert the campus identity of an user into
> standard SAML assertions,
>
> - InCommon permits to convert these SAML assertions into an InCommon
> Silver-grade certificate, which is directly accepted across all InCommon
> participants,
>
> - CILogon (probably as MICS) permits to convert an InCommon Silver-grade
> certificate to an X.509 certificate, which will be accepted by all Grid
> infrastructures trusting IGTF when CILogon will obtain accreditation by
> TAGPMA.
>
> Can Alan confirm ?
>
>
> If fully implemented, the above security setup would immediately provide
> realistic answers to the questions which I asked inside the mail below
> to the Genesis II team of University of Virginia.
>
> Can the Genesis II team confirm ?
>
>
> Thank you in advance for your answers.
>
> Best regards.
>
> -----------------------------------------------------
> Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS
> Bat 200 91898 ORSAY France
> Tel: +33 1 64 46 84 87 Skype: etienne.urbah
> Mob: +33 6 22 30 53 27 mailto:urbah at lal.in2p3.fr
> -----------------------------------------------------
>
>
> On Tue, 21/09/2010 21:07, Etienne URBAH wrote:
>> Duane and Andrew,
>>
>> I have carefully read the document 'Genesis-II Security Implementation'
>> at http://forge.gridforum.org/sf/go/doc15435?nav=1
>>
>> Basic interoperation between different grid infrastructures require to
>> establish mutual trust and common processes.
>>
>> Currently, Security Policies for EGI are proposed by EGI SPG 'Security
>> Policy Group' at https://wiki.egi.eu/wiki/SPG
>> In particular, 'Approval of Certification Authorities' at
>> https://documents.egi.eu/public/ShowDocument?docid=83 defines that the
>> Trust Anchor is IGTF http://www.igtf.net/
>>
>> In order to permit basic interoperation between EGI and infrastructures
>> using Genesis II, members of EGI SPG need to have precise information on
>> Trust Anchor and Security Process used by grid infrastructures using
>> Genesis II.
>>
>> Referring to your above mentioned 'Genesis-II Security Implementation'
>> document :
>>
>> 1.1.2 Resource Identity
>> ------------------------
>> - The document states 'All Genesis II grid resources are given X.509
>> identities' and the 4th entry of a 'typical certificate chain of trust'
>> is a 'global Certificate Authority (CA) "trusted" by all grid
>> participants'.
>> - Please explain precisely this "trust" process :
>> If this process does not use IGTF as unique Trust Anchor, please
>> indicate the mandatory (and perhaps optional) Trust Anchor(s) for grid
>> infrastructures using Genesis II.
>>
>> 1.1.4 Existing Identities
>> --------------------------
>> - The document states 'Alternatively, users may have identities that are
>> managed by directory systems such as NIS/YP, LDAP, etc. Genesis II
>> integrates with these systems to virtualize these identities into the
>> grid'
>> - Does Genesis II really create X509 certificates (like an SLCS CA) ?
>> - If yes, which Root CA does Genesis II use ?
>> - Are you sure that this Root CA will be accepted by the target
>> resources inside the grid infrastructures using Genesis II ?
>> - If yes, what is the trust mechanism ?
>>
>>
>> 1.1.6 Identity Provider Resources (IDPs)
>> -----------------------------------------
>> - The document states 'New grid identities can be created and managed
>> using Genesis II Identity Provider (IDP) resources' implementing
>> 'WS-Trust Security Token Service (STS)'
>> - Same questions as for section 1.1.4
>>
>> Precise answers to these questions, taking into account real operational
>> constraints, would permit EGI SPG to understand the security process
>> offered by Genesis II, and perhaps to define a more flexible policy
>> about Trust Anchors, permitting real interoperation with grid
>> infrastructures using Genesis II.
>>
>> Thank you in advance for taking the pain of understanding these
>> questions and answering to them.
>>
>> Best regards.
>>
>> -----------------------------------------------------
>> Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS
>> Bat 200 91898 ORSAY France
>> Tel: +33 1 64 46 84 87 Skype: etienne.urbah
>> Mob: +33 6 22 30 53 27 mailto:urbah at lal.in2p3.fr
>> -----------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5073 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20101115/d286dd3b/attachment.bin 