1 / 6

KMIP Server-to-server: use-cases and status

Marko Vukolic mvu@zurich.ibm.com , Robert Haas rha@zurich.ibm.com. contributors HP - Stan Feather stan.feather@hp.com (Dec 2, 2010). KMIP Server-to-server: use-cases and status. Server to server (s2s): Focal use cases. Propagating key material closer to endpoints, e.g.,

dai
Download Presentation

KMIP Server-to-server: use-cases and status

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Marko Vukolic mvu@zurich.ibm.com, Robert Haas rha@zurich.ibm.com contributors HP - Stan Feather stan.feather@hp.com (Dec 2, 2010) KMIP Server-to-server: use-cases and status

  2. Server to server (s2s): Focal use cases • Propagating key material closer to endpoints, e.g., • Example 1 (retail store) • A retail store operation with each store relying on encrypted storage • Network connectivity with the central key management server (CKMS) not reliable • Small subset of the keys needed to be served locally, but the management is at CKMS • Keys at local key-management servers could be read-only, with pre-allocated usage or lease time • The local server needs to communicate with the CKMS • Example 2 (e-commerce websites) • Multiple e-commerce websites centrally managed (CKMS) • Some keys need to be pushed down from CKMS (readable locally), i.e., with CKMS exporting the keys • Propagating key material updates towards the central key manager • A large multinational bank needs the information about cryptographic material from distributed Location B in central Location A (but not vice versa) • Business-partner data exchange • Propagation of keys between KMIP servers to facilitate business partner data exchange • Example 3 (Collaborative development with offline key exchange) • Company A creates data to be processed by Company B. • Both companies have KMIP servers, behind separate firewalls • Company A stores the data (eg, encrypted tapes) and delivers the data to Company B • Company A transmits wrapped keys to Company B. • Exported attributes may be more restrictive than for the local keys • Company B registers the keys and attributes on their server. • Company B uses keys. • B’s server enforces restrictions set by Company A • Example 4 (Collaboration, with direct key exchange) • Similar to example 3, but servers have network access across firewalls (potentially temporary) • Rather than Company B registering the keys, Server A uses Put to transfer keys to Server B

  3. Server to server (s2s): Focal use cases (continued) • Partitioning • A KMIP server needs to be partitioned into more servers • KMIP server acting as the gateway/proxy • A less capable KMIP server may need to proxy client’s request to the more capable KMIP server (e.g., to interact with a PKI)

  4. Server to server (s2s): Deferred and excluded use cases • Deferred use cases: • Replication (fault-tolerance) • Exchange of different server policies and their enforcement • M&A • A company acquires another and cryptographic objects from different KMIP servers need to be merged • Excluded use cases (to be handled via mechansims outside KMIP): • Backup, Data Loss Prevention • Load balancing/Delegation

  5. KMIP Implications of s2s: Summary • Useful operations are optional (Notify, Put) • KMIPv2: make Notify and Put mandatory for a s2s compliant KMIP server • KMIPv2:More attributes are needed • e.g., Master, Slaves • Other issues (KMIPv2) • UUID, Name collisions across different servers. • Locate does not return an indication to the client whether there are more objects matching the query, nor the means to “resume” such a Locate (KMIPv2) • Bulk export/import can be only partially emulated (using batched operations) • support for “Get All Attributes” (fixed in KMIPv1.0) • The behavior of Put when Replaced Unique Identifier ruuid is specified, but the object with ruuid does not exist on the remote end needs to be specified (fixed in KMIPv1.0) • Notify does not support notification about deleted attributes (fixed in KMIPv1.0) • Other issues (fixed in KMIPv1.0) • Cannot Locate all • Locate supports wildcards only for Name and Object group

  6. Next steps summary • Write up detailed scenarios around focal use-cases • Address server representation/registration (cf. client registration) • “Entity” to represent servers as well, incl. contact info (IP address) to facilitate communication • Define additional attributes • Master/Slave • Interact with AC (e.g., Slave permissions). Can a Slave perform read-only, or pre-allocated usage, or … • Say something about UUID, Name collisions across servers • Provide means to continue/resume a Locate

More Related