[Pgi-wg] OGF PGI - Security Model

Fri Mar 27 06:36:36 CDT 2009

On Fri, Mar 27, 2009 at 11:17 AM, Morris Riedel <m.riedel at fz-juelich.de>wrote:

>  Hi,
>
>
>
>  thanks for your comments, so…
>
>
>
> >- Again, I don't see it is reasonable to put the support of proxy and full
> X.509 ("support" here means the verification of credential during the
> processing of TLS/SSL) in parallel. If the middleware supports proxy, then
> with no doubt it implicitly and naturally supports full X.509, since full
> X.509 support is just a specific scenario of proxy support, and also almost
> all of the middlewares support (or will support) proxy.
>
>
>
>
>
> ### addressing the comment:
>
> There is no AND basically, if ARC/gLite/NAREGI decide to support only proxy
> certificates that’s fine – leading to Grids that always use proxy
> certificates – which is also fine if you like. And UNICORE would like to
> share this vision as well – you can use it everywhere.
>
>
>
> The reason to put the solution for “full-entity’ (if you are not using
> proxies) is just for other deployments that are not using proxies.
>
>
>
> That’s why I think we have to distinguish between deployment and middleware
> implementation features and providing meaning to flexible (not too much)
> tagging them.
>
>
>
> The idea of plumbings is that we force not everyone to support both –you
> can still choose – but only from a well-defined manner.
>
>
>
>
>
> >- So supporting proxy should be a mandatory requirement, IMO.
>
>
>
> The idea of plumbings is that we don’t put this hugh requirement for every
> Grid infrastructure – instead GLUE describes which endpoints support which
> security setup.
>
>
>
> In some Grids it may be PROXIES (imply full X.509) …
>
>
>
>
>
> … on other Grids only full X.509 may be supported.
>
>
>
> I’m looking from a point of view that UNICORE is used in many Grid
> infrastructures, while one infrastructure such as D-GRID or DEISA may change
> to proxies – others like SKIF-GRID or BALTIC-Grid may don’t want to – or
> only for specific interop scenarios.
>
>
>
> That’s why I’m keen that we should keep this in scope of PGI, so that the
> GLUE instances can report about the specific setups.
>
>
>
>
>
> Again, this has nothing to do with if UNICORE supports proxies or not – it
> just that we have a much more broader scope than just one Grid with one
> deployment. The managers/admins of these infrastructures should decide which
> aspects of PGI should be supported… J
>
>
>
> …while we narrow in general the possibilities for them to the ones defined
> in PGI.
>

Probably I should not have used "Mandatory" for proxy support. We can
defines two profiles : full X.509 and proxy. But we should also mention that
if those deployments (though I can not see why if middleware can support
proxy, while its deployment would not support it) can only support full
X.509 will not be capable to interoperate to the bigger island with proxy
support.
Again here, "support" means the service or client which can verify (consume)
the proxy certificate, not those can use proxy certificate.

Weizhong Qiang

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