standard – Bredemarket

Authenticator Assurance Levels (AALs) and Digital Identity

(Part of the biometric product marketing expert series)

Back in December 2020, I dove into identity assurance levels (IALs) and digital identity, subsequently specifying the difference between identity assurance levels 2 and 3. These IALs are defined in section 4 of NIST Special Publication 800-63A, Digital Identity Guidelines, Enrollment and Identity Proofing Requirements.

It’s past time for me to move ahead to authenticator assurance levels (AALs).

Where are authenticator assurance levels defined?

Authenticator assurance levels are defined in section 4 of NIST Special Publication 800-63B, Digital Identity Guidelines, Authentication and Lifecycle Management. As with IALs, the AALs progress to higher levels of assurance.

AAL1 (some confidence). AAL1, in the words of NIST, “provides some assurance.” Single-factor authentication is OK, but multi-factor authentication can be used also. All sorts of authentication methods, including knowledge-based authentication, satisfy the requirements of AAL1. In short, AAL1 isn’t exactly a “nothingburger” as I characterized IAL1, but AAL1 doesn’t provide a ton of assurance.
AAL2 (high confidence). AAL2 increases the assurance by requiring “two distinct authentication factors,” not just one. There are specific requirements regarding the authentication factors you can use. And the security must conform to the “moderate” security level, such as the moderate security level in FedRAMP. So AAL2 is satisfactory for a lot of organizations…but not all of them.
AAL3 (very high confidence). AAL3 is the highest authenticator assurance level. It “is based on proof of possession of a key through a cryptographic protocol.” Of course, two distinct authentication factors are required, including “a hardware-based authenticator and an authenticator that provides verifier impersonation resistance — the same device MAY fulfill both these requirements.”

This is of course a very high overview, and there are a lot of…um…minutiae that go into each of these definitions. If you’re interested in that further detail, please read section 4 of NIST Special Publication 800-63B for yourself.

Which authenticator assurance level should you use?

NIST has provided a handy dandy AAL decision flowchart in section 6.2 of NIST Special Publication 800-63-3, similar to the IAL decision flowchart in section 6.1 that I reproduced earlier. If you go through the flowchart, you can decide whether you need AAL1, AAL2, or the very high AAL3.

The AAL CYOA from https://pages.nist.gov/800-63-3/sp800-63-3.html#63Sec6-Figure2.

One of the key questions is the question flagged as 2, “Are you making personal data accessible?” The answer to this question in the flowchart moves you between AAL2 (if personal data is made accessible) and AAL1 (if it isn’t).

So what?

Do the different authenticator assurance levels provide any true benefits, or are they just items in a government agency’s technical check-off list?

Perhaps the better question to ask is this: what happens if the WRONG person obtains access to the data?

Could the fraudster cause financial loss to a government agency?
Threaten personal safety?
Commit civil or criminal violations?
Or, most frightening to agency heads who could be fired at any time, could the fraudster damage an agency’s reputation?

If some or all of these are true, then a high authenticator assurance level is VERY beneficial.

A Few Thoughts on FedRAMP

The 438 U.S. federal agencies (as of today) probably have over 439 different security requirements. When you add state and local agencies to the list, security compliance becomes a mind-numbing exercise.

For example, the U.S. Federal Bureau of Investigation has its Criminal Justice Information Systems Security Policy (version 5.9 is here). This not only applies to the FBI, but to any government agency or private organization that interfaces to the relevant FBI systems.
Similarly, the U.S. Department of Health and Human Services has its Health Insurance Portability and Accountability Act (HIPAA) Security Rule. Again, this also applies to private organizations.

But I don’t care about those. (Actually I do, but for the next few minutes I don’t.) Instead, let’s talk FedRAMP.

Why do we have FedRAMP?

The two standards that I mentioned above apply to particular government agencies. Sometimes, however, the federal government attempts to create a standard that applies to ALL federal agencies (and other relevant bodies). You can say that Login.gov is an example of this, although a certain company (I won’t name the company, but it likes to ID me) repeatedly emphasizes that Login.gov is not IAL2 compliant.

But forget about that. Let’s concentrate on FedRAMP.

From https://www.informationweek.com/machine-learning-ai/how-fedramp-can-accelerate-cloud-adoption.

Why do we have FedRAMP?

The Federal Risk and Authorization Management Program (FedRAMP^®) was established in 2011 to provide a cost-effective, risk-based approach for the adoption and use of cloud services by the federal government. FedRAMP empowers agencies to use modern cloud technologies, with an emphasis on security and protection of federal information. In December 2022, the FedRAMP Authorization Act was signed as part of the FY23 National Defense Authorization Act (NDAA). The Act codifies the FedRAMP program as the authoritative standardized approach to security assessment and authorization for cloud computing products and services that process unclassified federal information.
From https://www.fedramp.gov/program-basics/.

Note the critical word “unclassified.” So FedRAMP doesn’t cover EVERYTHING. But it does cover enough to allow federal agencies to move away from huge on-premise server rooms and enjoy the same SaaS advantages that private entities enjoy.

From https://marketplace.fedramp.gov/products.

Today, government agencies can now consult a FedRAMP Marketplace that lists FedRAMP offerings the agencies can use for their cloud implementations.

A FedRAMP authorized product example

When I helped MorphoTrak propose its first cloud-based automated biometric identification solutions, our first customers were state and local agencies. To propose those first solutions, MorphoTrak partnered with Microsoft and used its Azure Government cloud. While those first implementations were not federal and did not require FedRAMP authorization, MorphoTrak’s successor IDEMIA clearly has an interest in providing federal non-classified cloud solutions.

When IDEMIA proposes federal solutions that require cloud storage, it can choose to use Microsoft Azure Government, which is now FedRAMP authorized.

From https://marketplace.fedramp.gov/products/F1603087869.

It turns out that a number of other FedRAMP-authorized products are partially dependent upon Microsoft Azure Government’s FedRAMP authorization, so continued maintenance of this authorization is essential to Microsoft, a number of other vendors, and all the agencies that require secure cloud solutions.

They can only hope that the GSA Inspector General doesn’t find fault with THEM.

Is FedRAMP compliance worth it?

But assuming that doesn’t happen, is it worthwhile for vendors to pursue FedRAMP compliance?

If you are a company with a cloud service, there are likely quite a few questions you are asking yourself about your pursuits in the Federal market. When will the upward trajectory of cloud adoption begin? What agency will be the next to migrate to the cloud? What technologies will be migrated? As you move forward with your business development strategy you will also question whether FedRAMP compliance is something you should pursue?

The answer to the last question is simple: Yes. If you want the Federal Government to purchase your cloud service offering you will, sooner or later, have to successfully navigate the FedRAMP process.
From https://www.mindpointgroup.com/blog/fedramp-compliance-is-it-worth-it.

And a lot of companies are doing just that. But with less than 400 FedRAMP authorized services, there’s obviously room for growth.

When the health passports can’t talk to each other

I’m going to open this post with something that I wrote nearly eight years ago.

I’m sure that many people imagine that standards are developed by a group of reasonable people, sitting in a room, who are pursuing things for the good of the world.
You can stop laughing now.

I wrote this in the context of the then-emerging compression format WebP (we’ll return to WebP itself later). The point that I was making was that something becomes a “standard” by brute force. If a lot of people like something, it’s a standard.

The issue with standards is that they can take years to develop, so standards are adopted after the fact.

Now let’s look at “health passports.” As you may have guessed, these “passports” can be used to enter a country, or a state, or an office building, and are specifically devoted to certifying the health of the passport bearer. If the person meets the health criteria, they can enter the country/state/building. If not, they are prohibited from entry.

An Ottoman passport (passavant) issued to Russian subject dated July 24, 1900. By FurkanYalcin3 – Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=27699398

In a sense, the concept of a health passport is nothing new. Before entering a country, you are often required to satisfy various health conditions, such as being free of tuberculosis.

The current impetus for health passports, of course, is COVID. When COVID spread across the world a year ago, and governments began shutting down borders between countries, a lot of people at a lot of government agencies and a lot of companies began asking two basic questions:

When reliable COVID tests are developed, how will we know whether someone has successfully passed a COVID test?
When reliable COVID vaccines are developed, how will we know whether someone has successfully been vaccinated against COVID?

These questions, especially the second one, were mostly theoretical a year ago, but the government agencies and the companies needed answers to them as soon as possible. And the governments and the companies weren’t going to wait for the entire world to agree on a plan; they wanted to move ahead THAT DAY.

It’s a year later, and COVID tests are readily available, and COVID vaccines have been developed and approved in various countries. And we’ve made a lot of progress.

Or have we?

As Jim Nash notes in a Biometric Update article, there are several different solutions to the “health passport” issue. Nash lists two of them:

The state of Hawaii is working with Clear, United Airlines, and Delta Airlines on a solution. Initially this only documents testing, but it could be expanded to vaccine documentation.
The Malaysia Aviation Group is working with “local authorities” on its own solution.

And that’s just the start of options for health passports. In addition to Clear’s Health Pass, there are a myriad of other options, including AOKpass, CommonPass, IATA Travel Pass, IBM Digital Health Pass, the Mvine-iProov solution, Scan2Fly from AirAsia, VaccineGuard from Guardtime, VeriFLY from Daon, the Vaccination Credential Initiative, and probably some others that I missed.

Can you say “early in the product lifecycle”?

Now the wealth of health passport solutions isn’t much of a problem for most consumers, since we’ll probably need one or two health passports at most as this market matures. Maybe a US person might need one or two health passports for domestic travel, and maybe one to get into the office. In extreme conditions, maybe they’ll be required to enter grocery stores, but this is doubtful considering the resistance of American personalities to governments telling us what to do.

But the wealth of health passports IS a problem if you’re a business. Imagine being at an airport gate and asking a traveler for a Clear Health Pass, and getting an angry reply from the traveler that he already has a VeriFLY pass and that the airline is infringing upon the traveler’s First and Second Amendment rights by demanding some other pass.

Eventually there will be enough of a brouhaha over the multitude of incompatible passes. At that time, several efforts will be made to establish THE standard for health passports, or at least for health passport interoperability.

Yes, “several efforts” will be made. Because each vendor will unsurprisingly advance its own passport as the best one for the standard, or perhaps will form alliances with selected other vendors.

And it will get messy.

Take WebP, which Google was trying to push as a standard eight years ago, with some people accepting WebP, others not supporting it, and others opposing it and then supporting it. Well, while that fight continues…

…Google is experimenting with WebP2.

Yes, progress is good, but there’s a cost to planned obsolescence.