Require Mutual Authentication (HTTPS-26)

[sparrell]

Section 3.2.3 states
When deployed in an operational environment, OpenC2 endpoints MUST support basic authentication and SHOULD support mutual authentication.
I the the SHOULD should be a SHALL. I say should be because I won't vote no based on this but I do not know of documented use cases where a security device would accept commands from an unauthenticated openc2 command producer. Ie if the openc2 consumer is the server (preferred configuration) I believe it MUST authenticate the openc2 producer. If someone documents a use case where they can demonstrate the risks are worth saving the cost of mutual authentication, then I will stop bringing this up. But if we do leave it as SHOULD, then I think we need more words pointing out the security risks of not being mutually authenticated.

[dlemire60]

This was discussed extensively at the October 2018 face-to-face; relevant notes are here. Consensus of the group was to retain SHOULD language in the requirements text and define conformance targets at levels of security (TBD as of this writing). The requirements language in 3.2.3 was also tuned somewhat in a group editing session.

There was also consensus that the IC-SC should return to the IA Considerations document and prepare that for publication as an OASIS Committee Note.

[jmbrule]

Bottom line on the proposed change: do not agree with it. In the context of the importance of mutual authentication, agreed however it is not the specs place to make risk management decisions and if one acknowledges that authentication is a derived tenet, then it follows that (depending on the implementation) can be achieved by other means.

[sparrell]

I have resisted closing this issue because I had a conflict with the meeting where it was discussed. I still favor mutual authentication (ie actuator trusts the command producer and command producer trusts the actuator) over the proposed language where the actuator is conformant when accepting commands from an untrusted (since unauthenticated) command producer. Wrt @jmbrule comment about deriving authentication from somewhere else - then I believe that is still a 'mutually authenticated' communication. I just want them mutually authenticated, not that it has to be done a certain way (which is my other issue #6). I did not bring this up as a ballot comment since this issue already existed. The suggestion to deal with it in conformance requirements may be sufficient if we are clear on the consequences of accepting security control commands from an untrusted source.

[dlemire60]

This has been re-raised as a PR01 comment and will be addressed as such.

https://lists.oasis-open.org/archives/openc2/201812/msg00058.html

[dlemire60]

This was discussed at the 19 Dec 2018 IC-SC meeting (attendees were Lemire, Brule, Considine, Kemp, Martinez, Sparrell). Consensus of the meeting was supportive of requiring mutual authentication, without presently specifying particular authentication mechanisms:

• OpenC2 is building a security C2 system, and not having all parties in an OpenC2 interaction be confident of distant element identities is "bad security architecture"
• There are a variety of old (e.g., X.509) and new (e.g., CSA SPA) authentication mechanisms available to draw on.
• Experience in vendor interactions (e.g., at an IoT conference) has generally been that vendors are amenable to building appropriate security mechanisms once the need is explained.

[dlemire60]

Duncan's original proposal was to change SHOULD to SHALL in

(Section 3.2.3) When deployed in an operational environment, OpenC2 endpoints MUST support basic authentication and SHOULD support mutual authentication.

My question is whether the reference to basic authentication should be removed entirely, so that the requirement instead reads

When deployed in an operational environment, OpenC2 endpoints MUST support mutual authentication.

[davaya]

RFC 2119 keywords (MUST/SHOULD) apply to Units Under Test. A "product" or "implementation" or whatever unit is being tested for conformance has to meet the specified requirements. (c.f., https://books.google.com/books?id=gkT2fVgPmLcC&pg=PA177&lpg=PA177).

Systems are built from units that conform to OpenC2 specifications. Enterprises will have additional security requirements beyond those defined by OpenC2, and will compose various units to meet those requirements.

Delete the phrase "When deployed in an operational environment" - it is meaningless. When a unit is being tested for OpenC2 conformance the tester has no knowledge of where it will be deployed. And the unit MUST satisfy all conformance requirements when it is in the test environment (i.e., NOT deployed).

I believe the MUST support basic authentication should remain present, in order to allow system builders flexibility to configure authentication at various network layers. I don't think we have defined conformance requirements for mutual authentication well enough to test whether a unit supports it. Without those requirements, even if a document says MUST it is only an aspirational goal, not a conformance criterion. So I recommend SHOULD support mutual authentication, but won't strongly oppose saying "the unit MUST support mutual authentication" even if there are no tests to determine whether it actually does.

[dlemire60]

This was discussed at the January 2019 F2F and the PR language was presented. This issue was discussed in conjunction with Issue #6 (HTTPS-27) The consensus of the F2F meeting was to approve this change. While the two issues are distinct it proved difficult to discuss them in isolation. The language generally agreed to at the meeting was "each party to an openc2 communication must authenticate the other party" (credit Toby Considine), that authentication might be handled by mechanisms outside of TLS, and that the TC was not in a position to specify mechanisms. The editor will close PR #59 and revise PR #58 with changes to address both issues. so that they can be addressed as a whole.

[dlemire60]

Per the discussion at the 6 February IC-SC meeting, I am applying PR #58 and closing this issue.