The Provider Authentication Policy Extension defines a series of previously agreed-upon authentication policies that the OpenID provider applies when authenticating an end user through a relaying party (i.e., the site or service that is requesting the user authentication through something like a “Sign in with Yahoo” request). The PAPE mechanism also enables the OpenID provider to inform the relaying party of which authentication policies were used during the authentication process, which in turn enables the relaying party to determine how secure the authentication was. We will look at the methods for setting and obtaining this information in our upcoming OpenID example.
The PAPE policies that we will explore include:
Phishing-resistant authentication
Multifactor authentication
Physical multifactor authentication
Note
These three authentication policies are being discussed only as starting points to cover the most common use cases—additional policies may be applied as needed.
In addition, PAPE provides a mechanism by which the relaying party may request that the OpenID provider inform it of the levels of authentication assurance (known as NIST assurance levels) that were used.
The three most common PAPE policies include numerous technologies that can be employed during the authentication process. Table 11-15 breaks these methods down by each policy in which they apply.
Table 11-15. Authentication methods available within each PAPE policy
Method | Phishing-resistant | Multifactor | Physical multifactor |
|---|---|---|---|
Password via HTTPS | |||
Visual secret via HTTPS | |||
PIN and digital certificate via HTTPS | ✓ | ✓ | |
PIN and “soft” OTP token via HTTPS | ✓ | ||
PIN and “hard” OTP token via HTTPS | ✓ | ✓ | |
PIN and “hard” crypto token via HTTPS | ✓ | ✓ | ✓ |
Information card via HTTPS | ✓ | ✓ |
With all of that information in hand, now let’s explore what the authentication policies and the NIST assurance levels actually mean in practice.
The phishing-resistant authentication works to prevent the relaying party from being able to capture enough information about the user to be able to authenticate to the user-selected OpenID provider as if it were the user himself. In basic terms, this authentication process prevents a site that you may not trust from pretending to be you when you are signing in using your OpenID account.
Multifactor authentication means that the user will be authenticating the OpenID process using multiple authentication factors.
The authentication factors that are usually employed are:
Something you know
Something you have
Something you are
For instance, passwords are a commonly used authentication factor (something you know). In the case of this policy type, multiple authentication factors may include the user password as well as a digital certificate.
Much like the multifactor authentication policy, the physical multifactor authentication policy means that the user will need to authenticate using multiple authentication factors. The difference here is that one of those authentication factors must be a physical factor such as a hardware device or some piece of biometric data.
Also like the multifactor authentication policy, this policy usually employs the three common authentication factors (or some combination) listed previously—something you know, have, or are. For instance, the user may authenticate using his password and a hardware token.
The National Institute of Standards and Technology (NIST) defines a series of guidelines for the levels of assurance protection that should be in place when services attempt to authenticate users over open networks. These recommendations indicate certain levels of protection that PAPE puts in place while authenticating users. In this section, we’ll look into a few specific token types and protections that are employed at each defined NIST assurance level.
First, we’ll look at the types of tokens that can be used at each authentication assurance level (Table 11-16). As we increase NIST assurance levels, we can see that the less secure token types (that is, the easiest to break) are removed.
Table 11-16. Token types for each NIST assurance level
Token type | Level 1 | Level 2 | Level 3 | Level 4 |
|---|---|---|---|---|
Hard crypto token | ✓ | ✓ | ✓ | ✓ |
One-time password device | ✓ | ✓ | ✓ | |
Soft crypto token | ✓ | ✓ | ✓ | |
Passwords and PINs | ✓ | ✓ |
So now we’ve outlined the token types that are applied, but what kind of protections will we receive at the different levels? It’s especially important to understand this aspect of the NIST assurance levels, since this will help us determine which level is the most appropriate for what we are trying to accomplish. In many use cases, level 4 assurance contains a far higher degree of security than most common implementations will need. Table 11-17 details the attack protections offered at each level.
Table 11-17. Protections at each NIST assurance level
Protect against | Level 1 | Level 2 | Level 3 | Level 4 |
|---|---|---|---|---|
Online guessing | ✓ | ✓ | ✓ | ✓ |
Replay | ✓ | ✓ | ✓ | ✓ |
Eavesdropper | ✓ | ✓ | ✓ | |
Verifier impersonation | ✓ | ✓ | ||
Man-in-the-middle | ✓ | ✓ | ||
Session hijacking | ✓ |
Let’s break down the assurance levels a little further by defining the attacks they protect against:
- Online guessing
This is an attack wherein the malicious party attempts to guess the user’s password.
- Replay
In this type of attack, the malicious party (most likely the relaying party) purposely repeats or delays the user authentication process. A common attack vector for this is a spoofing attack whereby the relaying party may masquerade as the user who is attempting to authenticate.
- Eavesdropper
This is an attack in which the malicious party eavesdrops on two parties that use an anonymous key exchange protocol to secure their conversation.
- Verifier impersonation
In this attack, the malicious party impersonates the legitimate verifier in an effort to learn valuable information—for example, the user’s password.
- Man-in-the-middle
This is a type of active eavesdropping attack wherein the malicious party makes a connection with the user and relays messages between the user and the attacker. In other words, the attacker impersonates the legitimate service to obtain the user’s private information or attempts to hijack the user session to gain access to that information.
- Session hijacking
This attack involves the malicious party taking control (or impersonating) of a valid session between the user and the intended, valid web server source. These sessions are usually controlled by a session token, which is what this attack uses. In one possible scenario, the malicious party sniffs a valid session to gain the session token, and then sends that token to the web server to open a new valid session, impersonating the user. Cross-site scripting is another possible method for the attacker to gain access to the session token.
Now that we understand the basics of the tokens and attack protections that are in place, let’s take a quick look at the minimum number of authentication factors required at each NIST authentication level. Table 11-18 lists them.
Table 11-18. Minimum number of authentication factors required at each NIST level
Level | Factors |
|---|---|
1 | 1 |
2 | 1 |
3 | 2 |
4 | 2 |
Warning
Some OpenID providers do not support the NIST assurance protection levels in their implementation. In some of these cases, the provider may return a NIST level response of 0 to denote that the service should not be used for any secure transactions such as online payments. If you require a high level of security, you should always check the NIST level returned at the end of the OpenID authentication process before proceeding with secure transactions.
When we combine all of this information, we have the foundation for the NIST assurance-level security mechanisms employed within PAPE. Since we will always be dealing with user authentication within OpenID, it’s important to be able to determine the current security level that we are authenticating into and to understand how we should be managing user privacy and security.