[Rats] freshness in the background check interaction model

[Michael Richardson <[e-mail]>]

In the background check interaction we assume that the Attester
has connectivity to the Relying Party, and that Relying Party will
communicate with a Verifier itself, passing Evidence along the way.

{This is not an architectural issue.  This is an issue of how to
implement RATS in a particular flow}

This could occur as part of Network Endpoint Assessment, including both
802.1X processes or onboarding such as with BRSKI (RFC8995).
(I am unclear in the TEEP case (which uses both interaction models), how this
works)

In the BRSKI case the mapping is as follows:

1) Pledge    => Attester.
2) Registrar => Relying Party.
3) MASA      => Verifier

This works well, because the MASA is associated with the manufacturer and so
it can get all the Endorsements or Reference Values by private channel.

The Pledge reaches out to the Registrar, and provides it with a Voucher-Request.
We could trivially include Evidence (or pretty much any form) in the
Voucher-Request.

The Voucher could include a reply which can be evaluated by the Registrar
(Relying Party) to provide a signal to the Registrar (they RP) as to whether
or not the Pledge (Attester)'s evidence is satisfactory.

There are some options other than embedded the answer for the (2)->(3) protocol including:
  a) use another end-point on the (3) that would return the response.
  b) use multipart/mixed reply for the reply from (3)->(2)
     [this wins for constrained case, because (1) never needs to see this]

but, the purpose of this email is to ask about how we get freshness.

Ideally, a nonce would be created by the Verifier (MASA) and transmitted to the
Attester (Pledge) via the RP (Registrar).  A challenge is that the Registrar
doesn't know which MASA to use until after it has received some communication
from the Pledge.  That comes with the Pledge's IDevID, which it uses both
to sign the Voucher-Request, and which it uses as TLS Client Certificate.

Since the TLS setup occurs before the Voucher-Request, in theory the
Registrar could retrieve a nonce from the Verifier, but in the BRSKI protocol
flow, we did not add a step to return the Nonce to the Pledge.

In the middle of writing this, a gather.town discussion occured...

A suggestion was to use a TLS Exporter to get a nonce that both the Registrar
and the Pledge knew.  The Pledge can then build it's Evidence and include
that in the (raw) Voucher-Request.   The Registrar then has to communicate this to
the MASA (Verifier)..... how do this is a question... probably in the
parboiled Voucher-request.

In the middle of this, Goran Selander brought out his slides on
draft-selander-ace-ake-authz, and most of this can be wrapped up into EDHOC.
If we can get our packets small enough, we can do AKE, Enrollment, and
Remote Attestation in three flights (two round trips).

Is it acceptable for a nonce to be created via TLS Exporter?
Is it acceptable for the nonce to be known to the RP?
Is it okay that the Verifier didn't get to insert entropy into the nonce?

All of this coming to a draft near you.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [