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:

•   V Amendment/addition from the Mullen et al document V 

  • Text

    ^ Amendment/addition from the Mullen et al document ^ 

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

•   V Amendment/addition from the Mullen et al document V 

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).

•   ^ Amendment/addition from the Mullen et al document ^ 

IMPORTANT REMOVAL FROM THE MULLEN et al DOC:
"Accordingly, every set of authentication credentials should be tied to the identity of an individual..."

Also minor changes in the next paragraph (shown in italics).

Accordingly, every set of authentication credentials should be traceable to the identity of an individual, because this provides stronger security by way of auditability, revocation, and problem determination. However, in very special cases 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."

•   V Addition to the Mullen et al document V 

Where credentials are supplied pseudonymously by an identity provider (home organisation) to a grid node or nodes, a service level agreement must be in place between that identity provider and the grid community that will ensure the rapid revocation of those credentials when demanded. This may be invoked by a service provider (or grid node) that detects a security problem associated with those credentials. It may be advantageous that credentials may thus be issued and re-issued easily, and therefore the consequences to the user (or end entity) may be minimised following a false positive (i.e. mistaken) revocation.

•   ^ Addition to the Mullen et al document ^ 

May need to re-write the above as it is rather wordy and verbose and, erm, wordy.

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.

Assurance

An authentication system may provide multiple methods for a user to perform their initial authentication, and these methods may differ in their convenience, resistance to attack, and risks of exposure of secrets. Even when an implementation offers its users only one method, it may not be clear to relying parties which method it is. Since some inverse correlation does exist between convenience and strength of authentication, there may be inducements to allow and employ multiple levels of authentication if sites make some class of services available through weaker but less burdensome authentication methods.

  V Many changes (unless highlighted) the Mullen et al doc exist in the following sections V 

In a deviation from the Mullen et al document, we suggest that there is certainly a greater variety of assurance levels possible, due to both the nature of the authentication tokens (and their storage/encryption) and the policies and procedures regarding their issue and timely revocation. Thus, a numbered scale of assurance level should exist and a value should be passed from the identity provider (home organisation) to the grid node or nodes for short term credentials, or should be kept permanently (implicitly or explicitly) within longer term credentials. This assurance 'grade' [xxxxbetter terms?] needs to be a value recognised by an international standard or (more likely in the shorter term) be based upon a system agreed upon by collaborators within a particular grid.

The system for grading the assurance level of each authentication assertion is beyond the scope of this document. However, this assertion should be made and transmitted. If practicable, the method used to perform authentication should be deducible from credentials, but this requirement is secondary to the requirement of the transmission of assurance level.

Levels of authentication strength

We consider this to be eyond the scope of this document. However, we demur from Mullen et al. in that we believe that the concept of "authentication strength" is too close to the concept of "assurance level". The reliability or trustablility of an authentication event or authentication token is based equally upon the technology used (and short/long term credentials and encryption etc.) and the policies used to initially authenticate, maintain data, and renew revoke credentials.

Mode of storage

We agree broadly with the Mullen et al document, but consider these details to be outside of the scope of this requirements document at present.

Ranking of storage modes

We agree broadly with the Mullen et al document, but believe that this is where home organisation (or "identity provider") security policies play a role in ranking the storage mode in a way that would affect a judgement of assurance level.

•   V Original text (endorsed) from the Mullen et al document V 

It is not possible to give a strict ranking of storage modes discussed in section 1.5.3.3 relative to safety without asking and answering a number of questions about the details of the secrets, their storage, and their registration as the users' authentication information. Also, users may perform unsafe actions (knowingly or unknowingly) which place their secrets at much greater risk of disclosure.

•   ^ Original text (endorsed) from the Mullen et al document ^ 

Deducible Authn strength

• We detract slightly from the Mullen et al document in that "Authentication strength must be mechanically deducible from credentials" and "The method used to perform authentication should be deducible from credentials". This appears to be too difficult to make workable and would give rise to a difficult set of ontologies. We return to our avowal that a recognised and endorsed assurance level should be asserted by the home organisation (or identity provider).

  ^ END of Many changes (unless highlighted) from the Mullen et al doc ^ 

There are a number of cases where processes running on a machine need to authenticate to other processes. Automated processes may have to act as authenticated clients and users may wish to have automatic software ("cron jobs") that require automatic authentication. All of these should be somehow restricted such that theft of credentials from an individual machine does not easily permit their reuse elsewhere. In either case, secrets will be of the "stored" class and must be considered to be stored in cleartext form, regardless of any measures which obfuscate them.

•   Note: do we need any more thinking about the next 2 points? 

• Authenticated identities of automated client processes should include identification of the machine which is intended to have access to the authentication secret. Authentication methods based on stored secrets should indicate the machine from which they were used. If they do not, then this information must be available in auditable records.

Lifetimes

1.4.1. All forms of digital credential in common use are subject to possible theft and misuse. The probability of such an event is monotonically nondecreasing with time. The countermeasures against eventual credential theft are expiration and revocation. Neither measure alone is sufficient to prevent all misuse, nor is the combination of the two.

•   V Amendment/addition from the Mullen et al document V 

Two types of digital credential should be highlighted here to take into account the roles and behaviour of proxy parties. In many use-cases it has been seen to be necessary to generate proxy credentials. These may differ in digital nature and in assurance level from the original user digital credential. They are typically shorter lived than the original digital credentials, but there may be exceptions to this generalisation.

•   ^ Amendment/addition from the Mullen et al document ^ 

    V Much changed in the following sections from the Mullen et al document
      to accommodate user and proxy credentials and to make some of the timings
      more onerous/rigorous V 

  • 1.4.1.1
    • User authentication credentials must not be valid for more than 1 Ms if there is no method for checking for revocation. User authentication credentials should be renewed or checked for revocation every 0.1 Ms.
    1.4.1.2
    • Authorities issuing revocable credentials must publish the procedures for initiating revocation. In the case of X.509 certificates, each revocable certificate should include a pointer to such procedures. These procedures must include the location and

Mullen [Page 5]

GGF Draft Grid AAA Requirements 21 May 2004

• publication frequency of revocation information and an upper bound on the time required to act on a revocation request.

• 1.4.1.3
  • It should be possible for authority parties other than the credential issuer or the credential owner to initiate revocation, under some circumstances. ( For example the authority that vetted the identity of the user.) The processing time bound above may not apply to third-party requests for revocation.
  1.4.2 The lifetime of authentication secrets is a separate parameter from the lifetime of credentials. 1.4.2.1
  • User secrets stored mentally should have a lifetime of 50 Ms or less. Some environments or applications may demand shorter lifetimes, down to perhaps 10 Ms. These times may vary depending on the strength of the password enforced by the password requirements of the system.
  1.4.2.2
  • Secured user secrets may reasonably have lifetimes of 100 Ms or more depending on the securing technology.
  1.4.2.3
  • Stored user secrets should not be valid for more than 1 Ms, and if valid longer than that, their associated credentials must declare that fact.
  1.4.2.4
  • The above lifetimes are relevant to both the strength of the password and the strength of the crypto-analysis or password cracking tools. These lifetimes should be adjusted to reflect the current state of the art in these two related technologies.