Enhancing Identity and Access Management

Properly managing access to IT systems, processes, and information is central to managing cybersecurity risks and a priority for NIST's cybersecurity program. NIST regularly engages and collaborates with international standards bodies and consortia on enhancing identity and access management. Major accomplishments include creating the predominant access control model, role-based access control (RBAC) and establishing the standards for Personal Identity Verification (PIV) identification and authentication for federal employees and contractors.

User Authentication: The Early Days

Before most people had ever used a computer or heard of terms like "password," the National Bureau of Standards (NBS) was already developing guidelines for using automation to identify the people using computers—in other words, user authentication.

At that time, regular citizens weren't the ones using government computers—government employees were, and there was an increasing need to identify who those employees were because, as the Privacy Act of 1974 stated, "the privacy of an individual is directly affected by the collection, maintenance, use and dissemination of personal information by Federal agencies."

NBS had to address user authentication in an era when the number of computing devices connected to the internet was counted in dozens, not billions. They had to acknowledge the transition from using only physical means to restrict access to computers to also needing digital means to restrict access. Despite differences in the terminology of those early days, many of the concepts applied then are still used 50 years later, such as  three factors of authentication, the tradeoffs in password-based authentication, and the criteria for evaluating authentication methods.

By the mid-1980s, passwords were widely used for authenticating computer users, and NIST advanced concepts that are still familiar today, such as password strength and lifetime.  Other concepts worked on at the time have disappeared, such as having separate passwords for "personal identity authentication" (i.e., who are you?) and "data access authorization" (i.e., what are you allowed to do?).

Smart Cards for Authentication

NIST started its work on smart cards in the late 1980s. Researchers at the agency wanted to expand work being done at the Department of the Treasury, which initially focused on putting standard cryptographic algorithms on smart cards for authentication purposes. At that time, each smart card vendor used its own proprietary algorithms, and vendors didn't think it would be possible to put standard algorithms on their smart cards.

NIST's first work in this area was to successfully put the Data Encryption Standard (DES) algorithm on a cryptographic token to create what was called the Token Based Access Control System (TBACS). Next, on two projects NIST put standard cryptographic algorithms—DES in one case and RSA in another—onto smart cards. Shortly after that, the agency collaborated with several vendors to develop the Advanced Smartcard Access Control System (ASACS), with smart cards that not only had DES built in, but also offered public key cryptographic functions.

In guidelines published in 1994, NIST provided recommendations for acquiring and using alternatives to passwords, such as authentication tokens (including smart cards) and biometric devices.  The work was successful from a technical standpoint, but its impact was limited, because passwords were deemed good enough for most situations, especially given the costs associated with issuing smart cards, card readers, and other components.

In the late 1990s, the U.S. General Services Administration (GSA) formed the Government Smart Card Interagency Advisory Board (GSC-IAB) to serve as a steering committee for the Government Smart Card program. NIST led the GSC-IAB’s Architecture Working Group (AWG), made up of representatives from federal agencies and industry partners, to work on defining smart card interoperability technical specifications and standards.  It was an incredibly complicated subject, with many standards, layers of interfaces, and smart card solution components.

The AWG developed the GSC Interoperability Specification (GSC-IS), establishing the framework for smart cards to work in an open environment. It defined an architectural model for smart card service provider modules that allowed smart card application developers to obtain various services (for example, encryption, authentication, and digital signatures) from GSC-compliant smart cards through a common services interface.

Finally, there was something developers could agree on and use to achieve some level of interoperability. One critical issue was that the interoperability specifications omitted the administrative functions that allow someone to set up a card and initialize it because that was seen by vendors as a key proprietary feature—the vendors all had their own smart card issuance systems. While full interoperability across all features would have been ideal, NIST staff felt operational interoperability was a good first step.

NIST was also charged with developing a GSC-IS conformance test program. NIST reused an automated test generation framework and its associated toolkit that were originally used to develop executable code for testing security functions of a database management system (DBMS).

The U.S. Government Accountability Office (GAO) issued a report in January 2003 that included recommendations for NIST’s roles in the GSC program. NIST then initiated an effort to identify the state of operational and developmental storage and processor card-based technologies, and the nature of user requirements for and constraints associated with integrating these technologies onto a single platform.

Personal Identity Verification (PIV) Credentials

A presidential directive issued in August 2004 (Homeland Security Presidential Directive 12 [HSPD-12]) established requirements for a common standard for identification of federal employees and contractors requiring physical access to federally controlled facilities and logical access to federally controlled information systems. At that time, there were wide variations in the quality and security of these forms of identification used to access facilities with the potential for terrorist attacks. The presidential directive would limit these variations through a new, mandatory ID called the Personal Identity Verification (PIV) card.

NIST immediately began developing the standard in two parts: First to address the common identification, security, and privacy requirements for issuing organizations, and second to provide detailed technical specifications of components and processes required for government-wide interoperability use of PIV cards in authentication, access control, and PIV card management.

There was an unusually short time frame to develop the standard, and NIST staff wanted to engage the public as soon as possible. A strawman for the PIV card was quickly developed and a briefing created to indicate NIST's plans. It was clear that there were many concerns. The Department of Defense (DoD) wanted their existing Common Access Cards (CACs) used, and other agencies with their own cards wanted to keep using them too. One agency was opposed to having a contactless interface because of the potential for invasion of privacy. Smart card vendors pushed back because NIST planned to specify standard-based interfaces rather than proprietary smart card interfaces. The public also had serious concerns about privacy. NIST designed the physical layout of the PIV card so it would look like a DoD CAC.

NIST managed to complete the work on the standard about one week before the final deadline.  However, getting the final approval took maneuvering worthy of a Beltway thriller. The night before the deadline, it began snowing. NIST staff drove from Gaithersburg, Maryland, to the Office of the Undersecretary at the Commerce Department in D.C. with the package in hand and waited while he signed it. The Secretary was leaving the next morning on a trip, so the Undersecretary took the package to the airport and the Secretary signed it on the plane.

This was only the beginning of the work. The next tasks were to complete the publications supporting the standard, produce and issue the first PIV cards, establish a program for PIV product validation, and provide PIV reference implementations. The initial supporting publications for the standard were released between April 2005 and February 2006.

Help with Implementing the PIV Standard

To aid with PIV implementation, NIST developed a PIV Card simulator that behaved and responded exactly like a PIV card. NIST also developed PIV Middleware that implemented the application programming interface (API). In response to the request for sample PIV data, NIST developed a software tool that generated mandatory and optional PIV data elements consistent with the standard, and a data loader utility that could be used to load the test data onto PIV cards.

NIST established the NIST Personal Identity Verification Program (NPIVP) to validate PIV system component as the standard required. The program facilitated testing of PIV products through approved test laboratories. NIST and the laboratories established conformance criteria, and NIST developed and published conformance test suites in mid-2006. NIST also developed tools to automate the testing and to enable consistent testing among the laboratories. Through an iterative test and validation process with the laboratories, NIST provided additional clarifications and details on the implementation of the PIV standard.

Improvements to the PIV Standard

Even while some of the initial PIV standards were under development, improvements were already underway.  Interoperability and clarification—reducing the possibility of different interpretations—were two reasons for many of the improvements. Another reason was cryptographic strength. As the full set of initial supporting publications was being completed, the identification of gaps led to development of additional specifications. Similarly, public comments  led to enhancements and spurred research on new authentication approaches for smart cards and additional cryptographic protocols that could be used to implement them.

As an example, NIST conducted a feasibility study of Secure Biometric Match-On-Card (SBMOC) to explore the technical feasibility of performing biometric fingerprint matching on a smart card. This included understanding the effects of security on the performance of data transfers over the contactless interface. SBMOC was subsequently included in the standard.

PIV Test Suite

Federal agencies and PIV product vendors needed to perform some testing using revoked PIV cards, but most people didn't have access to such cards for testing purposes. To respond to this need, NIST created an initial test suite of 16 cards, nine of which were valid and seven of which contained invalid data. A few sets of the cards, which depicted figures such as George Washington and Abraham Lincoln, were first made available to beta test volunteers. Beta testing was successful, and production began in mid-2012. The test card sets were publicly available for sale as NIST Special Database 33. NIST was able to keep the price of a set low enough so government employees could purchase them on government credit cards. The first printing sold out in less than a year, and additional printings were done to meet the demand.

Subsequent PIV Standard Work

The first few years after the release of the PIV standard were a time of learning, refinement, and growth for both PIV product suppliers and federal agencies. During this time, over 300 standards-conformant products were developed, validated, and brought to market, and federal agencies developed and refined their PIV issuance processes. By early 2008, production PIV issuance systems were operating and engaged in high-volume enrollment of federal employees and contractors.

With the majority of federal employees being enrolled, the emphasis shifted from PIV card issuance to deployment and use of the PIV Card in logical access applications to federal IT systems/resources and physical access application to access federal facility.  To spur progress, NIST created downloadable software packages to be used as demonstrations of PIV and tutorials for product developers. Demonstrations included using PIV cards for email signing and encryption, website authentication, and operating system logon.

In 2010, NIST began the process of revising the standard. Over 1000 comments were submitted on the first draft revision and over 500 comments on the second draft. The revised standard was finalized in August 2013, and it spurred revisions to supporting publications. There was a great deal of subsequent PIV standards work. One of the most notable additions to the Standard was derived PIV credentials, which are PIV credentials that reside on mobile devices rather than on the PIV Card. Federal employees were increasingly using mobile devices for their daily work and PIV Cards could not easily be used with these devices because of a lack of smart card readers. Derived PIV credentials provides the way forward to PIV-enabled mobile devices. The technical detail for implementing and deploying derived PIV credentials on mobile devices were specified in SP 800-157.

In 2019, NIST again began the process of revising the standard as part of a regular review cycle. Over 400 comments were submitted on the draft revision. The revised standard was finalized in January 2022. The third revision expanded the set of PIV credentials further&emdash;beyond those on PIV Cards and beyond those for mobile devices. More flexibility in the choice of credentials and devices was needed to accommodate the Federal Government’s use of cloud services and applications, which often is neither smart card nor public key infrastructure (PKI) credential-enabled. To achieve interagency interoperability with the expanded set of PIV credentials, the Standard specifies identity federation. The technical details for implementing and deploying the expanded set of PIV credentials will be specified in the first revision of SP 800-157. The Standard also allows for remote identity proofing, which was a welcome addition to support increased teleworking in the federal community.

Electronic Authentication

COMING SOON

Access Control Models

One of the basic tenets of IT security is controlling access to vital resources—in other words, answering the question, "who is allowed to do what?" A NIST research team created, and introduced in 1992, a new approach to controlling user access called Role-Based Access Control (RBAC). What was most striking about RBAC was its rapid evolution from a theoretical model to commercial implementation and deployment. An independently conducted NIST-sponsored economic impact study estimated that $1.1 billion in net economic benefits from RBAC technology could be attributed to NIST.

Role Based Access Control (RBAC)

NIST initiated research that led to development of the world's most widely used access control model, improving security and dramatically reducing the cost of protecting information.

In the 1980s, the predominant specification for computer security was the DoD Trusted Computer Security Evaluation Criteria (TCSEC). By the early 1990s, virtually every major computer vendor had one or more products evaluated against the TCSEC, delivering Mandatory and Discretionary Access Control (MAC and DAC) features. The prevailing argument was that DAC requirements would meet the security needs of the non-DoD marketplace. Although regulations for handling classified information provided the rationale for the military access control systems, no analogous body of requirements existed to drive security in the commercial sector. Consequently, in 1992 NIST surveyed the security needs of civilian government agencies and commercial enterprises. The responses indicated that these non-military institutions required a means to associate permissions with users through roles and that capability was not provided by existing systems. In particular, end users did not “own” and control information as assumed by DAC, but rather users were given access in a non-discretionary fashion based on their job functions or roles in the organization.

A solution was proposed in a 1992 NIST paper, "Role Based Access Control" (Ferraiolo and Kuhn), specifying a rigorous structure of roles, constraints, and hierarchies, plus permission relations and authorization mappings. Although some notion of roles has been recognized since the 1970s, that paper has been widely cited as the origin of RBAC.

Shortly after its publication, Sandhu et al. (1994) addressed the NIST RBAC Model and its future significance:

…an important innovation, which makes RBAC a service to be used by applications… Instead of scattering security in application code, RBAC will consolidate security in a unified service which can be better managed while providing the flexibility and customization required by individual applications.

Sandhu et al.'s (1996) RBAC96 model framework extended and formalized a modular RBAC structure, which has become one of the most cited papers in computer science.

Early confirmation of RBAC’s value came from Sybase. In a formal letter to NIST's Information Technology Laboratory director, Sybase stated that “by basing our RBAC feature on the work of [Ferraiolo and Kuhn], we were able to reduce significantly development time.” Sybase went on to state, “during a recent Sybase Users Group meeting, I briefed this RBAC feature and there was spontaneous applause. I congratulate you and thank you for conducting research that has such immediate and significant relevance to the computer industry at large.”

To show viability and scale, NIST led development of two RBAC prototypes – Role Control Center (RCC) and RBAC/Web. The impact can be seen in the extensive technology transfer of RBAC. For instance, according to Microsoft, “The existence of a widely visible prototype advanced the concrete understanding of corporate IT architects so significantly that we were able to get unusually good early feedback validating and influencing our design choices. Getting educated feedback early undoubtedly saved industry a significant amount of money” (NIST Journal of Research 107(4), p. 123).

A unified RBAC standard, combining features of NIST publications and RBAC96 models, was proposed in 2000. Based on workshop discussions and proposals, a revised specification was published in 2001 and submitted to ANSI for standardization. Over the next three years, NIST led the industry working group that developed the international standard for RBAC (INCITS 359-2004) that was later revised (INCITS 359-2012).

With enhanced security and reduced complexity for controlling access, RBAC has become the most widely used access control model to this day. An independent economic analysis of RBAC found that, “RBAC saved U.S. organizations $1.8 billion in 2009 from more efficient access control policy maintenance.” Internationally, these savings are compounded across thousands of organizations. The economic benefit attributed to NIST’s RBAC research alone was estimated at $1.1 billion (Research Triangle Institute). Note that these figures are administrative cost reductions alone. Savings from prevention of data breaches are likely to be much larger but were not included in the study as they reflect attacks that were prevented, and thus impractical to estimate.

Technical advances provided by RBAC also led to extensive research by universities and industry worldwide, including theoretical analysis of the relationship between this model and others, role structures, and separation of duty, contributing to foundational knowledge of information security. As of 2022, Google Scholar lists more than 41,000 conference and journal papers addressing RBAC, and it has been the subject of more than 100 doctoral dissertations, as well as hundreds of patents held by the world’s largest software and information technology companies.

Policy Machine and Next Generation Access Control

Although RBAC’s widespread use in the early 2000s brought significant advancement, issues remained. At the time other access control policies and models were developed to suit a variety of policy and administrative goals. While each had a particular area of strength, the notational differences were substantial. As a result, it was difficult to combine them, both in making formal statements about systems based on differing models and in using more than one access control policy model within a given system. Thus, there was a need for a unifying formalism that was general enough to encompass a range of these policies and models. NIST proposed an open security architecture called the Policy Machine (PM) to meet this need.

At the request and support of the Department of Homeland Security (DHS), in 2003 NIST initiated the PM project in pursuit of a standardized access control mechanism that is general enough to configure and enforce any attribute-based access control policy to include RBAC. It was not NIST’s intent to devise a completely new access control mechanism, but instead to redefine, implement and transfer to industry an access control mechanism that includes abstractions, properties, and functions common to most, if not all, access control mechanisms.

During this effort, the PM evolved from a concept described in several publications to a formal specification (NISTIR 7987 Rev. 1), and then became a reference implementation, with product demonstrations and open-source distributions. The Policy Machine has further served as a research component, in alignment with, and in support of, an American National Standards Institute/International Committee for Information Technology Standards (INCITS) standardization effort for Next Generation Access Control (NGAC) (INCITS 565-2020). In its protection of objects under one or more policy instances, NGAC and the PM categorize users and resources and their attributes into policy classes, and it transparently enforces those policies through a series of fixed functions invoked in response to user or subject (process) access requests. Besides expressing and enforcing a wide variety of access control policy combinations, NGAC facilities can be used to effectuate security-critical portions of the program logic of arbitrary data services and enforce mission-tailored access control policies over data services, making its deployment amenable to a large variety of operational environments.

With the availability of the PM specification and multiple open-source distributions (including two outside of NIST), and the emergence of NGAC as a national standard, a growing number of commercial and academic products have come into existence or are under development. Striking is the diversity of objectives and environments of use. Deployments have included:

• protection of PII sensitive automobile sensor information;
• management and protection of most the world’s clinical trial data;
• dynamic protection involving IoT and Edge computing for factory automation;
• blockchain-enabled control to protect security and privacy of Longitudinal Personal Health Records; and
• empowering a complete authorization framework for distributed and multi-cloud architectures.

Trusted Identities

The National Strategy for Trusted Identities in Cyberspace (NSTIC), signed by President Obama in April 2011, was a 10-year initiative to work collaboratively with the private sector, advocacy groups, public sector agencies, and other organizations to improve online transactions through the creation of an identity ecosystem. The NSTIC vision was for individuals and organizations to utilize secure, efficient, easy-to-use, and interoperable identity solutions to access online services in a manner that promotes confidence, privacy, choice, and innovation. It defines guiding principles to which all identity solutions should adhere: privacy-enhancing and voluntary, secure and resilient, interoperable, and cost-effective and easy-to-use.

NIST was chosen to be part of NSTIC because of its expertise in the technologies needed for identity solutions and solution interoperability. From NSTIC's inception, NIST served as the  National Program Office (NPO). In 2016, the NSTIC NPO was renamed the Trusted Identities Group (TIG) to reflect the expectation that NIST would continue supporting the ongoing evolution and sustainment of the identity ecosystem established by NSTIC past the 10-year NSTIC completion target date.

The identity ecosystem being created under NIST's leadership is an online environment where individuals and organizations will be able to trust each other because they follow agreed-upon standards and policies to obtain and authenticate their digital identities. Implementation of the NSTIC has three major focus areas:

• Catalyzing a marketplace of identity solutions through NIST-funded pilot projects. The first sets of pilot projects were an open competition; subsequent years focused on filling critical gaps in the identity ecosystem. For example, the 2016 focus was targeting impediments to the use of secure, privacy-enhancing, federated identities for state and local government services. NIST also issues awards for other organizations to assess the pilots.
• Supporting the development of an Identity Ecosystem Framework (IDEF) via a private sector-led organization, the Identity Ecosystem Steering Group (IDESG). NIST participates in the IDESG, along with hundreds of organizational and individual members from many sectors. The IDEF is working on delivering a baseline set of standards and policies so individuals and organizations can start using a new generation of more secure, convenient, privacy-enhancing credentials that are interoperable across the internet.
• Establishing the Federal Government as an early adopter of NSTIC-aligned identity solutions. The original site demonstrating this, connect.gov, was a hub-based federation solution officially launched in a pilot phase in late 2014. It aimed to ease the process by which agencies can accept federated credentials from both government and commercial identity providers. Eventually connect.gov was replaced with login.gov, which allows people to create a single account and use it across numerous government websites.