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

Re: [Pgi-wg] OGF PGI - Security Strawman
by Duane Merrill 27 Mar '09

27 Mar '09

Since we are talking about dynamically advertising the requirements of services (and not clients) within hypothetical information services, we should talk explicily about "service plumbing" and not "client plumbing". For example: - Service endpoint *requires *xyz (e.g., delegation-step, WS-Addressing reference parameters, TLS mutual authentication, etc.) - Service endpoint *can accept* xyz (e.g., TLS proxy-path-validation, SOAP WS-S proxy-path-validation, PGI VOMS-ACs, PGI SAML ACs, TLS client-anonymous authentication, etc) It is implicit that we will be putting in effort to implement clients that fit within the realm of options provided by the services that those clients intend to use. (And it is has become clear from several from these email threads which services those are.) Thus "grid islands" become "grid DAGs". -Duane 2009/3/27 Morris Riedel <m.riedel(a)fz-juelich.de> > Hi, > >- Currently all sentence are read on this mailing lists looked like > requiring only listed options to be used for authorization. And this is > wrong from my point of view. > > > I refer to two different plumbings nothing more. This already narrows down the > thousand other possibilities... > > 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: Aleksandr Konstantinov [mailto:aleksandr.konstantinov@fys.uio.no] > > >-Sent: Friday, March 27, 2009 2:40 PM >-To: Morris Riedel > >-Cc: pgi-wg(a)ogf.org > >-Subject: Re: [Pgi-wg] OGF PGI - Security Strawman > >- > > >-On Friday 27 March 2009 14:39, Morris Riedel wrote: >-> But Aleksandr - > I think we all agree to the VOMS scenario - come on > that’s > >-> something where we can't go currently... :-) > >- > >-As I already said I'm not suggesting to profile other information whihc > can be used > >-for authorization. > >-I said that such information should not be disallowed. Just write profile > in such way > >-that other options > >-are up to deployment. Currently all sentence are read on this mailing > lists looked like > >-requiring only > >-listed options to be used for authorization. And this is wrong from my > point of view. > >- > >- > >-A.K. > >- > >- > >- > >-> > >-> ------------------------------------------------------------ > >-> 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: Aleksandr Konstantinov > [mailto:aleksandr.konstantinov@fys.uio.no] > >-> >-Sent: Friday, March 27, 2009 1:29 PM > >-> >-To: Morris Riedel > >-> >-Subject: Re: [Pgi-wg] OGF PGI - Security Strawman > >-> >- > >-> >-On Friday 27 March 2009 12:24, you wrote: > >-> >-> Aleksandr, > >-> >-> > >-> >-> could you give me one example for this: > >-> >-> > >-> >-> >- I do support idea of attribute based authorization. But can't > >-> understand > >-> >-> why other information authenticating the client should be > disallowed > >-> from > >-> >-> making authorization decision. > >-> >-> > >-> >-> > >-> >-> I seek to understand what you mean. > >-> >- > >-> >- > >-> >-Most brutal example would be DN of X.509 certificate. > >-> >-More sophisticated could be distrust of specific computing resource > for > >-> specific > >-> >-VOMS service. > >-> >- > >-> >-A.K. > > >-> > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg > > >

2 1

Figures about Authorization plumbings
by Morris Riedel 27 Mar '09

27 Mar '09

Hi team, actually I drafted three figures for AuthZ plumbings as well: http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.pgi-wg/doc man.root.meeting_materials.2009_03_30_mwsg_pgi_talk/doc15588 have a look if you find time - and please feel free to look and/or modify the ppt as you like. Hear you soon in the TelCon, 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

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

27 Mar '09

Morris Riedel wrote: > > OpenSSL Proxy-based TLSs are different from GSI-Proxy-based TLSs – as > far as I understood from my interop experiences and from our conversations. Actually, they are the same. You are thinking about legacy proxies, which are indeed different. However, from GT4 onward, RFC proxies (OpenSSL) proxies, are supported. Ciao, Vincenzo > > > > 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 > <mailto:m.riedel@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 <mailto:m.riedel@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> > [mailto:pgi-wg-bounces@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 <mailto:pgi-wg@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 <mailto:urbah@lal.in2p3.fr> > >-> ---------------------------------- > >-> > >-> > >-> On Mon, 23 Mar 200, Jens Jensen wrote: > >-> > 2009/3/20 weizhong qiang <weizhongqiang(a)gmail.com > <mailto:weizhongqiang@gmail.com>>: > >-> >> On Fri, Mar 20, 2009 at 3:00 PM, <m.riedel(a)fz-juelich.de > <mailto:m.riedel@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 <mailto:Pgi-wg@ogf.org> > >-http://www.ogf.org/mailman/listinfo/pgi-wg > > > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org <mailto:Pgi-wg@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

4 5

Some slides for authentication considerations in GridForge now
by Morris Riedel 27 Mar '09

27 Mar '09

Hi PGI team, I think we getting closer somehow and understand each other more and more... :-) I drafted some slides that I put in Gridforge of how I see the 3 different Authentication profile options: http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.pgi-wg/doc man.root.meeting_materials.2009_03_30_mwsg_pgi_talk/doc15587 Please comment or modify as you like (typical ppt) - but for now please keep the AuthZ out of the play. If you find time please upload them also before the telcon starts... 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

Re: [Pgi-wg] More information on Security Plumbings (with GLUE dependencies)
by Duane Merrill 27 Mar '09

27 Mar '09

You *have* to support WS-Addressing in order to leverage the BES spec. Why are you (re)defining endpoint properties in GLUE instead of re-using existing ways of describing the same in EPR documents? -Duane 2009/3/27 Morris Riedel <m.riedel(a)fz-juelich.de> > Hi team, > > > So in my mail from yesterday evening, I referred again to the plumbings > and before I will draft now slides/factsheets I would like to shortly point > out again what I mean with it - maybe more explicitly - although this has > been already discussed with several AuthZ specialists in prior OGFs or > other > events (e.g. Valerio Venturi, etc.). > > Major idea: Simple + Stupid - not cracking the security dilemma, but > creating a significant step towards DEFINING the common security > models/plumbings: > > # First of all, the clients choose the client technology they like or find > convenient for their science (maybe even business) - I think that's > something where we all agree to. > > > ###### > 1 - Pluming Type: Authentication (either-or) > > = TWO choices here: PGI_AUTHN_ENDENTITY or PGI_AUTHN_PROXIES (meaning one > has to support the chain checkings) > > > > # an end-user uses this client with an PGI out-of-band mechanism (maybe > LDAP > queries) to retrieve GLUE-based information about a certain endpoint > getting: > > # endpoint contact information (i.e. BES URL) AND > > # GLUE SECURITY.AUTHENTICATION capability of this endpoint > > # The value of this capability is either PGI_AUTHN_ENDENTITY or > PGI_AUTHN_PROXIES > > # The client know how to contact the endpoint on the TLS level then, which > is in PGI the foundation for AUTHN > > > > ###### > 2 - Plumbing Type: Attibute-based AuthZ (at least one of it) > > = TWO choices here: PGI_AUTHZ_AC or PGI_AUTHZ_SAML > > # an end-user uses his client again (or retrieved information with the > first > request) with an PGI out-of-band mechanism (maybe LDAP queries) to retrieve > GLUE-based information about a certain endpoint getting: > > apart from the above information: > > # GLUE SECURITY.AUTHORIZATION capability of this endpoint > > > # The value of this capability is AT LEAST ONE of PGI_AUTHZ_AC, > PGI_AUTHZ_SAML - maybe even both > > > # The client knows how the attributes have to be transported to the > endpoint > then so that the endpoint understands them and uses them for attr-authz > based on resource-owner policies. > > > > #### > The bottom line is that we just have to define a few bits and pieces > precisely that are PGI_AUTHN_ENDENTITY, PGI_AUTHN_PROXIES , PGI_AUTHZ_AC, > PGI_AUTHZ_SAML. Each of it well-defined with respect to used standards, > IETF > RFCs, OASIS SAML, like Etienne listed... > > > With that we significantly narrow down the possibilities in terms of > security while we have two different types of plumbings that are easy to > understand: AuthN + Attr-AuthZ. > > > Maybe we need another plumbing because of the difference of using the > incompatible general proxies and GSI proxies on the TLS level, but both are > part of the AuthN plumbing type. Maybe in future this incompatibility is > fixed and then one plumbing might be just removed without changing > standards. > > > ### > Looking from the end-user point of view seeing a united federation of Grid > systems, the user uses his client that may only support one plumbing in > terms of attr-AuthZ . In that matter the client only queries from the > out-of-band-information service GLUE-described endpoints that only supports > these systems that match with the supported plumbings from the client (and > matched other requirements like cores/memory/interconnection of course). > > > Of course, we have to agree on the transported attribute structure - but > the > deployment of plumbings is policy of the respective infrastructures. The > infrastructures may even setup two endpoints with different plumbings to > support more clients that is still better than having a complete middleware > co-existence at the resource level... > > > > Hence, the idea of the plumbings was to have a relatively easy to > understand > mechanism to describe what end-user clients require to understand when > performing interoperability use cases. Also, as you see in my figures, the > security plumbings are close to the information plumbing (i.e. GLUE) > meaning > that both have to be installed in a working house. > > > I hope the idea of plumbings got much clearer now, but I will try to > provide > some figures for the telcon this afternoon. Like the reference model term, > also the plumbings term can be changed to something more understandable. > > > Of course, the plumbings are only my suggestion coming from GIN interop. > use case experience and working in the field of interop for many years now > - > of course its still subject to discussion - but it has much potential to > bringing us closer together NOW instead of waiting for a huge common > security framework in the future that may not even be defined (+deployed!) > before the Grid fundings are stopped... > > > > > Finally, with looking from a slightly distance on the group, I'm happy that > we are still in the process of jointly discussing in the group and no one > leaves and thus I'm confident that we can act as a team to provide > something > useful to the Grid community, which is maybe not the perfect solution in > terms of security, but a good step forward bridging different worlds - > achieving interoperability at least between several Grid islands... > > > > > 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) > > > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg > >

1 0

Re: [Pgi-wg] Sec: Agreement on attributetransportmechanismsforAttrAuthZ
by Aleksandr Konstantinov 27 Mar '09

27 Mar '09

On Friday 27 March 2009 15:53, you wrote: > Hi, > > > (B) > > > > I use a OpenSSL proxy to establish an OpenSSL-based proxy TLS > > connection (which included C) each hop creates new proxy-pair > > >TLS connection by itself can't create >*new* proxy. One needs some > >additional way to do that. > > > Of course, so you do: > > (1) Create a new proxy using OpenSSL > (2) using this proxy to create the TLS connection > > Is that wrong? That depends if TLS connection in next hop is going to be established using identity impersonation. If yes, then step (1) can't be performed because previous step did not provide delegated credentials. (Or did it? Delegation is very tightly coupled here.) If no, then credentials of service (or whatever is available) are used and step (1) is not necessary. A.K.

1 0

Re: [Pgi-wg] Sec: Agreement on attributetransportmechanismsforAttrAuthZ
by Aleksandr Konstantinov 27 Mar '09

27 Mar '09

On Friday 27 March 2009 15:03, you wrote: > Yes, > > > > thats what I meant I guess we just need two because of some legacy > production systems?! > > > > > > When I think about opening a TLS I think the following options exist: > > > > > > (A) > > I use a GSI Proxy to establish a GSI-based TLS connection each hop creates > a new proxy-pair. You are falling to delegation. Should it be a different topic? > > > > (B) > > I use a OpenSSL proxy to establish an OpenSSL-based proxy TLS connection > (which included C) each hop creates new proxy-pair TLS connection by itself can't create *new* proxy. One needs some additional way to do that. > > > > (C) > > I use a full end-entity certificate to establish a TLS connection > > > > > > Would you agree on this one with me and what do others think, e.g. gLite? > > > > > > Thanks, > > 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" No, thanks. signed, 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 1:46 PM > To: Morris Riedel > Cc: Aleksandr Konstantinov; pgi-wg(a)ogf.org > Subject: Re: [Pgi-wg] Sec: Agreement on > attributetransportmechanismsforAttrAuthZ > > > > > > 2009/3/27 Morris Riedel <m.riedel(a)fz-juelich.de> > > Hi, > > >- Of course. "Full certificate" is just an extreme case of proxy > > certificate - like table without legs. > > Unfortunately, we heard earlier that this is not generally the case since > GSI proxy-based TLS changes also the wire or handshaking process while I > agree with end-entity TLS is a subset (as chain length 0 proxy) of normal > TLS. > > However, in practical works I have done in scenarios - I learned we have to > support both. So I see that we have to support both?! > > > There are at least two "both" from my understanding here: > 1, in terms of certificate itself, both full X.509 and proxy certificate; > and support means the verification of certificate, and only normal TLS wire > protocol is used. > Which you agree from your sentence, I think. > > 2, in terms of wire protocol, both TLS and GSI, which practically are > incompatible. > I guess your question is about this one. > I propose we can have two profiles about this, while mentioning GSI (wire > protocol) profile is only for legacy reason, but is not recommended. > > > Weizhong Qiang > > > > > > Take care, > Morris > > > >

2 2

Re: [Pgi-wg] OGF PGI - Security Strawman
by Aleksandr Konstantinov 27 Mar '09

27 Mar '09

On Friday 27 March 2009 14:39, Morris Riedel wrote: > But Aleksandr - I think we all agree to the VOMS scenario - come on thats > something where we can't go currently... :-) As I already said I'm not suggesting to profile other information whihc can be used for authorization. I said that such information should not be disallowed. Just write profile in such way that other options are up to deployment. Currently all sentence are read on this mailing lists looked like requiring only listed options to be used for authorization. And this is wrong from my point of view. A.K. > > ------------------------------------------------------------ > 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: Aleksandr Konstantinov [mailto:aleksandr.konstantinov@fys.uio.no] > >-Sent: Friday, March 27, 2009 1:29 PM > >-To: Morris Riedel > >-Subject: Re: [Pgi-wg] OGF PGI - Security Strawman > >- > >-On Friday 27 March 2009 12:24, you wrote: > >-> Aleksandr, > >-> > >-> could you give me one example for this: > >-> > >-> >- I do support idea of attribute based authorization. But can't > understand > >-> why other information authenticating the client should be disallowed > from > >-> making authorization decision. > >-> > >-> > >-> I seek to understand what you mean. > >- > >- > >-Most brutal example would be DN of X.509 certificate. > >-More sophisticated could be distrust of specific computing resource for > specific > >-VOMS service. > >- > >-A.K. >

2 1

Re: [Pgi-wg] Sec: Agreement on attributetransportmechanismsforAttrAuthZ
by weizhong qiang 27 Mar '09

27 Mar '09

2009/3/27 Morris Riedel <m.riedel(a)fz-juelich.de> > Hi, > > >- Of course. "Full certificate" is just an extreme case of proxy > certificate - like table without legs. > > Unfortunately, we heard earlier that this is not generally the case since > GSI proxy-based TLS changes also the wire or handshaking process while I > agree with end-entity TLS is a subset (as chain length 0 proxy) of normal > TLS. > > However, in practical works I have done in scenarios - I learned we have to > support both. So I see that we have to support both?! There are at least two "both" from my understanding here: 1, in terms of certificate itself, both full X.509 and proxy certificate; and support means the verification of certificate, and only normal TLS wire protocol is used. Which you agree from your sentence, I think. 2, in terms of wire protocol, both TLS and GSI, which practically are incompatible. I guess your question is about this one. I propose we can have two profiles about this, while mentioning GSI (wire protocol) profile is only for legacy reason, but is not recommended. Weizhong Qiang > > > Take care, > Morris > >

2 1

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

27 Mar '09

On Friday 27 March 2009 11:52, you wrote: > Ok, > > and that's why we have to support both in our profiles I guess - correct?! > Definitely not because of ARC. Rather vice versa. :) A.K. > > 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 > >-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 >

2 1