[Rats] remote attestation Epoch ID distribution in IPv6 and GRASP

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 19 August 2022 16:41 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 937FFC1522CB; Fri, 19 Aug 2022 09:41:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.706
X-Spam-Status: No, score=-6.706 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (OpenSSL error: data too large for modulus)" header.d=sandelman.ca
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DjwfyD2o3wFA; Fri, 19 Aug 2022 09:41:25 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74D85C1522BF; Fri, 19 Aug 2022 09:41:25 -0700 (PDT)
Received: from localhost (localhost []) by tuna.sandelman.ca (Postfix) with ESMTP id DC5AB18200; Fri, 19 Aug 2022 13:01:06 -0400 (EDT)
Received: from tuna.sandelman.ca ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id YRqwzy-5GstF; Fri, 19 Aug 2022 13:01:02 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 313BA18023; Fri, 19 Aug 2022 13:01:02 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1660928462; bh=/4N5yXYk08c/cdm322tUGfBmpWa05M4d0xJQP5IKIiw=; h=From:To:CC:Subject:Date:From; b=wpDBvGvA64g+wxuiVAAmqlqXwpDxCOpmfS8HtvoNyvKgMiE+ah38XtP4B3smFxphg waHwQmvWz3NTNaoHyAOzH8HdH+bsiQYtOXXKQGXuYDL/GDuzhpDLNPl56gomMldjn/ q3NBtEGha2jo3K4vkd3SA999yHIiawg4Na1kZ23C66jIQxpyzRqSnd/UmjHHfDIkcC tAXuQ9eixwF7mZQmf1Muy3C3ZF3upLWxc4KAXmqSAvJ+LjDPO0ewXKJ2Z9hGBGRoto rzABQ+BwBjHDS65w26CkYuwhqO4jwxp0EXXNce3yLHGy6RlLpk/8TYKg6K2uxQYi34 I4Ceoj413UUpA==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 201E8189; Fri, 19 Aug 2022 12:41:18 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima@ietf.org, rats@ietf.org
CC: otroan@employees.org, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "Brian E. Carpenter" <brian.e.carpenter@gmail.com>, Nick Allott <nick@nquiringminds.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 19 Aug 2022 12:41:18 -0400
Message-ID: <18007.1660927278@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/bd-HqBQWAwPmnG9zbtOBo66K-RM>
Subject: [Rats] remote attestation Epoch ID distribution in IPv6 and GRASP
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Aug 2022 16:41:29 -0000

As explained at:

and also referenced at:
  (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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide