You are here: TWiki > Security Web>SecurityTeamWorkingArea>CiLogonPilot2010 (10 Feb 2011, X509_2fDC_3dorg_2fDC_3ddoegrids_2fOU_3dPeople_2fCN_3dMine_20Altunay_20215076)

CILogon Basic CA Pilot Project


The CILogon Basic CA is part of the CILogon project which aims to provide a logon service for NSF cyberintrastructure (CI). This CA will provide a user with an X.509 certificate following authentication to any of the InCommon Identity providers (IdPs). InCommon is a federation of about 250 institutions serving the higher educational community in the U.S. with a goal of enabling users to access CI and other web-based services based on their login at their home institution. We anticipate that this federation will eventually cover a significant fraction of the OSG user community.

Another CA in the CILogon project (CILogon Silver CA) has been accredited by the IGTF but as of October 2010 there are no InCommon members with IdPs accredited at the Silver level and it is anticipated that the first universities will achieve that accreditation in mid to late 2011. This means no one is able to receive X.509 grid certificates from the CILogon Silver CA until their home institution achieves the Silver level of accreditation.

In order to enable production level testing of the CILogon service and start to leverage the InCommon federation, the OSG is collaborating with the CILogon project to enable sites to install the CILogon Basic CA easily and with some controls (described below) to compensate for the lack of IGTF or InCommon accreditation of the individual IdPs so that some users are able to begin to use the service.

Review of OSG access model

When users access grid resources on OSG there are three levels of controls implemented to ensure that the access is authorized and that the user, via their grid credentials, is identified sufficiently. These controls are:
  1. The CA issues X.509 certificates based on identity vetting in the registration process
  2. The VO asserts that a user is a member based on providing the identifier for the user in the VOMS server (the user's DN)
  3. The site enforcing the credential authentication/authorization checks that credentials received are from a trusted CA and listed in a trusted VOMS server.

CAs that are accredited by the IGTF are automatically included in the package of trusted CAs distributed by OSG. In certain cases where there is a community need and OSG thinks that a non-IGTF accredited CA meets a sufficient level of identity & credential quality, additional CAs are included in the distribution from OSG. This includes CAs from TeraGrid and Purdue, and the FNAL KCA before it was accredited in IGTF.

Controls restricting the scope of CILogon Basic CA

InCommon federation policies

Any InCommon member can publish an identity provider in the InCommon metadata so that it is accessible to services provided by other InCommon members. There are mostly universities but also some DOE laboratories as well as Protect Network that runs a self-registration service where anyone can receive an InCommon based on validation of email address. One can expect that the credentials received from IdPs have unique identifiers across all the InCommon members but do not necessarily allow you to identify who the person is that holds the credentials. Below are examples, using the LBNL IdP and Protect Network:
$ openssl x509 -in x509up_u_olson.cilogon-basic.100901 -noout -subject -issuer
subject= /DC=org/DC=cilogon/C=US/O=Lawrence Berkeley National Laboratory/CN=Douglas Olson A241
issuer= /DC=org/DC=cilogon/C=US/O=CILogon/CN=CILogon Basic CA 1

$ openssl x509 -in x509up_u_olson.cilogon-basic-pn-101012.pem -noout -subject -issuer
subject= /DC=org/DC=cilogon/C=US/O=ProtectNetwork/CN=Douglas Olson A265
issuer= /DC=org/DC=cilogon/C=US/O=CILogon/CN=CILogon Basic CA 1
shows that the name of the organization and the name of the person are listed. Note that in the case of Protect Network you can "be anyone you want" but an extra string is added to the name ('A265' above) to make sure it is unique within the Protect Network namespace.

signing_policy file

The primary grid services on OSG (gatekeeper, gridftp server, srm) make use of the signing_policy file distributed with each trusted CA, which allows sites to restrict what identities are acceptable for a given CA. The example signing_policy file below
access_id_CA   X509    '/DC=org/DC=cilogon/C=US/O=CILogon/CN=CILogon Basic CA 1'
pos_rights     globus  CA:sign
cond_subjects  globus  '"/DC=org/DC=cilogon/C=US/O=Clemson University/*" \
                 "/DC=org/DC=cilogon/C=US/O=Lawrence Berkeley National Laboratory/*"'
will restrict acceptable credentials to those issued by Clemson and LBNL. Note that every CA, not just CILogon, has a signing_policy file and sites may use these to enforce additional restrictions (within limitations) on the credentials from any particular CA.

VOMS registration

While VOs and the administrators of VOMS servers in general do not have a prescribed process to verify someone's identity before including their credential in the VOMS server for the VO we expect that some level of validation takes place that is roughly equivalent to the process by which people are registered for grid certificates from IGTF accredited CAs. It is the VOs' self interest as much as the sites to make sure that only valid users are included in their VOMS servers. Many VOs do have very controlled procedures for registration in the VOMS server but without an accrediting organization defining standards we can not make a blanket statement about the strength of the vetting procedures.

Risk of using CILogon Basic CA

The OSG registration process using the DOEGrids CA relies on a network of people associated with the VOs (people choose a VO when they request a certificate) and is roughly (but not precisely) a duplication of the procedure that people need to do when registering with their VO. For some VOs these two registrations are rather tightly coupled and for others they are similar but not directly related.

One aspect of name uniqueness for InCommon IdPs that is unclear is the period of time for which a given identity is guaranteed to NOT be reassigned to a different individual. IGTF requires that period to be indefinite (forever). For the pilot test of CILogon Basic CA we make sure that the identities are not re-assigned for at least a year, at which point the CILogon SIlver CA should become useful.

OSG will provide a signing_policy file that includes only IdPs that we have investigated at some level and we consider to be acceptable and for which we have the ability to contact the operators of the IdP. Due to limitations of the signing_policy file as well as OSG effort we will not be able to include a large number of IdPs for CILogon Basic CA. Including a significant number of IdPs for OSG users will require the CILogon Silver CA to be functional.

Given the basic policies of InCommon and the CILogon Basic CA (name uniqueness, CRLs), the signing_policy file (specific list of IdPs) and the VO registration required before a user is granted access to a resource on OSG we think that the risk to sites/users/VOs of using CILogon Basic identities in the OSG infrastructure is comparable to that for using the IGTF accredited CAs, at least for the next year.

To install CILogon Basic CA

We will include the CILogon Basic CA (and CILogon Silver CA) in a distribution for the OSG ITB sites (1.16ITB). To install it on other sites and client system you should download the tarball from (TBD), untar it to some directory, check the signing_policy file to make sure it has the IdPs you are interested in, and use vdt-ca-manage to install it into your trusted CAs directory. ( More detail needed here. )

Use CILogon Basic CA


Since the CILogon Basic CA is not accredited by the IGTF is will very likely not be accepted outside the U.S., by sites or VOMS servers, and not all sites in the U.S. However, we hope that it is acceptable for significant number of sites and VOs participating in OSG.

How to add an IdP

Users and VOs interested in having additional IdPs included in the signing_policy file provided by OSG should send a request to or one of the security team members so we can assess it and establish contacts with the IdP operators. As mentioned above, there are limitations in the signing_policy file so that we can not add a large number of individual IdPs but a few more than the initial two is possible.

Included IdPs

Updates 2/10/2011

  • We are only moving forward with the Clemson IdP? for the pilot test happening in March of 2011

Updates to the risks

We understood that Clemson IdP? is integrated into the enterprise access control management system at the Clemson University. All of the accounts are retrieved from regular departmental, registrars and other official account databases. Therefore, the Clemson IdP? carries out the same level of identity vetting assurance as any other Clemson Identity services. The guest accounts such as library cards and such are given out to visitors only when the visitors can provide strong support from a regular Clemson employee. The sponsoring Clemson employee vets the identity and vouches a form to allow the guest account go live. The guest accounts last 180 days.

Our conclusion is Clemson IdP? operates at the same level of assurance as any other IGTF CA does. We see no additional risk in accepting the authentication tokens distributed by the Clemson University.

Another risk that is NOT related to Clemson IDP, but related to our own middleware is distinguishing the IdPs? that OSG has agreed to work with. CILogon Basic CA provides certificate services to a number of IdPs? all working at different levels of identity assurance. Clemson IdP? is just one of these IdPs? out of hundreds of IdP? that can get certificates from the Basic CA.

In order to distinguish which IdPs? are acceptable to OSG, we will use a number of controls. First, we will employ signing policy files. These files show the namespace in which a CA promises to issue certificates in. During authentication, GSI libraries checks a presented certificate against the signing policy file of the CA. If the certificate's name space is not covered in the CA namespace, then the authentication fails even when the certificate is validly signed by the CA. In OSG, we will create a signing policy file for Basic CIlogon CA that will only include the Clemson IdP? namespace.

In addition, every certificate issued by the Basic CA indicates the related IdP? in the certificate DN.

In OSG middleware, there are some software components who does not use GSI libraries fully. Instead they use openssl libraries to implement GSI protocol. We do not know how closely these components implement the GSI library. We do know that openssl does not check agains signing policy files. This is a feature of GSI protocol. There is a small risk that a component who uses openssl directly may not check against the signing policy files and authenticate Basic CA certificates from all IdP? associated with Basic CA.

Our mitigation for this risk is the authorization step. The IdP? information is also included in user's DN, and the during authorization, the component will get a failure that the end user DN does not match the DN downloaded from the VOMS.Because the IdP? specified by the VO does not match the end user certificate submitted for the access request.

There is always the residual risk that a VO may enter incorrect DN names into the VOMS server. This risk is independent of the authentication process or which CAs are used. At the worst case scenario, A VOMS admin may accept a certificate from a user without noticing the IdP? included in the end user certificate does not match the OSG signing policy. This risk is almost non-existent because VOMS server uses the GSI and should download the signing policy file. When a user submits a registration request with its certificate, the VOMS server does the authentication first and does not let the user proceed with the request if the authentication fails.

We conclude that the risk of moving ahead with CILogon pilot CA is very small and equivalent to that of using other IGTF CAs.

-- DougOlson - 12 Oct 2010

Topic revision: r4 - 10 Feb 2011 - 17:53:48 - X509_2fDC_3dorg_2fDC_3ddoegrids_2fOU_3dPeople_2fCN_3dMine_20Altunay_20215076
Hello, TWikiGuest


TWiki | Report Bugs | Privacy Policy

This site is powered by the TWiki collaboration platformCopyright by the contributing authors. All material on this collaboration platform is the property of the contributing authors..