Zusammenfassung

  • Fassung 25 des GAAP-Entwurfs der PIM-Arbeitsgruppe nennt Abschnitt 5 nun „Illustrative GAAP API“ und stellt klar: GAAP ist ein Protokoll, weder Bibliothek noch Python-API. Die pseudopythonischen Aufrufe sind ein Integrationsbeispiel; auch andere Schnittstellen oder gar keine sind möglich, sofern das Claim-Protokoll auf der Leitung eingehalten wird. Schon Fassung 24 bezeichnete das Beispiel als nicht normativ.
  • Außerdem präzisiert die Fassung die vier wirklichen Felder eines Claim und begründet ausführlicher, weshalb ChaCha20 ohne Nachrichtenauthentisierung manipulierbar ist. Daraus folgen weder ein neues Nachrichtenformat noch ein erstmals ausgesprochenes Verbot oder ein belegter Angriff.

Bei dezentraler Vergabe von Multicast-Gruppenadressen ist nicht entscheidend, ob zwei Programme dieselbe Funktion aufrufen. Entscheidend ist, ob ihre Teilnehmer dieselben Claims austauschen und verstehen. GAAP will die Zuteilung ohne einen einzelnen Vergabeserver ermöglichen. Der Entwurf enthält dafür ein Python-artiges Beispiel. In der am 25. September veröffentlichten Fassung 25 wird deutlich ausgesprochen, dass dieses Beispiel keine gemeinsame Programmierschnittstelle festlegt. Der Protokollvertrag betrifft den Austausch auf der Leitung.

Der Befund verdient eine genaue Zeitform. Bereits Fassung 24 erklärte die API-Skizze für illustrativ und nicht normativ. Es wurde also keine bisher verpflichtende Python-Bindung abgeschafft. Neu ist die kategorische Klarstellung, GAAP sei keine Bibliothek und keine Python-API. Implementierungen dürfen ihre lokale Anbindung selbst bestimmen oder ganz ohne Programmierschnittstelle auskommen, solange das Claim-Protokoll beachtet wird. Ein eingebettetes Modul oder ein separater Dienst wären denkbare Architekturen, keine hier nachgewiesenen Produkte.

Auch beim Datensatz selbst zieht der Text eine präzisere Linie. Ein Claim enthält eine IPv4-Multicast-Gruppenadresse, eine IPv6-Multicast-Gruppenadresse, einen Zeitstempel und einen Gruppennamen. Die nachfolgenden Absätze beschreiben Benutzung, Vergleich und Auswertung dieser Felder; sie erweitern den Datensatz nicht. Wer die Gliederung mit der Paketstruktur verwechselt, könnte fälschlich ein fünftes Feld oder eine Änderung der Feldreihenfolge annehmen. Die Gegenüberstellung mit Fassung 24 belegt das nicht. Die neue Passage verbessert die Lesbarkeit der Spezifikation, nicht die Beweislage für eine bereits erzielte Interoperabilität.

Die Sicherheitsänderung erklärt ein bekanntes Verbot genauer. Fassung 24 sagte bereits, dass ChaCha20 ohne Message Authentication Code die Integritätsanforderung nicht erfüllt und nicht allein eingesetzt werden darf. Fassung 25 führt die Manipulierbarkeit eines Stromchiffretexts ohne authentisierte Integrität aus: Ein Angreifer auf dem Übertragungsweg könnte Bits verändern und beim Empfänger eine andere Gruppenadresse, einen anderen Zeitstempel oder einen anderen Namen entschlüsseln lassen, ohne dass die Änderung auffällt. Der Entwurf warnt, trügerische Sicherheit könne gefährlicher sein als ein offen unverschlüsselter Basismodus.

Das ist eine Beschreibung eines möglichen Mechanismus, keine Meldung über eine beobachtete Attacke oder eine bekannte GAAP-Installation.

Das gemeinsame Muster liegt im Unterschied zwischen einer Eigenschaft und ihrem Etikett. Eine Methode mit passendem Python-Namen sagt nichts darüber aus, ob ein anderer Teilnehmer den Claim verstehen kann. Verschlüsselung allein sagt nichts darüber aus, ob der Claim unverändert geblieben ist. Für beide Fragen benötigt man andere, beobachtbare Nachweise. Daraus lässt sich redaktionell ein schmaler gemeinsamer Standard und eine offene lokale Implementierung ableiten; ein IETF-Zertifizierungsverfahren ist das nicht.

Der Datatracker führt Fassung 25 weiterhin als Internet-Draft der PIM-Arbeitsgruppe in IESG Evaluation mit AD Followup und angestrebtem Experimental-Status. Ein RFC ist sie nicht. BTW behandelte zuvor GAAP-23 unter dem Gesichtspunkt fester Adressbereiche und der Konvergenz gleichnamiger Claims nach Netzpartitionen. Fassung 25 löst dieses frühere Problem nicht nachweislich. Die hier berichtete Neuigkeit ist die ausdrückliche Grenzziehung zwischen Austauschregel, Codebeispiel und Integritätsnachweis.

Quellen