User Authentication and Levels of Assurance

Authentication focuses on verifying a person’s identity based on the reliability of a credential offered, typically a password. Assurance answers the question, "How sure am I that you are who you say you are?" In other words, how much confidence does a relying party have that the credential presented is in the possession of the person whose identity is being asserted.

The Office of Management and Budget (OMB 04-04) describes four levels of identity authentication assurance levels, with Level 1 being the lowest level of assurance and Level 4 being the highest level of assurance. Each assurance level describes the degree of confidence that the user that presented a credential (e.g. a password) is in fact that user.

The level of assurance needed is based on the consequence of authentication errors and/or misuse of credentials. As the consequences of an authentication error increase, the level of assurance should increase. Informal or low value requests will require less stringent assurance. Higher value or legally significant requests (e.g. HIPAA) will require more stringent assurance.

Identified risks for a particular application should be mapped to an appropriate authentication level based on potential impact. Assignment of impact to these risks is based on the context and nature of the people or entities affected by an improper authentication. For example, if five categories of potential impact are for Level 1 and one category of potential impact is for Level 2, the application should require Level 2 authentication.

  Maximum Potential Impact of Event for each Assurance Level
Impact of Authentication Error Level 1 Level 2 Level 3 Level 4
  Little or no confidence exists in the asserted identity; usually self-asserted; essentially a persistent identifier Confidence exists that the asserted identity is accurate; used frequently for self service applications High confidence in the asserted identity's accuracy; used to access restricted data Very high confidence in the asserted identity's accuracy; used to access highly restricted data.
Potential Damage to reputation  Low  Moderate  Moderate  High
Potential financial loss or liability  Low  Moderate  Moderate  High
Potential for unauthorized release of sensitive information  N/A      
Potential civil (or criminal) violations; e.g. out of compliance with regulatory rules  N/A  Low  Moderate  High
Potential harm to University programs or public interests  N/A  Low  Moderate  High
Potential impact to personal safety  N/A  N/A  Low  Moderate/High

Impact values assigned by OMB for these categories of harm are defined in Federal Information Processing Standard 199, "Standard for Security Categorization of Federal Information and Information Systems" and reproduced below.

Impact Values (FIPS 199)  
 Low The loss of confidentiality, integrity and availability could be expected to have a limited adverse affect on organizational operations, organization assets or individuals.
 Moderate The loss of confidentiality, integrity and availability could be expected to have a serious adverse affect on organizational operations, organization assets or individuals.
 High The loss of confidentiality, integrity and availability could be expected to have a severe or catastrophic adverse affect on organizational operations, organization assets or individuals.

NIST 800-63 Electronic Authentication Guideline provides technical requirements for each of the authentication levels of assurance defined in OMB 04-04. Each assurance level has defined controls for identity proofing, token (secret) requirements and authentication/assertion protection mechanisms as summarized in the table below.

The University of Wisconsin-Madison plans to adopt these technical guidelines as the basis for establishing level of confidence in the user identities electronically presented to our systems as well as technical requirements needed to participate in the InCommon federation.

Summary of NIST 800-63


Level Description Technical Requirements Example credentials meeting requirements
Identity Proofing Requirements Token (Secret) Requirements Authentication Protection Mechanisms Requirements
1 Little or no confidence exists in the asserted identity; usually self-asserted; essentially a persistent identifier Requires no identity proofing Allows any type of token including a simple PIN Little effort to protect session from off line attacks or eavesdropper is required. Self registration web sites;

current InfoLab authentication; 3270 transactions; Guest NetID; Library EZProxy access based on campus ID
2 Confidence exists that the asserted identity is accurate; used frequently for self service applications Requires some identity proofing Allows single-factor authentication. Passwords are the norm at this level. On-line guessing, replay and eavesdropping attacks are prevented using FIPS 140-2 approved cryptographic techniques. UW NetID; InfoAccess (3 character logon with credentials stored in Oracle db); Library EZProxy access based on UW NetID.
3 High confidence in the asserted identity's accuracy; used to access restricted data Requires stringent identity proofing Multi-factor authentication, typically a password or biometric factor used in combination with a 1) software token, 2) hardware token, or 3) one-time password device token On-line guessing, replay, eavesdropper, impersonation and man-in-the-middle attack are prevented. Cryptography must be validated at FIPS 140-2 Level 1 overall with Level 2 validation for physical security. OTP devices or X.509 user certificates
4 Very high confidence in the asserted identity's accuracy; used to access highly restricted data. Requires in-person registration Multi-factor authentication with a hardware crypto token. On-line guessing, replay, eavesdropper, impersonation, man-in-the-middle, and session hijacking attacks are prevented. Cryptography in the hardware token must be validated at FIPS 140-2 level 2 overall, with level 3 validation for physical security X.509 user certificates on a hardware token that is FIPS 140-2 compliant.

Application of NIST 800-63 to UW-Madison

UW-Madison will apply the NIST standard based on data classification. The ability to access restricted data other than ones own will require at least Level 3 authentication. Most access of data classified as internal (the default classification for unclassified data) will require Level 2 authentication. Access to public information generally requires no authentication. Improper access to restricted data increases the risk of activating the 2005 Wisconsin Act 138 data breach disclosure Notice of unauthorized acquisition of personal information. Therefore, access to this data warrants the added assurance of Level 3.

In determining the appropriate level of assurance, applications should seek to use the minimum assurance level that meets its risk requirements. There may be other reasons besides data classification to require lower or higher assurance levels, but our initial implementation of assurance levels will use data classification to determine authentication assurance needs. As the infrastructure matures to provide different authentication levels, other criteria (based on environmental changes such as threat profiles, privacy regulations, etc) for categorizing certain other types of authentication will be warranted.

We provide the following guidelines for determining appropriate levels of assurance for specific types of access to UW Madison systems.

Level Data Classification Type of Access Examples
0 Public Level 0 is for unauthenticated access. There is no assurance because there is no authentication. Public web sites e.g. www.wisc.edu;
1 Public Level 1 is appropriate for users who are loosely affiliated with the University Guests; Users of MyInfo; Group accounts
2 Internal Level 2 is appropriate for users accessing information they created, are the subject of or is intended for them; or because of their work responsibilities have access to information that is not their own. This includes users of the MyUW portal and other portal-like self-service functions. This includes activities such as: reading/writing email, checking calendar, viewing pay statements on-line, preparing class materials, buying from the techstore, enrolling, etc.

This includes users who have:
  • Access to other people’s information (e.g. registrar staff that can accept tuition payments, but does not have access to data classified as "restricted"; or an instructor that can enter grades for their students).
  • Access to programs/files/data on an internal system (e.g. developers and DBA’s)
  • Access to an internal system as root or admin (e.g. sysAdmins)
  • Access to an internal system that is NOT subject to requlatory requirements (e.g. HIPAA, PCI etc)
3 Restricted Level 3 is appropriate for users who because of their work responsibilities have access to restricted information that is not their own. This authority presents a higher risk and thus a higher level of assurance. This includes users who have:
  • Access to more than one’s own personal or restricted information (e.g. an HR person who can view/update records for all personnel in their workgroup (aka functional users).
  • Access to programs/files/data on a restricted system (e.g. developers and DBA's)
  • Access to a restricted system as root or admin (e.g. sysAdmins)
  • Access to a restricted system that is subject to regulatory requirements (e.g. HIPAA, PCI etc)
4 Highly Restricted Level 4 is similar to Level 3 with more technical requirements. At this time, we have not identified an application (based on data classification) that requires this level of assurance.