As explained at: https://www.ietf.org/archive/id/draft-ietf-rats-reference-interaction-models-05.html#name-uni-directional-remote-atte
and also referenced at: https://www.ietf.org/archive/id/draft-ietf-rats-architecture-21.html#name-example-3-epoch-id-based-pa (which has a cool SVG diagram) one of the key ways to get freshness for remote attestation mechanisms is to have some entity send a series of Epoch IDs to all parties. They are non-repeating, non-deterministic nonces that wind up being included in the signed Evidence produced by Attesters. draft-birkholz-rats-epoch-markers imagines reuse of RFC3161 TimeStampTokens as one example. In bilateral systems where TLS is used as a transport (such as in BRSKI onboarding), then it possible to use tls-unique^WTLS Exporter to get something which is fresh. In other scenarios where Evidence will be shared with a Verifier that did not participate in the TLS connection (such as in background check model, which is what BRSKI would need to use) then the Epoch ID mechanism may be a better way. When working on this freshness model in the RATS architecture, one distribution mechanism that we envisioned was some kind of rain from ("heaven") above of Epoch IDs. Such as having them embedded in a GPS or 3G signal/beacon. This has advantages for uni-directional attestation where no signals are allowed into the nuclear power plant, yet fresh attestations need to be emitted. Much more mundane scenarios just need to have the EpochID distributed in an efficient manner. One thought is an RA option. The universal RA option comes to mind, but the EpochID is not a constant, so it does not entirely fit into one concept of universal RA where it's something that can just get inserted verbatim into a router configuration. (I was going to CC 6man, but I'm not doing that yet) A second thought is to do this via GRASP (RFC8990) M_FLOOD. ANIMA's ACP operators will want to do regular attestation of routing platform, so we will need such a thing. A GRASP M_FLOOD could be forwarded through the ACP, and if an Enterprise situation, could be then multicasted on the normal links for hosts that need the EpochID. As GRASP is just CBOR over UDP, sometimes multicast on IPv6-LL, it's not more complicated than an RA. As draft-birkholz-rats-epoch-markers seems to be defining a signed EpochID in CBOR format, the match seems quite good. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
