Attester Groups for Remote Attestation
draft-labiod-rats-attester-groups-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Houda Labiod , Amine Lamouchi , zhang jun , Andrzej Duda , Henk Birkholz | ||
| Last updated | 2024-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-labiod-rats-attester-groups-01
RATS H. Labiod
Internet-Draft A. Lamouchi
Intended status: Standards Track J. Zhang
Expires: 24 April 2025 Huawei Technologies France S.A.S.U.
A. Duda
Grenoble INP - Ensimag, LIG Lab
H. Birkholz
Fraunhofer SIT
21 October 2024
Attester Groups for Remote Attestation
draft-labiod-rats-attester-groups-01
Abstract
This document proposes an extension to the Remote Attestation
Procedures architecture as defined in [RFC9334] by introducing the
concept of Attester Groups. This extension aims to reduce
computational and communication overhead by enabling collective
Evidence appraisal of high number of homogeneous devices with similar
characteristics, thereby improving the scalability of attestation
processes.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 24 April 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Labiod, et al. Expires 24 April 2025 [Page 1]
Internet-Draft Attester Groups October 2024
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
3. Attester Group and Comparison to Composite Devices . . . . . 3
4. Attester Group Extension . . . . . . . . . . . . . . . . . . 4
5. Use Case Scenarios with a large scale network . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Implementation Considerations . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
[RFC9334] defines Attesters as entities comprising at least one
Attesting Environment and one Target Environment co-located in one
entity. It also presents different ways to compose the Attesting and
Target Environemtns, such as Composite Devices and Layered Attesters.
Layed Attester reflects a cascade of staged Environments. It is more
related to one device with different layers and there is a
relationship between them. However, mechanisms for efficiently
managing multiple, independent Attesters are missing. Assessing the
trustworthiness of large numbers of independent devices individually
can result in high conveyance and processing overhead. This comes
into effect particularly when these devices share identical hardware
or firmware components, which can lead to redundancy between all
individual remote attestation procedures. One example would be a
smart factory scenario where numerous sensors of the same model
monitor different parts of the manufacturing process. These sensors
share identical hardware and firmware configurations. This document
proposes a model by which these separate sensors devices can be
grouped into a single Attester Group and a shared remote attestation
procedure can appraise their authenticity collectively rather than
individually. Direct Anonymous Attestation (DAA) [I-D.ietf-rats-daa]
has a similar concept of using one unique ID for one group of
Attesters, but its goal is to mitigate the issue of uniquely
Labiod, et al. Expires 24 April 2025 [Page 2]
Internet-Draft Attester Groups October 2024
(re-)identifiable Attesting Environments, while scalability is the
major concern in this document.
2. Terminology
The following terms are imported from [RFC9334]: Attester, Composite
Device, Evidence, Layered Attester, Verifier.
Newly defined terms for this document:
Attester Group: A role performed by a group of Attesters whose
Evidence must be appraised in order to infer the extent to which
the individual Attesters comprising the group are considered
trustworthy.
group-id: A new Attester Identity type (see Section 2.2.1. of
[I-D.ietf-rats-ar4si]). It is a unique identifier assigned to
each Attester Group, allowing the group to dynamically adjust its
membership without redefining its fundamental identity.
2.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Attester Group and Comparison to Composite Devices
We should be able to leverage the similarities between attesters to
avoid redundant attestations. An Attester Group is by definition a
dynamic entity. Attesters can join or leave the group, in contrast
to Composite Devices that have a static composition with a pre-
defined set of Attesting Environments and fixed parameters. The
dynamic nature of an Attester Group allows for the flexibility to
tailor group parameters. This kind of flexibility facilitates the
implementation of various group attestation schemes that can optimize
the resources required to conduct remote attestation procedures for
large device groups. A composite device is an entity composed of
multiple sub entities. Each sub entity is an Attester. In a
composite device we can have multiple Attesters with a Lead Attester.
The Attesters are appraised via the main Lead Attester's help. The
lead Attester generates Evidence about the layout of the whole
composite device, while sub-Attesters generate Evidence about their
respective (sub-)modules. Composite device model is not enough
flexible to represent our definition of attester group where we do
need a leader attester nor a composition of evidences of the
Labiod, et al. Expires 24 April 2025 [Page 3]
Internet-Draft Attester Groups October 2024
attesters.
The table below summarizes the key differences between the Group
Attester concept and the Composite Device concept.
+===================================+==========================+
| Composite Device | Attester Group |
+===================================+==========================+
| Lead Attester | No Lead Attester |
+-----------------------------------+--------------------------+
| The Composite Device is | The Attester Group is |
| identifiable by the Lead Attester | identifiable by a group- |
| | id a unique identifier |
+-----------------------------------+--------------------------+
| Composition of Evidence of sub- | No composition |
| modules (attesters) | |
+-----------------------------------+--------------------------+
Table 1
4. Attester Group Extension
In Section 3 (Architectural Overview) of [RFC9334]: we could add a
subsection 3.4 titled "Attester Groups". In addidion, Section 2.2
(Non-repudiable Identitythe) of the draft [I-D.ietf-rats-ar4si], we
could add an Identity Type "group-id" (i.e add another row in the
Table 1 in [I-D.ietf-rats-ar4si]).
5. Use Case Scenarios with a large scale network
In this section, we provide two examples of applications where all
devices are homogeneous with similar characteristics.
Use Case 1: Remote maintenance in the aerospace domain
Context: EU ASSURED H2020 Project.
Once an aircraft lands, there is the need for the physical presence
of an engineer to go and connect to the "head unit" (in the cockpit)
for extracting log data so as to check whether something needs to be
checked/maintained. We need attestation of all core PLCs and
embedded systems responsible for the core functionalities of the
aircraft. All attestation reports are remotely sent (in a secure
manner) to the control station once landed. We can group the
attested elements into different attester groups.
Approach: We can consider an attester group of 1000 aircrafts (same
manufacturing brand)
Labiod, et al. Expires 24 April 2025 [Page 4]
Internet-Draft Attester Groups October 2024
Use Case 2: Automotive domain, a Vehicle with embedded Electronic
Control Units (ECUs)
Context: CONNECT EU H2020 project.
The automotive industry is moving to a more hierarchical in-vehicle
architecture where ECUs are monitored by Zonal Controllers and these
in turn communicate with the Vehicle Computer. This is, for
instance, how kinematic data are extracted from the sensors all the
way up to the vehicle computer to be encoded into a V2X message.
This data need to be associated with Evidence on the integrity of the
sensor as a data source and this is where group attestation is an
interesting capability. The attester group can be formed for
hierarchical-based attestation, like attester group of all in-vehicle
ECUs or attested group of vehicles within an intersection.
Approach: we can consider an attester group of a fleet of 70000
vehicles (same brand). We can also consider an attester group of
similar ECUs.
6. IANA Considerations
This document has no IANA actions
7. References
7.1. Normative References
[I-D.ietf-rats-ar4si]
Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V.
Scarlata, "Attestation Results for Secure Interactions",
Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-
07, 2 September 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
ar4si-07>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
7.2. Informative References
Labiod, et al. Expires 24 April 2025 [Page 5]
Internet-Draft Attester Groups October 2024
[I-D.ietf-rats-daa]
Birkholz, H., Newton, C., Chen, L., and D. Thaler, "Direct
Anonymous Attestation for the Remote Attestation
Procedures Architecture", Work in Progress, Internet-
Draft, draft-ietf-rats-daa-06, 5 September 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
daa-06>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
Appendix A. Implementation Considerations
Details on creating and maintaining Attester Groups, choosing the
number of Lead Attesters, and methods for evidence collection and
signing are left to the implementer's discretion, allowing for
tailored security measures.
Authors' Addresses
Houda Labiod
Huawei Technologies France S.A.S.U.
18, Quai du Point du Jour
92100 Boulogne-Billancourt
France
Email: houda.labiod@huawei.com
Amine Lamouchi
Huawei Technologies France S.A.S.U.
France
Jun Zhang
Huawei Technologies France S.A.S.U.
18, Quai du Point du Jour
92100 Boulogne-Billancourt
France
Email: junzhang1@huawei.com
Andrzej Duda
Grenoble INP - Ensimag, LIG Lab
France
Email: Andrzej.Duda@imag.fr
Labiod, et al. Expires 24 April 2025 [Page 6]
Internet-Draft Attester Groups October 2024
Henk Birkholz
Fraunhofer SIT
Rheinstrasse 75
64295 Darmstadt
Germany
Email: henk.birkholz@sit.fraunhofer.de
Labiod, et al. Expires 24 April 2025 [Page 7]