- pgi-wg - lists.ogf.org

Re: [Pgi-wg] TLS : OpenSSL and GSI implementations - gLite 3.2released today
by weizhong qiang 27 Mar '09

27 Mar '09

On Fri, Mar 27, 2009 at 11:20 AM, Morris Riedel <m.riedel(a)fz-juelich.de>wrote: > Ok, > > > > so more exactly J > > > > > > Because: > > > > OpenSSL Proxy-based TLSs are different from GSI-Proxy-based TLSs – > Agree. OpenSSL Proxy-based TLSs (including support for full X.509-based TLS) and GSI-Proxy-based TLSs (which is needed for some Grid Services, while not used in any normal Web Service based services; and which can be a optional profile in PGI, while the OpenSSL proxy-based TLSs should be a mandatory profile) Weizhong Qiang > as far as I understood from my interop experiences and from our > conversations. > > > > I thought this has unfortunately not changed yet? > > > > 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) > > > > *From:* weizhong qiang [mailto:weizhongqiang@gmail.com] > *Sent:* Friday, March 27, 2009 11:01 AM > *To:* Morris Riedel > *Cc:* Aleksandr Konstantinov; pgi-wg(a)ogf.org > > *Subject:* Re: [Pgi-wg] TLS : OpenSSL and GSI implementations - gLite > 3.2released today > > > > > > 2009/3/27 Morris Riedel <m.riedel(a)fz-juelich.de> > > Ok, > > and that's why we have to support both in our profiles I guess - correct?! > > > It depends what is the definition of the "both" here. > > Weizhong > > > > > > 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) > > > >------Original Message----- > >-From: pgi-wg-bounces(a)ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf > Of > >-Aleksandr Konstantinov > >-Sent: Friday, March 27, 2009 10:49 AM > >-To: pgi-wg(a)ogf.org > >-Subject: Re: [Pgi-wg] TLS : OpenSSL and GSI implementations - gLite > 3.2released > >-today > >- > > >-On Monday 23 March 2009 15:04, Etienne URBAH wrote: > >-> To all, > >-> > >-> Concerning various implementations of TLS to handle X509 certificates > >-> and proxies, it seems that : > >-> > >-> - DEISA (Unicore) uses the OpenSSL implementation of TLS to process > >-> X509 certificates, > >-> > >-> - EGEE (gLite) and NorduGrid (ARC) use the GSI (Globus Security > >-> Infrastructure) implementation of TLS to process X509 proxies, > >- > >-No, ARC uses OpenSSL for TLS data connections and Globus for > >-GSI connections (SRM and GridFTP). > >- > >- > >-A.K. > >- > >- > >-> > >-> - The OpenSSL and GSI implementations of TLS seem to be INCOMPATIBLE > >-> (see mails below of Weizhong QIANG and Duane MERRIL). > >-> > >-> This would make any interoperability very difficult. > >-> > >-> > >-> But the situation is perhaps NOT so desperate : > >-> > >-> - EGEE has just released gLite version 3.2 today 23 March 2009. > >-> > >-> - In slide 3 of the presentation 'Middleware update' performed at CERN > >-> GDB on 11 March 2009 and which is available at > >-> > >- > http://indico.cern.ch/getFile.py/access?sessionId=7&resId=1&materialId=0&c > onfId=4<http://indico.cern.ch/getFile.py/access?sessionId=7&resId=1&materialId=0&c%…> > > >-5473 > >-> Andreas UNTERKIRCHER explains that gLite 3.2 uses VDT 1.10, which > > >-> uses 'system OpenSSL'. > >-> > >-> > >-> ==> Can Andreas UNTERKIRCHER provide more precisions, and confirm that > >-> this permits interoperability at the X509 level ? > >-> > >-> ==> Can the PGI chairs plan an interoperability test ASAP to check if > >-> this really work ? > >-> > >-> > >-> In hope that the above informations and suggestions are useful. > >-> > >-> Best regards. > >-> > >-> ---------------------------------- > >-> Etienne URBAH IN2P3 - LAL > >-> Bat 200 91898 ORSAY France > >-> Tel: +33 1 64 46 84 87 > >-> Mob: +33 6 22 30 53 27 > >-> Skype: etienne.urbah > >-> mailto:urbah@lal.in2p3.fr > >-> ---------------------------------- > >-> > >-> > >-> On Mon, 23 Mar 200, Jens Jensen wrote: > >-> > 2009/3/20 weizhong qiang <weizhongqiang(a)gmail.com>: > >-> >> On Fri, Mar 20, 2009 at 3:00 PM, <m.riedel(a)fz-juelich.de> wrote: > >-> >> Basically the globus implementation if GSSAPI is about a specific > >-> >> context-initiation negotiation, and some data-padding for initiation > and > >-> >> data-transferring. Also you can accomplish proxy-delegation via it. > >-> >> What is for sure is that you can not use client based on normal TLS > to talk > >-> >> with service which is based on GSSAPI, or vice versa. > >-> >> AFAIK, There is some grid service (WS compliant) such as some SRM > service > >-> >> which uses GSSAPI. (SOAP + HTTP + GSS). > >-> > > >-> > Some years since I last looked at it in detail but IIRC GSSAPI > (RFC2743) is just > >-> > a mechanism for establishing security contexts - if you get these > >-> > bytes then send > >-> > this, etc. Presumably normal TLS can be implemented via GSSAPI as > well, see > >-> > eg section 5.3 of the RFC > >-> > Someone once told me Globus had to deviate from the standard GSSAPI > >-> > to implement GSI. If this is true then it's worth documenting, no? > >-> > Again long time ago I experimented with the Globus module for GSI and > >-> > the lower level Globus GSSAPI. At the time they did not interoperate > :-) > >-> > Had some discussions with Aleksandr at the time. > >-> > > >-> > Regards > >-> > --jens > >-> > >-> > >-> > >-> On Fri, 20 Mar 2009, Duane Merrill wrote: > >-> > In theory, rfc-3820 proxy certs should not have any effect on TLS > wire > >-> > protocol. For various reasons, different versions of GSI-OpenSSH > *have* > >-> > changed the wire format in different ways. (Shame on them.) Out of > >-> > curiosity, are there any published/publicly-availabe descriptions of > >-> > these deltas? > >-> > > >-> > Duane > >-> > >-_______________________________________________ > >-Pgi-wg mailing list > >-Pgi-wg(a)ogf.org > >-http://www.ogf.org/mailman/listinfo/pgi-wg > > > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg > > >

1 0

Re: [Pgi-wg] TLS : OpenSSL and GSI implementations - gLite 3.2released today
by weizhong qiang 27 Mar '09

27 Mar '09

2009/3/27 Morris Riedel <m.riedel(a)fz-juelich.de> > Ok, > > and that's why we have to support both in our profiles I guess - correct?! It depends what is the definition of the "both" here. Weizhong > > > > 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) > > > >------Original Message----- > >-From: pgi-wg-bounces(a)ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf > Of > >-Aleksandr Konstantinov > >-Sent: Friday, March 27, 2009 10:49 AM > >-To: pgi-wg(a)ogf.org > >-Subject: Re: [Pgi-wg] TLS : OpenSSL and GSI implementations - gLite > 3.2released > >-today > >- > >-On Monday 23 March 2009 15:04, Etienne URBAH wrote: > >-> To all, > >-> > >-> Concerning various implementations of TLS to handle X509 certificates > >-> and proxies, it seems that : > >-> > >-> - DEISA (Unicore) uses the OpenSSL implementation of TLS to process > >-> X509 certificates, > >-> > >-> - EGEE (gLite) and NorduGrid (ARC) use the GSI (Globus Security > >-> Infrastructure) implementation of TLS to process X509 proxies, > >- > >-No, ARC uses OpenSSL for TLS data connections and Globus for > >-GSI connections (SRM and GridFTP). > >- > >- > >-A.K. > >- > >- > >-> > >-> - The OpenSSL and GSI implementations of TLS seem to be INCOMPATIBLE > >-> (see mails below of Weizhong QIANG and Duane MERRIL). > >-> > >-> This would make any interoperability very difficult. > >-> > >-> > >-> But the situation is perhaps NOT so desperate : > >-> > >-> - EGEE has just released gLite version 3.2 today 23 March 2009. > >-> > >-> - In slide 3 of the presentation 'Middleware update' performed at CERN > >-> GDB on 11 March 2009 and which is available at > >-> > >- > http://indico.cern.ch/getFile.py/access?sessionId=7&resId=1&materialId=0&c > onfId=4<http://indico.cern.ch/getFile.py/access?sessionId=7&resId=1&materialId=0&c%…> > >-5473 > >-> Andreas UNTERKIRCHER explains that gLite 3.2 uses VDT 1.10, which > >-> uses 'system OpenSSL'. > >-> > >-> > >-> ==> Can Andreas UNTERKIRCHER provide more precisions, and confirm that > >-> this permits interoperability at the X509 level ? > >-> > >-> ==> Can the PGI chairs plan an interoperability test ASAP to check if > >-> this really work ? > >-> > >-> > >-> In hope that the above informations and suggestions are useful. > >-> > >-> Best regards. > >-> > >-> ---------------------------------- > >-> Etienne URBAH IN2P3 - LAL > >-> Bat 200 91898 ORSAY France > >-> Tel: +33 1 64 46 84 87 > >-> Mob: +33 6 22 30 53 27 > >-> Skype: etienne.urbah > >-> mailto:urbah@lal.in2p3.fr > >-> ---------------------------------- > >-> > >-> > >-> On Mon, 23 Mar 200, Jens Jensen wrote: > >-> > 2009/3/20 weizhong qiang <weizhongqiang(a)gmail.com>: > >-> >> On Fri, Mar 20, 2009 at 3:00 PM, <m.riedel(a)fz-juelich.de> wrote: > >-> >> Basically the globus implementation if GSSAPI is about a specific > >-> >> context-initiation negotiation, and some data-padding for initiation > and > >-> >> data-transferring. Also you can accomplish proxy-delegation via it. > >-> >> What is for sure is that you can not use client based on normal TLS > to talk > >-> >> with service which is based on GSSAPI, or vice versa. > >-> >> AFAIK, There is some grid service (WS compliant) such as some SRM > service > >-> >> which uses GSSAPI. (SOAP + HTTP + GSS). > >-> > > >-> > Some years since I last looked at it in detail but IIRC GSSAPI > (RFC2743) is just > >-> > a mechanism for establishing security contexts - if you get these > >-> > bytes then send > >-> > this, etc. Presumably normal TLS can be implemented via GSSAPI as > well, see > >-> > eg section 5.3 of the RFC > >-> > Someone once told me Globus had to deviate from the standard GSSAPI > >-> > to implement GSI. If this is true then it's worth documenting, no? > >-> > Again long time ago I experimented with the Globus module for GSI and > >-> > the lower level Globus GSSAPI. At the time they did not interoperate > :-) > >-> > Had some discussions with Aleksandr at the time. > >-> > > >-> > Regards > >-> > --jens > >-> > >-> > >-> > >-> On Fri, 20 Mar 2009, Duane Merrill wrote: > >-> > In theory, rfc-3820 proxy certs should not have any effect on TLS > wire > >-> > protocol. For various reasons, different versions of GSI-OpenSSH > *have* > >-> > changed the wire format in different ways. (Shame on them.) Out of > >-> > curiosity, are there any published/publicly-availabe descriptions of > >-> > these deltas? > >-> > > >-> > Duane > >-> > >-_______________________________________________ > >-Pgi-wg mailing list > >-Pgi-wg(a)ogf.org > >-http://www.ogf.org/mailman/listinfo/pgi-wg > > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg > >

2 1

Re: [Pgi-wg] OGF PGI - Security Model
by weizhong qiang 27 Mar '09

27 Mar '09

hi folks, 2009/3/26 Morris Riedel <m.riedel(a)fz-juelich.de> > Hi interop-friends, > > firstly sorry again for missing the last days. I have seen many comments > since then and unfortunately see that the different threads had been united > again mixing things up a bit (maybe it was nevertheless useful). > > > Finally Steven made a good point with 2-3 sec. models out of n^n ones. > > > > So finally we have reached to the ideas of my suggestions of having > well-defined different security 'plumbings' (aka 2-3 well-defined security > models). I don't care about its precise name... > > I just used this term 'plumbings' because it had no pre-definition in > security, please compare the vertical lines in the interoperability > reference model - they are just more simpler defined in terms of AUTHN and > ATTRIBUTE-AUTHZ than the long list presented by Etienne but very much of > its > content is the same. I presented this since OGF23&OGF24 within GIN with the > two ways (left AC and right SAML) and the open issues to work on, but never > had chance to write it down in written text yet: > > > http://www.ogf.org/OGF24/materials/1409/2008-09-16_GIN_SessionTwo_OGF24_Ried > el_v1.pdf<http://www.ogf.org/OGF24/materials/1409/2008-09-16_GIN_SessionTwo_OGF24_Rie…> > > Slide 6 and others... :-) > > Especially on this slide 6, even outsiders of our production Grids (like > Chris Smith) understood the meaning of the slide and I got positive > feedback > on this from numerous sides. > > > We all want to reach interoperability here in this group. > > We want to do this for certain interop applications. We shouldn't > underestimate the power of the combination of the different security > elements - nailing down the currently typical ways of using TLS with > certs, > Attr-Authz, Attributes, Constraints/Restrictions in conjunction are already > powerful. > > We will have precise PGI definition of aligning such building blocks even > if > there are two ways in the end - but there are less than n^n ways that are > currently out there in the security field combining different blocks, > profiles, etc.... > > > Also, what the middleware supports and what is then deployed in turn on > particular production Grids are both different stories! > > > For instance, UNICORE can be used with the proxy-style (plumbing) enabling > interoperability with gLite, ARC, NAREGI. We have done this for many > interop > use cases, for instance with portals requiring proxies. > > However, there should be also another full X.509 (plumbing) available where > other common approaches can be used and then expressed correctly via GLUE > in > interops as well used other infrastructures with different policies. I even > foresee that there could be used more than one plumbing in parallel. > Again, I don't see it is reasonable to put the support of proxy and full X.509 ("support" here means the verification of credential during the processing of TLS/SSL) in parallel. If the middleware supports proxy, then with no doubt it implicitly and naturally supports full X.509, since full X.509 support is just a specific scenario of proxy support, and also almost all of the middlewares support (or will support) proxy. But the principle does not apply vice versa. So I think it is not needed to define two profiles here in term of certificate support (proxy or full x509). So supporting proxy shoud be a mandatory requirement, IMO. > > > We may have still single islands in a way - but we also come closer > together, which is a good first step towards the right direction and my > suggestion to move forward in this complex security discussion since its > beginning. > > > > Which particular plumbings of both common approaches are then used in > production Grids is policy of the respective deployments of the middlewares > and may even depend on the underlying interop application use cases which > should be our most significant drivers (!) - BUT the main point is that we > know where we talking about in interop work without having n ^ n different > security setups available! > > > Only one short example: > > # There is one DB with attribute information about of end-users (used by > VOMS) > # Agreeing on the attribute semantics&Structure is important > My two cents here: 1. With or without voms AC in proxy extension is not a issue for authentication, while it is a issue for authorization. For those client carrying proxy certificates without voms AC extension can not access those services which requires those attributes from voms AC. But the rejection is only because service can not find the attributes which can match its local policy, not (should not) because anything else (for instance becaus of the service can not find voms AC). If the service can not find voms AC, it will try to find the attributes from some other place of the proxy certificate, for instance, if the DN of this proxy matches the grid-map file, the service will also give authorization. So supporting voms AC should be looked as optional. 2. For the format of voms AC, I think we probably should not put effors on the definition of it. It should be formated by other standalization group. Since there is only one implementation which support AC in grid community, we can simply adopt this implementation, and look it as de-facto standard. Weizhong Qiang > > # VOMS support interface for retrieving AC and also SAML assertions > # There are two ways of transporting the attributes that come out of the > same DB (used for later attr-authZ) > # Both transports have correct AuthN mechanisms (clarifies AuthN+ID-authZ) > # In the end using different plumbings, but the same attributes are then > evaluated against a policy describing maybe having equal policies based on > the same transported attributes of the same DB (re-alignment!) > # In the end what matter are the attributes a user has and what the policy > decides to do with them (if its XACML, ACLs, etc. is unimportant here), but > we should talk about the same things once we evaluate attributes. > > > I try to provide you more figures, etc. hopefully tomorrow - but on my > slides a lot of it has been already presented numerous times... we just > have > to nail it down - but in a more KISS style = Keep in Simple and > Sweet/Stupid! > > > > Your co-chair, > 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) > > >------Original Message----- > >-From: pgi-wg-bounces(a)ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf > Of > >-Steven Newhouse > >-Sent: Thursday, March 26, 2009 7:16 PM > >-To: Moreno Marzolla; Duane Merrill > >-Cc: pgi-wg(a)ogf.org; edges-na3(a)mail.edges-grid.eu; lodygens(a)lal.in2p3.fr > >-Subject: Re: [Pgi-wg] OGF PGI - Security Model > >- > >-> Having to build > >-> adapters to translate (if possible) credentials in different formats > >-is > >-> a compromise which is more reasonable than having to wait for all the > >-> middlewares of the world to move towards a common security > >-> infrastructure. > >- > >-In the short term... documenting and defining the 2 or 3 security models > >-is real progress. If a service only supports one of these I do not see > >-this as a problem - for all the reasons given. Providing credential > >-translation services to provide 'shims' (or bridges between these > >-islands) as an interim solution makes this work. Its a low risk to > >-individual services - they maintain their current stability - and can > >-migrate over time to support both or the most 'popular' one - let the > >-market decide! > >- > >-Each service can then advertise the mechanisms it supports and clients > >-can locate credential translation services as required. > >-_______________________________________________ > >-Pgi-wg mailing list > >-Pgi-wg(a)ogf.org > >-http://www.ogf.org/mailman/listinfo/pgi-wg > > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg > >

2 1

Re: [Pgi-wg] Sec: Agreement on attribute transportmechanismsforAttrAuthZ
by m.riedel＠fz-juelich.de 27 Mar '09

27 Mar '09

Howdy, >-PGI_TLS_PROXY (the notation is also in the virginia strawman) >-PGI_GSI so in this context what is the difference on TLS itself w/o considering different APIs?! Good point in checking this out - I'm still think its rather the same. 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: weizhong qiang <weizhongqiang(a)gmail.com> Date: Friday, March 20, 2009 1:10 pm Subject: Re: [Pgi-wg] Sec: Agreement on attribute transport mechanismsforAttrAuthZ > hi, > > PGI_TLS and PGI_GSI were mentioned by you in a few thread. > Again, I would like clarify something from my point of view. > Do you mean PGI_GSI the services/clients that talk to each other > by using > GSSAPI? > or just talk to each other based on TLS while using proxy > certificate. I > think there is difference between them. > So I would divide them into branch by using your notation: > PGI_TLS > PGI_TLS_PROXY (the notation is also in the virginia strawman) > PGI_GSI > > > 2009/3/20 Morris Riedel <m.riedel(a)fz-juelich.de> > > > 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. > > > > > > > > > > > > However, can we expect that you one contact a CREAM-BES any time > soon with > > full end-entity credentials or any other gLite component? > > > The CREAM service has been tested (by some of our colleagues) . > And the > result shows CREAM service requires "limited" proxy certificate > (proxy with > "CN=proxy") when it doing data transfer. > > Inherently, because of forwarding mechanisms internally – proxies are > > necessary probably. > > > > > > > > But maybe that’s my old interop* knowledge – so let’s clarify again… > > > > > > > > Some statements that need clarification: > > > > > > > > Note: UNICORE can be contacted using PGI_TLS and PGI_GSI – the > same is > > planned for GENESIS-II as far as I remember. > > > "and PGI_GSI" means PGI_TLS_PROXY or PGI_GSI? > From out experience about testing against UNICORE service, it uses > PGI_TLS_PROXY. > > > > > > > > > > Q: Do gLite also supports pure PGI_TLS apart from PGI_GSI? > > > > > > > > > > > > Q: Do ARC also supports pure PGI_TLS apart from PGI_GSI? > > > PGI_TLS > PGI_TLS_PROXY > possible to support PGI_GSI (the definition I mentioned) > > > > > > > > > > > > Q: Do we really imply that PGI-compliance means that both > PGI_GSI and pure > > PGI_TLS have to be supported? Or we rather go the plumbing way > of defining > > either or as MANDATORY and as MAY both supported (two plumbings). > > > I see PGI_TLS_PROXY should be mandatory. > > Regards, > > Weizhong > > > > > > Thanks for clarification, > > > > Morris > > > > > > > > > > > > *From:* Steven Newhouse [Steven.Newhouse(a)cern.ch] > > *Sent:* Friday, March 20, 2009 11:49 AM > > *To:* weizhong qiang; Morris Riedel > > *Cc:* pgi-wg(a)ogf.org > > *Subject:* RE: [Pgi-wg] Sec: Agreement on attribute transport > > mechanismsforAttrAuthZ > > > > > > > > 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. > > > > > > > > And to clearly describe the interoperability benefits that will > be derived > > (i.e. systems and communities) by making that change. > > > > > > > > Steven > > > > _______________________________________________ > > 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 ------------------------------------------------------------------- -------------------------------------------------------------------

7 6

Re: [Pgi-wg] REMINDER: Agenda and Numbers: PGI Security TelCon 4pm(CET) TODAY
by Steven Newhouse 27 Mar '09

27 Mar '09

> I attended several of these meeting before - and as far as I remember > there was never a dial-in, but I'm gonna ask of course. Morris - I have already asked. There will be. Once I have the details I will send them out. Steven

2 1

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

27 Mar '09

Hi, >- This is the problem you mentioned which we experienced during the OMII-EU project: BES clients were not executing the delegation operation, so the service did not have any delegated credentials to use. We then implemented a horrible workaround in CREAM which was fine for demonstration purposes, but unfortunately can not be applied for any real use. ok, that's interesting - if you don't extract the proxy obviously then from TLS level during AuthN steps - why is there still a proxy support needed on the TLS level then?! Q: It looks like now all middlewares can be accessed then easily with using full end-entity certificates: UNICORE, GENESIS-II, gLite,.. What about ARC? Thanks for pointing this out Moreno - indeed helpful - I missed that new fact. 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: Moreno Marzolla <moreno.marzolla(a)pd.infn.it> Date: Friday, March 20, 2009 3:25 pm Subject: Re: [Pgi-wg] Sec: Agreement on attribute transportmechanismsforAttrAuthZ > m.riedel(a)fz-juelich.de wrote: > > Hi, > > > >> - The gLite CREAM CE can be accessed either with pure TLS (X509 > > certificate) or using GSI (proxy-based) authentication. I think that > > the same holds for other gLite components as well. > > > > > > So your service can work w/o proxies? Maybe for the initial > AuthN yes > > - but for further use I guess you require a proxy for forwarding to > > CREAM or so?! > > You can invoke any CREAM operation using either a plain X509 > certificate, or a proxy certificate. In either case you can use > the > service without problems. HOWEVER, in order to submit a job you > NEED to > delegate a proxy to CREAM by first invoking the delegation port- > type. > Once you have delegated a proxy, you can create/cancel/monitor > your jobs > with plain X509 certificates. > > Note that in order to contact the delegation port-type you can use > either an X509 certificate, or a proxy certificate. > > So, a client with *only* an X509 certificate can perform any > operation > on CREAM, PROVIDED that FIRST it delegates its credential to CREAM > by > performing a delegation operation. A client with a delegated proxy > can > also execute any operation on CREAM, provided that it further > delegates > its credentials to CREAM. > > This is the problem you mentioned which we experienced during the > OMII-EU project: BES clients were not executing the delegation > operation, so the service did not have any delegated credentials > to use. > We then implemented a horrible workaround in CREAM which was fine > for > demonstration purposes, but unfortunately can not be applied for > any > real use. > > Moreno > > -- > Moreno Marzolla > INFN Sezione di Padova, via Marzolo 8, 35131 PADOVA, Italy > EMail: moreno.marzolla(a)pd.infn.it Phone: +39 049 8277103 > WWW : http://www.dsi.unive.it/~marzolla Fax : +39 049 8756233 > > ------------------------------------------------------------------- ------------------------------------------------------------------- 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 ------------------------------------------------------------------- -------------------------------------------------------------------

4 3

Re: [Pgi-wg] REMINDER: Agenda and Numbers: PGI Security TelCon 4pm(CET) TODAY
by Steven Newhouse 27 Mar '09

27 Mar '09

> (2) > PGI Security Talk for Tuesday next week (MWSG Group Meeting, Zürich) We should be able to provide a dialin for this part of the meeting and the discussion that follows. Steven

2 1

Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman)
by m.riedel＠fz-juelich.de 27 Mar '09

27 Mar '09

Right, but if I have an EPR obtained from UNICORE-BES (wsa:To + referenceproperties) that a client of ARC can't handle it rightly would break our desired interop by maybe just using wsa:To URIs... ...it seems like we have a lot wheels to work on...one after another. Let's not give up - at least the right set of people are this time together in the group representing the right middleware assembly... I'm delighted to join the call soon... In CET is currently 3:30 p.m. 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: Friday, March 20, 2009 3:22 pm Subject: Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman) > > So I see a demand that we discuss if our services are contacted with > > WS-Addressing or not. > > > In case this thread turns into a referendum on the merits of WS- > Addressing,I would like to point out that that the Basic Execution > Service (BES) spec > incorporates EPRs into its interface. > > So, if PGI has apsirations to discuss anything that resembles BES, > supportfor WS-Addressing would be a Good Idea if for no other > other reason that to > not have to completely re-invent the BES wheel (again). > > -Duane > ------------------------------------------------------------------- ------------------------------------------------------------------- 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 ------------------------------------------------------------------- -------------------------------------------------------------------

4 3

Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman)
by m.riedel＠fz-juelich.de 27 Mar '09

27 Mar '09

Ok, I understand much better know. So I see a demand that we discuss if our services are contacted with WS-Addressing or not. Q: How does ARC services then distinguish one instance from another if only one URL is used?! you don't seem to use referenceproperties then, instead adding to the url resource-instance ids?! 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:44 pm Subject: Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman) > On Friday 20 March 2009 12:24, Morris Riedel wrote: > > Hi, > > > > >- As I > > >-explained in an earlier mail, "limited" here means that the > PGI profile > > >-shall precisely described in a self-contained way the minimum > set of EPR > > >-elements which must be supported by conforming inplementations. > > > > So far, I guess we only depend on the wsa:To element of the > specification> with the URI making it the minimum element of it. > > > > With WS-Naming this would be expanded using wsa:metadata and ws- > naming> elements of course. > > > > Isn't our usual procedure to take the URI - encode an EPR (with > wsa:To) and > > send it to the BES systems? Or is this maybe only my narrow > UNICORE view of > > how we do it? > > > > Q: What is meant by accessing a CREAM-BES and A-REX with URI > (instead of > > EPRs)? > > ARC does not rely on EPR present in SOAP messages header sent to > BES service. > ARC clients do put EPRs into headers for compatibility. > Hosting environment of ARC services may perform routing of > messages depending > on wsa:To element of EPR. > To make it short - we can live with and without EPRs. > AFAIR BES specs say nothing about if BES service has to be > contacted using EPRs. > > > > 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 ------------------------------------------------------------------- -------------------------------------------------------------------

4 4

REMINDER: Agenda and Numbers: PGI Security TelCon 4pm (CET) TODAY
by Morris Riedel 27 Mar '09

27 Mar '09

Hi PGI team, Just a short reminder for our TelCon: TODAY - 4 pm CET (1 hour) Call-in details as follow: via Skype call +9900827049931906 (free of charge) ordinary phone numbers (local rates) with the 9931906 conference number: Austria 0820 401 15470 Belgium 0703 57 134 France 0826 109 071 Germany +49 (0) 180 500 9527 Switzerland 0848 560 397 Proposed agenda: (1) OGF PGI Security model (see emails) and 'plumbing' approach (2) PGI Security Talk for Tuesday next week (MWSG Group Meeting, Zürich) (3) Shortly the matrix about security in the wiki (4) PGI abbreviations/terms list provided by Johannes (5) AOB Please feel free to contact me if you would like to add certain agenda topics. I encourage all security folks to further discuss our issues on the mailing list in order to save valuable time for questions/clarifications during the TelCon. 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