Security: Add threat model for OCM - #398
Conversation
During discussion at IETF126 it became clear that being explicit about the threat model for OCM would be useful for implementers and reviewers alike. This patch introduces a threat model secion in each of the OCM documents, as well as a new paragraph that calls out to the security section of load bearing RFCs that OCM leans on.
|
I have been using lots of perplexity.ai to search for CVE and contexts for this 😄 It's a nice thing. Will post my review soon. |
|
This is very welcome, and definitely in the direction of IETF Drafts. I read a bit of RFC 3552 and I can see we could even include some kind of |
Oh, that is very nice, I had missed that RFC. Maybe we should even link to it? |
Make it explicit that the Sending and Recieving OCM server as well abortsprotocol servers are part of the trusted comput environment and that the threat model assumes that the OCM server is not compromised. The network, is untrusted as is other OCM servers on the network
I edited the threat model with RFC 3552 in mind, in another separate commit. I am in favor of adding a tabulation of risks, mitigations and residual risks btw. |
glpatcern
left a comment
glpatcern
left a comment
There was a problem hiding this comment.
I think this is already good, further improvements could be done once we go for a full security review. Just a couple of nits (but I must say I skimmed through the MLS I-D as that one is yet to be fully reviewed)
| authenticated introspection provide the protections described in this | ||
| specification against such an attacker. | ||
|
|
||
| An attacker may operate an OCM Server or Protocol Server of its own, |
There was a problem hiding this comment.
| An attacker may operate an OCM Server or Protocol Server of its own, | |
| An attacker may operate an OCM Server or Protocol Server of their own, |
| An attacker may operate an OCM Server of its own, control a remote user, | ||
| send malformed or deceptive protocol messages, or steal bearer |
There was a problem hiding this comment.
| An attacker may operate an OCM Server of its own, control a remote user, | |
| send malformed or deceptive protocol messages, or steal bearer | |
| An attacker may operate an OCM Server of their own, control a remote | |
| user, send malformed or deceptive protocol messages, or steal bearer |
| assertions under its own identity, but must not thereby gain authority | ||
| for users or Resources outside its administrative domain. | ||
| Implementations are expected to authenticate peers where required, | ||
| enforce local authorization policy, validate protocol inputs, and |
There was a problem hiding this comment.
| enforce local authorization policy, validate protocol inputs, and | |
| enforce local authorization policies, validate protocol inputs, and |
3 participants
During discussion at IETF 126 it became clear that being explicit about the threat model for OCM would be useful for implementers and reviewers alike. This patch introduces a threat model section in each of the OCM documents, as well as a new paragraph that calls out to the security section of load bearing RFCs that OCM leans on.