In June 2017, the National Institute of Standards and Technology (NIST) released its updated Digital Identity Guidelines in Special Publication 800-63-3. The draft of this publication gained a lot of press in 2016 for highlighting the cybersecurity risks when using SMS for multi-factor authentication. While the final version has not had as much focus, the truth is the new guidelines will cause the government, the military and many commercial organizations to re-architect their Identity and Access Management (IdAM) infrastructures and rethink their authentication token distribution methods.
The reason is that NIST 800-63-3 goes farther than its predecessor by covering all aspects of IdAM from initial risk assessment to deployment of federated identity solutions. Whereas NIST 800-63-2 focused almost exclusively on credential type (i.e., soft or hard token), NIST 800-63-3 includes Assurance Levels for Identity Proofing (how the user applied for the token), Authenticator Type (the form of the token) and Federated Architecture (how credentials are passed internally).
Federated Assurance Level (FAL) is by far the most important change since it will have the largest effect on internal networks. The reason NIST is so focused on FAL is that they have seen an increase in cybersecurity attacks that take advantage of how authentication tokens are passed from an Identity Provider to a Service Provider. These attacks include Man-in-the-Middle, Compromised Tokens, and Denial of Service and are not specific to any one standard (e.g., SAML, OAuth, Kerberos, etc.).
Click to Subscribe
To combat these cybersecurity attacks, the NIST guidelines now require that a user present a proof of key ownership in addition to an authentication token. This was instituted for the most secure systems, those that are deemed FAL3, because relying solely on authentication tokens exposes the network. The requirement to present a proof of key ownership is known as Holder of Key.
Holder of Key is not a new concept, however, the only standards based method to implement it is with PKI certificates and mutual TLS authentication. This is an issue for organizations that either do not implement PKI or implement a Break and Inspect tool. Break and Inspect refers to breaking a TLS connection between two parties in order to examine the secure contents of a message. Break and Inspect is necessary because hackers typically hide their malicious activity within TLS traffic. Once a TLS connection is broken, it is impossible to reestablish TLS with mutual authentication between the user and an application without also storing each user’s private key. Storing every user’s private key is a HUGE cybersecurity risk.
Congress passed the Federal Information Security Modernization Act (FISMA) which created a requirement for federal agencies to manage information security based on publications that are developed by NIST. In 2014 the DoD CIO, effectively joining federal agencies, issued Instruction 8510.01 replacing its own risk management process with NIST’s Risk Management Framework. This made NIST’s Special Publication 800-63-3 a requirement of the Federal Government, the military, and most government contractors. So, if you have not heard of NIST 800-63-3 and Holder of Key yet…you will soon.
If you currently implement Federated Identity or Single Sign-On (SSO) and are interested in getting more information on NIST 800-63-3 and Holder of Key, you should download TELEGRID’s white paper on Authentication Token Cybersecurity and NIST 800-63-3 Holder of Key. The white paper provides information on specific authentication token cybersecurity attacks and how to seamlessly implement PKI even if you employ a Break and Inspect tool. TELEGRID’s website also has helpful video tutorials on NIST 800-63-3 to help organizations meet the new Digital Identity Guidelines.
Eric Sharret is Vice President of Business Development at TELEGRID. TELEGRID has unique expertise in secure embedded systems, secure authentication, PKI, and Multi-Factor Authentication (MFA).
Disclaimer: The opinions expressed here do not represent those of TELEGRID Technologies, Inc. TELEGRID Technologies, Inc. will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use. All information is provided on an as-is basis.