OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [kmip] Re: [GRAYMAIL] [kmip] RE: [kmip] Groups - Handling Instruction_w_Examples.xlsx uploaded

I was not suggesting that we literally implement a Unix security model.  Merely to be very careful about over designing something.  

So start with the y- model, see if it can be used to cover the cases, and if not then very carefully make more complex.


On Fri, May 6, 2016 at 9:41 AM, Mark Joseph <mark@p6r.com> wrote:
My understanding was the main driver for this was to handle existing security systems for defense.    This is one use case.    And that is not the simple UNIX system which cannot handle multiple levels of data.   That analogy is not appropriate to this use case.   

If we don't want to handle existing military systems (at least US based ones) then I am fine with the trivial discretionary access control mechanism that UNIX represents 

Mark Joseph
P6R,  Inc

On May 5, 2016, at 4:27 PM, Anthony Berglas <anthony.berglas@cryptsoft.com> wrote:

One thing to keep in mind is the need to keep things simple.

Consider the Unix and Windows file access control systems.  The Unix model is very crude and has not changed in 30 years.  There are just three classifications (user/group/others) and a few bits of persmissions.  Yet, with BSD's addition of multiple groups, it gets the job done.  More over, everyone understands it, and it is easy to see what is going on with ls -l.

OTOH The Window's model is much more sophisticated.  Full ACLs, with arbitrary permissions assignable to arbitrary (groups of) users, and inheritance, very complex environments can be modeled.  But it is a complete mess.  Nobody really understands it.  The default tools make it impossible to understand or confirm security of a larger number of files.  In order to make it usable "home groups" were introduced whose exact semantics are very vague.  And all this makes the system ultimately insecure to use in practice.

So I would suggest starting out with something very simple.  Like just two classes of attributes, protected (z-) and normal (x-).  Then see if that can be used to model what you need.  Occasionally you might need to hack, such as duplicating and object, but that is OK.  If needed add a bit more.  


On Fri, May 6, 2016 at 6:19 AM, Mark Joseph <mark@p6r.com> wrote:
I don't think we should take this to the entire group for a while.   I suggest a few of us work on it and invite anyone else to join our little group separately.    Last week we just got silence from the entire group.   

Government oriented is fine just as long as we distinguish mandatory and discretionary access controls.   Label based systems are mandatory.    

Also I think we need structures for anything that can have multiple versions of things.   Not sure what your issue is with structures but we don't have any technical issue against them.   

We could do a small conference call just with our own smaller group.   I doubt Tony would have an issue with it.  

Mark Joseph
P6R,  Inc

On May 5, 2016, at 1:13 PM, Lockhart, Robert <Robert.Lockhart@thalesesec.com> wrote:

Something to definitely discuss next meeting.  I have some additional questions that can wait and maybe clarify my particular use case which was government oriented.  Also I want to be sure we are not requiring every attribute have a structure associated with it are we?  Just the ones that require additional protection based on an associated security level for a given attribute.


Bob L.


Robert A. (Bob) Lockhart

Chief Solutions Architect

Technical Directorate

Thales e-Security, Inc.


From: Mark Joseph [mailto:mark@p6r.com]
Sent: Thursday, May 05, 2016 12:45 PM
To: Lockhart, Robert <Robert.Lockhart@thalesesec.com>
Cc: Chuck White <chuck@fornetix.com>
Subject: Re: [GRAYMAIL] [kmip] Groups - Handling Instruction_w_Examples.xlsx uploaded


My understanding was that one of the primary use cases for this was multi-level secure systems.    In which case it is using mandatory access controls.    So the notion of a time out on an attribute does not make sense in that domain unless I have misunderstood your description


I do agree with your general approach let's pick a few domains and run with just those.   Using a structure like key block which can morph into different things.   


We could also make most of the structures repeatable.   So for one domain there will be just one attitude (e.g. US security label) but other domains can have multiple.    This may let us avoid the US vs Australia defense thing.   Just a thought.   


Mark Joseph

P6R,  Inc


On May 5, 2016, at 12:05 PM, Lockhart, Robert <Robert.Lockhart@thalesesec.com> wrote:



I am a bit concerned about getting too granular with tags.  While I know we have way more than enough numbers, I would prefer to keep them non-specific and if someone wants to define an extension that denotes US vs. Australia then leave it to them to define in more depth or request we add one for them.  I would lump the domains into very generic buckets similar to what you did for PII data.  If an organization wants us to define a specific domain for them, they can request it and we can decide then.  Until then I would consider keeping it simple.  Otherwise you end up with around ~206 defense/defence organization tags, 194+ health care tags and a subset of those with financial bodies you would need to include.


My suggestion would be to narrow it down to the following for simplicity (forgive my lack of international spelling as I only write American courtesy of my spell checker):

0                                  Defense/Military

1                                  Governmental Non-defense

2                                  Financial

3                                  Health Care

4                                  Personally Identifiable Information

5 – 7fffffff                     Reserved for future use

80000000 – FFFFFFFF   Custom Extensions


I would also like to see expiration or destruction date for attributes that require security in the Distribution Protection, Storage Protection section or as its own attribute in the Object Structure.  I have seen a use case that required that a portion of the information on a particular object had to go buh-bye prior to the actual object it was about (redaction anyone? – Can’t wait to display black felt pen marks on a key detail screen).  We could get long haired here and discuss a validity time versus a date on the off chance someone uses a common structure for multiple objects but I would prefer to stay away from it for now and just specify an attribute destroy date.


P.S. The 206 number comes from counting countries that don’t have global recognition like Taiwan, Kosovo, Western Sahara, Greenland, Palestine, etc… and only count the UK as one country instead of the four countries it is comprised of along with a few nation-states thrown in for fun.  The 194 number is from the number of countries or at least by worldatlas.com.


P.P.S.  The U.S. recognizes 195 countries today.


That’s it from me for today’s geography and international politics lesson.


Bob L.


Robert A. (Bob) Lockhart

Chief Solutions Architect

Technical Directorate

Thales e-Security, Inc.


From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Chuck White
Sent: Thursday, April 28, 2016 1:07 PM
To: Mark Joseph <mark@p6r.com>; kmip@lists.oasis-open.org
Subject: [kmip] RE: [GRAYMAIL] [kmip] Groups - Handling Instruction_w_Examples.xlsx uploaded


Howdy Mark!


Great points all!


Answers below


From: Mark Joseph [mailto:mark@p6r.com]
Sent: Thursday, April 28, 2016 3:43 PM
To: Chuck White <chuck@fornetix.com>; kmip@lists.oasis-open.org
Subject: Re: [GRAYMAIL] [kmip] Groups - Handling Instruction_w_Examples.xlsx uploaded


Hi Chuck,


   Two questions, just asking for clarification 


1) In the Department of Defense example the table has two security labels one at TS and one at S.   How can one piece of data have two labels?

Consider a MLS solutions where something could be authorized for Secret or Top Secret Storage that was the idea. Where there are multiple labels associated with all the authorized security levels.



2) In the US health care case, access is typically controlled by RBAC (we have a customer in this area and this seems how its done)   I just see

peoples names in the who has access no notion of access rules.

This is more of an Attribute Based Access Control (ABAC) model that takes it cues from the providers (My esteemed colleagues and Dr. Howser) and the appropriate ICD 10 tags for conditions as part of the labeling scheme that ends up being a combination of provider and condition.



3) Also in the who has access I just see text names, these are some type of user ids right?

Those are IDs and can be any type of ID….. kept those human readable for the sake of example










From: Charles White <chuck@fornetix.com>
To: <kmip@lists.oasis-open.org>
Sent: 4/28/2016 8:40 AM
Subject: [GRAYMAIL] [kmip] Groups - Handling Instruction_w_Examples.xlsx uploaded

Submitter's message
Howdy KMIP TC!

Here is the updated spreadsheet for Handling Instructions with examples for Healthcare and DoD.


-- Mr. Charles White

Document Name: Handling Instruction_w_Examples.xlsx

Updated with Department of Defense and Healthcare Example
Download Latest Revision
Public Download Link

Submitter: Mr. Charles White
Group: OASIS Key Management Interoperability Protocol (KMIP) TC
Folder: Drafts
Date submitted: 2016-04-28 08:40:39


Anthony Berglas Ph.D.
Principal Engineer

Anthony Berglas Ph.D.
Principal Engineer

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]