Zusammenfassung

  • RFC 10020 definiert CoAP-, Anwendungs- und Sicherheitsgruppe als getrennte Mengen. Ihre Beziehungen können Viele-zu-Viele, Eins-zu-Viele, Viele-zu-Eins oder Eins-zu-Eins sein; erst die konkrete Bereitstellung entscheidet, wie sie zusammenpassen.
  • Group OSCORE authentifiziert den bestimmten Sicherheitsgruppenangehörigen, der eine geschützte Nachricht gesendet hat. Der RFC warnt ausdrücklich davor, diese Mitgliedschaft als Zugriffskontrolle für Anwendungsressourcen zu verwenden.

Der aus einem Betriebsbereich entfernte Sensor blieb auf drei Ebenen in unterschiedlichem Zustand. Er hörte noch auf die Multicast-Adresse. Sein CoAP-Pfad war noch vorhanden. Die nächste Schlüsselrotation war noch nicht abgeschlossen. Als ein Gruppenbefehl eintraf, konnte der Sensor ihn korrekt prüfen und einem bekannten Absender zuordnen.

Die Kryptografie lieferte ein richtiges Ergebnis. Sie konnte nicht entscheiden, ob der Absender für diese Ressource noch ein Mandat besaß.

Diese Grenze ergibt sich unmittelbar aus RFC 10020, dem im Juli 2026 veröffentlichten IETF-Standards-Track-Dokument zur Gruppenkommunikation mit CoAP. Es ersetzt RFC 7390, aktualisiert RFC 7252 und RFC 7641 und legt UDP/IP-Multicast als Standardtransport für Gruppenanforderungen fest. Für Governance besonders wichtig: Der Text weigert sich, aus verschiedenen Mitgliedschaften eine einzige Autorität zu machen.

Drei Gruppen beantworten drei Fragen

Eine CoAP-Gruppe umfasst Endpunkte, die für den Empfang von Gruppenmeldungen an einer zugeordneten IP-Multicast-Adresse und einem UDP-Port konfiguriert sind. Sie beantwortet die Netzwerkfrage: Wer hört an diesem Ziel? Eine Gruppen-URI kann die Multicast-Adresse oder einen Gruppen-Hostnamen enthalten und bei Bedarf einen anderen Port als den CoAP-Standardport 5683 angeben.

Eine Anwendungsgruppe umfasst Serverendpunkte, die über CoAP-Ressourcen eine Anwendungsfunktion teilen. Sie beantwortet die Funktionsfrage: Welche Server sollen Methode und URI-Pfad im Sinne dieser Anwendung bearbeiten? Der Gruppenname kann im Pfad stehen oder aus Nachricht und Bereitstellungskontext abgeleitet werden.

Eine Sicherheitsgruppe umfasst Endpunkte, die gemeinsames Sicherheitsmaterial zum Schützen und Prüfen von Nachrichten besitzen. Sie beantwortet die kryptografische Frage: Wer kann in diesem Sicherheitskontext gültig senden oder empfangen? Ein Endpunkt darf mehreren Sicherheitsgruppen angehören.

Keine dieser Mengen wird aus einer anderen abgeleitet. RFC 10020 erlaubt alle Kardinalitäten zwischen ihnen. Mehrere Anwendungsgruppen können aus Speicher- und Aktualisierungsgründen dieselbe Sicherheitsgruppe verwenden. Eine Anwendungsgruppe kann mehrere Sicherheitsgruppen nutzen, wenn Clients unterschiedliche Algorithmen unterstützen. Konfigurierende Stellen stellen die Beziehungen für die jeweilige Installation her.

Auch die Absenderliste entspricht nicht der Empfängerliste. RFC 10020 betrachtet Any-Source Multicast. Eine Quelle kann, muss aber nicht Mitglied der Ziel-Multicastgruppe sein; die Zahl der Quellen ist durch dieses Modell nicht begrenzt. Eine Oberfläche, die Hörer zugleich als befugte Sender ausweist, ergänzt eine Regel, die der Transport nicht enthält.

Authentizität endet vor der Ressourcenfreigabe

Geschützte Gruppenkommunikation verwendet Group OSCORE aus RFC 10021. Das Verfahren baut auf OSCORE nach RFC 8613 auf und nutzt COSE-Strukturen, unter anderem aus RFC 9052, um CoAP-Nachrichten auf Anwendungsebene zu schützen. Im Gruppenmodus signiert der Sender mit seinem privaten Schlüssel; der paarweise Modus leitet Schlüssel für Eins-zu-Eins-Verkehr ab.

Der Empfänger erhält damit eine starke, aber begrenzte Aussage. Er kann prüfen, dass die Nachricht von einem bestimmten, identifizierbaren Endpunkt als Mitglied der OSCORE-Gruppe stammt. Gemeinsames symmetrisches Material allein würde nur die Gruppe authentifizieren; Group OSCORE fügt Quellauthentifizierung hinzu. Es authentifiziert jedoch nicht die als Netzwerkquelle verwendete IP-Adresse oder den UDP-Port.

Ebenso wenig erteilt es eine allgemeine Ressourcenfreigabe. RFC 10020 sagt ausdrücklich, unterschiedliche Sicherheitsgruppen seien nicht dazu bestimmt, Zugriffsrichtlinien innerhalb einer Anwendungsgruppe abzubilden. Die Mitgliedschaft erlaubt geschützten Nachrichtenaustausch und die Authentifizierung der Mitglieder. Die Berechtigung zur Nutzung einer Ressource liegt in einer getrennten Sicherheitsdomäne und soll mit Ressourceneigenschaften oder besonderen Zugriffsnachweisen durchgesetzt werden.

Die Signaturprüfung beantwortet folglich: Wer hat während dieser Schlüsselepoche gesendet? Die Autorisierung beantwortet: Darf diese Identität jetzt diese Methode auf diesen Pfad und in diesem Anwendungsbereich anwenden? Wer die erste Antwort in das Feld der zweiten kopiert, macht Schlüsselverteilung unbeabsichtigt zum Berechtigungssystem.

Das ACE-Rahmenwerk aus RFC 9200 kann die Autorisierung unterstützen, wenn ein Endpunkt beim Group Manager den Beitritt beantragt. Doch die Erlaubnis, Gruppenmaterial zu erhalten, ist nicht automatisch die Erlaubnis, jede damit geschützte Ressource zu verwenden. Beitritt, Nachrichtenauthentizität und Ressourcenfreigabe brauchen eigene Nachweise.

Die Abweichung entsteht entlang des Lebenszyklus

RFC 10020 spricht bewusst von einer „konfigurierenden Stelle“. Eine Anwendung, ein Benutzer, ein Entwickler, ein Cloud-Dienst, ein Inbetriebnahmewerkzeug oder eine andere Partei kann Gruppen erzeugen. Konfiguration geschieht bei der Softwareerstellung, im Werk, beim Händler, bei der Erstinstallation oder während einer späteren Neukonfiguration.

Das Dokument weist darauf hin, dass verschiedene Stellen diese Schritte mit wenig oder gar keiner Abstimmung ausführen können. Das Werk hinterlegt eine Sicherheitsidentität, der Integrator wählt Adresse und Port, der Cloud-Dienst bestimmt die Ressourcengruppe, und die Wartung ändert später nur eine der drei Ebenen. Abweichung ist dann kein Einzelfehler, sondern eine Eigenschaft getrennter Zuständigkeiten.

Gruppenpflege umfasst Hinzufügen und Entfernen von Mitgliedern, Wechsel des Sicherheitsmaterials, neue Multicast-Adressen oder UDP-Ports, geänderte Gruppen-URIs, Umbenennungen sowie Aufteilung und Zusammenführung. Ein Ticket mit dem Satz „Gerät aus Gruppe entfernt“ ist ohne Bezeichnung der Gruppe, der Epoche und der Abstimmung mit den anderen Verzeichnissen nicht prüffähig.

Sicherheitsgruppen haben zusätzlich einen Schlüsselzustand. OSCORE-Gruppen brauchen Rekeying für sichere Erneuerung und Sperrung. Bei hoher Fluktuation und langsamer Verteilung kann der Group Manager mehrere Änderungen vorsichtig bündeln. Die Folge muss sichtbar bleiben: Bis zum Abschluss kann ein ausgeschiedenes Mitglied auf Kommunikation mit altem Material zugreifen; je nach Richtlinie kann ein neues Mitglied frühere Kommunikation erreichen.

„Mitglied der Sicherheitsgruppe“ benötigt deshalb eine Epoche. Ohne Schlüsselversion, Austrittszeit und Abschlussgrad der Rotation erscheinen ein aktuelles Mitglied und ein noch nicht technisch gesperrter Abgänger gleich.

Schweigen ist kein negativer Ausführungsbeleg

Eine Gruppenanforderung wird per Multicast gesendet; die einzelnen Server antworten normalerweise per Unicast. Zur Vermeidung von Überlastung und Antwortimplosion sind Gruppenanforderungen Non-confirmable. Server verteilen ihre Antworten über ein zufälliges Leisure-Intervall. Auch NSTART und PROBING_RATE begrenzen den Verkehr.

Antworten können unterdrückt werden. RFC 10020 empfiehlt die Unterdrückung bei Fehlern oder wenn es nichts Nützliches zu antworten gibt, sofern nicht die Anwendungsrichtlinie für die Ressource eine Antwort verlangt. Die No-Response-Option soll dieses Verhalten nur bei Ressourcen beeinflussen, für die es zuvor als angemessen festgelegt wurde.

Schweigen kann daher Verlust der Anfrage, fehlende Ressourcenpassung, unterdrückte Ablehnung, noch laufendes Leisure, Verlust der Antwort oder Ausführung ohne Antwort bedeuten. Eine Wiederholung mit neuer Message ID kann Server, die das erste Exemplar bereits bearbeitet haben, zu einer zweiten Verarbeitung veranlassen. Antwortzahlen sind keine Wirkungszahlen.

An dieser Stelle wird Heng Lus Vorrang für laufenden Code praktisch. Konfiguration zeigt beabsichtigte Erreichbarkeit, Funktion und Sicherheitsmitgliedschaft. Beobachtung zeigt die tatsächliche Verarbeitung. Eine belastbare Kontrolle stellt beide nebeneinander, statt Planung als Ergebnis auszugeben.

Der Drei-Verzeichnis-Berechtigungsbeleg

Ein Drei-Verzeichnis-Berechtigungsbeleg kann die Kette erhalten. Sein erster Teil beschreibt die CoAP-Gruppe: Multicast-Adresse oder Hostname, UDP-Port, Adressbereich, hörende Endpunkte, Erkennungsquelle und Konfigurationsepoche. Der Sender wird gesondert aufgeführt, weil Any-Source Multicast keine Empfängermitgliedschaft verlangt.

Der zweite Teil beschreibt Anwendungsgruppe und Ressourcenentscheidung: URI-Pfad, Methode, Nutzlastklasse, erwartete Server, Richtlinienversion, geprüfte Ressourceneigenschaft oder Zugriffsberechtigung, Ergebnis und Ablauf. Eine gültige Signatur darf niemals als Ressourcenfreigabe eingetragen werden.

Der dritte Teil beschreibt die Sicherheitsgruppe: Group Manager, Gruppenkennung, Algorithmen, authentifizierter Sender, OSCORE-Epoche, Beitrittsnachweis, Austrittsstatus, letztes Rekeying und dessen Abschluss. Senderauthentifizierung und Netzwerkadressvalidierung bleiben getrennt. Wenn Erreichbarkeit am behaupteten Absender nötig ist, kann die Echo-Option aus RFC 9175 den authentifizierten Anforderer an dieser Adresse prüfen.

Der Ergebnisteil erfasst erwartete Empfänger, beobachtete Verarbeitung, Unterdrückungsrichtlinie, Leisure-Fenster, Antworten, bekannte Verluste, Wiederholungen und Nebenwirkungen. Schweigen bleibt ungeklärt und wird nicht in „nicht ausgeführt“ umgeschrieben. Jede Verzeichnisänderung verweist auf die ausführende Stelle und die anschließende Abstimmung der beiden anderen.

Dieser Beleg ist Daniel Kades redaktioneller Governance-Vorschlag, keine Forderung von RFC 10020. Er verhindert, dass gültige Adresse, vorhandene Ressource und aktueller Schlüssel in einer einzigen grünen, aber unerklärbaren Anzeige verschwinden.

Sicherheit begrenzt, beseitigt aber keine Verstärkung

NoSec wird in RFC 10020 dringend abgeraten. Ausnahmen bleiben auf enge, gut verstandene Schritte beschränkt, die keine Sicherheit benötigen oder noch nicht erreichen können, etwa bestimmte frühe Erkennungen. Ein NoSec-Gruppenserver darf nicht aus dem öffentlichen Internet erreichbar sein. Eine einzige Multicast-Anfrage mit gefälschter Quelladresse kann mehrere Antworten auf ein Opfer lenken.

Group OSCORE verkleinert diese Fläche, weil es den Sender authentifiziert und Pfad sowie Abfrage schützt. Antwortbegrenzung und Echo ergänzen die Abwehr. Sie beseitigen weder bösartige Gruppenmitglieder noch Angreifer auf dem Pfad oder den Multiplikator zulässiger Antworten.

Heng Lus Policy Mirror gibt dafür einen Maßstab: Die Oberfläche muss die wirkliche Verteilung von Kontrolle spiegeln. Adresse, Ressource, Group Manager, Autorisierung, Antwortverhalten und Beobachtung gehören verschiedenen Stellen. „Gruppe sicher“ sagt nicht, welche davon verantwortlich ist.

Der wirklichkeitsbezogene Ansatz von BTW Media führt zu präziserem Vertrauen. Die Adresse belegt ein konfiguriertes Ziel. Group OSCORE belegt eine Identität in einer Epoche. Autorisierung belegt den Ressourcenzugriff. Betriebsdaten belegen das Ergebnis. Erst die Trennung macht jede Aussage verantwortlich.

Quellen