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

Re: [Pgi-wg] Sec: Agreement on SOAP and authentication
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

...we are not on the same page, let's wait for the telcon. -------------------------------------------------------------------------------- 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: Friday, March 20, 2009 2:09 pm Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication > Authorization *policy *is out of scope for this conversation. How > a callee > decides to perform allow/deny checks is irrelevent in a push-style > model. > I strongly suggest that we take a "zero-or-more" approach to both: > > - Proxy chain depth > - Attribute certificates > > You are suggesting a "one-or-more" approach, which is a Bad Idea > because it > increases complexity while reducing the number of supportable use- > cases.There is nothing good about a one-or-more mandate for either. > > -Duane > > > > On Thu, Mar 19, 2009 at 1:40 PM, <m.riedel(a)fz-juelich.de> wrote: > > > Duane, > > in addition I forgot to mention that we already agreed in PGI > that we only > > do attribute-based authorization for those that would like to be > > PGI-compliant while still supporting identity-based authZ of course. > > > > It's not related here for AuthN - but helps to understand my > circumvention> of the complicated 'additional' scope. It makes > sense - but allows too much > > flexibility I think that break possibly interop again. > > > > You may want to support still purely identity-based authZ in the > > non-PGI-compliant part. At least that is my suggestion. > Otherwise we end up > > of standardizing each functionality purely out of our systems. > > > > Sorry for not mention that again, > > > > 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: Duane Merrill <dgm4d(a)virginia.edu> > > Date: Thursday, March 19, 2009 2:40 pm Subject: Re: [Pgi-wg] Sec: > > Agreement on SOAP and authentication > > > > > > > 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/TLSauthentication with certificates, and these certificates > > > MAY have proxy > > > extensions (making them PCs) and MAY have AC extensions (embedding > > > attributecertificates). > > > > > > 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 > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------------- > -- > > ----------------------------------------------------------------- > -- > > 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 > > ----------------------------------------------------------------- > -- > > ----------------------------------------------------------------- > -- > > > > > > > > > ------------------------------------------------------------------- ------------------------------------------------------------------- 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 attribute transportmechanismsforAttrAuthZ
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

Hi, as mentioned before we have PGI_GSI as the elements of GSI related to TLS. We indicated in an earlier message that PGI_GSI is like "proxy-based TLS", but in the meanwhile even this has been revoked. Currently, I think each middleware representative is talking about different things. That's fun - but hard to get agreements! ;-) 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: Aleksandr Konstantinov <aleksandr.konstantinov(a)fys.uio.no> Date: Friday, March 20, 2009 2:04 pm Subject: Re: [Pgi-wg]Sec: Agreement on attribute transport mechanismsforAttrAuthZ > On Friday 20 March 2009 13:14, Morris Riedel wrote: > > Hi, > > > > > > > > >- My personal thinking is, since we are talking about PGI or > > interoperability, we probably do need to change the current > implementation> if it can not satisfy interoperability, while > keeping the principle that the > > change should be as little as possible. > > > > > > > > In terms of little changes I agree - but I consider PGI_TLS / > PGI_GSI as > > massive changes. > > > > > > > > For instance, we have developed a UNICORE Gateway (for AuthN) > that works > > with PGI_TLS naturally - and PGI_GSI more recently providing of > course not > > FULL delegation support per hop, but proxies are supported on > GSI-TLS level. > > I'm lost. What do mean by PGI_GSI technically? Is there any > document which > defines it? How is it related to delegation? > > > A.K. > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg > ------------------------------------------------------------------- ------------------------------------------------------------------- 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] Sec: Agreement on SOAP and authentication
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

Subject indicates : we are at authentication - so let's keep to GSI in the context of TLS - Thanks -------------------------------------------------------------------------------- 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: Friday, March 20, 2009 2:01 pm Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication > GSI encompasses MyProxy, Delegation Service, Community Authorization > Service. GSI does not include binding of attribute certificates > within PKCs > or PCs. So GSI is an overlapping but different set of features > than we are > talking about right here. > > Besides, to my knowledge, GSI supports vanilla PKCs as well as PCs. > > -Duane > > On Thu, Mar 19, 2009 at 1:27 PM, <m.riedel(a)fz-juelich.de> wrote: > > > Hi, > > > > ok let's put it as follows: I meant "proxy-based TLS == GSI" - > maybe a bit > > simplified but isn't it clear in the context here? But we can > talk about GSI > > then... > > > > Yeah GridFTP is an important service but indeed with no WS- > interface, so > > out of scope here. > > > > What do you think about the "either-or" dependency to nail it > down more > > precisely. > > > > 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: weizhong qiang <weizhongqiang(a)gmail.com> > > Date: Thursday, March 19, 2009 3:51 pm > > Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication > > > > > 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 > > > transportcommunication, 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 > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------------- > -- > > ----------------------------------------------------------------- > -- > > 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 > > ----------------------------------------------------------------- > -- > > ----------------------------------------------------------------- > -- > > > > > > _______________________________________________ > > 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 WS-Naming (ref by strawman)
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

Hi Aleksandr, >- I would like to know what do You mean by "contacted". If that implies human user is expected to write EPR by hand to make his/her client to contact some service then I disagree. I refer to contacted as "accessed from a Grid client" w/o avoiding to create the EPR manually - instead the EPR has an URI in wsa:To and maybe referenceproperties to point to a particular resource instance behind the service interface. Q: Isn't A-REX not also accessible via EPRs? Thanks for clarification, 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: Aleksandr Konstantinov <aleksandr.konstantinov(a)fys.uio.no> Date: Friday, March 20, 2009 12:40 pm Subject: Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman) > On Friday 20 March 2009 12:21, Morris Riedel wrote: > > Hi Aleksandr, > > > > >-IMO the real question is what such EPRs may be used for. If > they planned > > as > > >-replacements for URLs and *full* such EPR is going to be put into > > >-every SOAP header then I wohuld vote strongly against. But if > such EPR is > > just a way > > >-to describe service (same as corresponding section in Glue > > >-document) and are ony meant to be used in some kind of information > > system/port > > >-then why not. > > > > Just for clarification: With URLs you refer to the wsa:To > element of > > WS-Addressing correct? If so, they are of course in any SOAP > message - or I > > didn't get your point. > > With URL I mean URL which was supposed to identify resource. > Now with introduction of EPRs we get another layer of indirection > in resource > identification. That's alright. But EPRs can also be used to > describe resource. > And that description part may become lenghty. So if PGI goes for > EPR I would > like to see it profiled which parts of EPR are expected/needed at > which place/moment. > If my client application queries for some service with specific > capabilities > and gets 100kB EPR describing who where and how can contact > service that is > probably ok. But if for contacting that service my application has > to insert that > EPR into every SOAP message I would like to know which parts of it > I can be safely > removed in order to avoid buying dedicated optical link to > computing center hosting > that service. :) > > > > > Also, if it would be only to put into a kind of information > system I would > > vote for crunching the EPR in elements that can be probably > better searched > > for by an query instead of putting information into EPR. > > I just have to agree. > > > > > Here, WS-Naming, provides basically a name of a service while > its EPR might > > change over time (renewable reference). Also the document refers to > > trackability of messages once you use WS-Naming (e.g. UUID > dependency) - so > > I expect that this information of WS-Naming EPR additions should > be part of > > any SOAP message. But that's only my interpretation from the > document.> > > > > Q: Can we agree that each functional service in the EPR space > such as > > OGSA-BES are contacted with an pure EPR using URIs? We don't > consider> accessing a BESService simply with an URI - or do we? I > would not vote for > > that. > > I would like to know what do You mean by "contacted". If that > implies human > user is expected to write EPR by hand to make his/her client to > contact some > service then I disagree. > > > A.K. > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg > ------------------------------------------------------------------- ------------------------------------------------------------------- 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] Sec: Agreement on attribute transport mechanismsforAttrAuthZ
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

Howdy, >- I do code for doing authentication with and without proxies. And I never noticed significant difference. We do to - difference, for example, would be to climb the proxy chain using the "specific path validation algorithm" which is not needed by using typical X.509 certs. >- So why not to use last option? Or am I missing something? As I said before - probably not all services understand normal TLS and require proxies where pure PGI_TLS is not correct - e.g. CREAM-BES I know from my own experience so far. >- If (a) covers (b) then "either (a) or (b)" is not achievable. my fault - (a) should be rather in the questions section, but an answer from gLite may help to understand. 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: Aleksandr Konstantinov <aleksandr.konstantinov(a)fys.uio.no> Date: Friday, March 20, 2009 12:26 pm Subject: Re: [Pgi-wg]Sec: Agreement on attribute transport mechanisms forAttrAuthZ > On Friday 20 March 2009 12:08, Morris Riedel wrote: > > Good morning Aleksandr, > > > > > > >-I see no reason for "either". Also it would be nice to > define used > > terms. > > >-AFAIK there are no restrictions for using X.509 proxies (aka > PC) in TLS. > > As long as > > >-we are talking about > > >-standardaized PCs (RFC 3820) of course. > > >-For infrastructures relying on full or partial/restricted > X.509 identity > > delegation PC > > >-(proxy certificate) is > > >-a must. But I see no reason why that should exclude usage of > ordinary> X.509 > > >-certificates/keys as > > >-mean for identifying (direct or through attributes) > communicating parties. > > > > > > The reason is basically to precisely define what an endpoint > supports, if do > > not define this precisely interoperability will break since > there is a big > > difference using TLS with or without proxies for the authN > check. The either > > I do code for doing authentication with and without proxies. And I > never > noticed significant difference. > > > is a reason to make it more simpler although there is a polymorphic > > dependency, but this is not always helpful for the implementations. > > > > Example: > > > > (a) > > For instance, if we would only claim that the UNICORE Gateway > (AuthN check > > for end-users) supports the PGI_TLS w/o knowing if it uses > proxies or not: > > > > If you then use your ARC-Client with proxies and access the > Gateway you > > fail, because the AuthN check only checks for full end-entity > certificates.> > > (b) > > For instance, if we would claim that UNICORE Gateway supports > PGI_GSI (so > > proxies including some newly defined PGI revocation mechanism > since this is > > a general GSI problem, or proxy problem although they have > limited lifetime) > > : > > > > If you then use your ARC client with proxies and access the > Gateway you win, > > because the AuthN check climbs up the whole proxy-hierarchy. > > > > If we use our own UNICORE Client with full end-entity > certificates it works > > as well since PGI_GSI MAY include PGI_TLS (your polymorphic item). > > So why not to use last option? Or am I missing something? > > > > > ### Conclusions and motivation for either: > > > > (a) > > So clearly every service that do supports PGI_GSI is able to > accept client > > request based on PGI_TLS only > > > > (b) > > But every service that purely supports PGI_TLS is not able to > accept client > > requests based on PGI_GSI > > > > Bottom line: the either is needed for differentiation including > inherently> your statement of polymorphism that only indicated > 'one direction' or 'is-a' > > and not the other direction! > > If (a) covers (b) then "either (a) or (b)" is not achievable. > > > A.K. > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg > ------------------------------------------------------------------- ------------------------------------------------------------------- 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] Sec: Agreement on SOAP and authentication
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

Hi, ok let's put it as follows: I meant "proxy-based TLS == GSI" - maybe a bit simplified but isn't it clear in the context here? But we can talk about GSI then... Yeah GridFTP is an important service but indeed with no WS-interface, so out of scope here. What do you think about the "either-or" dependency to nail it down more precisely. 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: weizhong qiang <weizhongqiang(a)gmail.com> Date: Thursday, March 19, 2009 3:51 pm Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication > 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 > transportcommunication, 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 > > > > > ------------------------------------------------------------------- ------------------------------------------------------------------- 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 ------------------------------------------------------------------- -------------------------------------------------------------------

4 6

Sec: Agreement on WS-Naming (ref by strawman)
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

Hi security folks, in preparation of tomorrow I scanned the WS-Naming spec (GFD109) since there was an optional (MAY) dependency in the strawman doc of it. ### Goal: (a) We are discussing the WS-Naming specification... (b) ... because we want to survey what's is adoption status is in production setups is and what impacts might occur when implementing it... (c) ... in order to find out if the WS-Naming dependency makes sense for PGI in general and for our security setup in particular. ### Bottom line of spec contents # Defines an Endpoint Identifier Profile -> WS-A add-ons # WS Address Endpoint identifier Profile -> WS-A add-ons # Endpoint Resolvers Profiles -> portType ### Possible Conclusions: # (A) As discussed earlier, this is yet another profile that increases the size of an EPR significantly -> while one spec adoption might not be critical, adopting WS-Naming together with OGF Sec Addressing and VO lists in WS-MetaData elements of EPRs might be together a 'just too big' EPR to be realistic - apart from the functionality of the necessary resolvers in particular for WS-Naming. Bottom line: Too much for the EPR - rather covered by an appropriate information service ### Questions: # (A) Which middleware platform is adopting it currently and has precise plans to adopt it in the near future. We can list for now GENESIS-II adopting it while I know that UNICORE does not and has no precise plans for it now - what about others like gLite, ARC, or NAREGI? # (B) Is GLUE covering partly the information of getting endpoints for unique names or something similiar like renewable references? The discussion before the TelCon might increase our progress... Your co-chair, 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.' ------------------------------------------------------------------- ------------------------------------------------------------------- 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 ------------------------------------------------------------------- -------------------------------------------------------------------

5 5

Re: [Pgi-wg] Sec: Agreement on SOAP and authentication
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

Duane, in addition I forgot to mention that we already agreed in PGI that we only do attribute-based authorization for those that would like to be PGI-compliant while still supporting identity-based authZ of course. It's not related here for AuthN - but helps to understand my circumvention of the complicated 'additional' scope. It makes sense - but allows too much flexibility I think that break possibly interop again. You may want to support still purely identity-based authZ in the non-PGI-compliant part. At least that is my suggestion. Otherwise we end up of standardizing each functionality purely out of our systems. Sorry for not mention that again, 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: Duane Merrill <dgm4d(a)virginia.edu> Date: Thursday, March 19, 2009 2:40 pm Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication > 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/TLSauthentication with certificates, and these certificates > MAY have proxy > extensions (making them PCs) and MAY have AC extensions (embedding > attributecertificates). > > 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 > > > > > ------------------------------------------------------------------- ------------------------------------------------------------------- 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

Re: [Pgi-wg] Sec: Agreement on attribute transport mechanismsforAttrAuthZ
by Aleksandr Konstantinov 20 Mar '09

20 Mar '09

On Friday 20 March 2009 13:14, Morris Riedel wrote: > Hi, > > > > >- My personal thinking is, since we are talking about PGI or > interoperability, we probably do need to change the current implementation > if it can not satisfy interoperability, while keeping the principle that the > change should be as little as possible. > > > > In terms of little changes I agree - but I consider PGI_TLS / PGI_GSI as > massive changes. > > > > For instance, we have developed a UNICORE Gateway (for AuthN) that works > with PGI_TLS naturally - and PGI_GSI more recently providing of course not > FULL delegation support per hop, but proxies are supported on GSI-TLS level. I'm lost. What do mean by PGI_GSI technically? Is there any document which defines it? How is it related to delegation? A.K.

1 0

Re: [Pgi-wg] Sec: Agreement on SOAP and authentication
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

Hi Duane, have you read the slides about the IIRM and the plumbings concept was basically refers to that concept of "either-or". Although both are X.509 certificates - It's a fundamental difference if you have full X.509 end-entity certificates only signes by a CA you trust or X.509 certificates signed by users with a chain. Implementations have to now the difference in order to 'climb the whole chain' while doing authentication - that was breaking interoperability in the past between numerous implementatio. In short: my suggestion is to remove too much flexibility by just using "either or" for these models that are quite established. Furthermore, I would like to decouple the attrauthZ from TLS. I hope it gets a bit clearer now - but I feel the need for a picture, I start to develop a small supportive figure here. 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: Duane Merrill <dgm4d(a)virginia.edu> Date: Thursday, March 19, 2009 2:40 pm Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication > 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/TLSauthentication with certificates, and these certificates > MAY have proxy > extensions (making them PCs) and MAY have AC extensions (embedding > attributecertificates). > > 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 > > > > > ------------------------------------------------------------------- ------------------------------------------------------------------- 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