[Pgi-wg] Sec: Agreement on attribute transport mechanisms forAttrAuthZ

Fri Mar 20 05:08:20 CDT 2009

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.

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 at ogf.org [mailto:pgi-wg-bounces at ogf.org] On Behalf Of
>-Aleksandr Konstantinov
>-Sent: Friday, March 20, 2009 10:27 AM
>-To: pgi-wg at ogf.org
>-Subject: Re: [Pgi-wg] Sec: Agreement on attribute transport mechanisms
>-forAttrAuthZ
>-
>-On Friday 20 March 2009 09:22, m.riedel at 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 at 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 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3550 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20090320/28efa5c8/attachment-0001.bin 