Improving Zero-Trust in a Multi-Workload Environment

So, yes, my name is George Fletcher. I am an identity architect at Capital One, and also a community board member of the Open ID Foundation and longtime sort of identity standards person. And today I wanna talk about some work that we're doing in the IETF that can help improve zero trust in a multi workload environment. So we'll talk a little bit about sort of common backend deployments, the zero trust implications, and then this work that we're calling transaction tokens as a way to help address that.

One of the things when I'm talking here about zero trust is it's at the application level, not so much at the network level. So we're talking about zero trust between applications in our networks that sometimes doesn't get discussed. So hopefully this will be interesting. Where's my butt?

Okay, so I wanna talk a little bit about what are some common deployments of backend. So just think within, you know, within your particular backend deployment, how does that work?

Well, in some cases you have a client, it hits the edge of your network, maybe some authentication stuff happens there, and then everything is open inside. Hopefully we don't have very many of these left, but that has been a common pattern in the past, and I'm sure it still exists, right? Obviously there's, in this kind of an environment, there's effectively no zero trust anything, right? Because anybody can talk to anybody about anything they want.

Another model might be looking at protecting the interactions between servers with MTLS, or you could use OAuth client credentials that gives you basically client authentication. Server one is authenticating itself to server two and it invokes an a PII tend to look at this as hop to hop security in the sense that we're, we're protecting those calls and, and from a zero trust perspective, if, if this service is sitting here, it can know I can only take calls from this and because it's MTLS protected, right? You can sort of constrain the, who can talk to me kind of a perspective.

You could try and do OAuth access token. So this is kind of like using an an OAuth access token to come into your, an edge, right? And then you just pass it down through, depending on what kind of an OAuth access token, this can potentially give you some protect, give you some help in the sense that you've got potentially the, the scopes that are associated with this particular request as well as oftentimes a user. So that gives you some, some help in that context. You could run that over MTLS as well.

Unfortunately, OAuth tokens we'll talk a little bit about, but they don't tend to have the data that you need for what you're trying to accomplish. And if it happens to be the context where you are using an opaque access token, right, or you need additional data that isn't in the OAuth access token, then you're constantly bouncing to the authorization server doing introspection or the user info endpoint or something of that nature to try and get more data about this token before you can actually process the request. And my timer isn't working.

So, okay, so what are the, what are some zero trust implications here? Well, if we go back, let's just use this picture. And if I compromise this particular server as an attacker, right? I can make any API calls that the server can make and generally right? All of the information, like who, who it's about what is the purpose of the transaction? All of these things are all API parameters, right? So once I've compromised this, then I can pretty much do anything that thing can do in the underlying sim may or may not even detect it, right?

Because this, this server is authorized to call that server, right? And then so you're look, unless you're looking for like increased numbers of API calls or something else, right? You might not even notice. So that's a a, an issue that happens when we basically look at just protecting the communication between servers but not looking at the overall purpose of what's happening at that point in time.

That also, so basically this end-to-end transaction is not being protected. And as we'll go into in a minute, that's sort of the goal of this work is how do we protect the transaction? So taking up the thought process from just API call to API call, but looking at the overall set of things that are needed to complete, what was the intended purpose? So you often lose the originating context. Who requested this?

How did, where did it come from? If you're talking about OAuth, this might be your client ID of the requesting application. Nothing's immutable in this kind of a flow, right? And any intermediate server can invoke the parameters as we talked about. And effectively oftentimes what I'm trying to do in a particular transaction is much narrower than the, than the scopes that were issued to the client. We'll talk a little bit about that. So we started this work in the OAuth working group of the IETF on something that we're calling transaction tokens.

And so hopefully for the techies in the room, there's a Jason over here. The, the other side sort of describes what's there.

The, a transaction token is bound to a particular trust domain. So it's not intended to cross trust domain boundaries. It's supposed to be internal to your backend. It's supposed to, it's a signed jason object. And that's really for performance reasons so that any intermediate server in our pictures can basically validate it locally, right? Because I can get the public key of the signer of the Jason token and I can validate it locally. So that can help with performance from a authorization perspective. And then we want to encapsulate critical properties of the overall transaction, right?

Who's the subject of the transaction? It could be a a machine, it doesn't have to be a human though in many cases that would be the, the use case. We want a transaction identifier, we'll talk about the benefits of that, who requested it is often an important detail, especially if the, the requesting entity of this transaction is internal to your network. And I'll give you a use case for that. And then the purpose of this particular transaction, so we'll delve into this a little bit more, but if you think about like a messaging app, right?

The client probably has the scope to update the messaging service. It tends to be a fairly coarse grained scope. What I'm trying to do right this minute is add a user to a group. So in that context, it's a much narrower scope in reality. So how can I effectively, if we were to use OAuth terms for those who are familiar with it, how do we effectively down scope the authorization exposure of this particular transaction to just what I'm trying to do now as opposed to all that's allowed by the OAuth token.

So when, when we looked at that deployment architecture that's using OAuth access tokens internally, they tend to have a lot more privilege than what I'm trying to do right now. So once again, compromise of an intermediate server would allow you to do a lot more than what you would be able to do if you were to compromise an intermediate server and capture a transaction token. They're very short-lived. Most of our transactions today execute in seconds and they're explicitly intended to be bar tokens.

And I'll just put a quick caveat here that, that there are probably some use cases in your backend where you want more security than an internal bari token that's very short-lived. But, but those use cases tend to be not high transaction numbers, right? The TPS is generally is not high and latency is generally not a critical factor in those kinds of transactions. So what does this look like effectively?

It's very similar to the OAuth one, except for I'm going to exchange my OAuth access token through a transaction token service and get a transaction token back and then that gets passed through and effectively any of these intermediate servers, right? Only accept API calls that contain a transaction token. This would probably would not be in the authorization header, but you could combine MTLS plus the transaction token as a way to increase the ability of this server to do proper authorization and, and, and basically just follows the entire request.

So two, two examples quickly, and maybe I can catch this back up. We talked about this one, right? My client has, you know, read group messaging, write group messaging. Alice wants to add Bob to the Identity Rocks group message channel, right? So the transaction from the client is coming with, you know, Alice, I mean with Bob and the identity rocks is the two key elements. I can make those immutable in the transaction token, right?

So it, so the transaction token contains the subject and then in the authorization details it, it has basically the fact that Bob is the, is the sort of a principle in this transaction and the identity rocks is the channel that's being requested. And now any in compromise of an intermediate server effectively can, you could replay this, but your val your value in replaying it is basically not high because all you're going to do is, you know, re-add bob to the group messaging channel internal use case. You can think about SMS inbound mail delivery, the SMS server receives the message, right?

It can do the DEC IM and all that other stuff. But for all the virus scanning and the scam analysis and all of those things, right? You want to ensure that, that, that in that mail thread of delivering this mail message to the user's mailbox, right? That it's always known to be about alice@example.com. And the purpose of this transaction is to deliver inbound mail. So a compromise of the transaction token is not gonna allow you to read Alice's inbox. So basically what this gets us, we improve our, our sort of attack service.

We improve our zero trust posture, we can down scope the transaction token at the edge. It gives us traceability in our backend. So if you think about, you know, a sim tool or some of those kinds of things, it gives us the ability to follow the transaction and, and changes in transaction paths are anomalies, right? And so now you can start looking at, hey, wait, why did this change? It might not always be malicious, but it gives you another detection point that we currently don't have today. And from a pure deployment perspective, it we get some performance benefits.

So these are the links to the work, the GitHub repository is there, you can file issues and the the current draft is at the data tracker in the ITF. And if you are involved in this kind of work and have thoughts, we would love your participation. And that's it. And I think I'm on top. Thank you. I think we do have time for one question, right? And the question from our online audience is, will not macaroon tokens solve this problem? I have no idea what that is. Macaroon, macaroons is a, a token type that was developed by Google and they've written some papers on it.

The, the, the authorization models are slightly different with macaroons. I think some of the properties you could get with macaroons if you wanted to deploy them in that way. But a lot of the macaroons is, when I looked at this in the past is it's trying to determine the authorization bits sort of in, in a precursor kind of way, and then add these additional criteria as you go through.

So, so I think the purposes between macaroons and this are slightly different, but there are some overlaps. I, Well, thank you. Thanks George.