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

Re: [Pgi-wg] Sec: Agreement on supported Attribute Authority Interfaces
by Steven Newhouse 21 Mar '09

21 Mar '09

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

2 2

GSI OpenSsh
by Duane Merrill 20 Mar '09

20 Mar '09

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

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

ok, consider two EPRs with exactly the same wsa:to elements and only the referenceparameter is different indicating the different resources behind the service interface. How do you visualize/deal with the different EPRs if they are opaque!? 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:39 pm Subject: Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman) > On Fri, Mar 20, 2009 at 10:30 AM, <m.riedel(a)fz-juelich.de> wrote: > > > > > 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... > > > > The beauty of WS-Addressing is that reference parameters are > opaque. As a > client, *you don't need to know* how to handle them. And as a > service, you > don't need to know how to handle any other service's reference > parameterseither. Only your own (and only then if you decide to > have them.) > > -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 ------------------------------------------------------------------- -------------------------------------------------------------------

2 1

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

20 Mar '09

Hi, >- 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. I made this experience as well - but a few month ago... Maybe things have been changed like within gLite then? 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: Friday, March 20, 2009 3:41 pm Subject: Re: [Pgi-wg] Sec: Agreement on attribute transportmechanismsforAttrAuthZ > On Fri, Mar 20, 2009 at 3:00 PM, <m.riedel(a)fz-juelich.de> wrote: > > > 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?! > > > > 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 > servicewhich uses GSSAPI. (SOAP + HTTP + GSS). > > > Weizhong > > > > > > Good point in checking this out - I'm still think its rather > the same. > > > > Thanks for clarification, > > Morris > > > > > > > ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

2 1

PGI Meeting Minutes Location
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

Hi folks, I just get questions regarding the minutes location. Please note that the minutes of each TelCon (+ OGF sessions) are in the gridforge 'discussion' section: http://forge.gridforum.org/sf/discussion/do/listTopics/projects.pgi-wg/disc… Hear you soon, 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: m.riedel(a)fz-juelich.de Date: Friday, March 20, 2009 3:46 pm Subject: Re: [Pgi-wg] Sec: Agreement onattributetransportmechanismsforAttrAuthZ > Hi, > > >- 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. > > I made this experience as well - but a few month ago... > > Maybe things have been changed like within gLite then? > > 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: Friday, March 20, 2009 3:41 pm > Subject: Re: [Pgi-wg] Sec: Agreement on attribute > transportmechanismsforAttrAuthZ > > On Fri, Mar 20, 2009 at 3:00 PM, <m.riedel(a)fz-juelich.de> wrote: > > > > > 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?! > > > > > > > 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 > > servicewhich uses GSSAPI. (SOAP + HTTP + GSS). > > > > > > Weizhong > > > > > > > > > > Good point in checking this out - I'm still think its rather > > the same. > > > > > > Thanks for clarification, > > > Morris > > > > > > > > > > > > > > > ------------------------------------------------------------------- > ------------------------------------------------------------------- > Forschungszentrum Juelich GmbH > 52425 Juelich > > Sitz der Gesellschaft: Juelich > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe > Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), > Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, > Dr. Sebastian M. Schmidt > ------------------------------------------------------------------- > ------------------------------------------------------------------- > _______________________________________________ > 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, >- Proxy certs require *additional* path validation. Exactly, that's where it is all about - I think we still misunderstand each other. In using your e-mail I try: Before I send someone an attach - I would like to know if the person has an email system with or w/o attachments ;-) That's my point - but let's discuss in the telcon about it. We are not talking about the same things. 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 1:52 pm Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication > I strongly disagree. > > Proxy certs require *additional* path validation. You *still* > have to do > the same PKC path validation on the EEC that the proxies chain to. > This > work has to be done regardless of whether there are proxy > certificates in > the chain. This is a clear "is-a" relationship, a superset of > functionalitywith PCs. > > Let me illustrate with an analogy: You are tasked to provide > requirementsfor an email system. What you are suggesting is > analagous to a requirement > that > > "The email system must EITHER support email-without-attachments OR > email-with-attachments." > > My point is that if you build an email system to support > email-with-attachments you have implicitly already built a system > to support > email-without-attachments. > > If you make it a requirement to reject PKCs explicitly, you are > creatingunnecessary additional complexity in both your services > (by explicitly > rejecting certs that do not have the proxy extension) and in your > clients(by mandating that callers with statically-assigned > credentials create a > proxy to delegate to themselves just so they can use your service). > > -Duane > > > > On Thu, Mar 19, 2009 at 1:20 PM, <m.riedel(a)fz-juelich.de> wrote: > > > 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 > > ----------------------------------------------------------------- > -- > > ----------------------------------------------------------------- > -- > > > > > > > ------------------------------------------------------------------- ------------------------------------------------------------------- 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] Discussion about elements/priorities in the field of security
by weizhong qiang 20 Mar '09

20 Mar '09

hi, Thanks for throwing out those points. 2009/3/17 Morris Riedel <m.riedel(a)fz-juelich.de> > Hi PGI security folks, > > > currently I see five major elements in terms of security related to PGI: > > > (1) > Authentication/Attribute-based Authorization (i.e. plumbings as named > earlier), maybe first push-based before looking at pull-based models - > although, this of course, can be discussed as well among us. If we are talking about attributes carried inside SAML assetion, getting the attributes from attribute authority is not a challenge, for instance we can use the VOMS SAML service (client gets back SAML assertion that including attributes through SSL authentication with VOMS SAML service) as a candidate. But how to push the SAML assertion from client side to service side could be a challenge (for which voms has not provided solution, IMO). I can see two ways: one ways is put the SAML assertion into X.509 proxy certificate's extension, by which you can gurantee that the attributes information is binded with SSL authentication; the other way is to put SAML assertion in the SOAP header, which furtherly cause two branches: First brach, using the SAML assertion for message (SOAP) level authentication + attribute carraying (in this case the VOMS SAML service should probably be improved to creat SAML response containing a holder-of-key authentication assertion, then this assertion can be used for message level authentication according to WS-Security SAML Token profile 1.1); Second branch, using SAML assetion only for attribute carraying (in this case, the transport level securiry should be configured). I heard that VOMS attribute service is used in UNICORE, could some collegues provide some details about how the above scenario is processed? In case of ARC, it can get back SAML assertion from VOMS SAML service, and it can put the SAML assertion as extension of proxy certificate; It also support WS-Security (SAML Token profile, as well as UsernameToken and X.509 Token), but how to getting a SAMLToken is lacked. Maybe people from OGSA-AuthZ group can give some suggestions. > > > > (2) > Agreement on Definition/Semantics/Structure of Attributes Has the usage of SAML attribute assertion been decided? > > > > (3) > Encoding of delegation restriction/constraints The restriction is about what kind of policy will be used? > > > > (4) > Interface of delegation service (maybe based on subset of WS-Trust) > > > > (5) > Agreement on third party credentials transportation (e.g. a delegated > GridFTP proxy/SAML assertion-based access for data-staging during BES > submissions) > > > As a starting point - have I forgot something in this enumeration? If so - > please answer to this thread. > > > In terms of priorities, I would suggest to focus first on number one, but > of > course feel free to comment within this thread. Agree, IMO, the whole profile which will be adopted is mostly important. Regards, Weizhong > > > > Your co-chair, > Morris > > P.S. I cc'ed the area director of security (David Groep) to ensure that we > did not duplicate efforts done elsewhere (i.e. in the OGSA-AuthZ group). We > have been in touch about a few security issues raised in GIN earlier. CIAO. > > > ------------------------------------------------------------ > 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 > >

2 3

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

20 Mar '09

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?! In other words, if someone access your service with a proxy he is authenticated but can't work with the service since its requiring proxies?! Then, if not presented at TLS level, where do you get the proxy from? 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 1:24 pm Subject: Re: [Pgi-wg] Sec: Agreement on attribute transport mechanismsforAttrAuthZ > Morris Riedel wrote: > [...] > > Q: Do gLite also supports pure PGI_TLS apart from PGI_GSI? > > 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. > > 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 ------------------------------------------------------------------- -------------------------------------------------------------------

2 1

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

20 Mar '09

YES! >- As Weizhong mentions, there are additional validation steps in the event that GSI detects the presence of a proxy-extension within a certficate during handshake. But nothing that affects wire protocol. And exactly because of this fact we have to indicate which services have to take these validation steps and which not. Q: The question is thus how you indicate within the PGI profiles that you support proxies or only full certificates (w/o additional validation steps). We getting closer... 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.' Content-Type: multipart/alternative; boundary=00163646c4b66c64ef04658ce960 --00163646c4b66c64ef04658ce960 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > > I think Weizhong means implmentation of GSIAPI like one from Globus which > does have > own communication protocol incompatible with TLS. > I don't believe there are any protocol changes between the secure-communication in GSI-API (GSI-OpenSSL) and TLS. As Weizhong mentions, there are additional validation steps in the event that GSI detects the presence of a proxy-extension within a certficate during handshake. But nothing that affects wire protocol. -Duane --00163646c4b66c64ef04658ce960 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"> <div class=3D"im">=A0</div>I think Weizhong means implmentation of GSIAPI l= ike one from Globus which does have<br>own communication protocol incompati= ble with TLS.<br><font color=3D"#888888"></font></blockquote> <div>=A0</div> <div>=A0</div> <div>=A0</div> <div>I don't believe there are any protocol changes between the secure-= communication in GSI-API (GSI-OpenSSL) and TLS.=A0 </div> <div>=A0</div> <div>As Weizhong mentions, there are additional validation steps in the eve= nt that GSI detects the presence of a proxy-extension within a certficate d= uring handshake.=A0 But nothing that affects wire protocol.</div> <div>=A0</div> <div>-Duane</div></div> --00163646c4b66c64ef04658ce960-- ------------------------------------------------------------------- ------------------------------------------------------------------- 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 ------------------------------------------------------------------- ------------------------------------------------------------------- _______________________________________________ Pgi-wg mailing list Pgi-wg(a)ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg

1 0

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

20 Mar '09

Hi, >- I think Weizhong means implmentation of GSIAPI like one from Globus which does have >- own communication protocol incompatible with TLS. And I guess this is where all the misunderstandings comming from related to PGI_GSI or 'proxy-based TLS' :-) 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:22 pm Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication > On Friday 20 March 2009 15:14, Duane Merrill wrote: > > Embedded comments.... > > > > 2009/3/19 weizhong qiang <weizhongqiang(a)gmail.com> > > > > > > > > > > > On Thu, Mar 19, 2009 at 6:27 PM, <m.riedel(a)fz-juelich.de> wrote: > > > > > >> Hi, > > >> > > >> ok let's put it as follows: I meant "proxy-based TLS == GSI" > - > > > > > > > > > "proxy-based TLS" could also be normal TLS (only difference it > that you > > > need to check the delegation chain when verifying; the newer > version of > > > openssl itself has supported this, or you can also customize > the verifying > > > process of openssl with older version to support verification > of delegation > > > chain). > > > > > > > Correct. > > > > > > > > > > Of cause GSI is also "proxy-based TLS". But I thinks it is not > compatible> > to normal TLS since it use GSIAPI which has some > specific protocol. > > > > > > > > > I believe GSI-API is just that, a programming API that conforms > to RFC > > 2744<" target="l">http://www.faqs.org/rfcs/rfc2744.html> (GSS), > > and has no protocol restrictions/changes. > > I think Weizhong means implmentation of GSIAPI like one from > Globus which does have > own communication protocol incompatible with TLS. > > > 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