E-Infrastructure Security: Authentication Levels of Assurance (LoAs) – background and introductory discussion of issues

1. E-Infrastructure Security:Authentication Levels of Assurance (LoAs)– background and introductory discussion of issues Ning Zhang, the University of Manchester, UK David Groep, National Institute for Nuclear and High Energy Physics, NL Blair Dillaway, OGF Security Area Director

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

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

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

5. Current work/efforts in defining LoAs • 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

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

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

8. The NIST Guideline • Token types versus LoAs:

9. The NIST Guideline • Authentication protocols versus LoAs:

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

11. 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 Profilefocuses 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

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

13. 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?

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

15. Comments - 1

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

17. Comments - 2

18. 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?

19. Comments - 3