Endpoint.TrustedCA and ComputingEndpoint.TrustedCA Inconsistency in GFD147
Hi all, We recently stumbled upon problems while running EMI-ES integration tests across EMI middleware. The reason is there are different descriptions and therefore different interpretations of the TrustedCA attribute in Endpoint and ComputingEndpoint. Here are the two relevant tables in GFD147: Entity Inherits from Description Endpoint Entity <http://glue20.web.cern.ch/glue20/#tableEntity> A network location having a well-defined interface and exposing specific service functionalities. Attribute Type Mult. Unit Description TrustedCA DN_t <http://glue20.web.cern.ch/glue20/#b13> 0..* The Distinguished Name of a trusted Certification Authority (CA); i.e., certificates issued by the CA are accepted by the authentication process. Alternatively this may identify a standard bundle of accepted CAs, e.g. those accredited by the IGTF. Note that this does not imply that such certificates will be authorized to use the Endpoint <http://glue20.web.cern.ch/glue20/#tableEndpoint>. Entity Inherits from Description ComputingEndpoint Endpoint <http://glue20.web.cern.ch/glue20/#tableEndpoint> A network Endpoint for creating, monitoring, and controlling computational Activities called jobs. It MAY also be used to expose complementary capabilities (e.g., resource reservation or proxy manipulation). Inherited Attribute Type Mult. Unit Description TrustedCA DN_t <http://glue20.web.cern.ch/glue20/#b13> 0..* Distinguished name of the trusted Certification Authority (CA), i.e., certificates issued by the CA are accepted for the authentication process I just don't understand this sentence: "Alternatively this may identify a standard bundle of accepted CAs, e.g. those accredited by the IGTF. Note that this does not imply that such certificates will be authorized to use the Endpoint." Does "This" still mean a DN or a string? In GLUE2 every attribute value has a very well defined type, in this case DN_t. DN_t is a distingushed name as defined by RFC4514 (http://www.ietf.org/rfc/rfc4514.txt) but how can a DN represent a bundle of accepted CAs? gLite middleware is using a plain string there, for example IGTF. But IGTF is NOT a DN_t. This was also one of the things I didn't understand in Stephen's EGI GLUE2 profile. Can anybody comment on this? Sometimes these GLUE2 inconsistencies make me crazy :P -- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of Florido Paganelli said:
We recently stumbled upon problems while running EMI-ES integration tests across EMI middleware. The reason is there are different descriptions and therefore different interpretations of the TrustedCA attribute in Endpoint and ComputingEndpoint.
Probably the text for Endpoint was updated but not copied to ComputingEndpoint - the Endpoint text is correct. The basic point is that publishing every CA for every Endpoint would be a huge data volume, and in practice I think we have no clients that use it. Also the majority of Grid sites use a completely standard set of CAs so most of the information would be duplicated.
Does "This" still mean a DN or a string?
It means a string used as a reserved word - "IGTF" in this case.
Sometimes these GLUE2 inconsistencies make me crazy :P
If you expect absolutely precise definitions of everything I suggest you stop working in Grids ... Stephen
Hi Stephen, all On 2012-11-01 13:25, stephen.burke@stfc.ac.uk wrote:
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of Florido Paganelli said:
We recently stumbled upon problems while running EMI-ES integration tests across EMI middleware. The reason is there are different descriptions and therefore different interpretations of the TrustedCA attribute in Endpoint and ComputingEndpoint.
Probably the text for Endpoint was updated but not copied to ComputingEndpoint - the Endpoint text is correct. The basic point is that publishing every CA for every Endpoint would be a huge data volume, and in practice I think we have no clients that use it. Also the majority of Grid sites use a completely standard set of CAs so most of the information would be duplicated.
Does "This" still mean a DN or a string?
It means a string used as a reserved word - "IGTF" in this case.
This is very bad. How is a client/consumer supposed to know this? How can we solve this with respect to the DN_t type in the specification (which is "clearly unclear")? Recommendations in the renderings?
Sometimes these GLUE2 inconsistencies make me crazy :P
If you expect absolutely precise definitions of everything I suggest you stop working in Grids ...
Forget about it. I will *not* stop working on grid and fight to make it precise and useful, if not defined so. And that might happen even if I am not paid for it. So, coming back to the topic: Let's say there is recommendation in the renderings that tells to put a string there, overriding the GFD147 specs. Say you have a this reserved word there: IGTF. How is a third party client supposed to know the meaning of it? where to look for such strings? What kind of algorithm to deduce which are the CAs entitled? Note: The type of TrustedCA is currently not even a open enumeration. A solution might be to change the type of this attribute in the realization documents to have an open enumeration that clearly defines what are the CAs entitled. But then we face a second problem, for example in case of IGTF, the CAs allowed might change frequently and dynamically. So far the open enumerations we have are mostly static. Can it be done leveraging CRLs? Any idea? Thanks -- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project
A smattering of points: An advantages of a flat rendering is that it's fairly trivial to define new entities that describe reserved words/strings/enumerations so that clients can look them up and discover what those strings represent. Could these strings be a hash of a DN? Does IGFT have unique names/IDs for their accepted CAs? How many TrustedCAs are we thinking might need to be published for each endpoint, and how much data is that really? Do we think it would significantly impact the performance of our information systems to publish multiple collections of TrustedCA strings? On a side note, I wonder if anyone else on this list is familiar with Persistent Identifiers (PIDs)? http://www.clarin.eu/faq/technical-infrastructure/persistent-identifiers-pid... I've been pondering where PIDs might not be useful to define enumerations JP On Nov 1, 2012, at 8:13 AM, Florido Paganelli wrote:
Let's say there is recommendation in the renderings that tells to put a string there, overriding the GFD147 specs.
Say you have a this reserved word there: IGTF. How is a third party client supposed to know the meaning of it? where to look for such strings? What kind of algorithm to deduce which are the CAs entitled?
Note: The type of TrustedCA is currently not even a open enumeration.
A solution might be to change the type of this attribute in the realization documents to have an open enumeration that clearly defines what are the CAs entitled.
JP Navarro [mailto:navarro@mcs.anl.gov] said:
Could these strings be a hash of a DN?
That wouldn't help much, the problem is the number of CAs more than the length of each one.
How many TrustedCAs are we thinking might need to be published for each endpoint, and how much data is that really? Do we think it would significantly impact the performance of our information systems to publish multiple collections of TrustedCA strings?
At a quick count, I get 89 CAs and about 5 KB of data, compared with about 2 KB currently in an Endpoint - and that for something for which, as far as I know, we have no uses, and which would be duplicated several thousand times over. For the BDII I think publishing that would not make any sense. Stephen -- Scanned by iCritical.
An ideal design might be to support named collections of CAs where any number of services across an entire federation can reference these named collections. A detailed description of what is in a named collections would only need to exist in one place within a federation. First I think it's important to confirm that we indeed have NO uses for this today. Does anyone know of any? Second I would propose that we open up the floor to proposed solutions. Discussing a proposed solution, and even coming to a consensus, doesn't mean we have to change the current GLUE 2 specification. The community can first try to implement a consensus solution, or multiple solutions, and at some future point decide which of these we want to integrate into a future GLUE2 revision. In short, we need to confirm we aren't breaking any known uses and implementations while we explore solutions. JP On Nov 1, 2012, at 2:50 PM, <stephen.burke@stfc.ac.uk> wrote:
JP Navarro [mailto:navarro@mcs.anl.gov] said:
Could these strings be a hash of a DN?
That wouldn't help much, the problem is the number of CAs more than the length of each one.
How many TrustedCAs are we thinking might need to be published for each endpoint, and how much data is that really? Do we think it would significantly impact the performance of our information systems to publish multiple collections of TrustedCA strings?
At a quick count, I get 89 CAs and about 5 KB of data, compared with about 2 KB currently in an Endpoint - and that for something for which, as far as I know, we have no uses, and which would be duplicated several thousand times over. For the BDII I think publishing that would not make any sense.
Stephen
-- Scanned by iCritical.
JP Navarro [mailto:navarro@mcs.anl.gov] said:
First I think it's important to confirm that we indeed have NO uses for this today. Does anyone know of any?
glite certainly doesn't because GLUE 1 doesn't have the information at all. And it isn't an issue because in practice sites do just install all the standard CAs - partly because most sites support WLCG and they probably insist that all their CAs are allowed by all sites. I can see that there could be special cases where e.g. you have a site with funding specifically for national users, but we shouldn't need to require all sites to publish a large amount of data to support that.
Discussing a proposed solution, and even coming to a consensus, doesn't mean we have to change the current GLUE 2 specification.
The specification was intended to cover it already, so at most I would say that it's a clarification. Revising the specification is potentially possible, but as I've said about other things that's something with a multi-year timescale which can't alter what we have in production now. Stephen -- Scanned by iCritical.
On 2012-11-01 21:49, stephen.burke@stfc.ac.uk wrote:
JP Navarro [mailto:navarro@mcs.anl.gov] said:
First I think it's important to confirm that we indeed have NO uses for this today. Does anyone know of any?
I don't like this approach of "definition by needs". The model specifies what has to be there. If a service does not need that, it simply does not publish it. If the content of the information is not clear, we must clarify it, as we(you) defined the model as well.
glite certainly doesn't because GLUE 1 doesn't have the information at all. And it isn't an issue because in practice sites do just install all the standard CAs - partly because most sites support WLCG and they probably insist that all their CAs are allowed by all sites.
In don't get the point. Since you claim that such information is not used, I don't understand why gLite publishes it at all. I am quite sure infact that such information *is* used, but mostly by monitoring clients, checking that the IGTF string is there.
I can see that there could be special cases where e.g. you have a site with funding specifically for national users,
These "special cases" are ARC middleware's everyday life.
but we shouldn't need to require all sites to publish a large amount of data to support that.
but you know, clients would like to know which clusters to access before kamikaze-probing to open a secure connection to them... So if we do not put this information in the services, clients will have to find out by other means... of just submitting and hoping these CAs are accepted I'd call it "hope discovery algorithm"
Discussing a proposed solution, and even coming to a consensus, doesn't mean we have to change the current GLUE 2 specification.
The specification was intended to cover it already, so at most I would say that it's a clarification. Revising the specification is potentially possible, but as I've said about other things that's something with a multi-year timescale which can't alter what we have in production now.
There is no need at all to clarify the specification, I agree; let's just make clear how an information consumer should react when finding such information. Please explain how do gLite clients understand what are the TrustedCAs that such label represents, if they do. I'll be happy to produce any solution from that. Cheers, -- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project
Florido Paganelli [mailto:florido.paganelli@hep.lu.se] said:
I don't like this approach of "definition by needs".
This seems to be our fundamental difference of opinion, I would say that the *only* criterion is definition by needs. Our main incentive to make GLUE 2 at all was precisely that GLUE 1 was too inflexible and didn't allow enough adaptation as needs changed, so we defined a structure which would make it much easier to redefine or extend the usage without needing a schema change.
In don't get the point. Since you claim that such information is not used, I don't understand why gLite publishes it at all.
Publishing nothing would be a possibility, but "IGTF" does describe the real situation - see the EGI documentation here: https://wiki.egi.eu/wiki/EGI_IGTF_Release That opens the possibility of publishing additional CAs if necessary without having to repeat all the common information.
Please explain how do gLite clients understand what are the TrustedCAs that such label represents, if they do. I'll be happy to produce any solution from that.
As I said, currently glite clients don't do anything, they just assume that all CAs relevant to a given VO will be allowed if the VO itself is allowed, and that works due to the EGI (and EGEE and LCG) policies and the practice at the sites. Stephen
On 2012-11-01 21:01, JP Navarro wrote:
An ideal design might be to support named collections of CAs where any number of services across an entire federation can reference these named collections. A detailed description of what is in a named collections would only need to exist in one place within a federation.
First I think it's important to confirm that we indeed have NO uses for this today. Does anyone know of any?
ARC clients heavily rely on that. Moreover, is bad if we don't clearly define what these strings *mean*. A client willing to understand what the string it founds here means must be able to do it in an automatical an algorothmical way. Otherwise the information there would be labeled as unclear/unrelevant. Of course one can always try to "kamikaze" submit to any endpoint it finds. I personally don't find it very performing, and I also think it basically makes our contribution (GLUE2 as a pillar of infosys) useless if we don't clarify these things in a open and accessible way.
Second I would propose that we open up the floor to proposed solutions. Discussing a proposed solution, and even coming to a consensus, doesn't mean we have to change the current GLUE 2 specification.
I agree, that's why I was proposing to fit that in rendering documents.
The community can first try to implement a consensus solution, or multiple solutions, and at some future point decide which of these we want to integrate into a future GLUE2 revision.
Sound good
In short, we need to confirm we aren't breaking any known uses and implementations while we explore solutions.
The current situation *breaks* EMI-ES implementation, unfortunately, unless we give a clear definition. See my first post. Cheers, Florido.
JP
On Nov 1, 2012, at 2:50 PM, <stephen.burke@stfc.ac.uk> wrote:
JP Navarro [mailto:navarro@mcs.anl.gov] said:
Could these strings be a hash of a DN?
That wouldn't help much, the problem is the number of CAs more than the length of each one.
How many TrustedCAs are we thinking might need to be published for each endpoint, and how much data is that really? Do we think it would significantly impact the performance of our information systems to publish multiple collections of TrustedCA strings?
At a quick count, I get 89 CAs and about 5 KB of data, compared with about 2 KB currently in an Endpoint - and that for something for which, as far as I know, we have no uses, and which would be duplicated several thousand times over. For the BDII I think publishing that would not make any sense.
Stephen
-- Scanned by iCritical.
-- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project
On 2012-11-01 20:50, stephen.burke@stfc.ac.uk wrote:
JP Navarro [mailto:navarro@mcs.anl.gov] said:
Could these strings be a hash of a DN?
That wouldn't help much, the problem is the number of CAs more than the length of each one.
Yes, true
How many TrustedCAs are we thinking might need to be published for each endpoint, and how much data is that really? Do we think it would significantly impact the performance of our information systems to publish multiple collections of TrustedCA strings?
At a quick count, I get 89 CAs and about 5 KB of data, compared with about 2 KB currently in an Endpoint -
an ARC CE currently publishes 90-100. Each endpoint is supposed to publish its TrustedCAs, for a total of rougly 816 entries in relevant endpoints. The amount of data for a single endpoint is similar to that Stephen described
and that for something for which, as far as I know, we have no uses, and which would be duplicated several thousand times over. For the BDII I think publishing that would not make any sense.
ARC clients use this information for selection and brokering of CEs. We used to have a similar approach in NorduGrid schema. ARC infosystem is a crucial part of the infrastructure, we really rely on what is published there. Cheers, -- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project
Florido Paganelli [mailto:florido.paganelli@hep.lu.se] said:
ARC clients use this information for selection and brokering of CEs. We used to have a similar approach in NorduGrid schema. ARC infosystem is a crucial part of the infrastructure, we really rely on what is published there.
In practice do you have cases where some users in a VO can't use a particular resource because their CA is not allowed, while other users can? Stephen
On 2012-11-02 10:27, stephen.burke@stfc.ac.uk wrote:
Florido Paganelli [mailto:florido.paganelli@hep.lu.se] said:
ARC clients use this information for selection and brokering of CEs. We used to have a similar approach in NorduGrid schema. ARC infosystem is a crucial part of the infrastructure, we really rely on what is published there.
In practice do you have cases where some users in a VO can't use a particular resource because their CA is not allowed, while other users can?
Stephen
I launched a quick survey on NorduGrid communication channels and the answer to your question is NO, the clusters joining well know scientific experiments using grid that are part of EGI and the like do not filter. However I recently heard of France filtering out Iranian CAs on some clusters, and I am quite sure in the US are picky about who to trust either. Did you hear about that so far? I don't know how they solved it. Then I also asked the following: "Is it common to filter or customize the allowed CAs on several clusters?" And the answer was YES from different sites because of special training CAs that are put in place during training session for those who do not have a grid certificate and should just use selected clusters. In the above, ARC clients would be able to submit only to those clusters holding the correct CA by checking TrustedCA, wherever they are, without the need of hardcoding the target cluster somewhere. Very nice autodiscovery. In principle in such scenario one could have both the IGTF string AND a list of allowed CAs in TrustedCA. I am, however, still puzzled on how a client should find out what are the CAs allowed on that cluster by just reading a plain string and not a DN... Cheers, -- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project
Florido Paganelli [mailto:florido.paganelli@hep.lu.se] said:
However I recently heard of France filtering out Iranian CAs on some clusters, and I am quite sure in the US are picky about who to trust either.
Did you hear about that so far? I don't know how they solved it.
I have sometimes heard suggestions that people might do it, but I've never seen it raised as an actual problem, and I imagine it would be much discussed at a policy level before there was any question about technical implementation. My initial suggestion would probably be to publish a negative DN, i.e. explicitly publish that a certain IGTF CA is not supported, e.g. by prefixing the DN with "DENY:".
And the answer was YES from different sites because of special training CAs that are put in place during training session for those who do not have a grid certificate and should just use selected clusters.
In EGI and EGEE I think that's normally been done by using a special VO - no doubt there are many ways.
In principle in such scenario one could have both the IGTF string AND a list of allowed CAs in TrustedCA.
Indeed.
I am, however, still puzzled on how a client should find out what are the CAs allowed on that cluster by just reading a plain string and not a DN...
A Grid UI or WN should have (at least) all the IGTF certificates installed on it, otherwise it can't authenticate services, so it should be relatively easy for a client to determine the CA DNs. For WNs that's monitored and enforced by SAM tests. For example: grep access_id_CA $X509_CERT_DIR/*.signing_policy | cut -d\' -f2 (That's certainly not the correct way to do it, I would take advice from the security people about the best method, but it illustrates the point.) It's probably also possible to get the information by downloading from the web, but you would still want to cache it locally. Stephen
participants (3)
-
Florido Paganelli -
JP Navarro -
stephen.burke＠stfc.ac.uk