Re: [Anima] remote attestation Epoch ID distribution in IPv6 and GRASP

[Henk Birkholz <[e-mail]>]

Hi Michael,

similar to a MUD URL, an Epoch ID (or epoch marker, see: 
https://www.ietf.org/id/draft-birkholz-rats-epoch-markers-01.html) can 
be conveyed via many vehicles. As MUD URLs can, for example, be included 
in LLDP payload, it seems like a low hanging fruit to me to distribute 
Epoch IDs via router advertisements or M_FLOOD.

If there is interest in this application of a source for freshness, we 
can certainly make that happen.

And while we are at it: If ANIMA has any requirements on potential 
payloads of an epoch marker, please say so :-)

Viele Grüße,

Henk

On 19.08.22 18:41, Michael Richardson wrote:
> 
> 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
>             Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
>