# mTLS proves the NF at the handshake. It says nothing about the DNS, the route, or the log. Your SBA is mutually-authenticated and your NRF issues OAuth2 tokens — inside one operator, that binds tightly. But NF discovery still *addresses* over DNS, OAuth2 authorization at the NRF is *optional by spec*, and every cert chain terminates at your *private* CA — unverifiable to a roaming partner, an IPX, or a regulator. Spoof the DNS to a rogue NRF, forge an issuer URL, or speak as an NF you pulled from the NRF, and no counterparty can tell. The identity is real; the anchor is invisible outside your walls. **We give the NF a public anchor.** A routable, DNSSEC-signed /128 derived from the NF's own SBI key and named by the `urn:uuid:` it already carries, DANE-pinned to the very cert it presents — verifiable by anyone with `dig`, and revocable worldwide in one call. Prove the NF at the DNS, the route and the log — and close the rogue-NRF gap 33.501 leaves open. `whisper verify --trustless` — anchored at the IANA DNS root. Our own API is not in the trust path. **Proof pills.** OAuth2 authorization at the 5G NRF is optional by spec (TS 33.501 §13) — reachability ≈ authorization · $38.95B telecom fraud in 2023 (≈2.5% of revenue), $6.23B of it IRSF riding interconnect trust (CFCA) · ~70% of operators still lack the cloud-native capability SEPP needs (Heavy Reading, 2025) · the Splunk, Microsoft Sentinel & OpenCTI SIEM connectors ship today · fail-open, anchored at the IANA root, never in your SBI's critical path · on-prem — the graph & per-/128 logs stay in your jurisdiction, NIS2-ready. ## Which desk is this? Four ways in, one primitive underneath all of them. Whichever chair you sit in, the ask is the same at the network layer: a publicly verifiable identity for the thing on the wire, durable attribution when the egress rotates, and a kill-switch that crosses operator boundaries. Here is how it reads from each desk. ### A · MNO security architecture / core-NF SOC — you run the SBA and you carry the incident Vocabulary: NF · SBI · NRF · SEPP · N32 · mTLS · OAuth2 token · SCAS · lateral movement · fail-open · attribution. **Trigger:** NIS2 enforcement, a core-security incident, or a 5G SA rollout. **Lead:** mTLS proves the NF at the handshake; we prove it at the DNS, the route and the log — plus a one-call kill-switch. Close the DNS-spoofing / rogue-NRF gap 33.501 leaves open, and turn every on-wire action into signed, replayable attribution for the report. ### B · Private-5G / enterprise / neutral-host — you want zero-trust without a carrier PKI Vocabulary: private 5G · CBRS · zero trust · microsegmentation · workload identity · SASE · egress control. **Trigger:** a campus / neutral-host build, a customer security questionnaire, OT segmentation, or CRA on procured gear. **Lead:** per-NF identity and egress governance *without* running an operator CA — one call to provision, one to revoke. Zero-trust the way your IT team already thinks: default-deny per workload, addressed by name. ### C · 5G-core / NF-vendor PSIRT — you are scored in the operator's RFP Vocabulary: SCAS · NESAS · TS 33.117 / 33.51x · secure-by-design · SBOM · PSIRT · CVD. **Trigger:** a NESAS cert cycle, an operator RFP that scores security, a CRA deadline, or a CVE. **Lead (honestly — this is *not* a NESAS shortcut):** an RFP-differentiating verifiable-identity + attribution feature *beyond* the certified SCAS baseline. Cryptographic PSIRT attribution to the exact NF instance, and support for the CRA identity/access + logging you already build. ### D · Roaming / interconnect security — your security is your weakest roaming partner Vocabulary: SEPP · N32-c / N32-f · PRINS · IPX / GRX · HPMN / VPMN · PLMN · FS.36. **Trigger:** a 5G SA roaming launch, an interconnect fraud/spoofing incident, GSMA conformance, or a new IPX peering. **Lead:** verifiable, DANE-pinned peer identity at the N32 border — harden the N32-c spoofing FS.36 names, attribute which PLMN/SEPP an event came from, and revoke a compromised interconnect identity in one call instead of a slow, manual de-peer. Different triggers, different vocabulary — but every one of them lands on the same four claims, and each of those claims survives a hostile review. ## We only make claims a red-teamer and an auditor both let stand. Not a wall of framework logos — four claims, each traced to a named clause, each hardening a boundary the 5G stack leaves soft. Every one of them is **additive** to your mandated mTLS + OAuth2 and your operator PKI. If a claim didn't survive review, it isn't here. ### Claim 1 · the strongest — the DNS under discovery is unsigned 3GPP binds the NF's identity into the certificate — TS 33.310 §6.1.3c mandates a SAN `URI-ID = urn:uuid:`. But NF *discovery* and addressing ride ordinary DNS, and 3GPP mandates mTLS + OAuth2 without mandating DNSSEC/DANE on that name layer. Spoof the resolution and you redirect an NF to a *rogue NRF*, or forge a token-issuer URL, and every downstream check passes. **What we add.** A DNSSEC-signed zone for your NF/NRF names plus a DANE-EE (TLSA `3 1 1`) pin on the same certificate the NF already presents. That is a cryptographic, hijack-resistant *name → address → expected-cert* binding that mTLS alone does not cover — the least-contestable claim we make. Maps to TS 33.501 §13 · TS 33.310 §6.1.3c · strength ●●●. > "3GPP already mandates mutual TLS on the SBI. Why isn't the cert enough?" Because the cert is signed by your private CA and addressed over unsigned DNS. mTLS proves two endpoints negotiated a key; it says nothing about whether the *name you resolved* is the NF you meant, and no roaming partner or regulator can chain your CA to a public anchor. We DANE-pin the exact cert the NF presents into the DNSSEC root — the binding becomes hijack-resistant *and* third-party verifiable, with your mTLS untouched underneath. ### Claim 2 · attribution for incident handling & reporting When an NF misbehaves — or a rogue one speaks on your SBI — the clock starts: NIS2 Article 23 wants an early warning in 24 hours, a notification in 72, a final report in a month. But the attacker's egress rotates across clouds and a small IPX, so all your SOC has logged is a meaningless *last IP*. **What we add.** A live internet-infrastructure graph, 7.44B nodes and 39.3B relationships of fused BGP, DNS, WHOIS, TLS, hosting and threat intelligence, answering in under 300 ms, that fingerprints the *operator*, not the IP: shared ASN/hosting/certificate lineage collapses the cloud rotation, and a `JA4/JA3` client fingerprint travels with the tooling to collapse a hosted swarm. Every answer is a reproducible, replayable evidence chain, and each NF's own SBI activity is logged against its /128, ready-made SCAS TS 33.117 log material and NIS2 forensics. Maps to NIS2 Art.21(2)(b) & Art.23 · SCAS TS 33.117 · strength ●●●. ### Claim 3 · anti-lateral-movement micro-segmentation The flat, all-IP, HTTP/2 SBA mesh inherits the whole web/API threat model. OAuth2 authorization at the NRF is optional by spec, so in too many cores *reachability approximates authorization*: any NF that can reach the NRF can enumerate every NF, pull a profile, and move laterally. **What we add.** A per-NF /128 micro-perimeter with default-deny egress governance — `op:firewall` allow/deny by host, CIDR or port; `op:budget` caps a compromised NF's traffic; `op:revoke` cuts it off worldwide. An NF talks only to the names it should, and a foothold on one NF does not become a foothold on the mesh. Maps to NSA/CISA ESF 5G Cloud Pt II–III · CISA ZTMM Identity pillar · NIST 800-207 · strength ●●●. ### Claim 4 · verifiable peer identity at the N32 border Every inter-PLMN message crosses N32 between two SEPPs, and trust is transitive and opaque: through the peer's SEPP, and — with PRINS — through semi-trusted IPX hubs that can read and modify whitelisted JSON. The originating NF deep in the peer network is not independently verifiable by the home operator. It is the weakest point of the modern stack. **What we add.** A DNSSEC/DANE-anchored identity per NF and per SEPP lets the *home* operator verify a peer against a public anchor — "verify the address + the DANE pin" instead of "trust the SEPP's assertion" — independent of the peer's private CA and any IPX, hardening the N32-c spoofing vector GSMA FS.36 names. Revoke a compromised interconnect identity in one call. Maps to GSMA FS.36 · TS 29.573 (N32) · strength ●●○. > "IEEE-grade PKI already runs the SBA. What can a DNS layer possibly add at the roaming border?" A verification you can do without the peer's CA. Cross-operator trust today means bilaterally cross-certifying every MNO's private root — an N² PKI exchange, mediated by IPX. A DANE pin anchored in the public DNSSEC root collapses that to a resolve-and-check: the home operator confirms the peer NF's address maps to the expected key with no cross-certification, and a revoke propagates at cache-TTL rather than one CRL per operator. Four claims, one address. Below the boundary these ride, the derivation is the cure — here is how a name you already have becomes a name anyone can verify. ## The address *is* the NF — derived from the key it already holds. Every 5G NF registers a NFProfile with the NRF (TS 29.510): an `nfInstanceId` (a UUID), an `nfType`, and at least one of `fqdn` / `ipv4Addresses` / `ipv6Addresses`. A resolvable identity already exists — it is just trapped in your private NRF and private PKI. Derive a routable IPv6 /128 out of `2a04:2a01::/32` (announced by AS219419) from the NF's *existing* SBI key, with the `nfInstanceId` as the domain separator (pass it as `device_id`). The private key never leaves the NF; the address is a one-way function of its public half and that UUID. Drop the /128 straight into `NFProfile.ipv6Addresses` — **no NRF API change** — sign the `ip6.arpa` reverse zone, and pin the same certificate the NF already presents with DANE-EE. The operator-private identity becomes globally, third-party verifiable: a roaming partner or a regulator resolves the /128, pulls the DANE pin, and confirms "this address is NF X" *without your CA*. Revoke = pull the signed record. **Diagram — the socket → /128 bind.** The NF's existing SBI key (SAN `urn:uuid:`, already in the cert; private key never leaves the NF) → its public SPKI + `nfInstanceId` derive a /128 (`2a04:2a01:5e0::a3f`) that drops into `NFProfile.ipv6Addresses` with no NRF API change → DNSSEC + DANE-EE make it a name anyone can verify (`whisper verify --trustless`; a roaming partner or regulator confirms it without your CA) → `op:revoke` removes it worldwide at DNS-TTL. **Shipped & live today.** Derive a /128 from your NF's public key with its `nfInstanceId` passed as `device_id` — deterministic (same key + id → the same /128), tenant-bound and fleet-unlinkable (the same key under two tenants yields two unrelated /128s, so no one can correlate an NF across operators), enumeration-resistant (the `nfInstanceId` alone yields nothing without the key), and revocable at DNS-TTL. A first-class typed `--nf-instance-id` argument is on the roadmap; the generic `device_id` door is live now. **It attaches to what you already ship — it does not replace it.** Whisper is the publicly verifiable, DNSSEC/DANE-anchored layer *on top* of the anchors you already trust — your operator CA and CMPv2 enrolment, the SBA cert profile, OAuth2 at the NRF, the SEPP at the border. No bespoke trust store to push to every NF, and a cross-operator revoke at DNS-TTL instead of a CRL that never crosses the boundary. You can even DANE-pin the cert your NRF and SEPP already present to cut single-CA trust risk at the boundary. ## Verify the peer at N32. See who's mapping your core. Prove nothing was issued in the dark. An identity you can prove is also an identity you can *watch* and *govern*. Because every NF's name resolves through Whisper's own authoritative DNS and RDAP, and every mint and revoke lands in a public log, three surfaces open that a private NRF never gave you. **Diagram — the N32 border.** Inter-PLMN traffic crosses N32: peer NF (VPMN) → peer SEPP (topology hiding) → IPX hub (PRINS reads JSON) → home SEPP (HPMN border). Under trust-by-assertion the home operator must trust that chain transitively. With Whisper, the home SEPP instead resolves the peer NF's /128 and checks its DANE pin against the public DNSSEC root — confirming "this address is NF X" independent of the peer's private CA and the IPX, with a one-call revoke. - **Who checked this NF is a query.** `op:lookups` returns who resolved or RDAP-queried an NF's identity — an early warning that someone is *mapping your core* before the impersonation, the rogue-NRF reconnaissance tripwire a private NRF never surfaced. Shipped. - **Govern what each NF may reach.** A graph-first resolver and source-bound egress enforce default-deny per NF — `op:firewall` by host/CIDR/port, `op:budget` to cap it, `op:revoke` to cut it off worldwide. The per-NF micro-perimeter of Claim 3, as a control plane. Shipped. - **Nothing issued in the dark.** Every identity mint and every revoke lands in a public, append-only RFC 6962 Merkle log, Ed25519-signed and anchored to Bitcoin via OpenTimestamps — an auditable NIS2 issuance trail. Honest status: tamper-evident today, independent witnessing is the next step. The same address-is-identity primitive that governs a compromised NF also governs the AI agents your NOC and OSS/BSS are about to run — per-agent /128, per-agent logs, default-deny egress, one `revoke`. From day one. ## We DANE-pin. We never replace. This is a second, independent, DNS-anchored layer — strongest at the *trust boundaries* (NF discovery/DNS, N32/roaming, NEF exposure, management), not deep intra-SBI where mTLS and the NRF already bind tightly. Everything below stays yours; we harden the name and the route beneath it. - **3GPP mTLS + OAuth2 / NRF** — mandatory and primary. We do not touch the handshake or the token exchange; we pin the cert the NF already presents into DNSSEC, and harden the DNS under NF/NRF discovery so a token can't be redirected to a spoofed issuer. - **Operator PKI + SEPP** — your CA, CMPv2 enrolment and N32/PRINS topology-hiding keep running. We add a *public* anchor for the same identity so a peer or a regulator can verify it without cross-certifying your private root. - **EU 5G Toolbox TM02 · ENISA controls** — TM02 is "turn on optional security controls." A DANE-pinned NF resolution *is* a TM02 move — a concrete control you can point at, with TM03/TM04 supported alongside. - **EU CRA · O-RAN WG11 ZTA** — for a vendor, we support the CRA Annex I identity/access + logging you already build (not a conformity route). For O-RAN, a vendor-neutral public /128 per NF serves the WG11 Zero-Trust *Identity* pillar without every supplier chaining to one private CA. **Availability-safe — fail-open by construction.** If your discovery or border check consults the DANE/verify path, that plane is built to fail open: a Whisper outage never drops an NF's SBI traffic — the check degrades to the anchors you already ship, and connectivity is preserved. Anycast on AS219419, no single node in the path, no chatty third-party call on the hot path. Conservative in what we emit, liberal in what we accept — an NF is *never* denied because we were unreachable. ## Every capability lands on a clause — and produces an artifact you can file. All additive to your mandated 3GPP mTLS + OAuth2, your operator PKI, and your SEPP. Strength is stated honestly: ●●● a claim that survives a hostile review, ●●○ a solid defense-in-depth fit, ●○○ visibility only. | Defensible claim | Standard / clause | Evidence artifact | Strength | |---|---|---|---| | Close the DNS-spoofing / rogue-NRF / forged-issuer gap | 3GPP TS 33.501 §13 · TS 33.310 §6.1.3c (SAN `urn:uuid`) | DNSSEC-signed NF/NRF zone · DANE-EE `3 1 1` pin on the presented cert | ●●● | | Attribution for incident handling & reporting | EU NIS2 Art.21(2)(b) & Art.23 (24h/72h/1-mo) · SCAS TS 33.117 logging | Reproducible, replayable evidence chain · per-/128 SBI logs | ●●● | | Anti-lateral-movement micro-segmentation | NSA/CISA ESF 5G Cloud Pt II–III · CISA ZTMM Identity · NIST 800-207 | Per-NF /128 micro-perimeter · default-deny egress policy | ●●● | | Verifiable peer identity at the N32 border | GSMA FS.36 · TS 29.573 (N32-c/N32-f) | DANE-pinned peer/SEPP identity · one-call revoke | ●●○ | | Project the NF cert identity into routing / reverse-DNS / RDAP | TS 33.310 (nfInstanceId ↔ key ↔ endpoint) | /128 from the NF's existing key · RDAP object · `ip6.arpa` | ●●○ | | Turn on an optional 5G security control | EU 5G Toolbox TM02 (ENISA) · TM03/TM04 | DANE-pinned NF resolution — a concrete TM02 control | ●●○ | | Continuously-authenticated identity + fast revoke | CISA ZTMM Identity/Visibility · NIS2 21(2)(j) | DANE-verifiable identity · DNS-TTL revoke log | ●●○ | | Embeddable identity/access + logging feature (vendors) | EU CRA Annex I — identity/access, logging | Supports what you already build — **not a conformity route** | ●●○ | | Inventory which vendors are live on the wire | FCC Covered List (context only) | Attribution feed — **not a supply-chain / removal mapping** | ●○○ | Findings map onto CEF and ECS fields today; STIX 2.1 over TAXII and per-sector machine-readable export are on the roadmap. The Splunk, Microsoft Sentinel and OpenCTI connectors ship today. **Diagram — three planes into your stack.** Identity (NF /128 · DNSSEC · DANE-EE · bound to the nfInstanceId — who is this, provably), Attribution graph (operator fingerprint across rotating cloud + IPX egress — who's really behind this; 7.44B nodes · BGP·DNS·TLS·JA4), and Egress governance (per-NF /128 · policy · lookups · firewall · budget · revoke — what may talk to what) all rest on one primitive — THE ADDRESS IS THE NF (AS219419 · `2a04:2a01::/32`) — and exit into your SIEM (Splunk & Sentinel today), machine-readable formats (CEF / ECS today · STIX/TAXII roadmap), and your standards (33.501 · NIS2 · ESF · FS.36). It rides your DNS and IPv6 and adds no inline SBI chokepoint. ## The honest boundary — stated plainly, because a telecom buyer checks. Overclaiming loses the room. Here is exactly where Whisper stops, so the four claims above are trusted precisely because these five are ruled out. - **Not a NESAS / SCAS shortcut.** DANE/DNSSEC on the SBA is *not* a certification control and will not help you pass SCAS or a NESAS audit. The value is a defense-in-depth differentiator and a PSIRT attribution tool — beyond the certified baseline, never a substitute for it. - **Nothing for FCC rip-and-replace.** The Covered List is supply-chain provenance and removal — a different class. Attribution can inventory which vendors are live on the wire, but that is visibility, not a compliance mapping, and never assurance about a vendor's supply chain. - **Never replaces mTLS or OAuth2 / NRF.** Those are mandatory and primary. This is a second, independent, DNS-anchored layer that hardens the name→address→cert binding underneath them — strongest at trust boundaries, not deep intra-SBI where the NRF already binds tightly. We do not touch the handshake. - **Revocation is at the identity / network layer.** One call tears down the /128 + PTR + DANE pin + egress authorization worldwide at DNS-TTL — *faster* than a cross-operator CRL/OCSP — but it does **not** revoke the operator's TLS certificate; that stays your CA's job. It is an *additional* kill-switch, not a replacement. And an identity layer alone does not stop everything. Router/edge implants, stolen management credentials, and nation-state persistence *below* the identity layer are not stopped by verifiable identity — the class of interconnect intrusion publicly reported to have reached lawful-intercept systems across dozens of carriers is cited here only to show that cross-operator *attribution and eviction* remain unsolved, never as something we claim we would have prevented. That honesty is the point: we bite the impersonation and the unattributed-persistence stages hardest, and we say so. ## Prove it in 60 seconds — our API isn't in the trust path. Two tiers, by design. **No key:** anyone on your team can verify an NF's identity, resolve it, and back-trace a suspicious NRF — trustless, anchored at the IANA root. **Your key:** bind an NF to the `nfInstanceId` it carries, see who's mapping your core, govern its egress, and revoke it worldwide. ```bash # keyless — re-derive and verify any NF's identity, trustless $ whisper verify --trustless 2a04:2a01:5e0::a3f ✓ DNSSEC chain valid to the IANA root ✓ DANE-EE (TLSA 3 1 1) leaf matches the NF's SBI certificate ✓ RDAP: registered under AS219419 · 2a04:2a01::/32 identity: VERIFIED — same urn:uuid:, no operator CA needed # the address is the NF — reverse DNS names it $ dig -x 2a04:2a01:5e0::a3f +short amf01.nf.mnc015.mcc234.5gc.example-mno.whisper.online. # who really operates a suspicious NRF/host — the graph API, a CALL whisper.identify() $ curl -s https://graph.whisper.security/api/query -H "X-API-Key: whisper_live_xxx" \ -H 'content-type: application/json' -d '{"query":"CALL whisper.identify(\"203.0.113.7\")"}' operator: · seen across AWS / GCP / a small IPX hosted rotation collapsed by JA4: same tooling, 37 exit IPs → 1 operator ``` ```bash # bind an NF to the instance id it already carries — device_id = nfInstanceId $ export WHISPER_API_KEY=whisper_live_xxx $ curl -s https://graph.whisper.security/api/query -H "X-API-Key: $WHISPER_API_KEY" --data-urlencode "q=CALL whisper.agents({op:'connect', args:{tier:'wireguard', identity_public_key:'', device_id:'3f2504e0-4f89-11d3-9a0c-0305e82c3301'}})" # device_id = nfInstanceId → identity 2a04:2a01:5e0::a3f DNSSEC + DANE live · drop into NFProfile.ipv6Addresses $ whisper logs 2a04:2a01:5e0::a3f # this NF's own SBI egress, per-/128 $ curl -s https://whisper.online/ip/2a04:2a01:5e0::a3f/lookups # who's mapping your core — recon tripwire $ whisper policy set --default deny --allow nrf.5gc.example-mno.com,udm.5gc.example-mno.com $ whisper kill --revoke 2a04:2a01:5e0::a3f # worldwide, at DNS-TTL — the federated kill-switch ``` ## Four defensible claims. Mapped to your standards. Additive to your stack. Prove the NF at the DNS, the route and the log; attribute the operator when the egress rotates; micro-segment the mesh; verify the peer at N32 — additive to your mTLS/OAuth2 and operator PKI, fail-open in your path, mapped to 33.501 / NIS2 / the CISA ESF / GSMA FS.36. Keyless to try, one call to provision, one more to revoke. Or run `whisper verify --trustless` right now. --- Identity on the wire for 5G core network functions. AS219419 · `2a04:2a01::/32`. © viaGraph B.V. (dba Whisper Security).