Re: [Teep] Scalability of nonce-based freshness

[Thomas Fossati <[e-mail]>]

Hi Göran,

On 15/03/2021, 07:34, "Göran Selander" <[e-mail]>
wrote:
> Some more details.
>
> In addition to encryption key, the encryption context typically also
> requires an initialization vector (a.k.a. "nonce", but using that term
> would be confusing here) which must only be used once with a given
> key. This may e.g. involve a counter which is stepped for each
> encryption. The value of the counter needs to be reproduced at
> decryption time, e.g. by defining the token nonce to be the counter
> concatenated with the encrypted time stamp (using same notation as
> below: n = counter ||  E(t_req, k) ).

Right.

And looking a bit more at the practical side here, the whole crypto
overhead including the IV/counter and the authentication tag can make it
unfeasible for a "time token" of the sort you have described to stay
below ~32 bytes (note that EAT nonces are bstr .size (8..64)).  Taking
AES-GCM as benchmark you'd need a 12o nonce and a 16o authentication
tag, which leaves 4o for UNIX time with second resolution.  Cutting down
a bit on the tag size, but not too much because malleability is
absolutely not acceptable, you could get back maybe 4 bytes, which you
might or might not want to use for other kind of overhead (e.g., a
context identifier if you are doing some load balancing or for key
rotation, or have higher time resolution, etc.)

> While this part is straightforward there are some subtleties as to how
> the nonces are used which may have an impact on security.
>
> If only the nonces are tracked (or encryption context cached, in the
> case of encrypted time stamps) it is not necessarily possible to
> determine that a particular response is actually matching a request
> with the same nonce. For example, two colluding attesters who both
> have received a request from the same verifier could in theory
> exchange their nonces which would not be noticed.

Sure, the simple "time token" you described is just a bearer token that
can be "redeemed" more than once by one or more parties.  Per se, the
only proof it carries is about the time it was minted and the identity of
the minter.  If you need more than that, you need to boost it up a notch.

> This is not necessarily a problem depending on different things e.g.
> the policy for expiring nonces: If only freshness is sought, then it
> is only required that a recently issued nonce is presented, since that
> restricts the time when the response could have been created. It may
> not even matter if the same nonce is used by different attesters. In
> this setting the properties may be similar with nonces taken directly
> from a PRNG or encrypted time stamps.
>
> The nonce could also carry information about the request, e.g.
> encrypting parts of the request, in which case it is possible to
> verify a stronger binding to a particular request. Or, in the interest
> of saving bytes on the wire at the expense of caching more about the
> request, the nonce coule be a MAC over parts of the request. In the
> ase of a MAC, however, it doesn't make much sense to use encrypted
> time stamps since they would need to be cached.

Indeed, if one needs the "redeem time token" operation to be unique
(i.e., effectively asking the time token to be a nonce in the
cryptographic sense), one could look at some form of binding (e.g.,
RFC8471) or minimal state keeping - possibly playing with rate limiting
within the sliding validity window.

It doesn't look like TEEP has this requirement though.

> Again, not sure how much this matters for this work. Just input to the
> discussion.

Thanks, that was very helpful, for me at least :-)

Cheers!




IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.