OPEN ISSUES

Authentication Issues

Secure storage of private key (smartcards ? USB disks ? No filesystem storage)

While GSI long-term credentials are normally stored encrypted on disk, Globus support the PKCS11 interface to hardware tokens.
 

Use private key to check-in proxy credentials to a secure proxy server (OCR: online certificate repository).

[I think there is some confusion here over the use of OCRs in GSI. With the standard Globus Toolkit, OCRs are not used. Today most uses of OCRs are for Web-based portals are mainly used to handle delegation from the user to the portal so the portal can security act on the user?s behalf. This is needed because although web browsers and portals are capable of using SSL, they are not today capable of doing secure delegation of GSI credentials. So I?m making modifications to some of the questions below which I?ve indicated in brackets. - Von]

-Issues to resolve:

Who operates the proxy server ?

Today most uses of OCRs are for Web-based portals. Most of these portals are specific to a particular institution that runs both the portal, the OCR and the resources.

What are lifespan and renewal characteristics of proxy certs ?

[I?m ignoring OCRs and just answering this question about proxy certificates in general. - Von]

User?s today control the lifespan of their created proxy credentials (up to the limit of the lifespan on their long-term certificate). While this could lead to abuse by users who create unduly long proxies, with even minimal user education this has not been a problem to date.

If this were to start emerging as a problem we would envision making changes to the GSI code to allow a site to enforce policy - for example no proxy with a lifetime greater than X days could be used for authentication.

What are appropriate restrictions on proxy credentials and who/how controlled ?

[On 5.2.3, I was referring also to the usage restrictions (eg. may be used to get file A from machine B but not the login to machine B). - Dane]

This is still very much a area of research. In our Proxy Certificate draft to IETF and GGF we are intentionally flexible in the area of policy language since we don?t know yet what policies folks will want and what the best languages will be to carry these policies.

Since all languages have to be enforced by the resource, it ultimately decided what languages and restrictions it will understand. Our view is that any proxy that contains policy not understood by a resource should be treated by that resource as invalid and unusable for authentication and authorization decisions.

The restrictions in a Proxy Certificate are controlled by the entity that issues the Proxy Certificate (it is limited to a subset of the rights in the certificate that it is using to issue the proxy). The entity must have some way of knowing, currently out of band, what policies are understood by the resource the rights will be enforced by.

[My original response before Dane?s clarification. - Von]

[Again, ignoring OCRs. - Von]

Proxy credentials today are stored very much like Kerberos tickets - on the local filesystem, owned by the creator and protected by the filesystem?s access control mechanisms. In unix this means read and writable only by the owner.

 

User has to remember passphrase as well as maintain a secure electronic copy of the longterm private key for use.

How is minimum ( strength of )passphrase imposed ?

Today this is done through user education, though GSI software does enforce a trivial minimum of a four-character pass phrase.

 
 

Authorization Issues

How do Resource Providers apply consistent local authorization policy across a site ? Shouldn't there be something like a PAM callout in the gateway to allow for custom authorization policy decisions rather than force use of local file lookup (ie. gridmapfile)

It is common to have individuals belong to multiple authorization groups and need to try multiple permissions.

This is still very much a research area with GSI. Today this means having multiple credentials and trying them sequentially.

It is desirable for users to specify which authorizations they intend to invoke for a specific request.

This pretty much falls out in the answer to 2.6 above. Since a user has to explicitly use a given credential this is inherent in that process.

How does site articulate local authorization requirements to service requestors ?

This is currently handled outside of the Globus Toolkit.

What requests/arbitration is permitted at local authorization step and how translated ?

Currently there is no negotiation for authorization, the user can only attempt and succeed or fail.

How is communication from local resource to remote requester handled ?

Is the gateway involved in all communication ?

No. The Gatekeeper is involved in the job creation and the job-manager is involved in control of the process by the user, but the process itself is free to communicate in any manner allow by the local environment (e.g. firewalls and system software).

Is there direct communication with resource server and requestor ?

Yes, in that the gatekeeper is on the resource server.

 

Use of existing site to local mappings.

The desire here is to have GSI
map to a site identity (e.g. kerberos principal name) and then use existing
infrastructure (e.g. k5login) to map this identity to a local resource
identity. What I took away was that you think of Kerberos sites as having
two Security Infrastructures. First a site infrastructure (krb5) with it's
set of identities and then local infrastructure on each resource. And
really what you want is to have GSI come in to the border of the site, map
to the site infrastructure and then use all of site infrastructure
internally to get the resource where existing site/resource mapping takes over.

Accounting Issues

Sites will have to provide auditing abilities for the following purposes at least (agreements with VO?s may modify this list, but past experience indicates the sites would want to keep this even if the VO deferred):

-Resource utilization monitoring and agreement enforcement.
-Diagnostics and troubleshooting

-Conflict resolution between resource providers and consumers.

Globus today doesn't provide any auditing services beyond those on the local system. It?s services (e.g. Gatekeeper, GridFTP server) do log their actions to aid in diagnosis and troubleshooting.

In terms of monitoring, Globus provides the MDS service which allows for monitoring of a resource. MDS is extensible in that custom providers can be plugged in to allow for the reporting of any information desired. The set of default information can be found in the MDS Schema:

http://www.globus.org/gt2/mds2.1/Schema.html

CAS keeps a log of all the credentials it issues along with the authentication information from the user it issued the credential to. It can then either put the user?s identity in the CAS credential or a unique identifier in the CAS credential that can mapped back to the user?s identity using the CAS logs. In either case the current CAS-enabled GridFTP server logs this information.

ISSUES IN RESOLUTION

Authentication Issues

Sites all currently have authentication systems for identifying users and verifying user identities

Moving from these methods is expensive and tedious.

Sites must be able to continue using these methods for local users.

Von Responds:

Globus and GSI have no requirements that they replace existing authentication mechanisms. The goal of GSI is to authenticate a user using their Grid Credentials (i.e. X.509 certificate) and then converting this Grid identity, using local policy, to local credentials.

For standard Unix systems today this is implemented through simple mapping mechanism in GSI which uses a grid-mapfile. The grid-mapfile has locally-defined mappings from Grid identities to a local unix usernames. Application servers will then typically use setuid() to change to this local unix identity.

For credentials-based local security mechanisms, e.g. Kerberos and AFS, Globus supports credential conversion mechanisms, e.g. sslk5 and gsiklog,which allow conversion of X.509 credentials to local credentials.

Other mechanisms could be written to integrate Globus with other local security mechanisms. The idea being that GSI maps to local mechanisms, it does not replace them.

Dane Responds:

However, a requirement to propagate GRID credentials around internally within a site, is a defacto driver toward universal accomodation to the GRID mechanism. Site autonomy implies the need for a

robust, standard method for bi directional conversion.

 
 

Sites will require that they have a method to rapidly challenge an authentication

[1.6 talks about the need for a site to eg. Rapidly get an entry in the CRL for keys it knows to be compromised (eg. in case a machine is hacked and private keys stored there). - Dane]

This is an issue to be taken up between sites and the CAs issuing certificates they choose to trust. If a site wants to have a guarantee of a ability to communicate quickly this should be negotiated with the CA and written into the CA?s Certificate Policy (CP).

Looking specifically at the DOE Science Grid CA CP, while it does state that CRL?s will be issued as soon as they are changed and it does express intent to set up an OCSP (online certificate status protocol) service, there is no guarantee of being able to quickly contact the CA to get a certificate put on the CRL.

[In my opinion I think it?s reasonable to expect that during normal business hours this would be pretty quick, but if you are concerned about off-hours we may want to clarify this in the CP. - Von]
 

The site must be able to rely on timely (with 24 hours) communication through the authenticator about problems with specific accounts.

[1.7 talks about the need for all the sites that accept the same authentication tokens to learn rapidly when one has been compromised (e.g. rapid distribution of CRLs, online CRL, etc.) - Dane]

As stated in the response to 1.6 above, this is an issue to be negotiated between the site and the CA issuing certificates.

In the case of the DOE Science Grid CA, the CP is fairly clear that once the CA revokes a certificate it will publish a new CRL fairly quickly and eventually offer OCSP to give real time information.

[My original response before Dane?s clarification above. - Von]

For many cases a site will still maintain a entry in their user database for the user that is independent from the mechanism the user uses to authenticate. This database typically has the needed contact information to ensure this.

When using CAS as the authentication mechanism a site negotiates directly with the VO running the CAS server, so sites should negotiate this level of service with the CAS administrators.
 

Authorization Issues

Local authorization decisions are expected to be based on any or all of:

-Individual identity,

-Clique within approved VOs

-VO membership

Individual identity has been handled by GSI for several years now using the GSI authentication mechanism and the grid-mapfile mapping and authorization mechanism.

CAS enables the ability authorize based on VO membership and roles. A user?s possession of a CAS proxy credential indicates VO membership and their rights as granted by their roles in the VO are embedded in the credential.

Sites must have knowledge of each authorized user of its resources.

A site has ultimate control of who goes into their grid-mapfile and hence who is authorized to use their resources. A site may take whatever steps it desired to gain knowledge of a user before adding an entry for them to the grid-mapfile.

At runtime Globus applications log the mapping of identity they make from the subject name in the GSI certificate to the local account. This allows a site to determine the the actual subject name if needed.

Gateway model issues:

[This model, included below, corresponds to what we call the Gatekeeper. This normally runs on the resource in question and talked directly to the local job control mechanism on the resource. When a user job is created, a process known as a job-manager is created to monitor the process and allow control by the original user. - Von]

*In this model, there is a gateway layer at each site above each GRID resource.

*This layer has the following functions:

-Receive the GRID request and verify validity (format, contents, etc.)

-Confirm authenticity of the request (check all certs and signatures)

-Authenticate gateway back to requester

-Translate GRID identity to local identity (checking for local authorization)

-Obtain local authentication token

-Pass local authentication token and request to local GRID resource

-(How does the rest of the process work ?) ?
 

 

Accounting Issues

 

RESOLVED ISSUES

Authentication Issues

 

Supplemental systems for inter-lab access will need to be equivalent or better in strength for equivalent accesses.

Von Responds:

While it's really up to the reader, using the information in the rest of this document, to decide for themselves the relative security of the Globus Toolkit, we believe, that with proper deployment, it can meet a high standard, on the same level as Kerberos. Two fundament reasons we believe this are:

GSI is built on top of standard well-known and tested technology and software - X.509, SSL, the OpenSSL library. By using public and popular mechanisms and code we use public scrutiny to help assure security and help make the software more easy to understand.

Components of GSI that are extensions to existing standards are open source and many are well-documented in standards bodies like IETF and GGF allowing them to be subjected to public review.

Sites require an acceptable validation process for each individual to be authenticated

Sites have access to, and in many case input into, the Certificate Policies (CP) of the Certification Authorities (CA) they choose to trust. This allows them to select only processes they find to be acceptable.

This must be traceable through a trusted chain to each site.

This is done by the standard X.509 certificate chain and the SSL protocol. Each user?s certificate is signed by a CA that the site has, decided to trust.

Validations must be periodically renewed.

All X.509 certificates issued by a CA have a maximum validity lifetime that sites can determine through the CP.

For the case of DOE SG CA certificates this period is 24 months. [Still somewhat in flux, may end up just being 12 months. - Von]

Validations must be revocable by a site (at least within that site)

CAs will typically have a mechanism for a site to state that they believe a user?s identification credentials have been compromised and should be revoked. Again this will be spelled out in the CP.

In the case of the DOE SG CA any RA or any official entity may request revocation, which is very flexible.

In any case sites can always control access within their own site through their local authorization mechanisms.

 

Secure signage of proxy requests (done on smartcard ? On host PC(s) ? )

Currently this is done using software installed on a local machine. Standard system administration is expected to be done to ensure the integrity of the applications that generate the proxy certificate.

What resources needed to generate and sign proxy certs ? (subordinate CA?s ? User browser ?)

The Globus Toolkit comes with a command line application (grid-proxy-init) that given access to a user?s long term credentials (along with any pass phrase to temporarily decrypt the private key) can generate proxy certificates.
 

Forward the proxy private key.

Private keys in GSI are never transmitted over the network. Delegation is done by the acceptor of a delegation generating a new key pair, the public key is then sent over an integrity protected channel to the delegator, who signs the public key created a new proxy certificate which is returned to the acceptor.

How are authenticity checks performed and which failures may be fatal ?

The following checks are performed. Any failure is fatal.

OpenSSL checks that the user (or server if running on the user side) has a valid certificate.

OpenSSL verifies that the user possesses the private key that accompanies the certificate.

OpenSSL and GSI verify the certificate chain from the certificate presented up to a CA certificate. Each certificate in the chain must be valid.

OpenSSL and GSI verify the CA issuing the long-term certificate is trusted by the local resource.

GSI then verifies the authorization of the user identified by the certificate by check for the identity in the grid-mapfile.

GSI then maps the user to a local account name and verifies the local account name exists.

 

Authorization Issues

 

Requirements for granting authorization vary in stringency from admin access, to login access, to R/W data access to RO data access.

Authorization decisions still remain fully in the control of the resource administrator. GSI provides authentication and then the means to map users to local user accounts. The resource?s normal authorization mechanisms are then used to grant rights to that account, so normal procedures may continue to be used here.

When using CAS, you are granting the VO the right to grant authorization within certain constraints (the rights granted to the local account the VO?s CAS identity maps to). Any rights you are not comfortable allowing the VO to administer should not be granted to the CAS but instead handled through traditional user identity mapping.

Sites require the ability to revoke authorization for individuals and groups domain-wide (at least within their domain).

-This is often done now by disabling the ability to authenticate (e.g.. Change password)

-Implies user identity be part of credentials presented with requests.

Individuals and groups using CAS credentials are all required to be in the grid-mapfile and their removal from the grid-mapfile effectively revokes their authorization.

 
 

Accounting Issues

VO Requirements

The site must be assured that all members of the VO are aware of all local site security and computer usage policies and will abide by them (presumably the process of obtaining an account in the VO will include signing appropriate forms for each site).

This is policy and must be enforced by the resource or CAS administrator when they issue accounts.

Individual user validations must time out and be periodically renewed, taking account of any changes in local site policies.

This is standard in the PKI certificates used by GSI. Specifically with the DOE Science Grid CA they will expire every 1-2 years.

 
 

The site must be able to restrict access to only members of a specific VO and not automatically grant access to anyone who obtains authentication credentials from the "grid".

Regardless of where and how a certificate is obtained it does not grant the holder any rights until that certificate?s identity is placed into an authorization system (e.g. a grid-mapfile or CAS).

 

Use proxy private key to sign authentication packet (e.g.. Timestamp, proxy public key) and encrypt with remote server public key.

-Issues to resolve:

Is this an application level transaction or an SSL library call ? GSI library call ?

This is a SSL library call and is part of the standard SSL protocol.

How is remote server public key obtained ? Verified ?

The remote server certificate is obtained as part of the SSL handshake (standard SSL protocol). An application using the GSI passed to the GSI some information about what it expects to be talking to (e.g. the GridFTP server on host foo.bar.edu), based on this information and a list of trusted CA certificates installed on the clients system the GSI libraries make sure the server?s certificate came from a trusted CA and has a name that coincides with what the application expected.
 

Who is responsible for selecting, obtaining, distributing and supporting the application suite ?

[What application suite are we talking about here? - Von]

[5.6.2 refers to the globus-proxy-init, etal sorts of applications that a user is expected to have access to to "login" to the grid. Is the model that we install globus toolkit on all desktops of folks planning to participate in Grid computing ? Is it that VO applications and/or recipes include distribution/wrappers for these functions ? - Dane]

The Globus Project will continue to distribute and support the Globus Toolkit. Others projects (e.g. NMI, GriPhyN, NEES) are tailoring the toolkit to their particular needs (including configuration, bundling Globus with other software) and redistributing. Ideally projects should try to leverage off of one of these other distributions and make their own only if they need to.

It?s probably unreasonable to install and maintain any software on user?s systems outside those of the core sites. The model to follow, I suspect, would be the one that sites like FNAL have in place today for their Kerberos software.