How Does Continuous Access Evaluation Fit Into Your Zero Trust Strategy?
In this post-perimeter security world, how end-users authenticate to and access corporate resources should be the top priority for Chief Information Security Officers and security teams.
Mobile devices and cloud apps have been in mainstream use for over a decade and have altered the security strategy that organizations must employ to keep the bad guys out. While the COVID-19 pandemic has accentuated the need for modern security measures, the fact is that once the health crisis is behind us, the way people work – away from the traditional corporate perimeter – will continue to exist and will likely be the new normal.
For this reason, it is important that organizations begin adjusting to this reality by enacting policies that embrace and implement technologies that help enforce zero trust security. One of the principles of zero trust security is the concept of continuous authentication wherein an end user’s or device’s session connectivity is continuously being monitored for changes.
Kerberos authentication
First, a brief history lesson. Let’s discuss a well-known authentication flow, that of Kerberos authentication:
Kerberos has been in use as the default authentication protocol in Microsoft environments since the release of Windows 2000, over 20 years ago. The basic concept behind Kerberos is that both the client and the server have a mutual process for trusting each other, with the issuance and use of tickets as the access granting mechanism to services.
With Kerberos, tickets cannot be revoked
Kerberos is widely adopted and for the most part it performs well as a secure protocol. However, one of its flaws is that the tickets that are issued to clients for access cannot be revoked either manually or because of a change to the state of the client.
The official Microsoft documentation states: Kerberos V5 does not enforce revocation of accounts prior to the expiration of issued tickets.
This means that even for accounts that have been proactively disabled in Active Directory, existing access to services can continue for the life of the Kerberos ticket. The “maximum lifetime for service ticket” setting configured for a domain is typically the default value of 600 minutes (10 hours).
For example, JaneD works for WoodGrove Bank. Jane’s employment is terminated, and her account is disabled in Active Directory. Tickets granted to Jane’s account prior to disablement can continue to be valid. While there are ways to mitigate for these scenarios in traditional on-premises applications, the problem is now extended to cloud and mobile applications which have become the predominate way people work today.
Modern authentication with OpenID Connect/OAuth flow
Modern authentication protocols operate on a similar principle. Instead of tickets issued by an authentication service, access tokens are granted to endpoints and users in an OpenID Connect/OAuth flow:
There are many underlying similarities – just as the time limited service tickets issued by an AS/TGT server in a Kerberos flow, the JSON web tokens (JWT) issued by the cloud identity provider are also valid for a set time, typically one hour. In practical terms, we’ll use Exchange online as an example.
- User, GaryW, uses the Outlook app on his mobile device to access his Exchange online mailbox.
- The API requests are authorized using OAuth 2.0 access tokens, which are valid for one hour by default.
- At expiration, the client is redirected back to Azure Active Directory, the provider, to refresh the access token.
- At this stage, decisions on whether or not they should be refreshed are made based on the user’s current status (enabled/disabled account) or other conditions, typically via Conditional Access policies.
If an account is disabled or if the device state, location, or overall hygiene of the device has changed within that validity period, there is a potential for compromise either due to an insider threat (e.g., a disgruntled terminated employee) or outside threat.
One approach taken to address the risks has been to reduce the token lifetime, but this approach can degrade user experience and reliability without eliminating risks.
What is Continuous Access Evaluation Protocol?
The modern approach that takes into consideration policy violations (e.g., outdated anti-malware signatures) or security issues (e.g., disabled user accounts) requires a “…conversation between the token issuer, like Azure AD, and the relying party, like Exchange Online.”[i] This method provides vital information to the control plane that is making access decisions in real-time.
The OpenID foundation Shared Signal and Events working group, of which Microsoft has been an early participant, has been working on such a method, called Continuous Access Evaluation Protocol (CAEP). The goal of the working group is building “…a standards-based approach to communicating changes to access properties.”[ii]
How is CAEP different?
This capability is now available in Azure AD. As explained in a recent post about this feature, “CAEP provides a standard way for an identity provider or a service (also known as the relying party or resource provider) to be told to stop honoring a valid token and to re-issue an authentication and authorization attempt. With this mechanism in place, the lifespan of a token is no longer important, as we can re-challenge a user whenever circumstances change, without having to wait for their token to expire.”
This is a standards-based approach using a publisher-subscriber (pub-sub) model. In the Microsoft model, resource providers like Exchange Online or Teams, subscribe to critical events in Azure AD to allow the providers to evaluate conditions in real-time. In the initial implementation, the following events will be enforced:
- User Account is deleted or disabled
- Password for a user is changed or reset
- Admin explicitly revokes all refresh token for a user
- Elevated user risk detected by Azure AD Identity Protection
As illustrated in figure 3, a CAE-capable client is required. This means that the latest version of the following clients is a requirement:
- Outlook for Windows
- Outlook iOS
- Outlook Android
- Outlook Mac
- Teams for Windows
- Teams iOS
- Teams Android
- Teams Mac
The reason for this is that unlike the previous versions which would attempt to replay the access tokens from cache as long as it was not expired, a new mechanism called “claim challenge” is used. CAE requires a client update to understand claim challenge.
Who is eligible?
Customers that have not deployed Conditional Access policies in their tenants will be the first to benefit from these features. You can read more details about it here.
This is yet another incentive for customers that are still relying on legacy authentication and authorization methods to begin their journey to native cloud authentication and away from federated identity systems with on-premises (AD FS) or in the cloud (third-party IDaaS).
Watch
Check out OCG’s “Zero Trust Architecture: It’s all about Identity” webinar recording here.
Read
[i] https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-continuous-access-evaluation