Differences

This shows you the differences between two versions of the page.

--- mtrp:security [2026/06/10 12:54] – created mosh
+++ mtrp:security [2026/06/10 13:36] (current) – mosh
@@ Line 1: / Line 1: @@
-====== Security ======
+====== 9. Security Model ======
-MTRP security is designed to be practical for small embedded devices while leaving room for stronger profiles on more capable nodes.
+===== 9.1 Purpose =====
-===== Current Direction =====
+This document defines the current security posture and intended security boundaries of MTRP.
-MTRP distinguishes between:
+===== 9.2 Design Intent =====
-  * routing and transport behavior
+MTRP is intended to operate across a range of node classes, from constrained devices to more capable bridge or core nodes.
-  * security capability and trust behavior
-This allows different transports and device classes to participate at different security levels.
+The security model therefore distinguishes between:
-===== Security Capabilities =====
+  * protocol participation
+  * transport capability
+  * security capability
+  * trust policy
-Security capability values describe what a node or transport can support.
+===== 9.3 Security Capabilities =====
+Security capability values indicate the forms of security a node or transport may support.
 Examples include:
@@ Line 22: / Line 26: @@
   * ''AES256''
-===== Current Philosophy =====
+Capability signaling does not, by itself, guarantee that a given message was validated under that capability. It describes support and configuration context.
+===== 9.4 Network Separation =====
+The network identifier remains useful even in secure deployments.
+A receiver SHOULD use the network identifier as an initial discriminator for intentional protocol traffic before more expensive processing is performed.
+The network identifier is not, by itself, a security mechanism.
-For constrained devices, even basic security and message authenticity are better than none.
+===== 9.5 Constrained Security =====
-For more capable nodes, stronger validation and key handling can be layered in later.
+For constrained nodes, a reduced but practical security posture MAY be preferable to no security at all.
-===== Network ID =====
+Constrained security behavior SHOULD favor:
-The network ID is still useful even in secure deployments.
+  * compact validation logic
+  * bounded memory impact
+  * compatibility with bridge-assisted architectures
-It helps separate intentional protocol traffic from unrelated local radio traffic before deeper validation is performed.
+===== 9.6 Trust Boundaries =====
-===== Current Limitations =====
+MTRP currently assumes relatively simple trust behavior.
-MTRP does not currently provide:
+The current implementation does not fully define:
-  * full end-to-end authenticated delivery
+  * authenticated neighbor admission
-  * group-message security semantics
   * key exchange
-  * replay-hardening beyond local duplicate suppression
+  * replay-resistant secure sessions
-  * fully specified secure ACK behavior
+  * complete end-to-end trust validation
+  * secure group-delivery semantics
-===== Future Direction =====
+===== 9.7 Future Direction =====
-Likely future areas include:
+Likely future security work includes:
-  * trusted-neighbor validation
+  * stronger trusted-neighbor validation
-  * per-transport security policy
+  * transport-specific security policy
-  * constrained-profile secure frames
+  * constrained-profile secure framing
   * bridge-assisted security for limited radios
+  * reliable secure unicast behavior