Subject: [sacm] Question & comment on SACM requirements -03

From: Lisa Lorenzin <[email-masked]>
Date: Thu, 17 Apr 2014 16:59:03 +0000

Greetings!

After reviewing the SACM requirements -03 draft and discussing it with colleagues, I have a bunch of comments and questions on it.  I've been trying to organize them into one big email, but a) after three weeks I'm still not finished and b) it's way too long already anyway.  So to get past my wetware MTU problem, I'm going to try fragmentation. :)

REQ-007 states:
"Use Cases 2.1.3, 2.1.4 and 2.1.5 describe the need for the data model to support the means for the information to be published asynchronously.  Similarly, the data model must support the means for a requestor to obtain updates or change modifications asynchronously. [...]"

What does asynchronous publication encompass in this context?  If you have a global repository with replication around the world, a client might publish to the nearest repository, and information might propagate with some lag; is that form of asynchrony intended to be included?  Some description of what we intend by "asynchronous" would be helpful here.

G-007 states:
"To address security and privacy considerations, the data model, protocols and transport must consider authorization based on roles to only allow authorized requestors and publishers to access the information being requested or published."

Two thoughts here:

Authorization based on roles is necessary, but IMHO not sufficient; from our experience using IF-MAP for security automation, I believe authorization also needs to extend to specific information or resources available in the environment.  In other words, authorization should be based on both subject (the access requestor) and object (the resource / attribute / chunk of information requested). 

Separately, I think we should also consider whether authorization should be required to apply to the infrastructure itself - i.e. the central controller(s) / data repository(ies) / broker(s) - to enable enforcement of access control across organizational boundaries / partitioning of data / federation between multiple entities...

					Regards,

						Lisa

--
Lisa Lorenzin  /  919-384-7275  /  [email-masked] 
Principal Solutions Architect - Security & Mobility 
Juniper Networks  /  http://www.juniper.net/

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Wed, 30 Apr 2014 02:03:34 +0000

Hi Lisa,

Thanks for the comments! And apologies for the long delay

On 4/17/14 9:59 AM, "Lisa Lorenzin" <[email-masked]> wrote:

>Greetings!
>
>After reviewing the SACM requirements -03 draft and discussing it with
>colleagues, I have a bunch of comments and questions on it.  I've been
>trying to organize them into one big email, but a) after three weeks I'm
>still not finished and b) it's way too long already anyway.  So to get
>past my wetware MTU problem, I'm going to try fragmentation. :)
>
>REQ-007 states:
>"Use Cases 2.1.3, 2.1.4 and 2.1.5 describe the need for the data model to
>support the means for the information to be published asynchronously.
>Similarly, the data model must support the means for a requestor to
>obtain updates or change modifications asynchronously. [...]"
>
>What does asynchronous publication encompass in this context?  If you
>have a global repository with replication around the world, a client
>might publish to the nearest repository, and information might propagate
>with some lag; is that form of asynchrony intended to be included?  Some
>description of what we intend by "asynchronous" would be helpful here.
[NCW] I think where information gets published can be more of an
implementation detail as I believe your description is that the nearest
repository then propagates it (but to me that is still an asynchronous
event).  What I understood in the intent of publication vs. query is that
publication is that the information is delivered at an unprompted or
undetermined (in time, e.g. polling) response.

REQ-007 is meant to distinguish what I view a "query" as a synchronous
operation (e.g. An actor requests and awaits for the data).  Would it
suffice to state that?

>
>G-007 states:
>"To address security and privacy considerations, the data model,
>protocols and transport must consider authorization based on roles to
>only allow authorized requestors and publishers to access the information
>being requested or published."
>
>Two thoughts here:
>
>Authorization based on roles is necessary, but IMHO not sufficient; from
>our experience using IF-MAP for security automation, I believe
>authorization also needs to extend to specific information or resources
>available in the environment.  In other words, authorization should be
>based on both subject (the access requestor) and object (the resource /
>attribute / chunk of information requested)
[NCW] Agree, but I guess I was leaving the term "role" to be very loose
although, I am not sure it would be easy for an authorization agent to
determine the requestor's resource availability?

>
>Separately, I think we should also consider whether authorization should
>be required to apply to the infrastructure itself - i.e. the central
>controller(s) / data repository(ies) / broker(s) - to enable enforcement
>of access control across organizational boundaries / partitioning of data
>/ federation between multiple entities...
[NCW] Agreed, but by infrastructure, you are predisposing an architecture
that we have not reached agreement on :-) But your point is well taken;
the question is whether it becomes a requirement vs. a security
consideration.
>_______________________________________________
>sacm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sacm