Re: [Teep] Scalability of nonce-based freshness

[Göran Selander <[e-mail]>]

Hi Thomas,

Seems we have the same line of thought :-)

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) ).

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. 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.

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

Göran


On 2021-03-12, 22:10, "TEEP on behalf of Thomas Fossati" <[e-mail] on behalf of [e-mail]> wrote:

    Hi Göran,

    On 12/03/2021, 19:00, "Göran Selander" <[e-mail]> wrote:
    > Hi Dave, and all,
    >
    > Referring to the TEEP protocol presentation at the WG meeting, there
    > was a discussion about the use of tokens and what method of freshness
    > to apply in TEEP (slides 11-16 in the presentation).
    >
    > If I understood right the main argument against the nonce-based method
    > (slide 15) is the question of scalability: "Receivers have to keep
    > state to remember each nonce supplied until it’s used"
    >
    > If I'm not mistaken, this condition on the receiver could be relaxed
    > by the receiver generating nonces as encrypted time stamps. This would
    > only require the receiver to remember an encryption context used to
    > encrypt/decrypt the time stamps used as nonces. The encryption context
    > can be small (say, less than 50 bytes for key, IV and counter) and
    > doesn't grow with the number of TAs (but would typically be updated
    > for each nonce generated, e.g. stepping the counter).
    >
    > Note that the receiver needs a clock but it need not be synced because
    > the time stamps are only used by receiver; once when nonces are
    > generated, and then again when freshness is determined from the nonce
    > received back in the evidence. Such a clock coincides with the
    > assumption of this method according to slide 15: "Receivers need a
    > clock to “expire” nonces, but need not be synced".
    >
    > Perhaps this should be an input to RATS rather than TEEP. But since
    > this seemed to be the main argument against the nonce-based method I
    > just wanted to share my 2 cents to the discussion.

    I think this is all correct.  (BTW, that's what I meant when I said the
    TAM should make this a verifier problem as there is no need for the
    nonce to be stored at the TAM.)

    With your nonce generation scheme:

    A. Verifier is initialised with secret key k

    B.1: TAM asks Verifier for a nonce;
    B.2: Verifier generates nonce n = E(t_req, k) and sends it to TAM;

    C: TAM runs the challenge-response protocol with the Attester, sending
       N and obtaining Evidence(n) in return;

    D.1: TAM forwards Evidence(n) to Verifier for verification;
    D.2: Verifier extract n and does D(n, k):
      D.2.1: If decryption fails, goto drop;
      D.2.2: If decryption succeeds, extract t_req
    D.3: Verifier checks |now - t_req| < acceptable_recentness_threshold:
      D.3.1: If so, proceed with verification of Evidence;
      D.3.2: If not, return ESTALE

    Note that if B.* is done once every "period", thus avoiding the extra
    round-trip per nonce / attestation session, this scheme falls back to
    the epoch-id based model.

    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.
    _______________________________________________
    TEEP mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/teep