Why choose a response-wrapped token vs. a time limited 1 use token?

Vault
#1

I am reviewing the Cubbyhole and the response-wrapped token concept and I’m confused.

From what I understand, I can create a token that allows 2 uses and has a time limit. With that token, I can write a secret to the Cubbyhole, send the token to someone else, and they can either access the token (and no one else can as that is 2 uses), or they cannot access the token if someone has already read it.

Or, I can use the sys/wrapping/wrap endpoint to wrap up the token used to put the data in the Cubbyhole and send the response-wrapped token to someone else. Again, they can either unwrap the token and access the secret in the Cubbyhole, or they cannot.

In both cases, I can view the audit logs to see who attempted to use the token, or unwrap it.

Why would I use the response-wrapped token? Is it just because the added step of unwrapping a token slows down bad actors a smidgeon?

#2

The use cases you describe are roughly equivalent, but I think the utility of token wrapping is much broader than you’ve outlined: you could wrap a periodic token that never expires, for example.

In theory, you could imagine a scenario where you extend access to your environment for all your existing use cases, without breaking your existing security policy, simply by introducing token wrapping. In practice, you’d obviously want to conduct a new risk assessment prior to introducing such a fundamental change, and strengthen your processes, around monitoring and auditing as a minimum, I’d imagine.

1 Like
#3

Thanks for the response. I had read about the scenario that you described, and at the same high level. I have found it difficult to wrap my head why it would be helpful.

Would you be able to elaborate on why you would want to keep such a periodic token wrapped living for an indefinite time in your system? An example?

I am interested in learning more about that use case. Thanks!

#4

Hi Lyndsey! Sure, but first, it’s important to note that, even in the case of a long-lived periodic token, you wouldn’t want the TTL of the response-wrapping token to match it; this is one of the key benefits of response-wrapping, as outlined in HashiCorp’s documentation: regardless of the secret/token being wrapped, you can limit its lifetime in the event that it doesn’t reach its intended recipient.

So, as an example, I could create a periodic token for use as part of my automated Consul gossip key rotation, with the limited privilege of being able to read a secret from a specified path. As designed, this token should be used by consul-template to read the encryption key from Vault, and, if it’s changed, to add that key to Consul’s keyring, and remove all the old ones.

If my risk assessment suggested that passing that periodic token over the wire might put it at risk of interception, I would probably just configure TLS between all my nodes. But you can imagine a scenario where it might not be practical to have verifiable certificates at all endpoints. Response-wrapping that periodic token could be one solution, providing it cover (and tamper detection).

This is actually a point where your two-use token would not provide the same utility: there’s only one TTL associated with it, whereas, I could put a TTL of an hour on my periodic token, and then, regardless of how long it’s supposed to be valid, if consul-template doesn’t unwrap it and use it within an hour, it would expire.

Another example might be the DR operation token needed to promote a secondary cluster to primary in the case the latter’s total failure. In the wrong hands, this is a denial of service threat, and so you’d want to provide all the properties offered by response-wrapping in many environments.

3 Likes
#5

Thanks for the example, it helps.

I have to say, I really like Vault so far (and Hashicorp’s tools).

1 Like