OASIS Key Management Interoperability Protocol (KMIP) TC

 View Only
  • 1.  Locate by Value proposal

    Posted 11-17-2015 11:36
      |   view attached
    Hello All, Attached is the proposal for being able to Locate objects by their values in an analogous way that we can locate by attribute.  I would like to discuss this on this week's call.  However, any initial feedback would be most welcome. Regards, Anthony -- Anthony Berglas Ph.D. Principal Engineer Anthony.Berglas@Cryptsoft.com Attachment: LocateValueNov15-Ship.pptx Description: application/vnd.openxmlformats-officedocument.presentationml.presentation

    Attachment(s)

    pptx
    LocateValueNov15-Ship.pptx   53 KB 1 version


  • 2.  RE: [kmip] Locate by Value proposal

    Posted 11-17-2015 18:00
    Hi Anthony   An interesting idea, but I wonder if that capability would be more useful to a hacker than to a legitimate customer. The risks seem to outweigh the benefits.   As a contrived example, suppose you’re at a 5000-room resort hotel and you drop your room key in the lobby. Moments later, a thief finds your lost key, but doesn’t know which room it will open. No problem, because the hotel has a database of its room keys and a corresponding image of every key. The thief takes a photo of the key and pays $20 to his insider friend to run a search on the image. Voila, the thief learns that the key will open Room 3724.   Don’t analyze the example too intensely, because I’m sure there are a number of holes, but I think the general concern is valid. If instead of a lost physical key we substitute a lost or stolen password, I think you can imagine how the search capability could be exploited to a hacker’s advantage. You could argue that if the hacker is able to perform the search, then the hacker already has access to the keys, but the critical detail is that the hacker is already in possession of a piece of information but doesn’t know how to use it. The search result tells him. Perhaps this risk could be mitigated by a server policy requiring that Key Blocks be searchable only by clients that are also permitted to Get [i.e. export] the corresponding keys.   In one of your examples [4 th slide], you propose that this capability could find a Group Member attribute in the Key Block . Could you clarify why you would search for this attribute in the Key Block ? i.e. I understand that the attribute can be packaged within the Key Block – e.g. at time of Register – but why would the server leave this attribute in the Key Block ? It must anyway be made accessible by Locate ( and Get Attributes, and Get Attribute List) – even now, without the proposed extension.   Finally, also on the 4 th slide, could you clarify how this capability would match data within a wrapped Key Value [within a Key Block ]? If the Key Value is wrapped, would a search not require that the Key Value be unwrapped? And if the wrapped Key Value can be unwrapped, would not the unwrap have occurred once (and only once) when client first Register ’d the key?   Cheers, … Dave     From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Anthony Berglas Sent: Tuesday, November 17, 2015 6:36 AM To: OASIS KMIP Technical Committee Subject: [kmip] Locate by Value proposal   Hello All, Attached is the proposal for being able to Locate objects by their values in an analogous way that we can locate by attribute.  I would like to discuss this on this week's call.  However, any initial feedback would be most welcome. Regards, Anthony -- Anthony Berglas Ph.D. Principal Engineer Anthony.Berglas@Cryptsoft.com 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.


  • 3.  Re: [kmip] Locate by Value proposal

    Posted 11-18-2015 02:51
    Hello David and Bruce, Thank you very much for your prompt feedback.  I did not mention security policy because currently that is simply not part of the KMIP spec.  However, clearly it should be protected more than just Locate by Attribute, and possibly more than a Get for reasons that you outline.  I will add a note to the slides. However, given that server policy is properly enforced, I would think that it is useful for appropriately authorized officers to be able to perform searches.  To use your hotel key example, if a key was found lying around (or in the pocket of a thief) then it would be not unreasonable for management to be able to determine to which room it belonged? The NIST SP800-152 seems to want to treat the key material and attributes in a similar way, which it could be argued is what this proposal does.  I think that different attributes need different security profiles, which is what Chuck was talking about.  The key material is just one of those aspects that need to be properly secured with policy. And that all becomes grist for the ACL proposal that I had aired in the face to face, but is a much bigger and more difficult issue to deal with. As to the Group Member on slide 4, that is just referring to the ordinary Group Member KMIP attribute.  In other words the the search on (parts of) an object's value can be combined with ordinary Locate attribute searches.  And that is why I thought to use Locate rather than introducing some new LocateByValue operation.  I will clarify that in the slides. Likewise, the UUID (Unique Identifier) and wrapping crypto Algorithm  is just he one in the Wrap Data structure, which is not itself wrapped.  It is not in the Key Value.  So it is available without the need to unwrap anything.  I will also clarify that. I'll upload updated slides shortly. Anthony On Wed, Nov 18, 2015 at 3:59 AM, Featherstone, David < David.Featherstone@safenet-inc.com > wrote: Hi Anthony   An interesting idea, but I wonder if that capability would be more useful to a hacker than to a legitimate customer. The risks seem to outweigh the benefits.   As a contrived example, suppose you’re at a 5000-room resort hotel and you drop your room key in the lobby. Moments later, a thief finds your lost key, but doesn’t know which room it will open. No problem, because the hotel has a database of its room keys and a corresponding image of every key. The thief takes a photo of the key and pays $20 to his insider friend to run a search on the image. Voila, the thief learns that the key will open Room 3724.   Don’t analyze the example too intensely, because I’m sure there are a number of holes, but I think the general concern is valid. If instead of a lost physical key we substitute a lost or stolen password, I think you can imagine how the search capability could be exploited to a hacker’s advantage. You could argue that if the hacker is able to perform the search, then the hacker already has access to the keys, but the critical detail is that the hacker is already in possession of a piece of information but doesn’t know how to use it. The search result tells him. Perhaps this risk could be mitigated by a server policy requiring that Key Blocks be searchable only by clients that are also permitted to Get [i.e. export] the corresponding keys.   In one of your examples [4 th slide], you propose that this capability could find a Group Member attribute in the Key Block . Could you clarify why you would search for this attribute in the Key Block ? i.e. I understand that the attribute can be packaged within the Key Block – e.g. at time of Register – but why would the server leave this attribute in the Key Block ? It must anyway be made accessible by Locate ( and Get Attributes, and Get Attribute List) – even now, without the proposed extension.   Finally, also on the 4 th slide, could you clarify how this capability would match data within a wrapped Key Value [within a Key Block ]? If the Key Value is wrapped, would a search not require that the Key Value be unwrapped? And if the wrapped Key Value can be unwrapped, would not the unwrap have occurred once (and only once) when client first Register ’d the key?   Cheers, … Dave     From: kmip@lists.oasis-open.org [mailto: kmip@lists.oasis-open.org ] On Behalf Of Anthony Berglas Sent: Tuesday, November 17, 2015 6:36 AM To: OASIS KMIP Technical Committee Subject: [kmip] Locate by Value proposal   Hello All, Attached is the proposal for being able to Locate objects by their values in an analogous way that we can locate by attribute.  I would like to discuss this on this week's call.  However, any initial feedback would be most welcome. Regards, Anthony -- Anthony Berglas Ph.D. Principal Engineer Anthony.Berglas@Cryptsoft.com 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. -- Anthony Berglas Ph.D. Principal Engineer Anthony.Berglas@Cryptsoft.com


  • 4.  Re: [kmip] Locate by Value proposal

    Posted 11-18-2015 06:08
    P.S.  The security implications are actually rather small because an attacker with Get access could always iterate over all the keys, Get each one, and compare the key materials.  That would be inefficient, but quite effective unless there were a vast number of keys. On Wed, Nov 18, 2015 at 12:50 PM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote: Hello David and Bruce, Thank you very much for your prompt feedback.  I did not mention security policy because currently that is simply not part of the KMIP spec.  However, clearly it should be protected more than just Locate by Attribute, and possibly more than a Get for reasons that you outline.  I will add a note to the slides. However, given that server policy is properly enforced, I would think that it is useful for appropriately authorized officers to be able to perform searches.  To use your hotel key example, if a key was found lying around (or in the pocket of a thief) then it would be not unreasonable for management to be able to determine to which room it belonged? The NIST SP800-152 seems to want to treat the key material and attributes in a similar way, which it could be argued is what this proposal does.  I think that different attributes need different security profiles, which is what Chuck was talking about.  The key material is just one of those aspects that need to be properly secured with policy. And that all becomes grist for the ACL proposal that I had aired in the face to face, but is a much bigger and more difficult issue to deal with. As to the Group Member on slide 4, that is just referring to the ordinary Group Member KMIP attribute.  In other words the the search on (parts of) an object's value can be combined with ordinary Locate attribute searches.  And that is why I thought to use Locate rather than introducing some new LocateByValue operation.  I will clarify that in the slides. Likewise, the UUID (Unique Identifier) and wrapping crypto Algorithm  is just he one in the Wrap Data structure, which is not itself wrapped.  It is not in the Key Value.  So it is available without the need to unwrap anything.  I will also clarify that. I'll upload updated slides shortly. Anthony On Wed, Nov 18, 2015 at 3:59 AM, Featherstone, David < David.Featherstone@safenet-inc.com > wrote: Hi Anthony   An interesting idea, but I wonder if that capability would be more useful to a hacker than to a legitimate customer. The risks seem to outweigh the benefits.   As a contrived example, suppose you’re at a 5000-room resort hotel and you drop your room key in the lobby. Moments later, a thief finds your lost key, but doesn’t know which room it will open. No problem, because the hotel has a database of its room keys and a corresponding image of every key. The thief takes a photo of the key and pays $20 to his insider friend to run a search on the image. Voila, the thief learns that the key will open Room 3724.   Don’t analyze the example too intensely, because I’m sure there are a number of holes, but I think the general concern is valid. If instead of a lost physical key we substitute a lost or stolen password, I think you can imagine how the search capability could be exploited to a hacker’s advantage. You could argue that if the hacker is able to perform the search, then the hacker already has access to the keys, but the critical detail is that the hacker is already in possession of a piece of information but doesn’t know how to use it. The search result tells him. Perhaps this risk could be mitigated by a server policy requiring that Key Blocks be searchable only by clients that are also permitted to Get [i.e. export] the corresponding keys.   In one of your examples [4 th slide], you propose that this capability could find a Group Member attribute in the Key Block . Could you clarify why you would search for this attribute in the Key Block ? i.e. I understand that the attribute can be packaged within the Key Block – e.g. at time of Register – but why would the server leave this attribute in the Key Block ? It must anyway be made accessible by Locate ( and Get Attributes, and Get Attribute List) – even now, without the proposed extension.   Finally, also on the 4 th slide, could you clarify how this capability would match data within a wrapped Key Value [within a Key Block ]? If the Key Value is wrapped, would a search not require that the Key Value be unwrapped? And if the wrapped Key Value can be unwrapped, would not the unwrap have occurred once (and only once) when client first Register ’d the key?   Cheers, … Dave     From: kmip@lists.oasis-open.org [mailto: kmip@lists.oasis-open.org ] On Behalf Of Anthony Berglas Sent: Tuesday, November 17, 2015 6:36 AM To: OASIS KMIP Technical Committee Subject: [kmip] Locate by Value proposal   Hello All, Attached is the proposal for being able to Locate objects by their values in an analogous way that we can locate by attribute.  I would like to discuss this on this week's call.  However, any initial feedback would be most welcome. Regards, Anthony -- Anthony Berglas Ph.D. Principal Engineer Anthony.Berglas@Cryptsoft.com 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. -- Anthony Berglas Ph.D. Principal Engineer Anthony.Berglas@Cryptsoft.com -- Anthony Berglas Ph.D. Principal Engineer Anthony.Berglas@Cryptsoft.com


  • 5.  Re: [kmip] Locate by Value proposal

    Posted 11-17-2015 21:22
    Anthony, Interesting, but I would be hesitant to incorporate locate-by-value on cryptographic objects.  As David Featherstone noted in his comments, this almost seems a hacker use case. It may be that a server needs to evaluate incoming objects for matches in current materials already on the server, and reject duplicates.  The server can already do that, if its policy so dictates, without us baking it into the protocol.  One could add a new reason code to communicate this behavior, if really needed. And this would be going the opposite direction of NIST SP800-152 compliance, which is going to cause us to not only leave the cryptographic contents of the objects opaque but also to smudge up their attributes as well. Bruce A Rich brich at-sign us dot ibm dot com From:         Anthony Berglas <anthony.berglas@cryptsoft.com> To:         OASIS KMIP Technical Committee <kmip@lists.oasis-open.org> Date:         11/17/2015 05:35 AM Subject:         [kmip] Locate by Value proposal Sent by:         <kmip@lists.oasis-open.org> Hello All, Attached is the proposal for being able to Locate objects by their values in an analogous way that we can locate by attribute.  I would like to discuss this on this week's call.  However, any initial feedback would be most welcome. Regards, Anthony -- Anthony Berglas Ph.D. Principal Engineer Anthony.Berglas@Cryptsoft.com [attachment "LocateValueNov15-Ship.pptx" deleted by Bruce Rich/Austin/IBM] --------------------------------------------------------------------- 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