Re: [openc2-lang] RE: [Non-DoD Source] RE: [openc2-lang] New properties

[Dave Lemire <dave.lemire@g2-inc.com>]

I agree completely with Dave Kemp and Allan Thomson. The approach Allan's describing is consistent with the OpenC2 design-principles-and-assumptions briefing. Slide 5 describes being OpenC2 being agnostic regarding transport, authentication, integrity controls, etc., in order to enable flexibility w.r.t. implementation.

Much of this is described and discussed in the IA Implementation Considerations document, which I would envision would be transformed into an OASIS Committee Note.  It's a good read, and not nearly as long as the L-Spec!

What I believe needs to be worked out in the IC-SC is how we provide guidance for achieving interoperability with appropriate IA characteristics, without actually creating OpenC2 transport and IA specifications, which would conflict with the design principles described above.

Dave

On Mon, Oct 9, 2017 at 10:17 AM, Allan Thomson <athomson@lookingglasscyber.com> wrote:

It’s not just authentication but authorization that a system needs to be concerned about. There will be certain commands that are authorized but not others.

 

However, given that OpenC2 does not describe a transport protocol (yet) then I’m not sure it’s wise or necessary for OpenC2 to define that mechanism as part of the OpenC2. It would seem that is a solved problem that should be covered outside of OpenC2 itself.

 

OpenC2 commands and actions should both be authenticated and authorized but does OpenC2 really need to re-invent that wheel?

 

At most, OpenC2 should introduce text that defines that an authentication/authorization protocol takes place prior to the exchange of other OpenC2 messages.

 

regards

 

Allan

 

From: <openc2-lang@lists.oasis-open.org> on behalf of "Kemp, David P" <dpkemp@radium.ncsc.mil>
Date: Thursday, October 5, 2017 at 7:13 AM
To: "openc2-lang@lists.oasis-open.org" <openc2-lang@lists.oasis-open.org>
Subject: [openc2-lang] RE: [Non-DoD Source] RE: [openc2-lang] New properties

 

We discussed authentication at yesterday’s Implementation SC meeting, and as far as I could tell there was unanimous consensus around Danny Martinez’s point that deploying a network command and control system without authentication would be so dangerous as to be unthinkable.   So the question should not be *if* the IC-SC  specifies authentication of OpenC2 commands, but *how*.   Unless there are objections to authentication, it should be an axiom that an OpenC2 consumer knows the authenticated id of the producer.

 

Authentication can be provided for data at rest using digital signatures, and for data in transit using protocols such as TLS.  For data at rest (commands that are stored for some time before being delivered to the consumer) digital signatures include authenticated attributes such as creation time, e.g. RFC 5751 section 2.5.1.  For data in transit the consumer knows the time of creation to within the latency of the network.

 

So there would need to be a strong justification for putting redundant creator and creation time fields inside an OpenC2 command, including why they are needed and what the consumer should do if creator and time fields inside the command differ from those in the authentication layer.

 

Dave

 

 

From: openc2-lang@lists.oasis-open.org [mailto:openc2-lang@lists.oasis-open.org] On Behalf Of duncan@sfractal.com
Sent: Wednesday, October 4, 2017 11:26 PM
To: openc2-lang@lists.oasis-open.org
Subject: [Non-DoD Source] RE: [openc2-lang] New properties

 

Bret,

To be clear wrt ID - I think you are asking:

1) move id from being under command-option to being a peer to action/target/actuator/command-option

2) id to be mandatory (I'm presuming you meant that based on #1)

3) a specific format for the ID - UUIDv4

 

Did I get it right? If so, I think they are 3 separate, related issues. #2 got some discussion at the last LSC meeting.

 

Wrt UUIDv4 - are there other choices we should consider? Why v4 not v5? (which I think is a one-time vs reproducible argument that might be like a religious war). Note I don't know enough to favor one or other - I'm just asking since someone eventually will.

 

Wrt created/timestamp - Am I correct that you would prefer this as a 'top level' part of the json as opposed to it being under command-options? Could you explain logic of when you'd prefer top-level vs when under command-options? Or would you prefer all command-options to be top-level?

 

Wrt created/timestamp - could you provide the usecase for including this in the openc2 language? In particular why it's in the json itself as opposed to being in the transport (particularly in the STIX case which has one of it's own) or in the logging? I'll confess the use cases that interest me (as sFractal, not co-chair) the most are 2 authenticated entities talking directly so there is no transport delay to speak of so the producer doesn't need to send the consumer the time it was sent.

 

Similarly for creator/author - could you provide the use case? Ditto my previous confession since directly connected mutually-authenticated entities know the other end.

 

I agree the multiple target commands have issues we have yet to address. I would think the command id and target specifiers would be sufficient but maybe i'm just not seeing the use case you have in mind where that would not work. I think I may be stuck in the 'simple' use cases where we know the actuator(s) we are sending to. In the 'variable' cases the STIX COA have been discussing, the actuator/specifiers are not know a priori. But I'm not sure you could serial number it if you couldn't target-specifier it. I agree it needs more discussion.

 

My preference would be kick multiple-targets down the road until after January's 1.0. I fine with it being top of the list for next version but personally (Duncan as sFractal, not co-chair) I'd rather get the 'simple' use cases handled first.

 

Joe, Sounil,

This might be a good area to ask for input from the cyber-user council as to their priorities and urgencies.

 

 

 

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

 

-------- Original Message --------
Subject: [openc2-lang] New properties
From: Bret Jordan <Bret_Jordan@symantec.com>
Date: Wed, October 04, 2017 2:37 pm
To: "openc2-lang@lists.oasis-open.org"
<openc2-lang@lists.oasis-open.org>

I would like to propose that the language SC consider adding the following top-level properties to all commands:

 

id (UUIDv4)

created (timestamp)

creator or author or something  (an ID to a STIX Identifier or some sort of other identity)

 

We should also have some sort of serial number as well.  So that if you have a command with and ID of 1234 and you issue that command to 400 systems, you will need some way of knowing which systems / serial numbers accepted and processed that command successfully.

 

Bret

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php