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] Groups - KMIP 1.3 Custom Security Attribute Proposal uploaded


Thanks Joseph 

    I think I understand what you guys are trying to do.   I am also familiar with the NIST documents.   However, to me your proposal really does not do what you want to achieve.    Yes KMIP JUST describes the communication but that does not mean we should just send data over as opaque blobs.   If we where going to do just that then why do we have the transparent key types or the X.509 certificate types.    We could just define a key blob and then the server would be responsible to figure out what it was.
Yes sometimes you have extensions not covered and then that makes sense to send over a blob but that is an exception.

   I don't see any reason why you guys cannot define that security attributes as a structured piece of data.   That way the receiving server can know what it is.   
That way the server can perform a validation test on it.  Also how does a server define what type of NIST meta data it supports?   It will have to list these custom attribute strings where NONE of them are standard.  

   For me profiles are not enough to fix a broken protocol.    




Joseph Brand <jbrand@semper-fortis.com> , 7/16/2014 2:31 PM:

Mark, David,

 

The KMIP specification proposal is meant to help start the conversation for what needs to be updated in the specification.   Once that is agreed to we plan to also develop a profile document that will focus on how the client and server should work with the additional security attributes.

 

The profile document is aimed at supporting NIST requirements for Cryptographic Key Management Systems (800-130 and 152).  In this we are aiming for the security attributes to play a supporting role for a subset of the requirements in 800-130/152.  The KMIP specification only handles how a client and server communicate.  The 800-130/152 docs also require a whole mess of other requirements that are not applicable to the KMIP specification and would be up to the various server and client vendors to implement if they intend to support the 800-130/152 documents.  We are recommending the addition of security attributes so that the KMIP specification can support as a communications protocol the client/server interactions that are part of the 800-130/152 documents.  This goes back to our face to face presentation back prior to the RSA conference, as well as discussions that were had at the NIST Cryptographic Key Management Workshop which reviewed the 800-152 Federal Cryptographic Key Management profile draft.

 

Would it help to also have the recommended updates for test cases and the Profile document to complete the whole picture on how the security attributes are intended to be handled?

 

Regards,

 

Joe Brand

 

From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Mark Joseph
Sent: Wednesday, July 16, 2014 1:13 PM
To: Chuck White; 'Featherstone, David'; kmip@lists.oasis-open.org
Subject: Re: [kmip] Groups - KMIP 1.3 Custom Security Attribute Proposal uploaded

 

Hi Chuck,

 

   First let me state that I am a big supporter of what you are trying to do.   The problem I have is what appears to me a short term "hack" (for lack of a better word) instead of the proper standards based approach to solve the real problem.

 

 

Good point Mark! – for 1) I am open to suggestions on how to best expand the language for any managed object.

 

I think the wording is easy.   Just replace "key material" with "managed object".

 

 

For 2) a couple of points:  

 

In the long run I agree with security attributes being in a structure. In the short-term, the objective is to account for sensitive custom attributes that align with the concept of designating and safeguarding security meta-data.  Safeguarding is up to the client and server – designation needs to be captured in the communications.  

 

So why the rush?  Why do a short term thing when the right way to do it is to add a real attribute?  We can still add a real attribute to KMIP 1.3 which is FAR from being finalized.

If you need a short term thing for a customer or project then add an "X-" attribute for your application cause I still don't see a difference between "X-" and "ZX-".   There are no additional server guarantees that the "ZX-" data itself is secure.

 

 

As for X and Y for custom client and server designations, this accounts for implementation specific designation of security attributes. IE Department of Defense might say “Top Secret”, and a Health Care provider might have a “ “Patient Sensitive” designation.  Both are security attributes and will have similar handling associated with them – but they are implementation specific. 

 

Yup I understand that and that is why I suggested a structure with a type field.  Sending an opaque binary blob of data is hardly a way for a "standard" to encode semantics.  Especially of a concept such as this.

 

 

In that line of thought, a Security Attribute structure as a part of KMIP 2.0 would allow flexibility to address labels, as for 1.3 – just want to start with the concept of designation as a starting point.

 

Why can't we add an new attribute to KMIP 1.3?   I don't see that we are even near to a final deadline for new features.   I promise to add it into our P6R client for KMIP 1.3 so lets take the time and do it right instead of eventually getting it done 2 different ways (a ZX- attribute and a real attribute).

 

 

Thanks!

 

Chuck

 

 

Charles White

Semper Fortis Solutions, LLC

 


This message contains information from Semper Fortis Solutions, LLC which may be confidential and privileged. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited.

 

From: Mark Joseph [mailto:mark@p6r.com]
Sent: Wednesday, July 16, 2014 11:08 AM
To: Chuck White; 'Featherstone, David'; kmip@lists.oasis-open.org
Subject: Re: [kmip] Groups - KMIP 1.3 Custom Security Attribute Proposal uploaded

 

Hi Chuck,

 

   I had a few comments:

 

1) Seems like you are restricting this (at least in the text you wrote) to key material.   Security attributes should be for any managed object including opaque objects.

 

2) The definition of the "Custom Security Attribute" to me seems a little too open ended.   You are going to have different types of these things and it makes sense to have a type field.   So it should be a structure to start off with.   Also the restriction to not have sub structures seems arbitrary and overly restrictive.   I would add a type field and define at least one of these like a security label to start off with.  You can always have a type value of opaque or "extension" if you really want that.   Why are we making this a X- and y- attribute?  Why not make it a real attribute and do this right?

 

 

Best,

 

Mark Joseph, Ph.D. 

President P6R, Inc 

408-205-0361 

Skype: markjoseph_sc 

 

Chuck White <cwhite@semper-fortis.com> , 7/16/2014 7:47 AM:

Howdy David!

 

A Custom Security attribute is there to help both a client and server understand that a given piece of information is considered sensitive and should have steps taken by the client and server to secure that information upon reception.

 

Arguably this could be accomplished with plain custom attributes – but that does not map to NIST SP800-130 and 152 and the framework requirement to designate and safeguard security metadata.

 

It is also worth pointing out that this is a first step with Security Attributes that helps further align KMIP with NIST guidance.  Much like our conversation last week on string  vs integer (tag vs text value), there is much more work to go into security attributes in KMIP 2.0 and beyond.  So consider this “the thin edge of the wedge”

 

And in all of this – there is also the conversation to be had on existing attributes like Cryptographic Length, Algorithm, etc that are also considered sensitive.  Just want to make sure we collectively consider that as well.

 

Hope this helps.

 

Thanks!

 

Chuck

 

Charles White

Semper Fortis Solutions, LLC

 


This message contains information from Semper Fortis Solutions, LLC which may be confidential and privileged. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited.

 

From: Featherstone, David [mailto:David.Featherstone@safenet-inc.com]
Sent: Wednesday, July 16, 2014 10:22 AM
To: Chuck White; kmip@lists.oasis-open.org
Subject: RE: [kmip] Groups - KMIP 1.3 Custom Security Attribute Proposal uploaded

 

Hi Chuck

 

Would you please explain the semantic difference between Custom Security Attribute and Custom Attribute?

 

e.g. What could a client (server) achieve with zx-My-Special-Client-Attribute (zy-My-Special-Server-Attribute) that could not be achieved with x-My-Special-Client-Attribute (y-My-Special-Server-Attribute)?

                                                                                                                                                                                                                                                        

I presume that a semantic difference is intended, but I didn’t see that difference in the proposal.

 

Regards,

… Dave

 

 

 

From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Charles White
Sent: Wednesday, July 16, 2014 8:17 AM
To: kmip@lists.oasis-open.org
Subject: [kmip] Groups - KMIP 1.3 Custom Security Attribute Proposal uploaded

 

Submitter's message
Good morning KMIP TC!

I have uploaded the Custom Security Attributes Proposal for TC review. Feel free to ask questions.

Thanks!

Chuck
-- Charles White

Document Name: KMIP 1.3 Custom Security Attribute Proposal


Description
Update for the KMIP 1.3 Specification that reflects creation of custom z-x-
and z-y- custom security attributes that can be used for sensitive
information associated with managed objects.
Download Latest Revision
Public Download Link


Submitter: Charles White
Group: OASIS Key Management Interoperability Protocol (KMIP) TC
Folder: Drafts
Date submitted: 2014-07-16 05:17:00

 

The information contained in this electronic mail transmission

may be privileged and confidential, and therefore, protected

from disclosure. If you have received this communication in

error, please notify us immediately by replying to this

message and deleting it from your computer without copying

or disclosing it.

 

 



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