Use of host-bound agent credentials in peer2peer arrangements [Mike Helm, Doug Olson, 2005.01.15] Doug Olson has raised an issue about certificates for things like hosts or (really) services, that are used in P2P-like arrangements, or simply as clients to other services. The practical result is that the subject names in these certs wind up in Grid mapfiles. The threat, for a relying party, is that it is possible for certificates with the same name to be issued. We know this has been discussed in EGEE/EGD but I don't have a firm idea if there is a consensus. This seems like a minimum requirements/profile/GGF kind of problem. Could we take a few minutes in this month's session to talk this out, discuss relying party expectations, and ideas for how to resolve it: specific policies, a policy document direction &c? Doug Olson writes: ... > A use case is described below and the "Policy change 1" is > the thing I would like to complete farily soon. > The "Policy change 2" is part of a broader loanger term discussion > and I included it below for your thoughts & comments but do not > expect a change to the CP-CPS to happen soon on it. > Thanks, > Doug > > Use Case: > A physicist (Joe) runs a data analysis service > (CN=dial/analysis.physics.edu) as a user mode service that will > perform various data management and analysis processing tasks for > other physicists. The data management tasks performed by this service > do not have a delegated credential of any particular user because they > run asynchronously, managing data placement based on heuristics. The > DN of this service today can be > > CN=dial/analysis.physics.edu,OU=Services,DC=doegrids,DC=org > > This service will contact a storage system via gridftp and is > authenticated/authorized by having the service DN in the gridmap file > on the storage system. Another person (Frank), knowingly or > unknowningly, requests a certificate with the same DN. Frank has a > valid DOEGrids OU=People certificate and is properly issued a > certificate with this same DN. Joe is not notified that a certificate > with this same DN has been issued to another person. Frank can use > his new service certificate to impersonate Joe's service when > contacting the storage system. > > Policy change 1: > I propose changing the existing policy on > OU=Services,DC=doegrids,DC=org to have additional text like: When a > person requests a certificate in OU=Services with a new and unique DN > they become the "registered owner" of that DN. Any future certificate > requests with this same DN must be verified and validated by > contacting the "registered owner" of the DN. > > Policy change 2: > I don't have suggested text for this change but the idea is to discuss > the issue of including some identifier of the person (or organization) > responsible for an OU=Services certificate included in the complete > DN. This may be like the OU=robots proposal > (https://forge.gridforum.org/projects/caops-wg/document/Certificates_for_Automated_Clients/en/1). > The problem being that with peer-to-peer services operating without an > end-used delegated credential, the DN of certificate of the service > should include an identifier for the person or organization > responsible for the service since this DN is used in authorization > decisions. If and when the authorization infrastructure uses more > than just the DN field of a certificate then the information > identifying the responsible party could be included in another part of > the certificate but with the current practice in the Globus Toolkit > only the DN is used. ----------------------------------------------------------------------------- [Jans Jensen, 2005.01.17] For the UK e-Science CA, I require that the *responsible sysadmin* applies not just for host but also service certificates. Most sites (of a non-negligible size?) have a single responsible admin for any given machine and a "backup admin" in case the first is unavailable, as a part of normal security practice. The RA is required to verify that the person requesting the host/service certificate is responsible for the machine in question. In your example, when John Doe leaves, Jane Roe becomes the sysadmin of the box and handles the renewal. Or if she doesn't, she cannot renew the certificate. With my Grid hat, I have root on several machines that I don't admin, but I can no less renew their certificates than I can, say, (re)install Windows or NetBSD on them. If I want to do that, I must be appointed - at least temporarily - responsible sysadmin for the boxes. So if I urgently need a certificate for service foo I *must* go through the admins. Even if I'm the CA manager :-) Milan, IIRC, has even more stringent requirements; he requires a signed piece of paper authorising a person to apply for the certificate. N'est-ce pas? Cheers, --jens ------------------------------------------------------------------------------ [Mike Helm, 2005.01.17] Milan Sova writes: >> Jens G Jensen wrote: > >>> > So if I urgently need a certificate for service foo I *must* go through >>> > piece of paper authorising a person to apply for the certificate. >>> > N'est-ce pas? >>> > > >> C'est vrai. :) >> >> The reasoning is obviuos now, isn't it? I was thinking of you all when I posted this. I think that there's no question that the certificates are legitimate, as far as the approver and the requestor are concerned; there are controls in place for that (adequate or not, one could argue). Not completely sure about this but I think people are exploiting the Globus capability of setting up personal service infrastructure, and perhaps, on a very large system, it is possible to have independent installations of the same service. We don't seem to have enough controls in place to deal with this, to the satisfaction of some relying parties. I am not sure I can count on a sys admin to think of this as a problem. Does this situation ever come up here? I may need to explain this a little better. Thanks, ==mwh ------------------------------------------------------------------------------ [Mike Helm, 2005.01.21] >Doug Olson writes: > >>> > CN=dial/analysis.physics.edu,OU=Services,DC=doegrids,DC=org >>> > Policy change 1: >>> > I propose changing the existing policy on >>> > OU=Services,DC=doegrids,DC=org to have additional text like: When a >>> > person requests a certificate in OU=Services with a new and unique DN >>> > they become the "registered owner" of that DN. Any future certificate >>> > requests with this same DN must be verified and validated by >>> > contacting the "registered owner" of the DN. Doug Olson has drafted a set of changes to the DOEGrids CP/CPS that expands on this. Introduces and defines concepts of owners/registered owners; binds email address in host/service cert to DN (as indicator of "registered owner") ; assigns responsibility to maintain the binding between DN and registered owner to CA; subscriber responsibility: Verify that the DN being requested does not yet exist, or assert that they are the registered owner of the DN. CA, its RA's, and agents have the responsibility to verify that requestor is the owner of the DN. There are a couple of other changes (including one related to revoking these registered owner certs) that I don't quite understand, but I think this is the gist of it. Comments? Is this something that could be mapped into policies in EU Grid CA's now, or something that might be considered? [Same forr other communities that might be reading this] Thanks, ==mwh Michael Helm ESnet/LBNL