Ning Zhang, the University of Manchester, UKDavid Groep, National Institute for Nuclear and High Energy Physics, NLBlair Dillaway, OGF Security Area Director

E-Infrastructure Security:Authentication Levels of Assurance (LoAs)

– background and introductory discussion of issues

Agenda

• Factors affecting LoAs

• Why do we need LoAs

• Current work/efforts in defining LoAs

• Gaps when applying these existing definitions to the Grid context

Factors affecting LoAs

• All the steps of an authentication process:– Identity proofing/vetting – Credential issuance– Types/strengths of authentication credentials– How/where credentials are stored– Strengths of authentication protocols/services– Record keeping and auditing – Extent to which an authentication event is

coupled to an authorisation event

Why do we need LoAs?

• A binary ‘Yes’ or ‘No’ decision for authentication decision is no longer satisfactory, as– More diverse resources (data and services, etc) are

being incorporated into the Grid fabric, e.g. health Grids hosting patients’ private data

– Resources have varying levels of sensitivity– The Grid fabric is expected to integrate with other

trust fabrics, e.g. InCommon, e-Government, and this leads to a more diverse resource sharing environment

– So we need to have LoAs, and link LoAs to authorisation decision making

• Earlier efforts:– UK Government’s e-Government initiative

defined LoAs (a) based upon importance of transactions (2000) and (b) based on severity of the consequences from misuse of a credential (2002)

– US Government’s e-Authentication initiative (2003) defined LoAs based on likely consequences of an authentication error and misuse of credentials

• OMB M-04-04, E-Authentication Guidance for Federal Agencies

Current work/efforts in defining LoAs

OMB M-04-04

• The four assurance levels are defined as follows:– Level 1: Little or no confidence in the asserted

identity’s validity.– Level 2: Some confidence in the asserted

identity’s validity.– Level 3: High confidence in the asserted

identity’s validity.– Level 4: Very high confidence in the asserted

identity’s validity.

The NIST Guideline

• NIST SP800-63 [NIST06] provides technical requirements for authentication LoAs defined in [M-04-04]:

• Identity vetting– Level 1: names are not verified; names are

always assumed to be pseudonyms;– Level 2: credentials and assertions must

specify whether the name is a verified name or a pseudonym;

– Levels 3 and 4: names must be verified.

The NIST Guideline

Level 1 Level 2 Level 3 Level 4

Hard token √ √ √ √ OTP device √ √ √ Soft token √ √ √

Signed assertion valid for 2 hours

√ √ √

Signed assertion valid for 12 hours

√ √

Password & PINs √ √

•Token types versus LoAs:

The NIST Guideline

• Authentication protocols versus LoAs:

Level 1

Level 2

Level 3

Level 4

Private key PoP √ √ √ √

Symmetric key PoP √ √ √ √

Tunnelled or Zero Knowledge password

√ √

Challenge response password

√

The OMB M-04-04 & NIST Guidelines

• The scope– Only address human-to-machine e-authentication.– Only address secret-based e-authentication, and the use of

biometrics is only considered in the processes of registration and for unlocking keys.

– It does not address machine-to-machine authentication, credential delegation, n-tier authentication, or the use of on-line credential repository.

– It does not address the requirements for authentication credential/token issuance to machines or servers.

– It does not address how authentication events are bound to authorisation events.

The IGTF Profiles

• the IGTF (International Grid Trust Federation) WG has also been working on LoAs:– Classic Profile describes the minimum requirements

on traditional X.509 PKI CAs focusing operational aspects

– SLCS Profile focuses on operational aspects of short-lived credential services

• The scope is too narrow.• An initial attempt is being made (by Peter

Alterman & Scott Rea from Dartmouth and HEBCA/USHER) to map the IGTF Classic Profile to the Federal Bridge CAs

The InCommon Efforts

• The InCommon federation – Has proposed to be partnership with the

Authentication Federation. – They propose to map InCommon LoAs to

federal levels of assurance, 1 and 2, i.e.• InCommon Bronze = NIST Level 1• InCommon Silver = NIST Level 2

Two questions for you!

• Do we (the Grid community) need LoAs in achieving fine-grained access control, or are we happy with binary authentication decisions?

• If ‘Yes’, then how to approach this? – build on, or have something completely different from, the NIST recommendation.

• Should we work together with other federations, e.g. the e-Authentication federation, the InCommon federation, the UK JISC community (Shibboleth-based), etc… to come up with a set of consistent LoAs so as to achieve seamless inter-federation resource sharing?

Gaps for using existing LoA definitions (1/3)

• Assertion messages: Do we need guidance on the procedures and generation of assertion messages versus LoAs?

• Conflict: assertion message validity periods vs. LoAs vs Grid Job durations

• Token strength: Should we impose limited lifetimes to passwords?

• Extent to which an authentication event is coupled to an authorisation event.

Comments - 1

Gaps for using existing LoA definitions (2/3)

• No guidelines with regard to Grid context related LoA factors, e.g. – Credentials stored in remote on-line repositories– Proxy credentials and validity durations– when using delegation credentials, would the LoA be

different wrt: 1) using entity's identity; 2) using the delegation credential

– N-tier authentication issues – Credential translation service; though IGTF-SLCS

covers this (partially), there is no mapping versus LoAs

Comments - 2

Gaps for using existing LoA definitions (3/3)

– When entity identification/authentication is not performed by the relying parties directly

• do we need a standard algorithm or method for LoA derivation (e.g. the weakest link principle)?

• would RPs want to know the chain of authentications and credentials used?

• If so, do we need a standard mechanism for the conveyance of LoA attributes values from the verifier(s) to the relying parties?

• do we need to agree on a list of LoA attribute names and values which the RPs would be interested in knowing?

Comments - 3