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&sessionId=2&resId... http://indico.rnp.br/getFile.py/access?contribId=1&sessionId=2&resId... 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@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&sessionId=2&resId...

- CILogon http://indico.rnp.br/getFile.py/access?contribId=1&sessionId=2&resId...

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@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@lal.in2p3.fr -----------------------------------------------------