Expand description
GUID-zu-Identity-Bindings-Cache (C3.8).
Spec DDS-Security 1.2 §7.4.3 (Identity-Cert-Bind), §9.3.1 + §10.3.4:
ein boeswilliger Peer kann eine fremde GUID schadhaft “squatting”
versuchen, indem er SPDP-Beacons mit gleicher GuidPrefix aber
abweichendem IdentityToken sendet. Ohne Bindings-Tracking wuerde
der Peer-Cache den Squatter genauso behandeln wie den legitimen
Original-Peer und im SEDP-Match-Verfahren beginnt eine Confusion-
Phase, die ein DoS-/Cred-Exfil-Vektor ist.
Der IdentityBindingCache hier merkt sich pro GuidPrefix den
Hash des erstmals gesehenen IdentityToken. Bei nachfolgenden
Announces mit gleicher GuidPrefix wird der Hash neu berechnet und
verglichen — Mismatch fuehrt zur Ablehnung.
§Was hier nicht gemacht wird
- Identity-zu-GUID-Ableitung: Spec §9.3.1.1 erlaubt eine deterministische Bindung GuidPrefix = Hash(Cert-Public-Key). Das ist eine staerkere Garantie, kommt aber erst mit dem vollen PKI- Handshake-Pfad (C3.1).
- Time-bounded Re-Binding: ein Peer der seine Identity-Cert rotiert (OCSP-revoked → neues Cert) braucht ein Re-Binding-Path. Aktuell muss er aus dem Cache evicted werden, dann re-discovered wird er mit der neuen Bindung akzeptiert. Optionale Spec-Sektion §10.3.3.2 OCSP — kommt mit C3.9.
Structs§
- Identity
Binding Cache - Cache der ersten beobachteten Identity-Bindung pro
GuidPrefix.
Enums§
- Binding
Decision - Bewertung eines neuen IdentityToken-Announces durch den Cache.
Type Aliases§
- Guid
Prefix Bytes - 12-byte
GuidPrefixaus DDSI-RTPS (Wire-Layout).