- pgi-wg - lists.ogf.org

Reminder: task for all, today (Monday)
by Johannes Watzl 29 Mar '09

29 Mar '09

Hello, just to remind you. as agreed on Friday a task for all: Comment on Morris' slides on Monday, 30 March 2009 Best wishes, Johannes -- _ _ _ _ _ _ Johannes Watzl |\/| |\ | |\/| Institut für Informatik / Dept. of CS | | | \| | | Ludwig-Maximilians-Universität München ======= TEAM ======= Oettingenstr. 67, 80538 Munich, Germany Room D0.5, Phone +49-89-2180-9162 Munich Network Management Team Email: watzl(a)nm.ifi.lmu.de Münchner Netz-Management Team http://www.nm.ifi.lmu.de/~watzl

1 0

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

28 Mar '09

If the PGI working group wants to describe "compliance with GSI" (as is mentioned in several places above, e.g., 5.3, 5.4, 7.3, etc.), then the working group MUST reference or produce a publication that defines what GSI Compliance means. Also, you may have to spend a lot of political capital to get agreement on the GLUE schema as a way of describing and discovering secure communication requirements, particularly since WS-SecurityPolicy exists as an OASIS recommendation for doing just that. You may want to reconsider the mandates of a 6, as it will likely turn into a sticking point. Duane > On 3/27/09, Etienne URBAH <urbah(a)lal.in2p3.fr> wrote: >> To All, >> >> >> In order to handle X509 proxies, we regrettably have to take into >> account both the OpenSSL and GSI implementations of TLS, which are >> incompatible. >> >> >> So I have updated my 'PGI Security Model' below and at >> http://forge.gridforum.org/sf/go/doc15584?nav=1 >> >> >> OGF PGI - Security Model >> ======================== >> >> >> Current Established Base >> ======================== >> Chapters 1, 2 and 3 below describe the current security model of >> Computing Grid Infrastructures. >> >> >> 1) Grid Users and Certificate Authorities >> ----------------------------------------- >> 1.1) Each grid User is authenticated by a legal body (recognized by a >> government). >> >> 1.2) This legal body uses a Certificate Authority to grant a (long >> lived) X509 certificate to the grid User. >> >> 1.3) Each Certificate Authority is itself or is authenticated by a >> self-signed Root Certificate Authority. >> >> 1.4) All such Root Certificate Authorities trust each other and >> cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management >> Authorities). >> >> 1.5) These 3 Policy Management Authorities trust each other and >> cooperate within IGTF. >> >> 1.6) IGTF distributes the list of CA Certificates to be trusted. >> >> 1.7) Each grid Site providing grid Services to grid Users installs the >> CA Certificates it deems necessary. In general, there is no requirement >> to keep them up-to-date, but typically it is considered a security >> update and as such is strongly recommended to apply. Some >> infrastructures issue warnings for sites with outdated CA certs, but >> normally it does not impede operations. >> >> 1.8) Using its X509 certificate, each grid User can create at any time >> a (usually short lived) X509 proxy with permits impersonation / >> delegation during a (usually short) period. >> >> >> 2) Virtual Organizations >> ------------------------- >> 2.1) A Virtual Organization (VO) groups grid Users (usually with common >> goals). A Virtual Organization may be a legal body, and may be a >> Certificate Authority which can issue X509 certificates, but most are >> NOT. >> >> 2.2) Inside DEISA, a Virtual Community also groups grid Users with >> common goals. {{{The relationships between Virtual Communities and >> Virtual Organizations have to be explained by Morris RIEDEL}}} >> >> 2.3) Each grid User belongs to 1 or more VO (Virtual Organization), >> which grants him access rights to grid Storage and Computing Resources. >> >> 2.4) Access rights are granted by VOs to grid Users through either : >> 2.4.1) VOMS extensions of X509 proxies (this makes a VOMS proxy) >> 2.4.2) SAML assertions >> >> >> 3) Grid Services : Information, AUTHN, AUTHZ >> ---------------------------------------------- >> 3.1) Some grid Infrastructures provide an Information Service with >> describes the Infrastructure, for example according to the 'GLUE 1.3' >> schema. >> >> 3.2) If this Information Service exists, then each grid User can query >> it in order to discover the list, requirements and capabilities of grid >> Services. >> >> 3.3) Each grid User can directly access data hosted by grid Storage >> Services. For Authentication, the grid User can present the public part >> of his X509 certificate or X509 proxy. For Authorization, the grid User >> has to present either (depending on the Infrastructure) : >> 3.3.1) the public part of his X509 certificate, or >> 3.3.2) the public part of his X509 proxy (without VOMS >> extensions), or >> 3.3.3) the public part of his VOMS proxy, or >> 3.3.4) a bag of SAML assertions. >> In order to handle X509 proxies, both the OpenSSL and GSI >> implementations of TLS are widely used, but they are INCOMPATIBLE. >> If the grid User accesses data through a interface requiring >> delegation, then the next subchapter applies. >> >> 3.4) Each grid User can submit Jobs to grid Computing Services. If >> such a Job needs access to data hosted by grid Storage Services, then >> the grid User must provide a delegation token. This delegation token is >> either (depending on the Infrastructure) : >> 3.4.1) an X509 proxy, or >> 3.4.2) a VOMS proxy, or >> 3.4.3) a bag of SAML assertions. {{{Morris RIEDEL has to >> explain if and how delegation of SAML assertions work}}} >> >> 3.5) Each grid Site providing grid Services to grid Users has installed >> Authorization Files (such as 'gridmap' files) describing VOMS >> authorizations, other authorizations, and mapping of grid credentials to >> local credentials. Grid Sites try to keep those Authorization Files up >> to date. >> There is a trend to replace these static 'gridmap' files by a >> robust Authorization Service (SCAS by EGEE, GUMS by OSG). >> >> >> >> Where we propose to go >> ====================== >> Chapters 4, 5, 6 and 7 below describe a security model for short term >> Interoperability between Computing Grid Infrastructures. >> >> >> 4) Operational Robustness of Security >> -------------------------------------- >> 4.1) The number of Certificate Authorities for grid Infrastructures >> SHOULD be kept as low as possible. >> >> >> 5) Interoperability between X509 certificates and X509 proxies for >> Authentication >> ---------------------------------------------------------------------------------- >> 5.1) For this short term Security Profile aimed at short term >> Interoperability, we accept Shibboleth as an option, but knowingly >> exclude Shibboleth from any requirement. >> >> 5.2) X509 proxies MUST fully comply either to RFC 3820 or to GSI. >> >> 5.3) VOMS services, which deliver X509 proxies with VOMS extensions, >> MUST fully comply either to RFC 3820 or to GSI. >> >> 5.4) The authentication library used by grid Services MUST fully comply >> either to RFC 3820 or to GSI. >> >> >> 6) Information Service describing the Infrastructure according the the >> GLUE2 schema >> ------------------------------------------------------------------------------------ >> 6.1) Each grid Infrastructure MUST provide an Information Service, >> which describes the Infrastructure according the the GLUE2 schema. >> >> 6.2) If access to the Information Service is restricted, the grid >> Infrastructure MUST provide a Bootstrap Information Service, with >> describes the security requirements for access to the full Information >> Service according the the GLUE2 schema. >> >> >> 7) Interoperable Grid Services : Information, AUTHN, AUTHZ >> ------------------------------------------------------------ >> 7.1) The semantics of Authorization tokens MUST be the same for all >> grid Infrastructures. >> Examples of Authorization tokens are : >> 7.1.1) DN of the X509 certificate or proxy >> 7.1.2) VOMS-style Attribute Certificates >> 7.1.3) Restriction attributes >> 7.1.4) Shibboleth >> >> 7.2) The Information Service of each grid Infrastructure MUST describe, >> for each grid Service, the security requirements for access to the grid >> Service, and which Authorization Tokens this Service expects >> (potentially several). >> >> 7.3) The Information Service of each grid Infrastructure MUST describe >> the transport method that the grid Service expects (potentially several). >> In order to handle X509 proxies, we regrettably have to take into >> account both the OpenSSL and GSI implementations of TLS, which are >> incompatible. >> >> 7.4) Each grid Site providing grid Services to grid Users MUST install >> and keep up to date a robust Authorization Service enforcing VOMS >> authorizations, other authorizations, and mapping of grid credentials to >> local credentials. >> >> 7.5) Each grid Service MUST accept at least : >> 7.5.1) One of the following Authorization Tokens : >> - DN of the X509 certificate or proxy >> - X509 VOMS-style Attribute Certificates (VOMS >> extensions) >> They are defined in 'VOMS Attribute Certificate >> Format' at http://forge.gridforum.org/sf/go/doc13797?nav=1 >> - X509 restriction attributes >> {{{Please give the reference of a description >> document}}} >> - SAML assertions >> {{{Please give the reference of a description >> document}}} >> 7.5.2) One of the following transport methods : >> - OpenSSL (compliant to RFC 3820) for attributes of X509 >> proxies >> - GSI for attributes of X509 proxies >> - SOAP header for SAML assertions >> >> 7.6) As long as it satisfies subchapter 7.5, each grid Service MAY also >> accept Authentication and Authorization methods based on Shibboleth. >> >> 7.7) In order to ease the development and deployment of grid Clients, >> each grid Service SHOULD accept following types of Authorization Tokens : >> 7.7.1) X509 VOMS-style Attribute Certificates (VOMS extensions) >> 7.7.2) X509 restriction attributes. >> In the 2 previous cases, the grid Service SHOULD accept >> that they are transported through OpenSSL (compliant to RFC 3820). >> Transport through GSI is explicitly DEPRECATED. >> 7.7.3) SAML assertions. >> In that case, the grid Service SHOULD accept that they >> are transported inside SOAP headers. >> >> 7.8) In order to keep middleware complexity and bandwidth usage as low >> as possible, grid Services should NOT send their full description of >> their security interface inside each message, but only when specifically >> requested (for example by the Information Service). >> >> To be thoroughly criticized ... >> >> >> 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 >> ---------------------------------- >> >

2 1

Re: [Pgi-wg] Figures about Authentication and Authorization plumbings
by Etienne URBAH 27 Mar '09

27 Mar '09

Morris, Concerning the Authentication and Authorization plumbings, I completely agree on the principle : The 1-year goal of PGI is : - NOT that ALL grid Clients can use ALL grid Servers, - but that each grid Client can query the grid Information Service, in order to discover which grid Servers accept the Authentication and Authorization methods that the grid Client is able to use. - and to profile the Authentication and Authorization methods, in order to reduce the number of incompatible grid islands. 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 Fri, 27 Mar 2009, Morris Riedel wrote: > 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

1 0

PGI Vocabulary wiki
by Johannes Watzl 27 Mar '09

27 Mar '09

Dear all, as an initial input for our PGI vocabulary Wiki, I put a number of abbreviations and terms used in the PGI discussions on the GridForge site (Wiki) as initial input. To have a clear definition of each of these "things" and to be sure everybody has the same in mind talking about this or that, I kindly ask you to contribute to this vocabulary. Hear you soon! Cheers, Johannes -- _ _ _ _ _ _ Johannes Watzl |\/| |\ | |\/| Institut für Informatik / Dept. of CS | | | \| | | Ludwig-Maximilians-Universität München ======= TEAM ======= Oettingenstr. 67, 80538 Munich, Germany Room D0.5, Phone +49-89-2180-9162 Munich Network Management Team Email: watzl(a)nm.ifi.lmu.de Münchner Netz-Management Team http://www.nm.ifi.lmu.de/~watzl

2 1

More detailed security technical survey
by weizhong qiang 27 Mar '09

27 Mar '09

hi all, I just added a more detailed table about security survey onto PGI wiki, as I promised. Please take a look and fill/change it correspondingly. Cheers Weizhong

1 1

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

27 Mar '09

Yes. For example, an idealized TLS-Proxy-service-plumbing can equally accommodate a TLS-EEC-client-plumbing as well as a TLS-Proxy-client plumbing. (Those two client plumbings are very different, but work equally well with the single service plumbing.) Duane On 3/27/09, Morris Riedel <m.riedel(a)fz-juelich.de> wrote: > Service/Client plumbings? > > > > I rather refer to: > > > > 3 suggested Authentication Plumbings > > 2 suggested Authorization Plumbings > > > > 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: Duane Merrill [mailto:dgm4d@virginia.edu] > Sent: Friday, March 27, 2009 3:50 PM > To: Morris Riedel > Cc: Aleksandr Konstantinov; pgi-wg(a)ogf.org > Subject: Re: [Pgi-wg] OGF PGI - Security Strawman > > > > 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 > > > > > > > >

1 0

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