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

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

20 Mar '09

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

1 0

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

20 Mar '09

hi, PGI_TLS and PGI_GSI were mentioned by you in a few thread. Again, I would like clarify something from my point of view. Do you mean PGI_GSI the services/clients that talk to each other by using GSSAPI? or just talk to each other based on TLS while using proxy certificate. I think there is difference between them. So I would divide them into branch by using your notation: PGI_TLS PGI_TLS_PROXY (the notation is also in the virginia strawman) PGI_GSI 2009/3/20 Morris Riedel <m.riedel(a)fz-juelich.de> > Hi, > > > > >- My personal thinking is, since we are talking about PGI or > interoperability, we probably do need to change the current implementation > if it can not satisfy interoperability, while keeping the principle that the > change should be as little as possible. > > > > In terms of little changes I agree – but I consider PGI_TLS / PGI_GSI as > massive changes. > > > > For instance, we have developed a UNICORE Gateway (for AuthN) that works > with PGI_TLS naturally – and PGI_GSI more recently providing of course not > FULL delegation support per hop, but proxies are supported on GSI-TLS level. > > > > > > However, can we expect that you one contact a CREAM-BES any time soon with > full end-entity credentials or any other gLite component? > The CREAM service has been tested (by some of our colleagues) . And the result shows CREAM service requires "limited" proxy certificate (proxy with "CN=proxy") when it doing data transfer. Inherently, because of forwarding mechanisms internally – proxies are > necessary probably. > > > > But maybe that’s my old interop* knowledge – so let’s clarify again… > > > > Some statements that need clarification: > > > > Note: UNICORE can be contacted using PGI_TLS and PGI_GSI – the same is > planned for GENESIS-II as far as I remember. > "and PGI_GSI" means PGI_TLS_PROXY or PGI_GSI? >From out experience about testing against UNICORE service, it uses PGI_TLS_PROXY. > > > > Q: Do gLite also supports pure PGI_TLS apart from PGI_GSI? > > > > > > Q: Do ARC also supports pure PGI_TLS apart from PGI_GSI? > PGI_TLS PGI_TLS_PROXY possible to support PGI_GSI (the definition I mentioned) > > > > > Q: Do we really imply that PGI-compliance means that both PGI_GSI and pure > PGI_TLS have to be supported? Or we rather go the plumbing way of defining > either or as MANDATORY and as MAY both supported (two plumbings). > I see PGI_TLS_PROXY should be mandatory. Regards, Weizhong > > Thanks for clarification, > > Morris > > > > > > *From:* Steven Newhouse [mailto:Steven.Newhouse@cern.ch] > *Sent:* Friday, March 20, 2009 11:49 AM > *To:* weizhong qiang; Morris Riedel > *Cc:* pgi-wg(a)ogf.org > *Subject:* RE: [Pgi-wg] Sec: Agreement on attribute transport > mechanismsforAttrAuthZ > > > > My personal thinking is, since we are talking about PGI or > interoperability, we probably do need to change the current implementation > if it can not satisfy interoperability, while keeping the principle that the > change should be as little as possible. > > > > And to clearly describe the interoperability benefits that will be derived > (i.e. systems and communities) by making that change. > > > > Steven > > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg > >

1 0

Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman)
by Aleksandr Konstantinov 20 Mar '09

20 Mar '09

On Friday 20 March 2009 12:24, Morris Riedel wrote: > Hi, > > >- As I > >-explained in an earlier mail, "limited" here means that the PGI profile > >-shall precisely described in a self-contained way the minimum set of EPR > >-elements which must be supported by conforming inplementations. > > So far, I guess we only depend on the wsa:To element of the specification > with the URI making it the minimum element of it. > > With WS-Naming this would be expanded using wsa:metadata and ws-naming > elements of course. > > Isn't our usual procedure to take the URI - encode an EPR (with wsa:To) and > send it to the BES systems? Or is this maybe only my narrow UNICORE view of > how we do it? > > Q: What is meant by accessing a CREAM-BES and A-REX with URI (instead of > EPRs)? ARC does not rely on EPR present in SOAP messages header sent to BES service. ARC clients do put EPRs into headers for compatibility. Hosting environment of ARC services may perform routing of messages depending on wsa:To element of EPR. To make it short - we can live with and without EPRs. AFAIR BES specs say nothing about if BES service has to be contacted using EPRs. A.K.

1 0

Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman)
by Aleksandr Konstantinov 20 Mar '09

20 Mar '09

On Friday 20 March 2009 12:21, Morris Riedel wrote: > Hi Aleksandr, > > >-IMO the real question is what such EPRs may be used for. If they planned > as > >-replacements for URLs and *full* such EPR is going to be put into > >-every SOAP header then I wohuld vote strongly against. But if such EPR is > just a way > >-to describe service (same as corresponding section in Glue > >-document) and are ony meant to be used in some kind of information > system/port > >-then why not. > > Just for clarification: With URLs you refer to the wsa:To element of > WS-Addressing correct? If so, they are of course in any SOAP message - or I > didn't get your point. With URL I mean URL which was supposed to identify resource. Now with introduction of EPRs we get another layer of indirection in resource identification. That's alright. But EPRs can also be used to describe resource. And that description part may become lenghty. So if PGI goes for EPR I would like to see it profiled which parts of EPR are expected/needed at which place/moment. If my client application queries for some service with specific capabilities and gets 100kB EPR describing who where and how can contact service that is probably ok. But if for contacting that service my application has to insert that EPR into every SOAP message I would like to know which parts of it I can be safely removed in order to avoid buying dedicated optical link to computing center hosting that service. :) > > Also, if it would be only to put into a kind of information system I would > vote for crunching the EPR in elements that can be probably better searched > for by an query instead of putting information into EPR. I just have to agree. > > Here, WS-Naming, provides basically a name of a service while its EPR might > change over time (renewable reference). Also the document refers to > trackability of messages once you use WS-Naming (e.g. UUID dependency) - so > I expect that this information of WS-Naming EPR additions should be part of > any SOAP message. But that's only my interpretation from the document. > > > Q: Can we agree that each functional service in the EPR space such as > OGSA-BES are contacted with an pure EPR using URIs? We don't consider > accessing a BESService simply with an URI - or do we? I would not vote for > that. I would like to know what do You mean by "contacted". If that implies human user is expected to write EPR by hand to make his/her client to contact some service then I disagree. A.K.

1 0

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

20 Mar '09

On Friday 20 March 2009 12:08, Morris Riedel wrote: > Good morning Aleksandr, > > > >-I see no reason for "either". Also it would be nice to define used > terms. > >-AFAIK there are no restrictions for using X.509 proxies (aka PC) in TLS. > As long as > >-we are talking about > >-standardaized PCs (RFC 3820) of course. > >-For infrastructures relying on full or partial/restricted X.509 identity > delegation PC > >-(proxy certificate) is > >-a must. But I see no reason why that should exclude usage of ordinary > X.509 > >-certificates/keys as > >-mean for identifying (direct or through attributes) communicating parties. > > > The reason is basically to precisely define what an endpoint supports, if do > not define this precisely interoperability will break since there is a big > difference using TLS with or without proxies for the authN check. The either I do code for doing authentication with and without proxies. And I never noticed significant difference. > is a reason to make it more simpler although there is a polymorphic > dependency, but this is not always helpful for the implementations. > > Example: > > (a) > For instance, if we would only claim that the UNICORE Gateway (AuthN check > for end-users) supports the PGI_TLS w/o knowing if it uses proxies or not: > > If you then use your ARC-Client with proxies and access the Gateway you > fail, because the AuthN check only checks for full end-entity certificates. > > (b) > For instance, if we would claim that UNICORE Gateway supports PGI_GSI (so > proxies including some newly defined PGI revocation mechanism since this is > a general GSI problem, or proxy problem although they have limited lifetime) > : > > If you then use your ARC client with proxies and access the Gateway you win, > because the AuthN check climbs up the whole proxy-hierarchy. > > If we use our own UNICORE Client with full end-entity certificates it works > as well since PGI_GSI MAY include PGI_TLS (your polymorphic item). So why not to use last option? Or am I missing something? > > ### Conclusions and motivation for either: > > (a) > So clearly every service that do supports PGI_GSI is able to accept client > request based on PGI_TLS only > > (b) > But every service that purely supports PGI_TLS is not able to accept client > requests based on PGI_GSI > > Bottom line: the either is needed for differentiation including inherently > your statement of polymorphism that only indicated 'one direction' or 'is-a' > and not the other direction! If (a) covers (b) then "either (a) or (b)" is not achievable. A.K.

1 0

Re: [Pgi-wg] Sec: Agreement on attribute transport mechanisms forAttrAuthZ
by weizhong qiang 20 Mar '09

20 Mar '09

2009/3/20 Morris Riedel <m.riedel(a)fz-juelich.de> > Good morning Aleksandr, > > > >-I see no reason for "either". Also it would be nice to define used > terms. > >-AFAIK there are no restrictions for using X.509 proxies (aka PC) in TLS. > As long as > >-we are talking about > >-standardaized PCs (RFC 3820) of course. > >-For infrastructures relying on full or partial/restricted X.509 identity > delegation PC > >-(proxy certificate) is > >-a must. But I see no reason why that should exclude usage of ordinary > X.509 > >-certificates/keys as > >-mean for identifying (direct or through attributes) communicating > parties. > > > The reason is basically to precisely define what an endpoint supports, if > do > not define this precisely interoperability will break since there is a big > difference using TLS with or without proxies for the authN check. The > either > is a reason to make it more simpler although there is a polymorphic > dependency, but this is not always helpful for the implementations. IMO, clarification is for sure needed, but "either-or" restriction should not be enforced. The implementation itself should have the ability to judge the EEC (end entity certificate) and PC(proxy certificate) and process them accordingly, instead of rejecting one of them. My personal thinking is, since we are talking about PGI or interoperability, we probably do need to change the current implementation if it can not satisfy interoperability, while keeping the principle that the change should be as little as possible. Regards, Weizhong > > > Example: > > (a) > For instance, if we would only claim that the UNICORE Gateway (AuthN check > for end-users) supports the PGI_TLS w/o knowing if it uses proxies or not: > > If you then use your ARC-Client with proxies and access the Gateway you > fail, because the AuthN check only checks for full end-entity certificates. > > (b) > For instance, if we would claim that UNICORE Gateway supports PGI_GSI (so > proxies including some newly defined PGI revocation mechanism since this is > a general GSI problem, or proxy problem although they have limited > lifetime) > : > > If you then use your ARC client with proxies and access the Gateway you > win, > because the AuthN check climbs up the whole proxy-hierarchy. > > If we use our own UNICORE Client with full end-entity certificates it works > as well since PGI_GSI MAY include PGI_TLS (your polymorphic item). > > ### Conclusions and motivation for either: > > (a) > So clearly every service that do supports PGI_GSI is able to accept client > request based on PGI_TLS only > > (b) > But every service that purely supports PGI_TLS is not able to accept client > requests based on PGI_GSI > > Bottom line: the either is needed for differentiation including inherently > your statement of polymorphism that only indicated 'one direction' or > 'is-a' > and not the other direction! > > > Does it sound more clear now why we need such a mechanism of describing > exactly which of both is needed for AUTH? > > > Take care, > Morris > > > > > > > > > > > > > > > > >------Original Message----- > >-From: pgi-wg-bounces(a)ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf > Of > >-Aleksandr Konstantinov > >-Sent: Friday, March 20, 2009 10:27 AM > >-To: pgi-wg(a)ogf.org > >-Subject: Re: [Pgi-wg] Sec: Agreement on attribute transport mechanisms > >-forAttrAuthZ > >- > >-On Friday 20 March 2009 09:22, m.riedel(a)fz-juelich.de wrote: > >-> Hi PGI Security team, > >-> > >-> after discussing possible AA interface that gives us insights into > the > different > >-"attribute package" formats, we can discuss the transport of them (or as > said by > >-Steven: The presentation of these packages at the (functional services). > >-> > >-> ### Goal: > >-> > >-> (a) > >-> We are discussing the transport of agreed attribute packages that are > used in PGI > >-to achieve attribute-based authorization (overcoming pure id-based > authZ)... > >-> > >-> > >-> (b) > >-> ...because we want to specify exactly where services can expect the > "attribute > >-packages" in the request messages... > >-> > >-> > >-> (c) > >-> ... in order to find out if we can agree on simple "attribute-package" > transport > >-paradigms that are easy to understand and don't allow for too much > flexibility to > >-promote interoperability. > >-> > >-> > >-> ### (Agreed) Attribute Packages so far > >-> > >-> (a) > >-> SAML assertions with attributes of end-users > >-> > >-> (b) > >-> VOMS ACs with attributes of end-users > >-> > >-> > >-> ### StrawmanFoundational: 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). > >-> Supplemental: Conveying authorization attributes describing aspects of > virtual > >-organization membership. > >-> •X.509 proxy + attribute certificates (PGI_TLS_PROXY). X.509 proxy > certificates > >-exchanged at the SSL/TLS level, demonstrating ownership of any X.509 > attribute > >-certificates embedded within. This conformance target derives > foundational > >-requirements from PGI_HTTPS. > >-> •SAML attribute assertions (PGI_SOAP_SAML). Demonstrating ownership of > >-SAML attributes exchanged within the SOAP message header. This > conformance > >-target derives foundational requirements from PGI_HTTPS. > >-> > >-> > >-> > >-> ### proposal of easy plumbings: Attr-based Authorization profile > >-> > >-> The plumbings idea refers to the fact that the PGI security should be > EASY to > >-understand and less flexible compared to the wide variety of (OGF,OASIS) > >-specifications having the least dependencies to other specs as possible. > >-> > >-> // precondition > >-> (a) Authentication profile as one plumbing to be agreed before > (precondition) > >-> Simple: You agree on either on full X.509 certs (TLS) or restricted > X.509 proxies > >-(GSI) on transport level > >- > >-I see no reason for "either". Also it would be nice to define used terms. > >-AFAIK there are no restrictions for using X.509 proxies (aka PC) in TLS. > As long as > >-we are talking about > >-standardaized PCs (RFC 3820) of course. > >-For infrastructures relying on full or partial/restricted X.509 identity > delegation PC > >-(proxy certificate) is > >-a must. But I see no reason why that should exclude usage of ordinary > X.509 > >-certificates/keys as > >-mean for identifying (direct or through attributes) communicating > parties. > >- > >-> > >-> > >-> (b) Attr-based AuthZ profile as another plumbing to be agreed on top of > AuthN > >-> Simple: You agree on either SAML assertions or AC VOMS attribute > packages. > >- > >-Here I see no reason on either again. As long as information carried > inside > >-assertion/attribute is > >-semantically identical (or at least convertable) the envelope used to > carry it is of little > >-importance. > >-Of course both ways should be properly defined - without "this is out > scope and > >-should be provided > >-by other profile" sentences. > >-As for comparing SAML assertions to VOMS AC safety wise both provide > adequate > >-measures for ensuring > >-integrity and ownership of enclosed information. > >- > >-> > >-> (c) transportation profiling (with two ways so far) > >-> > >-> 1: if you agree on SAML assertions we put it in the SOAP header in > WS-Security > >-> (works for both options in AuthN) > >-> > >-> 2: if you agree on VOMS AC we put it in the extensions of X.509 > certificates > >-> (works for both options in AuthN) > >- > >->From point of view of ARC codewise there is no technical problem to > >-support both of them and also other 2 combinations of them as long > >-as all are properly defined. > >-Pesonally I would choose both for ARC services just to increase > interoperability. > >- > >-> > >-> > >-> Bottom Line plumbings -> Simple: One Agreement on AuthN and one > agreement > >-on AuthZ (two plumbings rather independent from each other like within > >-pipes/plumbings in a house such as warm water, sewage, cold water, etc.) > >-> > >-> > >-> Example: It doesn't matter if you put warm water (full X.509 certs for > AuthN) or > >-cold water (proxy X.509 certs for AuthN) into the plumbings/pipes - > important is to > >-know what is in the plumbing and thus the middleware is able to handle it > (possibly > >-via different handlers in modern container designs). > >- > >-If You extend idea of pipes to cars there are modern cars which are able > to run on up > >-to 3 kinds of fuels. Why should Grids be worse? > >- > >-> > >-> ### Possible conclusions > >-> > >-> # We need an easy mechanism to perform attribute-based AuthZ > >-> > >-> # Mechanisms for AuthZ decisions are out of scope as well as having a > specified > >-policy (ACLs, XACML) - they are considered to be implementation detail > >- > >-Do Yu mean "out of scope of this mail thread" or "out of scope of PGI"? > >- > >-> > >-> # We have to agree on the structure / Semantics on attributes (seperate > e-mail > >-thread soon) > >-> > >-> > >-> > >-> ### open Questions: > >-> > >-> Q: Is the plumbings idea just oversimplified? It's not exactly > specified, which can > >-be done after agreeing to its element easily. What is the problem with > the > above > >-mentioned plumbings. > >-> > >-> Q: What are the problems of the PGI communication strawman > differentiation > >-mentioned above? > >-> > >-> So let's discuss this important thread before the telcon, but please > keep the > >-structure and semantics of attributes (FQAN, etc.) out of this discussion > for now > >-(seperate e-mail thread) > >-> > >-> > >-> 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.' > >-> > >-> > >-> > >-> ------------------------------------------------------------------- > >-> ------------------------------------------------------------------- > >-> Forschungszentrum Jülich GmbH > >-> 52425 Jülich > >-> > >-> Sitz der Gesellschaft: Jülich > >-> Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > >-> Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe > >-> Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), > >-> Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, > >-> Dr. Sebastian M. Schmidt > >-> ------------------------------------------------------------------- > >-> ------------------------------------------------------------------- > >-> > >-> > >-> _______________________________________________ > >-> Pgi-wg mailing list > >-> Pgi-wg(a)ogf.org > >-> http://www.ogf.org/mailman/listinfo/pgi-wg > >-> > >-_______________________________________________ > >-Pgi-wg mailing list > >-Pgi-wg(a)ogf.org > >-http://www.ogf.org/mailman/listinfo/pgi-wg > > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg > >

3 2

Re: [Pgi-wg] Documenting the security agreement/info progress
by Duane Merrill 20 Mar '09

20 Mar '09

The "track-changes" and "insert comments" feature for MS Word documents has come in very handy in other OGF working groups. The "insert comments" feature is particularly useful for allowing discussions on particular aspects to flow on with perfect contextual reference. 2009/3/19 Morris Riedel <m.riedel(a)fz-juelich.de> > Hi PGI security folks, > > I'm thinking how we can document progress in agreements in terms of > security. Just let the flow of e-mails run us out of time is not a good > idea... > > > Also, the strawmen document is nice but it is a Formula 1 racecar (or US: > Indy500 car) compared to a bicycle, which is more needed by PGI in the > moment to agree on important 'forward-bringing elements' before profiling > it > precisely to realize a common view on a racecar. > > > As I said earlier - our common agreement (not only in security) is crucial > - > rushing a profile out is not collaborative enough and had nearly crushed > the > group instead of getting us out of the security hole mentioned by Steven > earlier. In slightly other words - it's the process - not the documentation > alone, especially in collaborative efforts. > > > So - I hesitate to again come up with a big document during the agreement > process and rather prefer a condensed WIKI page. > > > But also this page implies changes by numerous folks making again > unreviewable without having any 'place constraints' especially having not > really a good track changes option! > > > My current idea is around so-called factsheets that are only two-page word > documents for each security topic making it condensed and allowing the > valuable track changes functionality including one picture per topic that > represents our common agreement aligned with some text that later lays the > foundation for our 'one' document mentioned in the charter. > > > I just want to hear your opinions on this before I start working on them - > it makes no sense if you disagree. > > I'm also happy to hear better suggestions. > > > Thanks for sharing your views on this, > 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 > >

3 2

Sec: Agreement on attribute transport mechanisms for AttrAuthZ
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

Hi PGI Security team, after discussing possible AA interface that gives us insights into the different "attribute package" formats, we can discuss the transport of them (or as said by Steven: The presentation of these packages at the (functional services). ### Goal: (a) We are discussing the transport of agreed attribute packages that are used in PGI to achieve attribute-based authorization (overcoming pure id-based authZ)... (b) ...because we want to specify exactly where services can expect the "attribute packages" in the request messages... (c) ... in order to find out if we can agree on simple "attribute-package" transport paradigms that are easy to understand and don't allow for too much flexibility to promote interoperability. ### (Agreed) Attribute Packages so far (a) SAML assertions with attributes of end-users (b) VOMS ACs with attributes of end-users ### StrawmanFoundational: 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). Supplemental: Conveying authorization attributes describing aspects of virtual organization membership. •X.509 proxy + attribute certificates (PGI_TLS_PROXY). X.509 proxy certificates exchanged at the SSL/TLS level, demonstrating ownership of any X.509 attribute certificates embedded within. This conformance target derives foundational requirements from PGI_HTTPS. •SAML attribute assertions (PGI_SOAP_SAML). Demonstrating ownership of SAML attributes exchanged within the SOAP message header. This conformance target derives foundational requirements from PGI_HTTPS. ### proposal of easy plumbings: Attr-based Authorization profile The plumbings idea refers to the fact that the PGI security should be EASY to understand and less flexible compared to the wide variety of (OGF,OASIS) specifications having the least dependencies to other specs as possible. // precondition (a) Authentication profile as one plumbing to be agreed before (precondition) Simple: You agree on either on full X.509 certs (TLS) or restricted X.509 proxies (GSI) on transport level (b) Attr-based AuthZ profile as another plumbing to be agreed on top of AuthN Simple: You agree on either SAML assertions or AC VOMS attribute packages. (c) transportation profiling (with two ways so far) 1: if you agree on SAML assertions we put it in the SOAP header in WS-Security (works for both options in AuthN) 2: if you agree on VOMS AC we put it in the extensions of X.509 certificates (works for both options in AuthN) Bottom Line plumbings -> Simple: One Agreement on AuthN and one agreement on AuthZ (two plumbings rather independent from each other like within pipes/plumbings in a house such as warm water, sewage, cold water, etc.) Example: It doesn't matter if you put warm water (full X.509 certs for AuthN) or cold water (proxy X.509 certs for AuthN) into the plumbings/pipes - important is to know what is in the plumbing and thus the middleware is able to handle it (possibly via different handlers in modern container designs). ### Possible conclusions # We need an easy mechanism to perform attribute-based AuthZ # Mechanisms for AuthZ decisions are out of scope as well as having a specified policy (ACLs, XACML) - they are considered to be implementation detail # We have to agree on the structure / Semantics on attributes (seperate e-mail thread soon) ### open Questions: Q: Is the plumbings idea just oversimplified? It's not exactly specified, which can be done after agreeing to its element easily. What is the problem with the above mentioned plumbings. Q: What are the problems of the PGI communication strawman differentiation mentioned above? So let's discuss this important thread before the telcon, but please keep the structure and semantics of attributes (FQAN, etc.) out of this discussion for now (seperate e-mail thread) 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.' ------------------------------------------------------------------- ------------------------------------------------------------------- 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 ------------------------------------------------------------------- -------------------------------------------------------------------

3 2

REMINDER & Numbers: PGI Security TelCon 4pm CET TODAY
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

Hi PGI team, Just a short reminder for our TelCon: TODAY - 4 pm CET Call-in details as follow: via Skype call +9900827049931906 (free of charge) ordinary phone numbers (local rates) with the 9931906 conference number: Austria 0820 401 15470 Belgium 0703 57 134 France 0826 109 071 Germany +49 (0) 180 500 9527 Switzerland 0848 560 397 Proposed Agenda: 1) Debrief & Discuss the communication strawman document from Catania: http://forge.gridforum.org/sf/docman/do/listDocuments/projects.pgi-wg/docma… 2) Agreements and Discussions about items on the e-mail threads 3) AOB 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) ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

1 0

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

20 Mar '09

ok let dive into them..., ----- Original Message ----- From: weizhong qiang <weizhongqiang(a)gmail.com> Date: Thursday, March 19, 2009 4:57 pm Subject: Re: [Pgi-wg] Sec: Agreement on supported Attribute Authority Interfaces > hi, > I have some questions as following. > > 2009/3/19 Morris Riedel <m.riedel(a)fz-juelich.de> > > > 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 > > Do you proposed to use the stadardized RFC AC, instead of the VOMS > AC which > is known as a simplified RFC while de-facto AC. If so, I think it > is not > needed. We can use VOMS AC, because we already have a few > production Grid > systems which have supported it. Well I was aware that VOMS AC are compliant with RFC AC's - I didn't know that they reduced the complexity of the specification. Can you point me to a standard specification of AC VOMS then - or this really purely de-facto?! > > > > > 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. > > Shibboleth itself does not support SLCs, and you need to develope some > system to issuing SLCs by using Shibboleth as ONE part of this > system. You > can also get SLCs credential through otherway except Shibboleth- > based. IF we > use "push" model, I think how does the client get the credential > doesn'tmatter, what does matter is the content of the credential. Yes, of course, I was referring with Shib to the full palette of it [GridShib, ShibGrid, ***whateverSHIB] I didn't go so much into detail because I hoped Shib* was out of scope here, which in turn means that we do not have to deal with credential formats in that context - my experience is clearly related to GridShib (X.509 + Shib IDP) and rather Globus-driven, which is putting SAML assertions in SLC extensions to be checked by CAS. Q: However, is there precise demand to support Shib from ARC or could this be the non-PGI elements of ARC? Are there users in your production Grid using Shib as AA? Q: What is the plan of EGEE in this context? Are there already users in production using Shib as AA? Info: UNICORE has been enabled with Shibboleth in DEISA, but part of the implementation relies on GridShib to the best of my knowledge following the mentioned approach above. So far - we see no precise demand that Shib-* part should be part of the PGI profile - especially Shib access is not in production in DEISA now, only planned for the next years (-> our of scope of PGI from our viewpoint). > > Futhermore, I can see two different problems here about > interoperability in > PGI in terms of credential/attributes: > a.The interoperability of getting a credential (with attributes > inside); The points you mentioned above are all about this problem. > b.the interoperability of using a credential (with attribute inside). > One user or client (on behalf of user) get the credential, it > needs to > use it and interoperate with services. > > I guess PGI is supposed to solve both of them? I think a might be out of scope since it have to then include proprietary protocols such as classic VOMS?! Part of this discussion is to find this out - maybe there is a way for it?! (e.g. what do you do once your AC-based proxy lifetime ended?! Renewal problem, which interface you use of renewal then?) b. Absolutely! > > > > > > > > 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! > > > So we are only going to solve the second sub-problem I concluded > above? Maybe - its actually only my suggestion by now - I'm happy to discuss ways of how we could standardize point (a) mentioned by you. > > > > > > > C. We deal with RFC ACs > > Not VOMS AC? Please provide a reference for this standard. > > > > > > > > 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? > > Changing VOMS AC to RFC AC? > Plus Supporting SAML Assertion? That is the input for the next e-mail thread then - which types of attribute transport formats we have to support - I guess that's hopefully all of them, while hopefully avoid using SAML assertions within X.509 extensions?! > > > > > > > > Q: Is there any production infrastructure that largely supports > Shibboleth> w/o supporting VOMS either in classic or WS style? > > > In terms of ARC, > The production ARC supports VOMS classic > The development ARC supports VOMS classic and WS style, and has it > own SLCs > service which is based on Shibboleth IdP. ok - useful information - the question would be then when you plan to move from development to production with the WS-style? Nevertheless, we have to support VOMS Classic since Steven stated clearly that EGEE will not directly move soon to the WS-style - and even if they do - there would be probably a lot of services that will be only Classic VOMS compliant. > > Cheers > Weizhong Thanks for your sharing your thoughts! > > > > > > > > > > > > > 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) > > > > > > > > _______________________________________________ > > Pgi-wg mailing list > > Pgi-wg(a)ogf.org > > http://www.ogf.org/mailman/listinfo/pgi-wg > > > > > ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

2 1