Continuous Access Evaluation Protocol (CAEP)

Continuous Access Evaluation Protocol (CAEP)

Wednesday 8I

Convener: Atul Tulshibagwale

Notes-taker(s): Jordan Wright & Atul Tulshibagwale

Tags for the session - technology discussed/ideas considered:

Taxonomies, Semantic Interoperability, labels, international standards

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

1. Received from Atul Tulshibagwale:

Here is the link to the slides from the presentation: https://drive.google.com/file/d/11ZhOWmDmLfSS1UURBL89KCA8c93vNYeN/view?usp=sharing

****************** ******************** ******************* **************

2. Notes received from Jordan Wright:

Agenda

• What is continuous access evaluation
• Why is it needed
• How does it work

What is CAE

Continuous Access and Evaluation allows independent organizations to react quickly to changes in information related to shared user sessions, including:

• Access context (IP, GEO, device posture)
• Device and app health
• Updated authorization decisions based on internal and external updates

The idea is to create a standard to make this easier, especially to support interoperability between multiple parties.

Why now?

• The Zero Trust Networking (ZTN) model makes endpoints the weakest link
  • The endpoint becomes more important from an attack point-of-view.
• Mobility adding opportunities for compromise
  • For mobile devices, sessions can last for a long time, so reevaluating it regularly can be beneficial.
• Standard drives interoperability between independent parties
  • Each service need not integrate with each identity or device management provider

Use Cases

• IP/Geo location based access re-evaluation (public location, untrusted geo)
• Sensitive content
  • Maybe access should be cut off when the user is in a public location
• App vulnerability
• Suspicious user activity
• Helping security of long-lived sessions

Discussion Question: "Who determines suspicious activity"

An example may be an endpoint security program which may 

May also be a CASB, firewall, basically anything has the ability to identify suspicious information and relay that information to other parties.

Architectural Model

[See Attachment]

The Relying Parties can receive updates from policy service providers via an asynchronous pub/sub interface.

The two areas CAEP is interested in is:

• Express Context updates
• Evaluation of updates

Protocol Messages

• Based on SET's (RFC 8417)
• Subject identifiers include
  • User session (SAML Request Id or OIDC token)
  • Certificate serial or hash
  • Device identifier
• Events include
  • Context update
    • This user moved IP addresses
  • Device update 
    • The device status is now rooted, or has malware
  • App update
    • The properties of the application have changed (e.g. a vulnerability in the app was discovered)
• Session authorization update
  • The user's role has changed, or the user needs re-authorization

Protocol Methods

• Single endpoint at each party used for all protocol messages
• Receive expression of interest
• Receive updates
• TLS mutual auth - SETs not signed
• HTTP POST - express interest
• PATCH - provide an update
  • SET
• PATCH response type depends on expectation 

Discussion:

There may be multiple parties involved besides an IDP or SP.

We're not trying to restrict who can generate events. For example, the IDP can express interest to other providers to receive updates.

Question: When you say both parties have to stand up an endpoint, are both parties clients to each other?

This is a server-to-server protocol. We're not imagining this to be used by clients. Each element has the ability to publish events as well as take action based on its position in the network.

Trust is established via mTLS between the peers in the network.

Event types themselves are not in the scope of CAEP interaction.

Question: Does CAEP try to solve the problem of: you're willing to let the user browse the website without having a high-level of faith that they are who they are, and building trust over time?

This can be done by expressing interest in various providers. "Tell me if this user changes aspects of their session"

This spec isn't handling session confidence.

There was a discussion that we may define a minimal set of SET's.

Question: Who is responsible for managing the pub/sub queues?

Not talking about subscribing to a topic. Instead, you have an expression of interest via a HTTP post between peers. I tell IDP I'm interested in a session (the topic) and that's what determines.

Question: How much overlap is there with RISC?

RISC is geared towards events, while this is more people involved and more data vs. events. Consideration to review IFMAP and others to see if there's overlap.

Action Item: Work with RISC group to determine how we can best collaborate, if at all.

Question: Is this an alternative to the OpenID Session Management Protocol?

There is a backchannel, but openid doesn't do anything other than lock them out. This is a more nuanced aspect of changing session state.

Idea: It may be useful to separate the event document vs. the transport.

Idea: Instead of expressing interest to terminate the session, you could express interest to continue the session.

Here, we're just saying you're interested in the session. In an environment where I'm the IDP, depending on how you manage tokens, you may have no clue the user is logged in to a Relying Party. This isn't a standard for that problem.

Question: Should we have some kind of a heartbeat?

What you could do is use the expression of interest and get an OK (repeatedly).

Action Items

• Decided this is worth considering as a standard
• Will set up a mailing list to discuss next steps
• Will work with RISC group to determine how we can best collaborate, if at all.