Work in progress This is work building up to a final requirements document on grid AAA/Security. It draws very greatly upon [wiki:RequirementsBibliography Shawn Mullen et al's] (2004) document on "Grid Authentication, Authorization and Accounting Requirements". Most of the requirement text is from this document and where we disagree, we have indicated this

Thus:

The requirements for an ideal grid

Should this be "an 'ideal' grid" or "an idealised grid" or whatever?

This document

The sections of this document are:

  1. Abstract
  2. Terminology and definitions
  3. Grid use models
  4. Site Authentication Requirements
    • (Terminology and definitions)
  5. Site Authorization Requirements

Abstract

To be written last

However, it should include some definitions of "must" and "should" etc. AND a discussion of the grid model (e.g. Customer-Service, Technical Research User (agnostic of node), Technical Research User (node specific), Privacy/Conf./High security etc. (The musts and shoulds will be different for each grid model)

Terminology and definitions

To be written late-on when we know what we need.

Grid use models

Introduction

The use models of grids are written about elsewhere by this project. However, for clarity, they are reproduced here

BLAH BLAH

(Chapter 1) Site Authentication Requirements

Terminology and definitions

"User secrets" refers to values intended to be known only by the user, known by the user and an authentication infrastructure, or known only to an authentication infrastructure and employed on the user's behalf after the user has authenticated with some other secret(s).

To sidestep such questions as whether "a day" means eight hours or 24 hours and just how long a month is, we will deal in seconds but not quibble over implementation variances at the 10% or 20% level.

Credentials are assumed to have lifetimes which bound their period of validity. "Long-lived" credentials have lifetimes of 1,000,000 seconds (1 megasecond or 1 Ms) or more. "Short-lived" credentials have lifetimes of 100,000 seconds (0.1 Ms) or less. Lifetimes between those limits are "intermediate." The terms long-lived and short-lived may also be applied to the secrets employed by a user to acquire credentials, although the only short-lived user secrets known to be commonly employed are one-time (or "single-use") authenticators.

(Conversions: 0.1 Ms is a bit more than a day; 1 Ms is a bit less than 2 weeks.)

If a credential's lifetime can be extended by the user, using no more proof of identity than the credential itself, this is considered "renewal" of the credential, while if the process of extending the lifetime requires measures equivalent to those employed in its initial acquisition, we consider the result a new credential.

We specifically do not consider "post-dated" credentials -- those with lifetimes that begin at some point later than the time of the authentication act. Neither do we consider the relative strengths of cryptographic protocols, algorithms, and key lengths. We assume they are always designed, selected and implemented appropriately.

Identity

Sites will often make authorization decisions on an aggregate basis: on Virtual Organization (VO) membership or group membership. However, at times it may be necessary to set access rights at the granularity of a single user. Sites therefore may need to reserve the right, and preserve the ability, to set authorization at this level. Incident handling requires the ability to identify the legitimate owner of credentials presented during transactions under investigation. However, this may be done in concert with a trusted partner (i.e. the site could accept a pseudonym with good provenance but later need to know who/what is the actual owner of the credentials presented, and could co-operate with that partner to determine the identity). 

FOLLOWING NEEDS EDITING INTELLIGENTLY
Accordingly, every set of authentication credentials should be tied to the identity of an individual, because this provides stronger security by way of audit ability, revocation, and problem determination.  However, there may be occasion to forfeit these benefits in order to provide temporary and generic identities.

For example, an Internet cafe could provide temporary (very limited lifetime) credentials authorizing use of grid resources based solely on the fact that access was purchased.  Such an identity may be a psuedonym such as "Customer 24."

Other, similar identity indirections are expected:
 * action traceable to a specific organization within a specific VO
 * action traceable to a specific VO
 * action purely anonymous

====   ====
Secure anonymous communications may still be allowable, and appropriate, for functions that do not require user authentication.

For example, in the case above of cafe access to Grid resources; the user may still require secure conversation because the results of the data derived may have some proprietary value.