Participant Relationship Protocol

Back to matrix

F05-RI: Yes

Rationale

The selected pairwise external-PSK DTLS profile can retain the native peer-admission policy already credited in F16-RI independently of its associations. Keep a record binding the opaque PSK identity to the intended peer/roles, secret, hash and an explicit allow/deny decision. RFC 8446 sections 4.2.11 and 6.2 distinguish binder verification from access control: even a valid PSK can be denied. Retain this record when discarding session traffic keys, then apply the same decision to a fresh handshake after reattachment through another authorized, reachable carrier. Admission is indexed by the provisioned peer context, not the old IP/port tuple. This is a documentary capability inference from native external-PSK and admission mechanisms, not from key stability alone.

Assessment method

Documentary native-policy composition; explicit retained authorization record and fresh-association boundary

Source context

TLS/DTLS external-PSK admission specifications and existing F16-RI policy witness

Outstanding qualification

Configure retained local admission records and distinct high-entropy keys per client/server pair with fixed roles; do not delete that policy on association teardown. RFC 9257 explicitly covers DTLS 1.3 and describes pairwise provisioning and stack PSK-selection interfaces. No tickets, early data, certificate fallback or application-login protocol is added. The later session uses fresh traffic secrets. Link access, neighbor discovery and routing must separately restore reachability. This does not establish seamless handover, automatic peer discovery, crash persistence or an executed full RPL/DTLS stack. No new runtime test occurred. The policy-retention condition is explicit, as for F05-HIP; the existing criterion and selected composition are unchanged.

Public sources

Editorial evidence references

The following identifiers refer to research records not included in this public package; they are not public links.