2009/3/20 Morris Riedel <m.riedel@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@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of -Aleksandr Konstantinov -Sent: Friday, March 20, 2009 10:27 AM -To: pgi-wg@ogf.org -Subject: Re: [Pgi-wg] Sec: Agreement on attribute transport mechanisms -forAttrAuthZ - -On Friday 20 March 2009 09:22, m.riedel@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@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@ogf.org -> http://www.ogf.org/mailman/listinfo/pgi-wg -> -_______________________________________________ -Pgi-wg mailing list -Pgi-wg@ogf.org -http://www.ogf.org/mailman/listinfo/pgi-wg

_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg