To answer the question about TEEP, the example in https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture#section-16.5 is indeed the default (i.e., when using nonces instead of timestamps or epoch ids) case that TEEP uses for freshness.
TEEP can also negotiate use of timestamps (in which case https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture#section-16.4 applies) or epoch ids, if both sides support them. Dave -----Original Message----- From: RATS <[email protected]> On Behalf Of Michael Richardson Sent: Wednesday, July 28, 2021 5:42 PM To: [email protected] Cc: [email protected] Subject: [Rats] freshness in the background check interaction model 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 [ ] [email protected] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&data=04%7C01%7Cdthaler%40microsoft.com%7C4dbc5796d82a44c6466308d95229af30%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637631161721316112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mK8Jyrn0N7pehFvHxgJBDAL0p3%2FxjWcBi13Vbrv%2Fy2Q%3D&reserved=0 | ruby on rails [ _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
