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