March 2009 - pgi-wg - lists.ogf.org

Re: [Pgi-wg] Sec: Agreement on supported AttributeAuthorityInterfaces
by m.riedel＠fz-juelich.de 19 Mar '09

19 Mar '09

Hi Steven, exactly - I just want to find out if we can agree on classic VOMS & SAML VOMS "attribute packages" or if we have to support a third "attribute package" maybe coming out of the [Shib*,GridShib,ShibGrid] field. They are all slightly different "attribute packages". Once we found that out - we going after the question how the packages are presented to the services. Take care, Morris -------------------------------------------------------------------------------- Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Central Institute of Applied Mathematics Research Centre Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel(a)fz-juelich.de Info: http://www.fz-juelich.de/zam/ZAMPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel 'We work to improve ourselves and the rest of mankind.' ----- Original Message ----- From: Steven Newhouse <Steven.Newhouse(a)cern.ch> Date: Thursday, March 19, 2009 9:22 pm Subject: RE: RE: [Pgi-wg] Sec: Agreement on supported Attribute AuthorityInterfaces > > I think standardization of the Classic AC VOMS interface is out of > > scope while the standardization of the SAML-based VOMS interface is > > done by SAML. > > I'd agree - just wanted to check! > > > But we should state in the document both as examples of > > retrieving attributes to get the profile more clear. > > They are both valid scenarios... surely we only need to profile the > attributes and how they are packaged and presented to the service? > Or am > I missing something? > > Steven > ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

1 0

modified plan for jobmanagement discussions
by Balazs Konya 19 Mar '09

19 Mar '09

Dear All, During the last teleconference a suggestion to speed up the PGI process was made. It was proposed to start weekly phone meetings (on Wednesdays) to discuss the computational related topics. Andrew volunteered to chair the first meeting and provide a summary of the available documents related to computation (http://forge.gridforum.org/sf/docman/do/listDocuments/projects.pgi-wg/docma…) Since then, the PGI co-chairs have been discussing and reconsidering whether this would really be the most efficient approach, i.e. start a discussion around the interpretation of raw drafts. The jobmanagement related drafts are the results of both the pre-OGF work of the ARC/gLite/Unicore teams and the work undertaken in the GIN community group. The drafts in their current status are rather difficult to be interpreted correctly since they were not meant to be for public consumption, they were written as internal working materials for a smaller group. Since then, we never had the time to put these documents in a more readable form. Thus, we feel that it is our responsibility to first better organize our initial drafts, so that people can make better use of their time by reading the improved document rather than trying to "reverse engineer" our ideas from the current poorly written notes. Therefore, we concluded that the PGI group would make a better progress if the proposed modified plan was followed: 1) the initial authors of the drafts are asked to re-work their internal memos, create a consistent write-up of their ideas, prepare a draft about the "production execution service". This document on "production execution service" should describe all the main aspects of a job management service needed in a production environment. Proposed deadline for the document: 31st March 2) schedule the first jobmanagement phone conference one week after the write-up is available: initially on 8th April. This also means that the teleconference called for this Wednesday is not needed. 3) meanwhile, the security discussions should go forward with full speed and hopefully result in an agreed draft. regards, Balazs, Moreno, Morris PGI co-chairs

7 9

Re: [Pgi-wg] Sec: Agreement on supported Attribute AuthorityInterfaces
by m.riedel＠fz-juelich.de 19 Mar '09

19 Mar '09

Hi, sorry for the confusion - the goal is here simply to find out if there are other ways in infrastructures except [SAML-based VOMS, classic AC VOMS, Shibboleth] to retrieve attributes and if we may can skip the need for Shib* ways of doing it. I think standardization of the Classic AC VOMS interface is out of scope while the standardization of the SAML-based VOMS interface is done by SAML. But we should state in the document both as examples of retrieving attributes to get the profile more clear. I got from the mail of you about EGEE (I refered to in my mail) that we have to support Classic AC VOMS, which in turn means to look closer on the "AC embedded proxy" approach in our profile (other upcoming e-mail thread). You may see it as a precondition before looking closer to the precise encoding of transport mechanism. Hope that helps, Morris -------------------------------------------------------------------------------- Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Central Institute of Applied Mathematics Research Centre Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel(a)fz-juelich.de Info: http://www.fz-juelich.de/zam/ZAMPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel 'We work to improve ourselves and the rest of mankind.' ----- Original Message ----- From: Steven Newhouse <Steven.Newhouse(a)cern.ch> Date: Thursday, March 19, 2009 3:55 pm Subject: RE: [Pgi-wg] Sec: Agreement on supported Attribute Authority Interfaces > Hi Morris, > > I'm confused by the context here... are you suggesting we look to > standardise the VOMS interface (or the service that serves up the > proxy that) or the proxy and its content itself? > > Thanks, > > Steven > > Dr Steven Newhouse > EGEE Technical Director > http://cern.ch/Steven.Newhouse > > > > -----Original Message----- > > From: pgi-wg-bounces(a)ogf.org [pgi-wg-bounces(a)ogf.org] On Behalf > > Of Morris Riedel > > Sent: 19 March 2009 14:22 > > To: pgi-wg(a)ogf.org > > Subject: [Pgi-wg] Sec: Agreement on supported Attribute Authority > > Interfaces > > > > Hi PGI security folks, > > > > another issue I see is the supported attribute authorities and > (more> notably) their interfaces. > > > > Taking our experience from GIN into account and addressing the > message> of Steven (EGEE) there are still two interfaces to > consider in terms of > > VOMS. > > Also, as an alternative AA there is Shibboleth quite much used > in the > > space. > > > > ### goal > > > > (a) > > We are discussing which AA can be used in PGI to retrieve > attributes...> > > (b) > > ...because we want to find out which interfaces have to be > supported to > > get attributes... > > > > > > (c) > > ... in order to know more precisely which types of attribute > transport> mechanisms we have to support in PGI. > > > > ### Possible scenarios > > > > A. A user contacts a non-WS-based classic VOMS with a proprietary > > interface, but gets a standardized RFC AC back with the attributes > > signed by the VOMS. > > (later on these are used within extensions of RFC proxies for > attr- > > authZ) > > > > B. A user contacts a WS-based VOMS with SAML-REQUEST-interface > standard> and gets a standardized SAML Assertion back signed by > the VOMS service. > > (later on these are used within WS-SecExt within SOAP Headers) > > > > C. A user contacts a Shibboleth system (possibly w/o WAYF) using > SLCs> with SAML assertions inside its extensions. > > > > D. A user contacts MyProxy with a stored proxy using ACs in its > > extension (implies no new attribute transport mechanism), but > possibly> a new interface of getting (indirectly) attributes. > > > > > > I see the agreement on the elements of this e-mail thread as a > > prerequisite to agree on the mechanisms of which attribute > formats we > > support and how we convey attributes precisely (separate email > thread).> > > ### Possible conclusion: > > > > A. We only reference in our profile possible ways of retrieving > either> ACs or SAML assertions (e.g. by pointing to the SAML- > request document > > that is in public comment currently as mentioned earlier). We do not > > intend to profile how exactly a user gets its attributes. > > > > B. If we agree on A - we indirectly agree on attribute push > since in > > the attribute pull mode - for interoperability reasons - the > interface> of getting attributes must be known so that the > middleware can contact > > it on behalf of the user! > > > > C. We deal with RFC ACs > > > > D. We deal with SAML assertions > > > > E. We only consider C+D in the first iteration of the profile > > > > > > > > ### open Questions > > > > Q: Can we agree on these conclusions? Are there any comments - > > something I missed? > > > > Q: Is there any production infrastructure that largely supports > > Shibboleth w/o supporting VOMS either in classic or WS style? > > > > > > > > > > Please consider the attribute - and its transport mechanisms out of > > scope in this e-mail thread. > > > > > > Take care, > > 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(a)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) > > > > ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

2 1

Sec: New directory for strawman from Catania
by m.riedel＠fz-juelich.de 19 Mar '09

19 Mar '09

Hi security folks, I put the strawman document as discussed earlier into the input section since it not reflects a draft we agreed on: http://forge.gridforum.org/sf/go/projects.pgi-wg/docman.root.input_document… I also put my commented version close to it - but of course it makes more sense to discuss many issues with it rather on the list or at the telcon tomorrow. Nevertheless - Duane might find some comments interesting to get easier into discussions on target tomorrow. Even if there is a lot of "stress" around the document - we also have to thank Duane for the work. Many items of it are useful (SAML, VOMS AC, etc.) and others have to be discussed and maybe revised (EPR with hundreds of VOs in it in the metadata section). I hope we all can get still to an agreement, which is the highest motivation of PGI. Finally, I encourage all the PGI security experts of being part of the discussions tomorrow while working on the e-mail threads we have established. Your co-chair, Morris ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

1 0

Re: [Pgi-wg] Documenting the security agreement/info progress
by m.riedel＠fz-juelich.de 19 Mar '09

19 Mar '09

Yes, I got the best experience of it as well combining it with the factsheets makes sense - what do you think Weizhong? -------------------------------------------------------------------------------- Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Central Institute of Applied Mathematics Research Centre Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel(a)fz-juelich.de Info: http://www.fz-juelich.de/zam/ZAMPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel 'We work to improve ourselves and the rest of mankind.' ----- Original Message ----- From: Duane Merrill <dgm4d(a)virginia.edu> Date: Thursday, March 19, 2009 2:45 pm Subject: Re: [Pgi-wg] Documenting the security agreement/info progress > The "track-changes" and "insert comments" feature for MS Word > documents has > come in very handy in other OGF working groups. The "insert comments" > feature is particularly useful for allowing discussions on particular > aspects to flow on with perfect contextual reference. > > 2009/3/19 Morris Riedel <m.riedel(a)fz-juelich.de> > > > Hi PGI security folks, > > > > I'm thinking how we can document progress in agreements in > terms of > > security. Just let the flow of e-mails run us out of time is not > a good > > idea... > > > > > > Also, the strawmen document is nice but it is a Formula 1 > racecar (or US: > > Indy500 car) compared to a bicycle, which is more needed by PGI > in the > > moment to agree on important 'forward-bringing elements' before > profiling> it > > precisely to realize a common view on a racecar. > > > > > > As I said earlier - our common agreement (not only in security) > is crucial > > - > > rushing a profile out is not collaborative enough and had nearly > crushed> the > > group instead of getting us out of the security hole mentioned > by Steven > > earlier. In slightly other words - it's the process - not the > documentation> alone, especially in collaborative efforts. > > > > > > So - I hesitate to again come up with a big document during the > agreement> process and rather prefer a condensed WIKI page. > > > > > > But also this page implies changes by numerous folks making again > > unreviewable without having any 'place constraints' especially > having not > > really a good track changes option! > > > > > > My current idea is around so-called factsheets that are only two- > page word > > documents for each security topic making it condensed and > allowing the > > valuable track changes functionality including one picture per > topic that > > represents our common agreement aligned with some text that > later lays the > > foundation for our 'one' document mentioned in the charter. > > > > > > I just want to hear your opinions on this before I start working > on them - > > it makes no sense if you disagree. > > > > I'm also happy to hear better suggestions. > > > > > > Thanks for sharing your views on this, > > 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(a)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) > > > > > > > > _______________________________________________ > > Pgi-wg mailing list > > Pgi-wg(a)ogf.org > > http://www.ogf.org/mailman/listinfo/pgi-wg > > > > > ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

1 0

Re: [Pgi-wg] Sec: Agreement on supported Attribute Authority Interfaces
by weizhong qiang 19 Mar '09

19 Mar '09

hi, I have some questions as following. 2009/3/19 Morris Riedel <m.riedel(a)fz-juelich.de> > Hi PGI security folks, > > another issue I see is the supported attribute authorities and (more > notably) their interfaces. > > Taking our experience from GIN into account and addressing the message of > Steven (EGEE) there are still two interfaces to consider in terms of VOMS. > Also, as an alternative AA there is Shibboleth quite much used in the > space. > > ### goal > > (a) > We are discussing which AA can be used in PGI to retrieve attributes... > > (b) > ...because we want to find out which interfaces have to be supported to get > attributes... > > > (c) > ... in order to know more precisely which types of attribute transport > mechanisms we have to support in PGI. > > ### Possible scenarios > > A. A user contacts a non-WS-based classic VOMS with a proprietary > interface, > but gets a standardized RFC AC Do you proposed to use the stadardized RFC AC, instead of the VOMS AC which is known as a simplified RFC while de-facto AC. If so, I think it is not needed. We can use VOMS AC, because we already have a few production Grid systems which have supported it. > back with the attributes signed by the VOMS. > (later on these are used within extensions of RFC proxies for attr-authZ) > > B. A user contacts a WS-based VOMS with SAML-REQUEST-interface standard and > gets a standardized SAML Assertion back signed by the VOMS service. (later > on these are used within WS-SecExt within SOAP Headers) > > C. A user contacts a Shibboleth system (possibly w/o WAYF) using SLCs with > SAML assertions inside its extensions. Shibboleth itself does not support SLCs, and you need to develope some system to issuing SLCs by using Shibboleth as ONE part of this system. You can also get SLCs credential through otherway except Shibboleth-based. IF we use "push" model, I think how does the client get the credential doesn't matter, what does matter is the content of the credential. Futhermore, I can see two different problems here about interoperability in PGI in terms of credential/attributes: a.The interoperability of getting a credential (with attributes inside); The points you mentioned above are all about this problem. b.the interoperability of using a credential (with attribute inside). One user or client (on behalf of user) get the credential, it needs to use it and interoperate with services. I guess PGI is supposed to solve both of them? > > > D. A user contacts MyProxy with a stored proxy using ACs in its extension > (implies no new attribute transport mechanism), but possibly a new > interface > of getting (indirectly) attributes. > > > > I see the agreement on the elements of this e-mail thread as a prerequisite > to agree on the mechanisms of which attribute formats we support and how we > convey attributes precisely (separate email thread). > > ### Possible conclusion: > > A. We only reference in our profile possible ways of retrieving either ACs > or SAML assertions (e.g. by pointing to the SAML-request document that is > in > public comment currently as mentioned earlier). We do not intend to profile > how exactly a user gets its attributes. > > B. If we agree on A - we indirectly agree on attribute push since in the > attribute pull mode - for interoperability reasons - the interface of > getting attributes must be known so that the middleware can contact it on > behalf of the user! So we are only going to solve the second sub-problem I concluded above? > > > C. We deal with RFC ACs Not VOMS AC? > > > D. We deal with SAML assertions > > E. We only consider C+D in the first iteration of the profile > > > > ### open Questions > > Q: Can we agree on these conclusions? Are there any comments - something I > missed? Changing VOMS AC to RFC AC? Plus Supporting SAML Assertion? > > > Q: Is there any production infrastructure that largely supports Shibboleth > w/o supporting VOMS either in classic or WS style? In terms of ARC, The production ARC supports VOMS classic The development ARC supports VOMS classic and WS style, and has it own SLCs service which is based on Shibboleth IdP. Cheers Weizhong > > > > > > Please consider the attribute - and its transport mechanisms out of scope > in > this e-mail thread. > > > Take care, > 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(a)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) > > > > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg > >

1 0

Re: [Pgi-wg] Sec: Agreement on SOAP and authentication
by weizhong qiang 19 Mar '09

19 Mar '09

hi, I think the issue you proposed can be divided into branches (since HTTPS is actually http + tls/ssl): 1. If all of the PGI services use SOAP (i.e. Web Service interface)? 2. If all of the PGI services use TLS? For the first one, at least GridFTP service is excluded, while it is widely used by production grid. For the second, maybe most of the services are based on secure transport communication, but some of them are using GSI (SRM service: SOAP + GSI?) In terms of ARC, the A-REX service (for job management, supporting BES, JSDL) is using SOAP plus TLS, while it is also configurable to support SOAP plus GSI. Regards, Weizhong 2009/3/19 Morris Riedel <m.riedel(a)fz-juelich.de> > Hi security folks, > > > reading certain elements of the IIRM, strawman, and following discussions > on the list - I see there is still no common agreement on SOAP / HTTP(S) in > some areas. > > ### Goal: > > (a) > We are discussing if SOAP / HTTPS can be used in PGI to contact a > functional > interface (like BES)... > > (b) > ...because we want to find out if there is any important service in the PGI > context that is not capable of using SOAP (over SSL layer)... > > > (c) > ... in order to find out if we can agree on SOAP/HTTPS or to understand > requirements from other non WS-based interfaces in PGI. > > > Therefore the aim of this thread is to get to an agreement in this context, > while considering Attribute authorities like VOMS as a supportive service > and not an functional interface (also separate thread). > > ### Contacting functional implementations with SOAP > > If we consider the case that we communicate with an functional interface > like OGSA-BES - we agree on SOAP. > > ### TLS/SSL Layer: > > # <strawman> > Foundational: Conveying identity for authentication. > SOAP over HTTPS (PGI_HTTPS). SOAP-over-HTTP communication using a SSL/TLS > transport protocol in which endpoints are mutually authenticated by X.509 > end-entity public key certificates (PKCs). > # </strawman> > > > # <simple plumbings: authentication> > We use authentication either based on identities inside X.509 end-entity > public key certificates or X.509 proxies (including restrictions, encoding > handled separately in another thread). > > This refers of using either one or the other of these certificate types on > the SSL/TLS level. > > For simplification of the profile - there should be no direct dependencies > with attribute-transport used for authorization. > # </plumbings> > > > ### Possible scenarios: > > # A. TLS with end-entity certificate, SOAP in message -> authN check with > CA > > # B. TLS with (restricted) proxy certificates, SOAP in message -> authN > check with proxy signer chain > > ### Possible Conclusion: > > # We use SOAP inside a message to contact functional interfaces. > > # We use either full X.509 end-entity certificates OR X.509 proxies (with > restrictions) > > ### Open Questions: > > > Q: There are WS interfaces for functional specifications that matter to PGI > (BES, WS-DAIS and SRM) - so in the context of PGI - can we agree on SOAP > based on HTTPS as mentioned above? > > Q: If not - are there any important functional interfaces (except support > interfaces from AAs like classic VOMS) that do not support SOAP in the PGI > ecosystem? > > > Please feel free to comment but let the question of attributes+restrictions > outside - I propose to deal with it in separate threads because of their > complexity. > > > Take care, > 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(a)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) > > > > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg > >

1 0

Re: [Pgi-wg] Sec: Agreement on supported Attribute Authority Interfaces
by Duane Merrill 19 Mar '09

19 Mar '09

> > > ### Possible scenarios ... E. A user (or agent service) is in possession of statically-assigned credentials (an identity + zero-or-more attributes). > > ### Possible conclusion: > > A. We only reference in our profile possible ways of retrieving either ACs > or SAML assertions (e.g. by pointing to the SAML-request document that is > in > public comment currently as mentioned earlier). We do not intend to profile > how exactly a user gets its attributes. > > B. If we agree on A - we indirectly agree on attribute push since in the > attribute pull mode - for interoperability reasons - the interface of > getting attributes must be known so that the middleware can contact it on > behalf of the user! > > C. We deal with RFC ACs > > D. We deal with SAML assertions > > E. We only consider C+D in the first iteration of the profile > > We would prefer to begin with A (which implies B). We can always layer an agreement for attribute/token aquisition at a later date if the world demands a pull-style mode. -Duane

1 0

Re: [Pgi-wg] Sec: Agreement on SOAP and authentication
by Duane Merrill 19 Mar '09

19 Mar '09

I don't understand the strict "either-or" wording below with regards to PCs versus PKCs in a *proxy-plus-embedded-AC* conformance target. You make it sound like their use would be unilaterally mutually exclusive. Both types of certificates can embed attribute certificates, and there is an "is-a"/polymorphic relationship here: a PKC is a PC of delegation depth zero (and therefore does not have the extension OID set). A *proxy-plus-embedded-AC* conformance target should describe implementations that allow both. In the strawman document, the goal of layering the *pgi-tls-proxy* conformance target on top of the *pgi-https*target was to add functionality (not take it away): *pgi-tls-proxy* describes SOAP implementations that perform mutual SSL/TLS authentication with certificates, and these certificates MAY have proxy extensions (making them PCs) and MAY have AC extensions (embedding attribute certificates). Perhaps I am just misinterpreting your language. -Duane 2009/3/19 Morris Riedel <m.riedel(a)fz-juelich.de> > Hi security folks, > > > reading certain elements of the IIRM, strawman, and following discussions > on the list - I see there is still no common agreement on SOAP / HTTP(S) in > some areas. > > ### Goal: > > (a) > We are discussing if SOAP / HTTPS can be used in PGI to contact a > functional > interface (like BES)... > > (b) > ...because we want to find out if there is any important service in the PGI > context that is not capable of using SOAP (over SSL layer)... > > > (c) > ... in order to find out if we can agree on SOAP/HTTPS or to understand > requirements from other non WS-based interfaces in PGI. > > > Therefore the aim of this thread is to get to an agreement in this context, > while considering Attribute authorities like VOMS as a supportive service > and not an functional interface (also separate thread). > > ### Contacting functional implementations with SOAP > > If we consider the case that we communicate with an functional interface > like OGSA-BES - we agree on SOAP. > > ### TLS/SSL Layer: > > # <strawman> > Foundational: Conveying identity for authentication. > SOAP over HTTPS (PGI_HTTPS). SOAP-over-HTTP communication using a SSL/TLS > transport protocol in which endpoints are mutually authenticated by X.509 > end-entity public key certificates (PKCs). > # </strawman> > > > # <simple plumbings: authentication> > We use authentication either based on identities inside X.509 end-entity > public key certificates or X.509 proxies (including restrictions, encoding > handled separately in another thread). > > This refers of using either one or the other of these certificate types on > the SSL/TLS level. > > For simplification of the profile - there should be no direct dependencies > with attribute-transport used for authorization. > # </plumbings> > > > ### Possible scenarios: > > # A. TLS with end-entity certificate, SOAP in message -> authN check with > CA > > # B. TLS with (restricted) proxy certificates, SOAP in message -> authN > check with proxy signer chain > > ### Possible Conclusion: > > # We use SOAP inside a message to contact functional interfaces. > > # We use either full X.509 end-entity certificates OR X.509 proxies (with > restrictions) > > ### Open Questions: > > > Q: There are WS interfaces for functional specifications that matter to PGI > (BES, WS-DAIS and SRM) - so in the context of PGI - can we agree on SOAP > based on HTTPS as mentioned above? > > Q: If not - are there any important functional interfaces (except support > interfaces from AAs like classic VOMS) that do not support SOAP in the PGI > ecosystem? > > > Please feel free to comment but let the question of attributes+restrictions > outside - I propose to deal with it in separate threads because of their > complexity. > > > Take care, > 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(a)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) > > > > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg > >

1 0

Sec: Agreement on supported Attribute Authority Interfaces
by Morris Riedel 19 Mar '09

19 Mar '09

Hi PGI security folks, another issue I see is the supported attribute authorities and (more notably) their interfaces. Taking our experience from GIN into account and addressing the message of Steven (EGEE) there are still two interfaces to consider in terms of VOMS. Also, as an alternative AA there is Shibboleth quite much used in the space. ### goal (a) We are discussing which AA can be used in PGI to retrieve attributes... (b) ...because we want to find out which interfaces have to be supported to get attributes... (c) ... in order to know more precisely which types of attribute transport mechanisms we have to support in PGI. ### Possible scenarios A. A user contacts a non-WS-based classic VOMS with a proprietary interface, but gets a standardized RFC AC back with the attributes signed by the VOMS. (later on these are used within extensions of RFC proxies for attr-authZ) B. A user contacts a WS-based VOMS with SAML-REQUEST-interface standard and gets a standardized SAML Assertion back signed by the VOMS service. (later on these are used within WS-SecExt within SOAP Headers) C. A user contacts a Shibboleth system (possibly w/o WAYF) using SLCs with SAML assertions inside its extensions. D. A user contacts MyProxy with a stored proxy using ACs in its extension (implies no new attribute transport mechanism), but possibly a new interface of getting (indirectly) attributes. I see the agreement on the elements of this e-mail thread as a prerequisite to agree on the mechanisms of which attribute formats we support and how we convey attributes precisely (separate email thread). ### Possible conclusion: A. We only reference in our profile possible ways of retrieving either ACs or SAML assertions (e.g. by pointing to the SAML-request document that is in public comment currently as mentioned earlier). We do not intend to profile how exactly a user gets its attributes. B. If we agree on A - we indirectly agree on attribute push since in the attribute pull mode - for interoperability reasons - the interface of getting attributes must be known so that the middleware can contact it on behalf of the user! C. We deal with RFC ACs D. We deal with SAML assertions E. We only consider C+D in the first iteration of the profile ### open Questions Q: Can we agree on these conclusions? Are there any comments - something I missed? Q: Is there any production infrastructure that largely supports Shibboleth w/o supporting VOMS either in classic or WS style? Please consider the attribute - and its transport mechanisms out of scope in this e-mail thread. Take care, 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(a)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)

1 0