SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
|
| News: Cover Stories |  |  |
| OASIS Members Form Key Management Interoperability Protocol (KMIP) Committee. |
Contents
Nearby: Cryptographic Key Management
Recent Updates:
On October 14, 2010, OASIS announced the
approval
of the Key Management Interoperability Protocol (KMIP) Version 1.0 as an OASIS Standard. Developed through a collaboration of more than thirty (30) vendors and end user organizations, KMIP enables communication between key management systems and cryptographically-enabled applications, including email, databases, and storage devices.
On September 01, 2010, OASIS announced that members of the Key Management
Interoperability Protocol (KMIP) Technical Committee had submitted two approved Committee Specification documents for
consideration at OASIS Standard maturity level: Key Management Interoperability Protocol Specification Version
1.0 and Key Management Interoperability Protocol Profiles Version 1.0. Balloting for the two
specifications was scheduled for September 16-30, 2010. Note also companion specifications at CS 01 level: Key
Management Interoperability Protocol Usage Guide Version 1.0 (provides illustrative information on using the
protocol) and Key Management Interoperability Protocol Use Cases Version 1.0 (provides samples of protocol
messages corresponding to a set of defined test cases).
On April 29, 2010, OASIS announced a 15-day public review for the four Key Management Interoperability Protocol Version 1.0 specifications, through May 14, 2010. The documents for review include:
On November 05, 2009, the OASIS KMIP Technical Committee voted to accept four KMIP Version 1.0 specification documents at Committee Draft level and release them for public review. Public review was announced for December 01, 2009 through January 30, 2010. Subsequently, comments were organized for evaluation by the TC members and for disposition. At the same time, additional proposals were sent to the KMIP TC list for consideration in KMIP 1.0 and 2.0.
On February 12, 2009, Brocade, EMC/RSA, HP, IBM, LSI, NetApp, Seagate, and Thales e-Security submitted a draft charter proposal for the creation of an OASIS Key Management Interoperability Protocol (KMIP) Technical Committee.
KMIP "establishes a single, comprehensive protocol for communication between enterprise key management servers and cryptographic clients. By defining a protocol that can be used by any cryptographic client, ranging from a simple automated electric meter to very complex disk-arrays, KMIP enables enterprise key management servers to communicate via a single protocol to all cryptographic clients supporting that protocol. Through vendor support of KMIP, an enterprise will be able to consolidate key management in a single enterprise key management system, reducing operational and infrastructure costs while strengthening operational controls and governance of security policy. KMIP addresses the critical need for a comprehensive key management protocol built into the information infrastructure, so that enterprises can deploy effective unified key management for all their encryption, certificate-based device authentication, digital signature, and other cryptographic capabilities."
Initial supporting entities for KMIP included Brocade, Cisco, EMC/RSA, HP, IBM, LSI, NetApp, Seagate, and Thales e-Security. Additional statements of support have been received (corporate or individual) from 3PAR, Aetna, Akamai Technologies, Algorithmic Research (Arx), Axway Software, BeCrypt, Computer Associates (CA), CipherOptics, Cryptsoft, Dajeil, DigiCert, Election Systems and Software, Emulex, Exar Corporation, Freescale Semiconductor, International Electronic Communication Analysts (IECA), Lexmark International, MIT, Mitre Corporation, National Security Agency (NSA), NIST, Oracle, PayPal, PGP Corporation, PrimeKey Solutions, Quantum, Red Hat, SafeNet, Skyworth TTG, Sun Microsystems, Symantec, Target, US Department of Defense (DoD), Valicore, Venafi, Verisign, Voltage Security, Vormetric, and others.
A final approved KMIP TC Charter and Call for Participation was published on March 04, 2009. The KMIP First Meeting was scheduled to be held as a Face-to-Face meeting on April 24, 2009, from 9am PDT until 5pm PDT, at the West Mezzanine 274/276 in the Moscone Convention Center in San Francisco (RSA 2009 San Francisco Conference). A special code is available for a free conference pass for those not otherwise registered. Initial (some provisional) agenda items include nomination and election of KMIP TC (Co-)Chair(s); review and modify meeting agenda; presentation on submitted draft KMIP specification, usage guide and use cases; discuss a weekly TC meeting schedule, identification of questions/issues/changes/additions for KMIP V1.0 and future versions; [in addition to the deferred items listed in the KMIP Usage Guide '6.0 Deferred KMIP Functionality'], other potential items that have been suggested so far include: byte alignment within KMIP messages and enhanced capabilities for registering client-generated symmetric keys; setting priorities of identified issues and process for moving them to resolution; draft schedule leading to KMIP V1.0 public review, including agenda for next meeting, etc...
The Key Management Interoperability Protocol (KMIP) was initially developed by HP, IBM, RSA, and Thales e-Security in the 2007-2008 timeframe to meet the compelling needs of today's enterprise data centre environments; Brocade, LSI, and Seagate later joined the specification development effort. NetApp representatives were named in the KMIP TC proposal and as specification co-authors.
The OASIS KMIP Technical Committee (as chartered) "will develop specification(s) for the interoperability of key management services with key management clients. The specifications will address anticipated customer requirements for key lifecycle management (generation, refresh, distribution, tracking of use, life-cycle policies including states, archive, and destruction), key sharing, and long-term availability of cryptographic objects of all types (public/private keys and certificates, symmetric keys, and other forms of "shared secrets") and related areas."
The problem addressed by KMIP, according to the published FAQ document, is "primarily that of standardizing communication between encryption systems that need to consume keys and the key management systems that create and manage those keys. Being able to encrypt and retain access to data requires that encryption keys be generated and stored. To date, organizations deploying encryption have not been able to take advantage of interoperability across encryption and the key management systems. By defining a low-level protocol that can be used to request and deliver keys between any key manager and any encryption system, KMIP enables the industry to have any encryption system communicate with any key management system. Through this interoperability, enterprise will be able to deploy a single enterprise key management infrastructure to mange keys for all encryption systems in the enterprise that require symmetric keys, asymmetric keys pairs, certificates and other security objects..."
According to the announcement from the supporting companies, KMIP "was developed to support other industry standardization efforts and is complementary to application-specific standards projects such as IEEE 1619.3 (for storage needs) and OASIS EKMI (for XML needs)."
The KMIP protocol supports all reasonable key management system related cryptographic objects. This list currently [version 0.98] includes: (1) Symmetric Keys; (2) Split (multi-part) Keys; (3) Asymmetric Key Pairs and their components; (4) Digital Certificates; (5) Derived Keys; (6) Opaque (non-interpretable) cryptographic objects.
The Charter Proposal for the OASIS KMIP TC reports that the initial TC goal is to "define an interoperable protocol for standard communication between key management servers, and clients and other actors which can utilize these keys. Secure key management for TPMs [Trusted Platform Modules] and Storage Devices will be addressed. The scope of the keys addressed is enterprise-wide, including a wide range of actors: that is, machine, software, or human participants exercising the protocol within the framework. Actors for KMIP may include: Storage Devices, Networking Devices, Personal devices with embedded storage (e.g., Personal Computers, Handheld Computers, Cell Phones), Users, Applications, Databases, Operating Systems, Input/Output Subsystems, Management Frameworks, Key Management Systems, and Agents..."
Planned deliverables from the OASIS KMIP TC include: (1) Revised KMIP Specification which defines the normative expression of the protocol, including objects, attributes, operations and other elements; (2) Updated KMIP Usage Guide which provides illustrative and explanatory information on implementing the protocol, including authentication profiles, implementation recommendations, conformance guidelines and security considerations; (3) Revised document for KMIP Use Cases and Test Cases which supplies sample use cases for KMIP, test cases for implementing those use cases, and examples of the protocol implementing those test cases; (4) Updated KMIP FAQ Document to provide guidance on what KMIP is, the problems it is intended to address, and other frequently asked questions.
In conjunction with the KMIP announcement of February 12, 2009 and the proposed TC Charter, four KMIP documents were designated for contribution to the OASIS KMIP TC: KMIP Specification, Usage Guide, Use Cases, and FAQ document.
KMIP: Key Management Interoperability Protocol. [aka "Key Management Interoperability Protocol Specification"] Draft Version 0.98. Revised February 10, 2009. 108 pages. Edited by Robert Haas (IBM Zurich Research Laboratory, WWW) and Jeff Kravitz [WWW]. Corporate authors: Brocade, EMC, Hewlett Packard Development Corporation, IBM, NetApp, and Thales e-Security. Copyright © 2009 EMC, Hewlett Packard Development Corporation, IBM, and Thales e-Security. Contributors: David Babcock (HP), Steven Bade (IBM), Paolo Bezoari (NetApp), Mathias Björkqvist (IBM), Bruce Brinson (EMC), Christian Cachin (IBM), Tony Crossman (nCipher), Stan Feather (HP), Indra Fitzgerald (HP), Judy Furlong (EMC), Jon Geater (nCipher), Bob Griffin (EMC), Robert Haas (IBM - Editor), Timothy Hahn (IBM), Jack Harwood (EMC), Walt Hubis (LSI), Glen Jaquette (IBM), Jeff Kravitz (IBM - Editor), Michael McIntosh (IBM), Brian Metzger (HP), Anthony Nadalin (IBM), Elaine Palmer (IBM), Joe Pato (HP), René Pawlitzek (IBM), Subhash Sankuratripati (NetApp), Mark Schiller (HP), Martin Skagen (Brocade), Marcus Streets (nCipher), John Tattan (EMC), Karla Thomas (Brocade), Marko Vukolic (IBM), and Steve Wierenga (HP).
From the specification 'Introduction': "This document is intended as a specification of the protocol used for the communication between clients and servers to perform certain management operations on objects stored and maintained by a key management system. These objects will be referred to as Managed Objects in this specification. They include symmetric and asymmetric cryptographic keys, digital certificates, and templates used to simplify the creation of objects and control their use. Managed Objects are managed with operations that include the ability to generate cryptographic keys, register objects with the key management system, obtain objects from the system, destroy objects from the system, and search for objects maintained by the system. Managed Objects also have associated attributes, which are named values stored by the key management system and which can be obtained from the system via operations. Certain attributes may be changed, added or deleted, again by operations.
The protocol specified in this document includes several certificate-related functions for which there are a number of existing protocols — namely Validate (e.g., SVP or XKMS), Certify (e.g., CMP, CMC, SCEP) and Re-certify (e.g., CMP, CMC, SCEP). The protocol does not attempt to define a comprehensive certificate management protocol such as would be required for a certification authority. However, it does include functions that are needed in proxying certificate management functions through a key server..."
Managed Objects. Managed Objects are objects that are the subjects of key management operations, including all objects that may be registered with the system. Managed Cryptographic Objects are the subset of
Managed Objects that contain cryptographic material, e.g., certificates, keys, and secret data.
- Certificate: A Managed Cryptographic Object, which is a digital certificate, such as an encoded X.509
- Symmetric Key: A Managed Cryptographic Object which has a Key Block
- Public Key: A Managed Cryptographic Object, which is the public portion of an asymmetric key pair; this is a raw public key, not a certificate
- Private Key: A Managed Cryptographic Object, which is a the private portion of an asymmetric key pair
- Split Key: A Managed Cryptographic Object, which is a split key; a split key is a secret, usually a symmetric key or a private key that has been split into a number of parts, each of which can then be distributed to several key holders, for additional security
- Template: A named Managed Object containing the client-settable attributes of a Managed Cryptographic Object, essentially a stored, named list of attributes used in various operations
- Policy Template: A named Managed Object containing attributes, used to encapsulate all of the policy-related attributes into a Managed Object which may be independent of any single Managed Cryptographic Object
- Secret Data: A Managed Cryptographic Object containing a shared secret that is not a key or certificate, e.g., a password, where the Key Block used to contain Secret Data should contain a (possibly wrapped) Key Value of the Opaque type
- Opaque Object: A Managed Object that the key management server may not be able to interpret, but will store, where the context information for this object can be stored and retrieved using Custom Attributes
Protocol Operations. KMIP defines a set of standardized Operations that apply to Managed Objects that
consist of Attributes and possibly cryptographic material. Some twenty-six (26) Client-to-Server Operations are described in Section 4 of the KMIP 0.98 specification; two (2) Server-to-Client Operations (Notify, Put) are presented in Section 5. Summary:
- Create: An operation which requests the server to generate a new key as a Managed Cryptographic Object, containing information about the type of object being created, and some of the attributes to be assigned to the
object (e.g., Cryptographic Algorithm, Cryptographic Length)
- Create Key Pair: An operation which requests the server to generate a new public/private key pair and register the two corresponding new Managed Cryptographic Objects, containing attributes to be assigned to the objects (e.g., Cryptographic Algorithm, Cryptographic Length), where Attributes and Template Names can be specified for both keys at the same time, by specifying a Common Template-Attribute object in the request
- Register: An operation which requests the server to register a Managed Object (created by the client or obtained by the client through some other means), allowing the server to manage the object, where arguments in the request are similar to those in the Create operation, but also may contain the object itself, for storage by the server
- Re-key: A request used to generate a replacement key for an existing symmetric key, analogous to the Create operation, except that many of the attributes of the new key are unchanged from the original key
- Derive Key: A request used to derive a symmetric key using a key or secret that is already known to the key management system, applicable only to Managed Objects that can be used for key derivation; the Derive Key bit must be set in the Cryptographic Usage Mask attribute of the specified Managed Object
- Certify: A request used to obtain a new certificate for a public key, where only a single certificate can be requested at a time; server support for this operation is optional, as it requires that the key management system have access to a certification authority
- Re-certify: A request used to renew an existing certificate with the same key pair, where only a single certificate can be renewed at a time; server support for this operation is optional, as it requires that the key management system have access to a certification authority
- Locate: An operation which requests that the server searches for one or more Managed Objects, specified by one or more attributes,where all attributes are allowed to be used
- Check: An operation which requests that the server checks for the use of a Managed Object according to policy-related values specified in the request, used only when placed in a batched set of operations, usually following a Locate, Create, Create Pair, Derive Key, Certify, Re-Certify or Re-Key operation and followed by a Get operation
- Get: A request that the server return a Managed Object, which is specified in the request by its Unique Identifier
- Get Attributes: A request which returns one or more attributes of a Managed Object, where the object is specified by its Unique Identifier and the desired attributes are specified by name in the request
- Get Attribute List: A request which returns a list of the attribute names associated with a specified object; the object is specified by its Unique Identifier
- Add Attribute: A request which adds a new attribute (with possibly multiple values) and sets its value, containing the Unique Identifier of the Managed Object which the attribute pertains to, and the name and new value of the attribute
- Modify Attribute: A request which modifies the value of an existing attribute, containing the Unique Identifier of the Managed Object which the attribute pertains to, and the name, optional index, and new value of the attribute
- Delete Attribute: A request used to delete an attribute, containing the Unique Identifier of the Managed Object which the attribute pertains to, and the name, and optionally the Attribute Index of the attribute
- Obtain Lease: A request used to request a new Lease Time for a specified cryptographic object, where the Lease Time is an interval value that determines when the client's internal cache of information about the object expires and must be renewed
- Get Usage Allocation: A request is used to obtain an allocation from the current Usage Limits values, to allow the client to use the Managed
Cryptographic Object for protection purposes, applicable only to Managed Cryptographic Objects that can be used for
protection purposes (symmetric keys, private keys, public keys) and valid only if the Managed Cryptographic Object has a Usage Limits attribute
- Activate: A request used to activate a Managed Cryptographic Object, containing the unique identifier of the Managed Cryptographic Object
- Revoke: A request used to revoke a Managed Cryptographic Object, containing the unique identifier of the Managed Cryptographic Object and a reason for the revocation, e.g., 'compromised', 'no longer used', etc.
- Destroy: A request used to indicate to the server that the key material for the specified Managed Cryptographic Object should be destroyed, where the meta-data for the key material may be retained by the server
- Archive: A request used to specify that a Managed Object is now permitted to be placed in archival storage, where actual time when the object is placed in archival storage and the location of the archive or level of archive hierarchy are determined by the policies within the key management system, and are not specified by the client
- Recover: A request used to obtain access to a Managed Object that has been placed in archival storage, and may require asynchronous polling to obtain the response
- Validate: An operation requesting that the server validate a certificate chain, and return information on its validity, where only a single certificate chain may be included; the request may contain a list of certificate objects, and/or a list of Unique Identifiers which identify Managed Certificate objects
- Query: A request is used by the client to interrogate the server to determine its capabilities and/or protocol mechanisms, where the Query Function field in the request may contain (one of) Query Operations, Query Objects, or Query Server Information
- Cancel: A request is used to cancel an outstanding asynchronous operation, where the correlation value of the original operation must be specified in the request
- Poll: A request is used to poll the server in order to obtain the status of an outstanding asynchronous operation
- Notify: Server-to-Client operation is used to notify a client of events, only sent by a server to a client outside the normal client request/response protocol
- Put: Server-to-Client operation is used to 'push' Managed Cryptographic Objects to clients, only sent by a server to a client outside the normal client request/response protocol
Attributes. KMIP Specification Section 3 ("Attributes") describes attributes that are associated with Managed Objects. Managed objects include: Certificate, Symmetric Key, Public Key, Private Key, Split Key, Template, Policy Template, Secret Data, and Opaque Object. The attributes may be obtained by a client from the server using the Get Attribute operation. Some attributes may be set by the Add Attribute operation or updated by the Modify Attribute operation, and some may be deleted by the Delete Attribute operation if they no longer apply to the Managed Object. When attributes are returned by the server, e.g., via a Get Attributes operation, the returned attribute value may differ depending on the client. For example, the Cryptographic Usage Mask value may be different for different clients, depending on the policy of the server. Similarly, when a client modifies an attribute, this is merely a mechanism for sending information to the server. The server may store the attribute as received, or modify the attribute before saving it, or combine it with information from other sources, or merely use it as advice on how to modify its internal knowledge of the cryptographic object. The choice depends on server functionality, policy, and the kind of attribute being modified."
Summary of Managed Object attributes:
- Unique Identifier: generated by the key management system to uniquely identify a Managed Object
- Name: used to identify and locate the object, assigned by the client
- Object Type: type of a Managed Object, e.g., public key, private key, symmetric key, etc
- Cryptographic Algorithm: cryptographic algorithm used by the object, e.g., RSA, DSA, DES, 3DES, AES, etc.
- Cryptographic Length: the length in bits of the cryptographic key material of the Managed Cryptographic Object
- Cryptographic Parameters: a structure that contains a set of optional fields that describe certain cryptographic parameters to be used when performing cryptographic operations using the object
- Certificate Type: type of a certificate, e.g., X.509, PGP, etc.
- Certificate Issuer: identification of a certificate, containing the Issuer Distinguished Name (from the Issuer field of the certificate) and the Certificate Serial Number (from the Serial Number field of the certificate)
- Certificate Subject: contains the Subject Distinguished Name (from the Subject field of the certificate) optionally including one or more alternative names (e.g., email address, IP address, DNS name)
- Digest: A digest of the key (digest of the Key Material), certificate (digest of the Certificate Value), or opaque object (digest of the Opaque Data Value)
- Operation Policy Name: indication of what entities may perform which key management operations on the object
- Cryptographic Usage Mask: is a bit mask which indicates to the client which cryptographic functions may be performed using the key
- Lease Time: defines a time interval for a Managed Object that indicates how long a client should use the object
- Usage Limits: a mechanism for limiting the usage of a Managed Cryptographic Object
- State: an indication of the state of an object as known to the key management server, where an object may be in one of six states at any given time, as described in NIST Special Publication 800-57
- Initial Date: date and time when the Managed Cryptographic Object was first created or registered at the server
- Activation Date: date and time when the Managed Cryptographic Object may begin to be used
- Process Start Date: date and time when a Managed Symmetric Key Object may begin to be used for process purposes, e.g., decryption or unwrapping, depending on the value of its Cryptographic Usage Mask attribute
- Protect Stop Date: date and time when a Managed Symmetric Key Object may no longer be used for protect purposes
- Deactivation Date: The date and time when the Managed Cryptographic Object may no longer be used for any purpose, except for decryption, signature verification, or unwrapping...
- Destroy Date: date and time when the Managed Cryptographic Object was destroyed
- Compromise Occurrence Date: date and time when the Managed Cryptographic Object was first believed to be compromised
- Compromise Date: date and time when the Managed Cryptographic Object is entered into the compromised state
- Revocation Reason: indication of why the Managed Cryptographic Object was revoked, e.g., 'compromised', 'expired', 'no longer used', etc.
- Archive Date: date and time when the Managed Object was placed in archival storage
- Object Group: group name, where an object may be part of a group of objects
- Link: A link from a Managed Cryptographic Object to another, closely related target Managed Cryptographic Object
- Application Specific Identification: used to specify the intended use of a Managed Object
- Contact Information: optional attribute, where content is used for contact purposes only
- Last Changed Date: date and time of the last change to the contents or attributes of the specified object
- Custom Attribute: user-defined attribute and intended for vendor-specific purposes
Key Management Interoperability Protocol Usage Guide. Draft Version 0.98. Revised February 10, 2009. 22 pages. Copyright © 2009 Brocade, EMC, Hewlett Packard Development Corporation, IBM, LSI, NetApp, and Thales e-Security.
This Guide is intended to complement the Key Management Interoperability Protocol Specification by providing guidance on how to implement KMIP most effectively to ensure interoperability. In particular, it includes the following guidance: (1) Clarification of assumptions and requirements that drive or influence the design of KMIP and implementation of KMIP-compliant key management. (2) Definition of required and optional profiles for authentication and communication privacy between KMIP participants — clients and servers. (3) Specific recommendations for implementation of particular KMIP functionality. (4) Clarification of mandatory and optional capabilities for conformant implementations. (5) Functionality considered for inclusion in KMIP V1.0 but deferred to subsequent versions of the standard. (6) Further assistance for implementing KMIP is provided by the Use Cases document that describes a set of recommended test cases and provides the TTLV (Type/Tag/Length/Value) format for the message exchanges defined by those use cases.
Section 2.0 ("Assumptions") describes assumptions that underlie the KMIP protocol and implementation of clients and servers that utilize the protocol. Summary:
- Islands of Trust: Clients are necessarily given key material but they must only use that keying material for the purposes explicitly listed in the delivery payload.
- Message Security: KMIP relies on TLS/SSL to authenticate the client and on the underlying protocol to provide confidentiality, integrity, message authentication and protection against replay attack.
- State-less Server: The protocol operates on the assumption that the server is state-less, which means that there is no concept of 'sessions' inherent in the protocol.
- Extensible Protocol: The protocol provides for 'private' or vendor-specific extensions, which allow for differentiation among vendor implementations.
- Support for Cryptographic Objects: The protocol supports all reasonable key management system related cryptographic objects.
- Client-Server Message-based Model: The protocol operates primarily in a client-server, message-based model; the exceptions are the Put and Notify operations.
- Synchronous and Asynchronous Messages: The protocol allows both modes of operation.
- Support for 'Intelligent Clients' and 'Key Using Devices': The protocol supports intelligent clients, such as end-user workstations, which are capable of requesting all of the functions of KMIP.
- Batched Requests and Responses: The protocol contains a mechanism for sending batched requests and receiving batched responses, to allow for higher throughput on operations that deal with a large number of
entities.
- Reliable Message Delivery: The reliable message delivery function is relegated to the transport protocol, and not part of the key management protocol itself.
- Large Responses: For requests that are capable of large responses, a mechanism in the protocol allows a client to specify in a request the maximum allowed size of a response.
- Key Life-cycle and Key State: The KMIP Specification describes the key life-cycle model, based on the NIST 800-57 key state definitions, supported by the KMIP protocol.
Section 3.0 ("KMIP Profiles") section describes two KMIP profiles. These profiles describe mechanisms by which
authentication and communications privacy are established outside KMIP. Both profiles must be supported by any conforming implementation of KMIP.
- SSL/TLS Profile (Mandatory): Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide secure communications for data transfers, using cryptographic mechanisms to provide both authentication of participants and privacy of the communication. SSL 2.0 has known security issues and all current implementations of HTTP/S support more recent protocols. Therefore this profile prohibits the use of SSL 2.0 and recommends SSL 3.1 or TLS 1.0.
- HTTPS Profile: Hypertext Transfer Protocol over Secure Socket Layer or https is a URI (Universal
Resource Indicator) scheme used to indicate a secure HTTP connection, requiring a different default TCP port (443) and an additional encryption and authentication layer, implemented by SSL/TLS, between HTTP and TCP. As in the SSL/TLS profile, the client certificate used in the SSL session must be included
in any client-initiated KMIP messages between the client and server as the value of the
Credentials object in the message, with credential type of certificate...
Section 4.0 ("Usage Guidelines") is the most substantial section, providing guidance on using the functionality described in the Key Management Interoperability Protocol Specification. For example:
- Authentication
- Authorization for Revoke, Recover, Delete and Archive Operations
- Using Notify and Put Operations
- Usage Allocation
- Key State and Times
- Templates
- Archive Operations
- Message Extensions
- Unique Identifiers
- Result Message Text
- Certificate Transitions
- Query
- Canceling Asynchronous Operations
- Multi-instance Hash
- Returning Related Objects
- Reducing Multiple Requests through Use of Batch
- Maximum Message Size
- Using Offset in Re-key and Re-certify Operations
- Locate Queries
- ID Placeholder
- Using Wrapped Keys with KMIP
Section 5.0 ("Conformance") clarifies (e.g.,) that "server implementations of the KMIP protocol must support all objects, attributes, operations and profiles not specified as optional in the KMIP Specification in order to be conformant to the specification. Server implementations that do not support objects,
attributes, operations and profiles defined as optional can claim KMIP conformance, though they may be limited in terms of interoperability with other KMIP implementations...
Section 6.0 ("Deferred KMIP Functionality") identifies missing items that have been judged candidates for
future inclusion in the specification:
- Registration of Clients
- Client-requested specification of additional clients allowed to use a key
- Registration of Notifications
- Key Migration
- Server to Server key management
- Specification by client of key encoding
- Multiple derived keys
- XML encoding
Key Management Interoperability Protocol Use Cases. [aka "KMIP Use Cases for Proof of Concept Testing"] Draft Version 0.98. Revised February 10, 2009. 63 pages. Edited by Mathias Björkqvist (IBM Zurich Research Laboratory) and René Pawlitzek (IBM Zurich Research Laboratory). Contributors (From Section 2, "Acknowledgments"): David Babcock (HP), Paolo Bezoari (NetApp, Joseph Birr-Pixton (Thales/nCipher, Mathias Bjvrkqvist (IBM - Editor), John Clark (HP), Stan Feather (HP), Jon Geater (nCipher), Bob Griffin (EMC), Robert Haas (IBM), Jack Harwood (EMC), Walt Hubis (LSI), Vlad Libershteyn (HP), Mark Lin (EMC/RSA), Brian Metzger (HP), Madhav Mutalik (EMC/RSA), Anthony Nadalin (IBM), Reni Pawlitzek (IBM - Editor), Subhash Sankuratripati (NetApp Martin Skagen (Brocade), Bruce Rich (IBM), Parameswaran Seshan (EMC/RSA), John Tattan (EMC), Karla Thomas (Brocade).
"The purpose of this document is to describe use cases to demonstrate the Key Management Interoperability Protocol (KMIP). The use cases shall indicate if all concepts within the protocol are sound and can be used to implement typical scenarios in real life. These use cases are not intended to fully test an implementation of KMIP. Thus, the use-cases do not contain typical QA scenarios which would stress an implementation. The use cases are based on Version 0.98 of the protocol. Message exchange: The message exchange between clients and the server to test the following use-case scenarios shall happen with TLV encoding over the HTTP transport. Use cases are provided for: (1) Centralized Management. Basic functionality use cases test the basic features of KMIP including key and template creation, attribute functionality, access methods, and batch operation [Use-case: Create / Destroy, Use-case: Register / Create / Get attributes / Destroy, Use-case: Create / Locate / Get / Destroy, Use-case: Dual client use-case, ID Placeholder linked Locate and Get batch]; Use case 'asynchronous locate' tests the asynchronous capabilities of KMIP using locate. (2) Key life cycle support [Usecase: revoke scenario]. (3) Auditing and reporting. Use case: 'get usage allocation scenario'tests the usage management functionality of KMIP. (4) Key Interchange, Key Exchange [Use case: Import of a Third-party Key] (5) Vendor Extensions. These use cases test the handling of unknown message extensions with vendor-specific content. (6) Asymmetric keys: Creation of keys using 'Create Key Pair' operation, locating pair using Link attribute. (7) Key Roll-over: These use-cases test manual key roll-over using the 'Re-key' operation. In particular, they test the formatting of the Re-key command, the handling and server-side processing of the various Time attributes and the setting of some other attributes that are not automatically copied from the existing key to the new key. (8) Archival: These use cases test archiving and locating keys using the off-line indicator. The Archive and Recover operations may be performed asynchronously, in which case the client must Poll the server until the operations complete. The client must also indicate in the request that it supports asynchronous responses..." Key Management Interoperability Protocol (KMIP) FAQ Document. Version 0.98. Revised February 10, 2009. 2 pages. Produced by representatives from Brocade, EMC, HP, IBM, LSI, Netapp, Seagate, and Thales. This document supplies answers to twelve (12) KMIP frequently asked questions.
This text is adapted from the full text of the Charter and Call for Participation, which contains detailed information on how to join as an OASIS Member, how to join the KMIP TC, and how to gain TC voting rights as of the First TC Meeting. References are provided to the canonical source files for the 'Call for Participation' in plain text format. See also, earlier, the KMIP TC (Draft) Charter Proposal.
Contents
Charter and Call For Participation: OASIS KMIP Technical Committee
TC Name
OASIS Key Management Interoperability Protocol (KMIP) Technical Committee
Statement of Purpose
The KMIP Technical Committee will develop specification(s) for the interoperability of key management services with key management clients. The specifications will address anticipated customer requirements for key lifecycle management (generation, refresh, distribution, tracking of use, life-cycle policies including states, archive, and destruction), key sharing, and long-term availability of cryptographic objects of all types (public/private keys and certificates, symmetric keys, and other forms of "shared secrets") and related areas.
Scope
The initial goal is to define an interoperable protocol for standard communication between key management servers, and clients and other actors which can utilize these keys. Secure key management for TPMs (Trusted Platform Modules) and Storage Devices will be addressed. The scope of the keys addressed is enterprise-wide, including a wide range of actors: that is, machine, software, or human participants exercising the protocol within the framework. Actors for KMIP may include:
- Storage Devices
- Networking Devices
- Personal devices with embedded storage (e.g., Personal Computers, Handheld Computers, Cell Phones)
- Users
- Applications
- Databases
- Operating Systems
- Input/Output Subsystems
- Management Frameworks
- Key Management Systems
- Agents
Out of Scope
Out of scope areas include:
- Implementation specific internals of prototypes and products
- Multi-vendor Key Management facility mirrors or clusters
- Definition of an architectural design for a central enterprise key management or certificate management system other than any necessary models, interfaces and protocols strictly required to support interoperability between Actors in the multi-vendor certificate and key management framework
- Framework interfaces not dedicated to secure key and certificate management
- Certain areas of functionality related to key management are also outside the scope of this technical committee, in particular registration of clients, server-to-server communication and key migration
- Bindings other than tag-length-value wire protocol and XSD-based encodings
List of Deliverables
The deliverables for the KMIP Technical Committee are anticipated to include the following:
Revised KMIP Specification v0.98. This provides the normative expression of the protocol, including objects, attributes, operations and other elements. A Committee Specification is scheduled for completion within twelve (12) months of the first TC meeting. Revised KMIP Usage Guide v0.98. This provides illustrative and explanatory information on implementing the protocol, including authentication profiles, implementation recommendations, conformance guidelines and security considerations. A Committee Specification is scheduled for completion within twelve (12) months of the first TC meeting. Revised KMIP Use Cases and Test Cases v0.98. This provides sample use cases for KMIP, test cases for implementing those use cases, and examples of the protocol implementing those test cases. A Committee Specification is scheduled for completion within twelve (12) months of the first TC meeting. Revised KMIP Frequently Asked Questions. This document provides guidance on what KMIP is, the problems it is intended to address and other frequently asked questions.
KMIP, as defined in the above deliverables, will be scoped to include the following:
1) Comprehensive Key and Certificate Lifecycle Management Framework
A. Lifecycle Management Framework to Include:
- Provisioning of Keys and Certificates
- Creation
- Distribution
- Exchange/Interchange
- Auditing
- Reporting
- Logging (Usage tracking)
- Backup
- Restore
- Archive
- Update/Refresh
- Management of trust mechanisms between EKCLM (Enterprise Key and Certificate Lifecycle Management) actors only as necessary to support EKCLM
B. Comprehensive Key and Certificate Policy Framework to include:
- Creation
- Distribution
- Exchange/Interchange
- Auditing
- Reporting
- Logging (Usage tracking)
- Backup
- Restore
- Archive
- Update/Refresh
- Expectation of Policy Enforcement
- At endpoints
- At Key Manager
- At intermediaries between endpoints and Key Manager facility
C. Interoperability between Machine Actors in performing all aspects of A) and B), and addressing:
- pre-provisioning and late binding of keys and certificates
- support for hierarchical or delegation or direct models
- actor discovery and enrollment as necessary to support ECKLM
- key, certificate and policy migration
- audit and logging facilities
D. General Capabilities may include:
- Secure and Robust Mechanisms, Techniques, Protocols and Algorithms
- Recovery capabilities, only as needed by interoperable interfaces, anticipating power failure, or other common failures of automated Actors
- Forward compatibility considerations
- Interface to Identity Management facilities as necessary for A) and B)
- Interface to Enterprise Directory facilities as necessary for A) and B)
2) KMIP TC will also support activities to encourage adoption of KMIP.
This would likely include:
- Interoperability sessions to test effectiveness of the specification
- Reference implementations of KMIP functionality
OASIS IPR Mode
IPR Mode under which the TC will operate:
The KMIP TC is anticipated to operate under RF on RAND IPR Mode.
Audience
Anticipated audience or users.
KMIP is intended for the following audiences:
- Architects, designers and implementers of providers and consumers of enterprise key management services.
Language
Work group business and proceedings will be conducted in English.
Similar Work
Identification of similar or applicable work.
Similar work is currently underway in several other organizations:
OASIS EKMI TC. We see KMIP TC as addressing a broader scope than the primarily symmetric key focused EKMI, providing a more comprehensive protocol in which SKSML can potentially participate. IEEE P1619.3. We see KMIP TC as addressing a broad scope than the primarily storage-related P1619.3. TCG Infrastructure Working Group. We see KMIP TC as addressing a broader scope than the primarily TPM related TCG IWG. IETF Keyprov. We see KMIP TC as addressing a broader scope than the primarily mobile-related IETF Keyprov.
KMIP TC intends to establish liaisons with each of these organizations and may also establish liaisons with other organizations that are identified as focused on similar or applicable work.
First Meeting
Date, time, and location of the first meeting:
The date for the first meeting is April 24th 2009, from 9am PDT until 5pm PDT, to be held as a Face-to-Face meeting in San Francisco in conjunction with the RSA Conference [URI. See details: Friday, 24-April-2009. Time: 09:00am - 05:00pm PDT. Meeting Logistics: West Mezzanine 274/276 in the Moscone Convention Center in San Francisco for Friday 24-April-2009. A special code is available for a free conference pass for those not otherwise registered. Dial-in information for those not able to attend in person will be posted.]
Meeting Schedule
Projected ongoing meeting.
Conference calls will be held weekly, to be sponsored by one or more of the companies proposing the KMIP TC. These conference calls will be complemented by the following:
- Face to face meetings as determined by the KMIP TC.
- General communication will be via email reflectors with archiving provided by the KMIP TC.
- KMIP TC progress will be communicated via a KMIP TC web page.
- The KMIP TC will communicate (conference calls, joint working sessions, etc.) with external groups as appropriate.
- The KMIP TC will communicate (conference calls, joint working sessions etc.) with internal OASIS groups (other TCs) as appropriate.
TC Supporters
Names, electronic mail addresses, and membership affiliations of at least Minimum Membership:
- Robert Griffin, EMC/RSA, Robert.griffin@rsa.com
- Robert Philpott, EMC/RSA, Robert.philpott@rsa.com
- Mark Schiller, HP, mark.schiller@hp.com
- Jishnu Mukerji, HP, jishnu@hp.com
- Anthony Nadalin, IBM, drsecure@us.ibm.com
- Robert Haas, IBM, rha@zurich.ibm.com
- Walt Hubis, LSI, walt.hubis@lsi.com
- Jon Geater, Thales, jon.geater@thales-esecurity.com
- Marcus Streets, Thales, marcus.streets@thales-esecurity.com
- Martin Skagen, Brocade, mskagen@brocade.com
- Karla Thomas, Brocade, karlat@brocade.com
- Scott Kipp, Brocade, skipp@brocade.com
- Subhash Sankuratripati, NetApp, Subhash@netapp.com
- Paolo Bezoari, NetApp, Bezoari@netapp.com
- Dave B Anderson, Seagate, dave.b.anderson@seagate.com
- Landon Curt Noll, Cisco, chongo@cisco.com
Convenor
The name of the Convenor who must be an Eligible Person:
Robert Griffin (EMC)
Affiliated OASIS Member Section
The name of the Member Section with which the TC intends to affiliate, if any:
The KMIP TC intends to affiliate with the IDtrust Member Section.
Contributions to the TC
List of contributions of existing technical work that the proposers anticipate will be made to this TC:
FAQ Document
Frequently Asked Questions (FAQ) document:
See preceding list of contributions.
Specification Working Title
Proposed working title and acronym for the specification(s) to be developed by the TC:
- KMIP Specification
- KMIP Usage Guide
- KMIP Use Cases and Test Cases
- KMIP FAQ
Source: KMIP TC Call for Participation
From the complete text of the announcement by the developers of the KMIP Version 0.98 specification: "Leading Organizations Unveil New Interoperability Specification for Encryption Key Management to Aid IT Security, Compliance and Data Recovery. Brocade, EMC, HP, IBM, LSI, Seagate, and Thales Work to Remove Barriers to Encryption Across Data Center Systems by Submitting New Specification to OASIS."
See also the announcement as published by EMC/RSA, HP, IBM (English, German), LSI, nCipher, and Thales e-Security.
February 12, 2009.
Brocade, HP, IBM, LSI, RSA — The Security Division of EMC, Seagate, and Thales (formerly nCipher) today announced the creation of a jointly developed specification for enterprise key management that is engineered to dramatically simplify how companies encrypt and safeguard information. The companies — leaders in enterprise computing, storage, and security — developed the Key Management Interoperability Protocol (KMIP) in response to customers' needs to enable the widespread use of encryption. The companies intend to submit KMIP to OASIS (Organization for the Advancement of Structured Information Standards) for advancement through the organization's open standards process.
KMIP was developed by HP, IBM, RSA, and Thales to meet the compelling needs of today's enterprise data centre environments, with Brocade, LSI, and Seagate joining the effort. All seven companies will now be devoting time and resources to OASIS for ongoing development.
According to IDC [1], 44 percent of enterprises plan to encrypt more than 75 percent of their data by 2009, and one of the top two issues related to deploying encryption is the ability to recover the data [2].
"The use of encryption is widely recognized as the best method for protecting valuable information and enabling compliance with industry and government regulations," says Charles Kolodgy, research director at IDC. "Time and time again, our research shows the primary barrier to the widespread use of encryption is the fear that encrypted data will be lost — slowing the adoption of encryption. Users are demanding strong key management systems and advancing this work through the open standards process offers tangible benefits for vendors, developers and enterprises alike."
Companies often deploy separate encryption and key management systems for different business uses, such as laptops, storage, databases and applications, and until now cumbersome — often manual — efforts were necessary to generate, distribute, vault, expire, and rotate encryption keys. This has resulted in increased costs for IT, difficulty meeting audit and compliance requirements, and lost data.
"The IT community is asking for open standards and interoperability to help meet the increasing demand for encryption," says Laurent Liscia, executive director of OASIS. "We applaud Brocade, HP, IBM, LSI, RSA, Seagate, and Thales for choosing to advance KMIP through the open standards process, and we encourage others in the security community — both users and providers — to participate in the standardization of this very important work."
Developed by leading enterprise storage, systems and security vendors, KMIP is designed to provide a single, comprehensive protocol for communication between enterprise key management services and encryption systems. Brocade, HP, IBM, LSI, RSA, Seagate, and Thales are committed to delivering KMIP-enabled solutions. By taking advantage of KMIP-enabled software and devices, companies will be able to cut operational costs and reduce risk by removing redundant, incompatible key management processes.
Streamlined key management is essential in a wide variety of data management processes. For example, the data recovery process requires locating encryption keys quickly even for tapes created weeks or months earlier. At the same time, this efficiency must not impact the security of keys or violate corporate policies regarding how keys are stored and distributed . KMIP enables vendors to address this need for enterprise-wide key management, providing customers with better data security and decreased expenditures on multiple key management products and operations.
KMIP is the first specification for enterprise key management that is ready for adoption. It was developed to support other industry standardization efforts and is complementary to application-specific standards projects such as IEEE 1619.3 (for storage needs) and OASIS EKMI (for XML needs).
About the Key Management Interoperability Protocol (KMIP)
KMIP enables key lifecycle management. KMIP can be used by both legacy and new encryption applications, supporting symmetric keys, asymmetric keys, digital certificates, and other "shared secrets." KMIP offers developers templates to simplify the development and use of KMIP-enabled applications.
KMIP defines the protocol for encryption client and key management server communication. Key lifecycle operations supported include generation, submission, retrieval, and deletion of cryptographic keys. Vendors intend to deliver KMIP-enabled encryption applications that support communication with compatible KMIP key management servers.
More information can be found at: http://xml.coverpages.org/KMIP/.
[1] IDC, Data Protection Study: Data Encryption Option, Document #207606, June 2007
[2] IDC, IDC Encryption Usage Survey, Document #213646, August 2008
About EMC
EMC Corporation (NYSE: EMC) is the world's leading developer and provider of information infrastructure technology and solutions that enable organizations of all sizes to transform the way they compete and create value from their information. Information about EMC's products and services can be found at www.EMC.com.
EMC Canada (http://www.EMC2.ca), headquartered in Toronto with nine offices from coast to coast, is a wholly owned subsidiary of EMC Corporation.
About Brocade
Brocade (Nasdaq: BRCD) develops extraordinary networking solutions that enable today's complex, data-intensive businesses to optimize information connectivity and maximize the business value of their data. For more information, visit http://www.brocade.com.
About HP
HP, the world's largest technology company, simplifies the technology experience for consumers and businesses with a portfolio that spans printing, personal computing, software, services and IT infrastructure. More information about HP (NYSE: HPQ) is available at http://www.hp.com/.
About IBM
For more information, please visit www.ibm.com.
About LSI
LSI Corporation (NYSE: LSI) is a leading provider of innovative silicon, systems and software technologies that enable products, which seamlessly bring people, information and digital content together. The company offers a broad portfolio of capabilities and services including custom and standard product ICs, adapters, systems and software that are trusted by the world's best known brands to power leading solutions in the Storage and Networking markets. More information is available at http://www.lsi.com.
About RSA
RSA, The Security Division of EMC, is the premier provider of security solutions for business acceleration, helping the world's leading organizations succeed by solving their most complex and sensitive security challenges. RSA's information-centric approach to security guards the integrity and confidentiality of information throughout its lifecycle — no matter where it moves, who accesses it or how it is used. RSA offers industry-leading solutions in identity assurance and access control, data loss prevention, encryption & key management, compliance and security information management and fraud protection. These solutions bring trust to millions of user identities, the transactions that they perform, and the data that is generated. For more information, please visit http://www.rsa.com and http://www.emc.com.
About Seagate
Seagate is the worldwide leader in the design, manufacture and marketing of hard disk drives and storage solutions, providing products for a wide-range of applications, including Enterprise, Desktop, Mobile Computing, Consumer Electronics and Branded Solutions. Seagate's business model leverages technology leadership and world-class manufacturing to deliver industry-leading innovation and quality to its global customers, with the goal of being the time-to-market leader in all markets in which it participates. The company is committed to providing award-winning products, customer support and reliability to meet the world's growing demand for information storage. Seagate can be found around the globe and at http://www.seagate.com.
For more information about Seagate's Self-Encrypting Drive security solutions, visit http://www.sedsecuritysolutions.com.
About Thales
Thales is a leading international electronics and systems group, addressing defense, aerospace and security markets worldwide. Thales's leading-edge technology is supported by 22,000 R&D engineers who offer a capability unmatched in Europe to develop and deploy field-proven mission-critical information systems. To this end, the group's civil and military businesses develop in parallel and share a common base of technologies to serve a single objective: the security of people, property and nations. The group builds its growth on its unique multi-domestic strategy based on trusted partnerships with national customers and market players, while leveraging its global expertise to support local technology and industrial development. Thales employs 68,000 people in 50 countries with 2007 revenues of € 12.3 billion. See: http://www.thalesgroup.com.
The Key Management Interoperability Protocol (KMIP) is one of several cryptographic key management specifications. Related initiatives include the following:
ANSI X9 Financial Industry Standards. The Accredited Standards Committee X9 (ASC X9) has the mission to develop, establish, maintain, and promote standards for the Financial Services Industry in order to facilitate delivery of financial services and products. Key management in the ANSI X9 context means key generation, key distribution, key life cycle facility requirements, modes, IVs (cipher initial values), and message formats. ANSI X9 has published many specifications in the key management space, for: [1] Key Management Protocols (e.g., X9.69 Framework for Key Management Extensions, X9.70 Symmetric Key Distribution Using Public Key, X9.73 Cryptographic Message Syntax, X9.77 Public Key Infrastructure Protocols) [2] Retail Key Management: (e.g., X9.24 Symmetric Key Management, X9.65 Triple Data Encryption Algorithm (TDEA) Implementation, X9.69 Key Extensions) [3] Public Key Cryptography: (e.g., X9.30 Public Key Cryptography Using Irreversible Algorithms (1-2), X9.31 Digital Signatures Using Reversible Public Key Cryptography). DMTF Security Modeling Working Group. The DMTF Security [Modeling] Working Group is creating Credential Profiles, where a Profile is a specification that normatively defines the data model interface between a WBEM Server and a WBEM Client. This includes Abstract and Specialized Profiles. DSP 1082 Credential Management Profile (Abstract Profile) provides a capability to represent and manage credentials in a managed system. Use case: Definition for the generic CIM model for managing different credentials. DSP 1096 Certificate Management Profile (Specialized Profile) provides capability to represent and manage X509 certificates. Use cases: (1) Import/management of asymmetric keys; (2) Management of key stores; (3) PKS#10 Request for certificate signing requests (CSR) generation; (4) Export/import/management of X509 certificates and certificate revocation lists (CRL)... (Examples) Import Asymmetric Key to Keystore, Import and Export X509 Certificates... GlobalPlatform Key Management System. GlobalPlatform provides a universally recognized and globally implemented suite of smart card specifications, together with market and application specific configurations of those specifications and supporting documents... The Systems Committee's Key Management System (KMS) Working Group seeks "(1) to define interfaces between Key Management Systems (KMS), enabling control of key usage and ensuring interoperability between systems that share keys during the lifecycle of GlobalPlatform cards and applications; (2) To develop, maintain and evolve the KMS Requirements Specification..." The document GlobalPlatform Key Management System Functional Requirements (Version 1.0, November 2003) is available from the GP Systems Specifications repository. IEEE P1619.3 Security in Storage Working Group (SISWG), Key Management. The IEEE Security in Storage Working Group (SISWG) is working on standards related to encrypted storage media, including both encryption and key management. Membership is open to anyone... IEEE Project P1619.3: "Key Management" was approved in February 2007 to develop a Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data. This project was chartered through December 31, 2011. The goals of the Key Management group are to: (1) Create a standard that allows secure interchange of encryption keys between devices that encrypt stored data and devices that manage keys; (2) Understand existing standards and use where possible to expedite the creation of this standard; (3) Raise public awareness of P1619.3 and encourage adoption; (4) Facilitate interchange by providing open source reference implementations. On February 18, 2009, Matt Ball announced the availability of IEEE P1619.3/D6, edited by Bob Lockhart. The draft is available for comment through March 20, 2009. Details: IEEE P1619.3/D6. Draft Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data, prepared by the IEEE Security in Storage Working Group of the Computer Society Information Assurance Committee (Unapproved IEEE Standards Draft, 90 pages). IETF Provisioning of Symmetric Keys (KEYPROV) Working Group. The scope of this IETF working group is "to define protocols and data formats necessary for provisioning of symmetric cryptographic keys and associated attributes. The group is considering use cases related to use of Shared Symmetric Key Tokens. Other use cases may be considered for the purpose of avoiding unnecessary restrictions in the design and ensure the potential for future extensibility..." As of 2009-02, the IETF KEYPROV Working Group was co-chaired by Phillip Hallam-Baker (Verisign) and Hannes Tschofenig (NSN - FI/Espoo) within the IETF Security Area, directed by Tim Polk (NIST) and Pasi Eronen (Nokia). I-Ds have been produced for the protocol ("Dynamic Symmetric Key Provisioning Protocol - DSKPP") and two container formats ("Symmetric Key Package Content Type", "Portable Symmetric Key Container - PSKC"). IETF KEYPROV Working Group Description: "Current developments in deployment of Shared Symmetric Key (SSK) tokens have highlighted the need for a standard protocol for provisioning symmetric keys. The need for provisioning protocols in PKI architectures has been recognized for some time. Although the existence and architecture of these protocols provides a feasibility proof for the KEYPROV work assumptions built into these protocols mean that it is not possible to apply them to symmetric key architectures without substantial modification. In particular, the ability to provision symmetric keys and associated attributes dynamically to already issued devices such as cell phones and USB drives is highly desirable. The working group will develop the necessary protocols and data formats required to support provisioning and management of symmetric key authentication tokens, both proprietary and standards based." ISO/IEC 11770: Key Management. ISO/IEC 11770 is concerned with the management of cryptographic keys. SO/IEC 11770-1:1996 Information technology — Security techniques — Key management — Part 1: Framework defines a general model of key management that is independent of the use of any particular cryptographic algorithm; it dentifies the objective of key management, basic concepts and key management services. Other parts include ISO/IEC 11770-2:2008 Information technology — Security techniques — Key management — Part 2: Mechanisms using symmetric techniques. Part 2 specifies a series of 13 mechanisms for establishing shared secret keys using symmetric cryptography. These mechanisms address three different environments for the establishment of shared secret keys: point-to-point key establishment schemes, mechanisms using a Key Distribution Centre (KDC), and techniques that use a Key Translation Centre (KTC). ISO/IEC 11770-3:2008 Information technology — Security techniques — Key management — Part 3: Mechanisms Using Asymmetric Techniques. Part 3 defines key management mechanisms based on asymmetric cryptographic techniques. It specifically addresses the use of asymmetric techniques to achieve the following goals. ISO/IEC 11770-4:2006 Information technology — Security techniques — Key management — Part 4: Mechanisms based on weak secrets. Part 4 defines key establishment mechanisms based on weak secrets, i.e., secrets that can be readily memorized by a human, and hence secrets that will be chosen from a relatively small set of possibilities. KeyGen2: Key Provisioning/Management Standards Proposal. KeyGen2 is an individual standardization initiative with the goal of creating a scheme allowing any issuer of authentication, signature, and encryption keys to use mobile phones as the primary vehicle. The long-term target of the effort is combining this system with complementary mobile phone technologies such as NFC (Near Field Communication) which can make phones work as "better smart cards". KeyGen2 has mainly been developed by former RSA engineer Anders Rundgren. KeyGen2 is currently in early beta and can be tested at the public site: http://keycenter.webpki.org. KeyGen2 is meant to be deployed as Open Source, currently with Google's Android as the initial target: Android Keystore V2. A forward-looking description of this project in the making could be something like using Android as the vehicle that will eventually thwart the current userid/password explosion on the Internet but there are several other useful, more short-term and down-to-earth targets as well, including OTP (One Time Password) generation and secure key storage. KeyGen2 is based on XML Security and Internet-browser extensions. Unlike most other efforts in this area, KeyGen2 is targeting consumers using phones for on-line banking, e-government services, and eventually, through the use of "virtual" credit-cards, also for payments..." National Institute of Standards and Technology (NIST). U.S. National Institute of Standards and Technology (NIST) publications on security (including encryption and key management) have played a prominent role for many years, especially for government applications. FIPS Publications are issued by NIST after approval by the Secretary of Commerce pursuant to Section 5131 of the Information Technology Reform Act of 1996 (Public Law 104-106) and the Federal Information Security Management Act of 2002 (Public Law 107-347). NIST Special Publications in the 800 series present documents of general interest to the computer security community. The Special Publication 800 series was established in 1990 to provide a separate identity for information technology security publications. This Special Publication 800 series reports on ITL's research, guidelines, and outreach efforts in computer security, and its collaborative activities with industry, government, and academic organizations. NIST Special Publication 800-57 provides cryptographic key management guidance. It consists of three (3) parts. Part 1 provides general guidance and best practices for the management of cryptographic keying material. Part 2 provides guidance on policy and security planning requirements for U.S. government agencies. Finally, Part 3 provides guidance when using the cryptographic features of current systems. The KMIP specification definition of the Managed Object State attribute (also Section 2.12 of the Usage Guide 'Key Life-cycle and Key State') clarifies that the KMIP Specification describes the key life-cycle model based on the [six] NIST 800-57 key state definitions, supported by the KMIP protocol." OASIS Enterprise Key Management Infrastructure (EKMI) Technical Committee. The OASIS EKMI TC was chartered in December 2006 to "define symmetric key management protocols, including those for (1) Requesting a new or existing symmetric key from a server; (2) Requesting policy information from a server related to caching of keys on the client; (3) Sending a symmetric key to a requestor, based on a request; (4) Sending policy information to a requestor, based on a request; (5) Other protocol pairs as deemed necessary. In addition, the TC set out goals to document use cases, produce test suites, provide guidance on how a symmetric key-management infrastructure may be secured using asymmetric keys, and provide input on how such enterprise key-management infrastructures may be managed, operated and audited..." The TC work was launched with the contribution of Symmetric Key Services Markup Language from StrongAuth, Inc. as draft proposal for the EKMI protocol, supported by a working implementation of this protocol. The open source StrongKey is a building block in an Enterprise Key Management Infrastructure (EKMI), with the goal of centrally managing symmetric encryption keys. The EKMI TC operates under the Royalty-Free (RF) on Limited Terms Mode of the OASIS IPR Policy. In January 2009, the EKMI TC released Symmetric Key Services Markup Language (SKSML) Version 1.0 as a Committee Specification. This specification "defines the first (1.0) version of the Symmetric Key Services Markup Language (SKSML), an XML-based messaging protocol, by which applications executing on computing devices may request and receive symmetric key-management services from centralized key-management servers, securely, over networks. Applications using SKSML are expected to either implement the SKSML protocol, or use a software library — called the Symmetric Key Client Library (SKCL) — that implements this protocol. SKSML messages are transported within a SOAP layer, protected by a Web Services Security (WSS) header and can be used over standard HTTP securely..." Sun Crypto Key Management System (KMS). In February 2009, Sun Microsystems announced the release of an open source key management technology, described as "the world's first generic communication protocol between a Key Manager and an encrypting device." The release terms enable partners to adopt this protocol to securely handle encryption keys without additional licensing. The protocol is implemented as a complete toolkit and is downloadable from the OpenSolaris website. According to the announcement, "Governments, finance, healthcare, retail and other vertical markets need to comply with current regulatory laws that create mandates to protect sensitive stored data. To support these requirements, this protocol is available to customers using the Sun StorageTek KMS 2.0 Key Manager and Sun StorageTek T9840D, T10000A, T10000B Enterprise Drives, as well as Sun StorageTek HP LTO4 drives shipped in Sun libraries. A number of additional partners are developing products based on this protocol, including EMC, whose RSA security division has talked about releasing it as an option on their RKM Key Manager... By releasing the Sun protocol as Open Source, Sun is taking a major step towards unifying [key management] technology. Sun continues to work with partners in the industry and with appropriate standards bodies such as IEEE 1619.3 Working Group and OASIS to further develop and formalize the interface as an industry standard. RSA is currently developing a solution using this protocol to work with their RKM key manager. IBM drive division is working on supporting this protocol for their IBM LTO4 drive shipped in Sun Libraries. Additionally, Sun has shared this protocol with numerous other industry partners including computer OEMs, back up application providers, disk array and switch manufacturers..." Trusted Computing Group: Key Management Services Subgroup. The Trusted Computing Group (TCG) Storage Workgroup formed a Key Management Services Subgroup (KMSS) to provide a specific method to manage keys necessary for use in the environment defined by the TCG Storage Specification. The goals of the TCG Key Management Services Subgroup (KMSS) are to: (1) Develop a uniform approach to managing keys across a variety of storage devices; (2) Define an extensible set of key management operations to nurture and sustain encrypted data and its associated keys; (3) Define key management audit operations that may be required to securely record all key management operations; (4) Leverage existing protocols and techniques, for example [i] Support the TCG Storage Specification, [ii] Secure Communications, [iii] Authentication, [iv]Discovery, [v] Any existing and applicable standards; (5) Define procedures, protocols, and client APIs as needed to implement these goals..." KMSS is addressing: Key management services (KMS), KMS use cases, KMS device/host secure communication, KMS device/host authentication, KMS device/host capability negotiation, KMS key policy specification, and KMS audit logs. KMSS protocols will allow the host platform or application to perform the following operations and services with trusted storage devices: Requesting key generation; Key usage; Storage of keys; Retrieving keys; Modifying keys; Searching for keys; Key access rights; Disabling of keys; Destruction of keys. KMSS and P1619.3 are cooperating to avoid overlap. W3C XML Key Management (XKMS). The W3C XML Key Management (XKMS) Activity was organized to specify protocols for distributing and registering public keys, suitable for use with the standard for XML Signatures defined by W3C and the Internet Engineering Task Force (IETF) and its companion standard for XML Encryption. The XKMS specification became a W3C Recommendation in June 2005, and has two parts: the XML Key Information Service Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS). X-KISS allows a client to delegate part or all of the tasks required to process XML Signature 'ds:KeyInfo' elements to an XKMS service. A key objective of the protocol design is to minimize the complexity of applications using XML Signature. By becoming a client of the XKMS service, the application is relieved of the complexity and syntax of the underlying PKI used to establish trust relationships, which may be based upon a different specification such as X.509/PKIX, SPKI, or PGP. By design, the XML Signature specification does not mandate use of a particular trust policy. X-KRSS describes a protocol for registration and subsequent management of public key information. A client of a conforming service may request that the registration service bind information to a public key. The information bound may include a name, an identifier or extended attributes defined by the implementation.
KMIP OASIS Standard
On October 14, 2010, OASIS announced the approval of the
Key Management Interoperability Protocol (KMIP) Version 1.0 as an OASIS Standard. Developed through a collaboration of more than thirty (30) vendors and end user organizations, KMIP enables communication between key management systems and cryptographically-enabled applications, including email, databases, and storage devices.
See also:
KMIP Candidate OASIS Standard Specifications
On September 01, 2010, OASIS announced that members of the Key Management Interoperability Protocol (KMIP) Technical Committee had submitted two approved Committee Specification documents for consideration at OASIS Standard maturity level. Balloting for the two specifications was scheduled for September 16-30, 2010. Note also at CS 01 level: Key Management Interoperability Protocol Usage Guide Version 1.0 (provides illustrative information on using the protocol) and Key Management Interoperability Protocol Use Cases Version 1.0 (provides samples of protocol messages corresponding to a set of defined test cases).
KMIP Committee Drafts Approved for First Public Review
On November 05, 2009, the OASIS KMIP Technical Committee voted to accept four specification documents at Committee Draft level and release them for public review. Public review was announced for December 01, 2009 through January 30, 2010. KMIP TC Members may send feedback to the TC discussion list, and others may submit comments via the TC Comment List.
[November 17, 2010] "KMIP Entity Object and Client Registration." By Alan Frindell, with and Robert Haas. OASIS KMIP TC Contribution, posted to the TC list. 7 pages. Draft presentation for adding an Entity object to KMIP to support client registration and access control. "What can you do with an entity? Require subjects passed in TLS and/or Credential to be registered entities. Register or generate data that can be used during authentication, possibly to a third party system. Restrict operations that create objects, including other entities. Register Attributes that can be searched and retrieved. Possible policy relevant attributes like FIPS Level, hardware capabilities, server to client operation support. Register extended data that can be logged by the server. Ask server to notify entity when one or more objects change... Credential Redefinition... How are entities created? Manually entered by server administrator. Imported from a third-party directory by a server administrator. Explicitly registered by a KMIP client with appropriate permissions, where some server implementations may require administrator approval before the entity is registered. Implicitly registered by a KMIP client by sending a new Credential object in a request..." [source .PPT] [October 26, 2010] "Encoding Options for Key Wrap of Unstructured Data." By Stan Feather and Indra Fitzgerald (Hewlett-Packard Co). Posted to the KMIP TC list. October 26, 2010. 12 pages. "This document proposes an encoding option for wrapped keys, to better support clients behind KMIP proxies. Additional use cases for key wrap are also proposed." Excerpts: "Reason for proposed change: Current key wrap specification may require all wrapped keys to be TTLV-encoded. TTLV encoding could be a problem in the following example use case: A KMIP proxy client requests a wrapped key on behalf of another device; The proxy is KMIP aware, but can't unwrap the key; The device using the key is not KMIP-aware; End-device unwraps the key, but doesn't understand the TTLV data... KMIP 1.0 spec (section 2.1.4) requires the Key Value Byte String to be TTLV-encoded even if the string only includes Key Material; example of Key Value Byte String, containing Key Material and encoding, before wrapping: [...] Proposal description, for KMIP 1.1 spec Provide a method (an Encoding Option) to choose between un-encoded or encoded wrapping of un-structured keys Un-structured is defined as Key Values with unstructured Key Material, and no attributes. If Key Value data is structured (i.e., includes attributes), then server will always encode. TTLV-encoding is the only encoding option currently specified. Default behavior is to encode, even if Key Value is un-structured (1.0 behavior) Example of an unstructured Key Value, with no encoding, before wrapping into a Key Value Byte String: [...] Related request: include a key wrapping use case in the KMIP 1.1 Use Case document and include an Encoding Option example in the KMIP 1.1 Usage Guide... [proposal details follow]" [source .PPT] [October 18, 2010] "Tutorial
on KMIP and FCEAP/GPSK." By Bob Nixon (Emulex). Reference: INCITS T11/10-428v0; see also the T11 Document Register. Presented October 18, 2010 at the 'T11.3 FC-SP-2 Ad Hoc Meeting, Seattle, Washington, USA. FC-EAP = Fibre Channel Extensible Authentication Protocol. Outline: "What's the motivation for involving KMIP? What is KMIP? What does FC-EAP/GPSK need from KMIP? The players are: (1) RADIUS:
RADIUS Server (an Authentication Server) and RADIUS Client; (2) KMIP: KMIP Server (a Key Management Server) and KMIP Client;
(3) FC-SP-2: FC SP Authentication Initiator and Authentication Responder. When using DHCHAP/RADIUS, Key management is
centralized, Cryptographic math is delegated, but the cryptography of RADIUS and CHAP are falling out of favor. EAP/GPSK
chosen for flexibility and security but it lacks an obvious management system. When using EAP/GPSK/KMIP, Cryptographic math
is not delegated. KMIP a protocol standard, not a server design. The intention is that it be 'front-ended' to existing and
future proprietary server designs. It covers management, not authorization. Intention is that, although a certain minimum is
expected, a design is free to elaborate its authorization capability (or import it, e.g., from a corporate
directory). As to the KMIP Specification (oversimplifying): the Protocol is composed of a sequence of Request/Response
pairs; Request or Response is a Message; A Message is a header followed by one or more Batch Items; A Batch Item is an
Operation Code and a Payload; A Payload is a Sequence of Objects and Attributes; An Object is zero or more subordinate
Objects and zero or more Attributes; An Attribute is one or more primitive data types; Everything is encoded as a TTLV
structure... What does FC-EAP/GPSK need from KMIP? [...]" [cache/archive] [October 15, 2010] "KMIP Server-to-Server: Use-Cases and
Status." By Marko Vukolic and Robert
Haas. Posted to the KMIP TC discussion
list. Server to server (s2s): Focal use cases. [1] Propagating key material closer to endpoints, e.g., Example 1 for
a 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 for 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. [2]
Propagating key material updates towards the central key manager. A large multinational bank needs the information about
cryptographic material from Location B in central Location A — but not vice versa. [3] Business-partner data exchange.
[4] Propagation of keys between KMIP servers to facilitate business partner data exchange. [5] Partitioning: A KMIP server
needs to be partitioned into more servers [6] 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)... Next steps: Write up
detailed scenarios around focal use-cases. Address server representation/registration (cf. client registration, 'Entity' to
represent servers as well, including 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..." See also Use
Case Scoping from the minutes of the
September 29, 2010 F2F meeting. For Server-to-Server: "(1) Backup, DLP and load balancing/delegation — non KMIP
solutions exist; (2) Key propagation closer to end points, so keep it on the table; (3) Slave => master sync —
HSM use case is there; (4) Business partner: Yes; (5) Partitioning/M&A — guidance on GUID generation; (6) Public
key search: part of business partner use case, low priority; (7) Symmetric key exchange: critical; (8)
gateway/proxy/referral: need to look at further; (9) Replication: only as part of the other use cases..." source .PPT] [October 15, 2010] "XML Message Encoding for KMIP." By Hal Lockhart. Posted to the KMIP TC discussion list. Excerpts:
"Problem Statement: "KMIP 1.0 defines a single message encoding format called TTLV. It is well suited for simple and
efficient processing, especially in resource-constrained environments. An equivalent XML encoding may be valuable in
environments where most messages are already in XML. Design Goals: Both encodings should convey the same semantics. All differences between encodings should be confined to one place in the spec per Chapter 9. Changes to other parts of the specs should automatically work with both encodings. TTLV -> XML, XML -> TTLV and round tripping should all work. Should be simple to build Server which supports both. Should be simple to build bi-directional gateway. This implies no information loss in moving from one form to the other. KMIP XML Conversion Principles: Use non-empty XML Elements to represent KMIP Objects. Use the current names given in KMIP spec as basis for naming in XML — remove spaces between words, use 'upper camel case' e.g. KeyWrappingData, dash character is OK as is, e.g. CommonTemplate-Attribute, Need to map '/' to something else e.g., MAC/Signature, perhaps dash, e.g. MAC-Signature (?), Single letter names might cause confusion, e.g., P, Q, X, Y - Perhaps CryptoP, CryptoQ, etc.... Data type: In TTLV data type is passed with object (I assume it is only used to interpret Value), in XML data type is in Schema... Parser needs to have access to Schema..." Still [2010-11-11], questions about custom extensions: what is level of support required? Are we assuming that mostly will be supporting custom extensions or their own? Could affect the design regarding how easy it is to consume someone else's custom extensions — vendor extensions? Custom attributes? Enumeration extensions, including new object types... we expect that all three will be used, at least for some vendor-specific needs...custom attributes from client side (e.g., storing info associated with key), would be simple, handled as an opaque element without any action besides what expected by server; if a server doesn't support that extensions, then it's to be ignored..." [source .PPT] [October 06, 2010] "KMIP Trust Establishment Proposal." By Judy Furlong (EMC/RSA), with contributions by Robert Griffin (EMC/RSA), David Lawson (Emulex), Larry Hofer (Emulex), and Robert Nixon (Emulex). Posted to the OASIS KMIP TC discussion list. 5 pages. Summary: Proposal for using public key infrastructure (PKI) techniques for establishing trust between a KMIP client and a KMIP server. Overview: This proposal defines changes to KMIP Version 1. The proposal describes a method for how a KMIP client and a KMIP server exchange their respective public key certificates and establish a trust relationship with one another. Once established, the trust relationship enables implementation of additional layers of security controls on KMIP messages such as digitally signing the payload of a KMIP message... The trust establishment proposal assumes the following pre-conditions: (1) The credential (either public key or public key certificate) for a Trusted Root Certification Authority (CA) has been transmitted out-of-bands and embedded in the KMIP client or otherwise pre-established. (2) The KMIP client has generated or requested and loaded an asymmetric key pair and associated public key certificate. [Note: The KMIP client certificate is not expected to chain to the Trusted Root CA embedded in the KMIP client.] (3) The KMIP server has created its own asymmetric key pair and has had its public key certified by a CA that chains to the Trusted Root CA whose credential is embedded in the KMIP client. New KMIP Operations: This proposal defines two new KMIP operations, Exchange Credential and Confirm Credential, both of which are initiated by a KMIP client. These operations allow a KMIP client and a KMIP server to exchange and trust credentials such as public key certificates that will subsequently be used to authenticate and/or protect KMIP messages exchanged by these parties. This proposal assumes the exchanged credential is a public key certificate, but it's possible other types of credentials may be added in subsequent revisions... The 'exchange credential' operation allows a KMIP client and KMIP server to exchange credentials such as public key certificates that will be used to authenticate and/or protect subsequent KMIP message exchanged by these parties. The request which is generated by the KMIP client contains information about the type of credential being exchanged, a nonce value generated by the KMIP client and the credential of the KMIP client... At the conclusion of a successful Exchange Credential operation, the KMIP client has authenticated the KMIP server by verifying its certificate (or certificate chain) and confirmed it has been communicating with a live KMIP server since the KMIP server returned the nonce generated by the KMIP client. However, the KMIP server has not confirmed that the client it has been communicating with is in fact the one which possesses the private key that corresponds to the KMIP client public key certificate. In order to prove to the KMIP server that the KMIP client is in possession of the private key, the KMIP client can send a Confirm Credential request message. The request message contains a new nonce value that has been generated by the KMIP client, a decrypted version of the encrypted nonce received from the KMIP server in the Exchange Credential response, and the first nonce value generated by the KMIP client and provide in the Exchange Credential request..." [source .DOC] [September 29, 2010] "KMIP Client Registration Ideasfor Discussion." Draft by Alan Frindell. 5 pages. Posted to the OASIS KMIP TC discussion list. "The presentation includes what a managed object for 'Entity' might look like, as well as some potential uses. There's also a slide that describes the Sun Ultra KMS protocol for automatically creating a TLS client certificate based on a challenge response protocol. I'm interested to hear the TC's opinion on adapting this protocol to suit KMIP." — "This presentation captures some ideas that from Wednesday's discussion of client registration." Presents: Automated TLS certificate creation(from Sun KMP). Assumption: Client and server share an authentication passphrase. Part I: Plaintext. Client sends subject information to server. Server replies with CA Certificate and client authentication challenge... Part II: TLS with server-only authentication. Client sends client authentication response and server authentication challenge to server. Server verifies client authentication response. Server generates key pair and certificate, signs certificate. Server replies with server authentication response, private key, certificate. Client verifies server authentication response, stores private key and certificate... " For followup, see the posting by Hal Lockhart 'Sun/Oracle Ultra KMS Crypto Bootstrap Scheme' and KMS-Registration.zip package. [source .PPT] [September 29, 2010] Clarifications to KMIP v1.1 for Asymmetric Crypto and Certificates. By Judith Furlong. Posted to the OASIS KMIP TC discussion list. 5 pages. "Topic 1: Cryptographic Length of Asymmetric Keys. For PublicKey and PrivateKey objects: How do we represent the CryptographicLengths of these objects? The actual lengths of the cryptographic material may vary, depending on input parameters, but users thinking they have a 1024-bit key pair will be quite dismayed if our length calculator reports anything other than what was input to the generation process. This becomes more problematic for keys that arrive via Register, rather than CreateKeyPair. Would propose that the lengths should be what the keypair generator would require as input, rather than a mechanical evaluation of the key itself. This may require some "fuzzy logic"...it's 1024-bitish...the spec should clearly instruct the server implementers what to do and what the limits might be on their flexibility... Topic 2: Signature Algorithms in Certificate Objects. For Certificate objects: 1) Do all Certificates have a CryptographicAlgorithm? If so, what is it? None of the current algorithms seem to relate to the actual signature on the certificate. Would propose that the algorithm of the Certificate is the algorithm of the enclosed public key. Disposition: Need to add signature algorithm to KMIP Specification. An open question as to how to represent the signature algorithm as an enumerated attribute or as a composite attribute, like crypto parameters... Topic 3: Certificate Length. 2) Do all Certificates have a CryptographicLength? If so, what is it? I do not believe that the bitlength of the encoded certificate is very interesting... Would propose that the length of the Certificate is the length of the enclosed public key, as interpreted above. Topic 4: ASN.1 to String Conversion. The CertificateSubject is a structure with the distinguished name of the subject, along with alternate names. Both of these are simply listed as text strings, but no mechanism is suggested for producing these strings from the underlying ASN.1 in the certificate. We may luck out on producing the former, but the latter is the road less travelled, and may produce more mismatches. (Not to mention that one may loses some context in knowing what kind of alternate name this was, if I remember correctly. Simply rendering as a text string may lose the fact that this alternate name was the DNS Name, for example). Would propose that a TC member might take this one as a work item, if we are addressing only in 1.1. Similar comments regarding CertificateIssuer..." [source .PPTX] [September 29, 2010] Policy and Design Considerations When Using KMIP. By Elaine Barker (NIST). Posted to the OASIS KMIP TC discussion list. 20 pages. Summary: "This is an attempt to capture the references to the need for policy or the the assumptions on the behavior of the client or server. This type of information may be very useful when deciding how hard it would be to use the KMIP." Exclusive of the protocol itself: this list of considerations is inspired by the protocol, but separate from the protocol itself (e.g., the ID Placeholder is a protocol tool that does not affect the server itself, other than its communication with the client)..." Each requirement is identified as to Section number and as to applicability for the ker server and/or client. [source .DOC] [September 29, 2010] Group As a New Managed Object in KMIP. By Krishna Yellepeddy. Posted to the OASIS KMIP discussion list. 12 pages. Support for updated operations on group objects. Use cases for group as a new managed object in KMIP: (1) Allow creation of groups of heterogeneous or homogeneous managed objects. Example: Create a homogeneous group of symmetric keys. This set of symmetric keys is treated as a resource and access control is enforced on it. E.g. a set of tape drives of a particular type have access to this group of keys. Create a heterogeneous group of cryptographic objects consisting of asymmetric keys, certificates and secret data. This heterogeneous group may represent a user's credentials for logging on to different applications such as their Gmail account, Facebook account, relational database etc. The user/owner retrieves this group and uses the credentials in the group for signing on to different applications. (2) Assign properties to the group governing how elements in the group are served out for use. This could be thought of as a cursor pattern which is specified at the time of creation of the group. For example: (a) for a group of symmetric keys, security policy for FIPS compliance may dictate that a key should be served out only once for use by a client for encrypting data. When all the keys have been served out from a group, server returns an error that there are no new keys available. Note that a key can be used any number of times to decrypt data (b) for a different group of symmetric keys, keys may be served out in a round robin fashion. In this example a key may be served out more than once for encrypting data (3) For a heterogeneous group of elements (e.g., credentials) being managed for a user, user may cache this group of objects and want to be notified by the server if any of the elements in the group have been modified. If they have been modified, then the user refreshes the cache..." [source PDF] [September 29, 2010] Access Control in KMIP Version 1.1. By Robert Haas and Marko Vukolic (IBM). Posted to the OASIS KMIP TC discussion list. 11 pages. Proposes changes to the Device Subject Type (simplified to Device Groups only). Summary of Changes WRT last version of the AC proposal: Roles and Access Control List Attribute are removed from the proposal. The new KMIP v1.1 Access Control proposal contains: Owner Attribute, Operation Policy Properties Attribute, Extensions of Link Attribute. Why Removal of Roles, Access Control Lists? Fears that KMIP server might hold redundant and conflicting information to that already maintained by an external AC infrastructure in a large organization. Potential difficulties in internal vs. external AC parameters synchronization. Defining AC in KMIP may become troublesome in case of different administrative/security domains (with e.g., different roles, different policies applicable to different servers). This new proposal makes a recommendation to: (a) Handle access control decisions and permissions via an external AC infrastructure, out of the scope of the KMIP specification; (b) Define a minimal yet sufficient support in KMIP for object ownership and strict access control. So: Introduce New Link Types to allow KMIP server to track dependencies among keys. Needed for Strict AC that protects against KMIP API attacks that exploit dependencies. Tracking dependencies unrealistic to be deferred to an external AC. KMIP server should do it and hence enable Strict AC Policy (not specified in protocol) to be enforced externally. New Link Types: (1) Wrapping Base Object Link: for an object specified in Key Wrapping Data and used to wrap current object in Get operation. (2) Wrapped Object Link: the object that was wrapped using the current object..." [source .PDF] [May 20, 2010] Proposal for Basic
Asymmetric Key Profiles. By Sean Turner (IECA Inc), with contributions from Kelley Burgin (National Security
Agency), Chris Dunn (SafeNet, Inc), Indra Fitzgerld (HP), Judith Furlong (EMC Corporation), and Jay Jacobs (Target
Corporation). 6 pages. Posted to the OASIS KMIP
TC discussion list; see versions in the KMIP TC repository reference
page. Summary: "Proposal for Asymmetric Key (and Certificate) profiles. Five seperate profiles are included in this
proposal for discussion. In general profiles require changes to the KMIP v1 Spec particularly in the area of getting rekey
to apply to asymmetric keys and to certification without providing a certificate request." Details: (1) Basic Asymmetric
Key Store Conformance Clauses: This proposal intends to meet this OASIS requirement by building on the KMIP Server
Conformance Clauses defined in the KMIP Specification to allow asymmetric key pairs generated external to the key server to
be vaulted by a key server. The intent is to simply support key registration for a very limited number of key types.
Implementation Conformance: An implementation is a conforming KMIP Basic Asymmetric Key Store if the implementation meets
the conditions as outlined in the following section... (2) Basic Asymmetric Key and Certificate Store Conformance Clauses:
This proposal intends to meet this OASIS requirement by building on the KMIP Server Conformance Clauses defined in the KMIP
Specification to allow asymmetric key pairs and certificates generated external to the key server to be vaulted by a key
server. The intent is to simply support key and certificate registration for a very limited number of key types. (3) Basic
Asymmetric Key Foundry and Server Conformance Clauses: This proposal intends to meet this OASIS requirement by building on
the KMIP Server Conformance Clauses defined in the KMIP Specification to provide basic asymmetric key services for central
key generation (by the key server). The intent is to simply allow key creation and serving with very limited key types. (4)
Basic Certificate Server Conformance Clauses: This proposal intends to meet this OASIS requirement by building on the KMIP
Server Conformance Clauses defined in the KMIP Specification to provide basic asymmetric key services for local key
generation (external to the key server) and certification via a key server. (5) Basic Asymmetric Key Foundry and Certificate
Server Conformance Clauses: This proposal intends to meet this OASIS requirement by building on the KMIP Server Conformance
Clauses defined in the KMIP Specification to provide basic asymmetric key services for central key generation (by the key
server). The intent is to simply allow key and certificate creation and serving with very limited key types..." [source
.DOC] [February 20, 2010] Mapping OASIS KMIP to an XML WSDL for IEEE P1619.3. Edited by Matt Ball (Sun Microsystems; Chair, IEEE P1619 Security in Storage Working Group). Version 2. February 15, 2010. Describes how the P1619.3 WSDL was created using the OASIS KMIP specification. See the associated posting: Updated P1619.3 XML Schema, posted February 15, 2010 to the IEEE P1619-3 list by Matt Ball [2010-02-01] and meeting minutes. Contribution to the IEEE P1619.3 Security in Storage Working Group (SISWG), Key Management. See also P1619-3_KMIP XML WSDL and examples: This zip file contains a proposed XML WSDL (Web Services Description Language) grammar, XSD file, and example XML files for an XML encoding of the OASIS KMIP specification..."
Details: "This document proposes a method to map OASIS KMIP (Key Management Interoperability Protocol) onto an XML WSDL (Web Services Description Language) schema. This document assumes that the reader is familiar with the OASIS KMIP specification, XML WSDL, XML XSD, and XML SOAP. The general strategy is to use XML SOAP to map KMIP onto a WSDL with Document/Literal encoding so that it is possible to validate the WSDL against the WS-I Basic Profile 1.0. The proposed WSDL for KMIP-P1619.3 mapping is located at http://schemas.siswg.org/P1619-3-KMIP.wsdl [cache]... When using XML/SOAP, there is a functional model that is different than that of KMIP. In particular, SOAP has a basic method for encoding procedures and the corresponding responses that differs from the KMIP method of wrapping each command and response with a message envelope. While it is possible to emulate this using SOAP, it forces everything to be interpreted as a single command and removes the benefits that XML parser generators provide in performing parameter type-checking. In practice, this will serve to simplify things on both the server and client side. Data type mapping [1] 'Primitive data types': Table 1 shows a proposed mapping of primitive OASIS KMIP data types to their corresponding XSD types and recommended C++ programming language types. Note that the C++ data types are not normative, but are rather informational, and may help programmers to better understand the implications of these mappings. [2] 'Complex data types': In addition to primitive data types, KMIP also supports complex data types, both explicit and implicit. Table 2 shows the mapping of KMIP complex types (both explicit and implicit) onto XML and C++..." [cache/archive] [February 20, 2010] IEEE P1619.3 Plan for 2010. Prepared by Matt Ball (IEEE Security in Storage Working Group Chair) and Walt Hubis (IEEE P1619.3 Task Group Chair). Version 1. January 19, 2010, per the posting. HTML from source .doc. "This document describes the plans for the IEEE P1619.3 Task Group for the 2010 calendar year. The IEEE P1619.3 Task Group was formed in February 2007, with the following: Title: 'Draft Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data', Scope: 'This standard specifies an architecture for the key management infrastructure for cryptographic protection of stored data, describing interfaces, methods and algorithms'; Purpose: 'This standard defines methods for the storage, management, and distribution of cryptographic keys used for the protection of stored data. This standard augments existing key management methodologies to address issues specific to cryptographic protection of stored data. This includes stored data protected by compliant implementations of other standards in the IEEE 1619 family...
In early 2009, a consortium brought forward the "Key Management Interoperability Protocol" (KMIP) into the OASIS standards organization. This new standard has much in common with the scope and purpose of P1619.3. Many people have asked whether P1619.3 is still relevant with the presence of OASIS KMIP. We believe the answer is 'yes'... Overall, the existing of KMIP has benefitted the P1619.3 effort because it is now possible to leverage the KMIP standard — which (as of January 2010) is in public review and nearly complete — as the basis for the low-level key management functions, and position P1619.3 as a KMIP profile that adds on enterprise-class additions to make it suitable for key management in a storage encryption environment. In reviewing KMIP, the P1619.3 task group plans to enhance KMIP with the following extensions: (1) Start with the KMIP binary format and the 'Symmetric Key Foundry' and 'Symmetric Key Store' profiles (2) Create an XML WSDL that is a mechanical translation of a subset of the KMIP binary protocol, and add on P1619.3-specific extensions. The KMIP binary primitives have a clean mapping into standard XML-Schema objects, and this work has already been completed by at least two members of the KMIP consortium, for a proof-of-concept. (3) Add in the P1619.3 Namespace work. KMIP does not appear to define any namespaces, but relies on the users to hopefully create identifiers that are unique (actually, the only requirement is that they are unique in the local server context). (4) Define concrete default port bindings for the XML P1619. 3 services, through IANA. KMIP is currently planning to reserve a port through IANA for both the client and server implementation of the binary KMIP format. (5) Define an enrollment protocol. KMIP doesn't do this, but assumes that you've already white-listed the certificates used for the SSL/TLS channel. The current proposal for this is the Sun KMS Agent Toolkit enrollment service. (6) Define a discovery protocol. As a starting point, we could use the discovery protocol as implemented in the Sun KMS Agent Toolkit. (7) Define an XML-based key backup format for interchangeable archiving keys from a key management server. (8) Define the use of WS-Security for further authenticating messages within a TLS channel (i.e., the TLS channel itself could have one level of authentication — based on the client certificate — but could be a proxy for other clients that use WS-Security for their authentication)... [February 20, 2010] Comments on KMIP Version 1.0 Public Review Draft. The public review for KMIP Version 1.0 resulted in over 100 comments, summarized in spreadsheets posted to the KMIP TC discussion list by Subhash Sankuratripati: (a) Comments from TC Members and Comments from Non-TC Members. Comments have been separated into groups reflecting comment on the KMIP Protocol prose specification, Use Cases, Profiles, and Usage Guide. The full text of comments as submitted may be found in: [1] postings to the KMIP TC discussion list, [2] postings to the KMIP TC comment list. Earlier versions of the spreadsheets are referenced from postings of February 11, 2010 (bis). As of 2010-02, KMIP TC members were evaluating the comments and proposed responses for addressing the issues raised. The KMIP TC will acknowledge receipt of each comment, track the comments received, and publish a disposition for each comment via the TC's discussion list. [February 20, 2010] Key Management Interoperability Protocol Specification Version 1.0, Committee Draft 07. February 04, 2010. 156 pages. Edited by Robert Haas (IBM) and Indra Fitzgerald (HP). Notice posted to the KMIP TC Kavi repository on 2010-02-04 by Robert Haas, in PDF and Word/.doc formats. This draft provides editorial fixes according to Elaine Barker's comments. Comments for which the proposed resolution is 'No Change' are indicated accordingly. Open issues marked with 'TBD' and possible Usage Guide items are marked with UG'. See also subsequent comments on this CD07 as posted by Elaine Barker (NIST). [February 20, 2010] Key Management Interoperability Protocol Use Cases Version 1.0, Committee Draft 07. February 17, 2010. 166 pages. Edited by Mathias Björkqvist (IBM) and René Pawlitzek (IBM). See the posting by Mathias Bjorkqvist on February 17, 2010 to the KMIP TC Kavi repository. "This draft addresses comments from spreadsheet. In particular, it adds and modifies some use cases to address comment HP-014: modified use cases 4.1, 5.1, 10.1, added new use cases 3.1.5, 11.1, 12.1..." [Source Word/.doc and PDF] [February 20, 2010] KMIP Usage Guide Proposal on Templates. Edited by Indra Fitzgerald (HP). Version: 1.0. Date: 2010-02-17. Purpose: Elaine Barker requested that the Usage Guide include a template example. [Proposal that] Section 3.6 of the KMIP Usage Guide will be replaced with the text in this document. See the posting to the KMIP TC Kavi repository by Indra Fitzgerald on February 18, 2010. "This proposal addresses KMIP Usage Guide comment NIST-001 by clarifying
templates and including a couple of examples..." [Source Word/.doc] [February 20, 2010] Using the Same Asymmetric Key Pair in Multiple Algorithms. Edited by Judy Furlong (EMC). Version 0.3.
February 11, 2010. References: [1] KMIP Specification Version 1.0, Committee Draft 06, 09 November 2009, [2] KMIP Usage Guide Version 1.0, Committee Draft 05, 09 November 2009. "Background: There have been some questions raised as to why the v1 KMIP Specification provides separate key structures for DSA and DH keys and ECDSA and ECDH keys where a single key pair may be used in both algorithms. This proposal provides text for inclusion in the KMIP Usage Guide to explain why separate key structures were provided... A proposed new section for inclusion in the v1 KMIP Usage Guide to explain that the same assymetric key pair can be used in multiple algorithms and to clarify why the same key pair needs to represented separately for each algorithm..."
" See the posting from Judy Furlong to the KMIP TC discussion list. Earlier: Posted by Judith Furlong on 2010-02-04. See comment by Sean Turner. [Source Word/.doc] [February 20, 2010] KMIP Server to Server. File: 'kmip-spec-1.0-cd-06-s2s.doc'. Edited by Marko Vukolic. See the list of changes to KMIP CD-06 in discussion posted January 28, 2010' also the message of February 20, 2010, and TC ballot to accept the Server to Server changes to KMIP v1 specification as proposed by Marko Vukolic, with reference page.
"During the work on server-to-server extensions of KMIPv1, we came up with few proposals for spec changes that the TC might consider for inclusion already in the KMIPv1. The benefit of this would be reducing the differences between KMIPv1 and its future versions. These could be accepted as a part of public review. We believe that the changes proposed below are not strictly related to server-to-server (although the need for them appeared in this context). Furthermore, most of the changes seem pretty lightweight and acceptable... Issue 1: The behavior of Put when Replaced Unique Identifier (ruuid) is specified, but the object with ruuid does not exist on the remote end (client) is not specified. Specifying this behavior might enhance interoperability... Issue 2: Notify does not support notification about deleted attributes... Issue 3: the optional support of wildcards in Locate is stated only for Name and Object group. It is not clear why other attributes that are represented as Strings are not supported by the wildcards. This seems to be a leftover from the early days of KMIP in which Locate supported only a subset of attributes..." [Source Word/.doc] [February 20, 2010] KMIP Server and Client Port Applications. Prepared by: Alan Frindell (SafeNet, Inc), with contributions by Steve Wierenga (HP) and Matt Ball (Sun). Version: 1.0. Publication date: 2009-12-09. Message formats: The sequence of fields is Tag, Type, Length and Value (TTLV). The type field can specify a structure, which itself contains zero or more elements of the same TTLV format. Message types: KMIP has both request and response message types. Message op codes: There are 26 operations defined for the KMIP server in the KMIP 1.0 draft specification: Create, Create Key Pair, Register, Re-key, Derive Key, Certify, Re-certify, Locate, Check, Get, Get Attributes, Get Attribute List, Add Attribute, Modify Attribute, Delete Attribute, Obtain Lease, Get Usage Allocation, Activate, Revoke, Destroy, Archive, Recover, Validate, Query, Cancel, and Poll. Message sequences: Both synchronous and asynchronous messages are allowed for KMIP servers in the KMIP 1.0 draft. For synchronous messages, the client sends a request and the server sends a corresponding response. To use asynchronous messages, the client sets an indicator in the request. If the server supports asynchronous messaging, it will immediately return a response including an Asynchronous Correlation Value. The client may then pass this value to the Poll and Cancel operations to manipulate the request. Batching of certain requests is also supported. It is designed to reduce the number of round trips between the client and server required for common functions. For example, a very common sequence is to query for an object using the 'Locate' operation an object and then retrieve it using the 'Get' operation. An ID Placeholder value is used by the client in the request sequence to refer to the ID of objects resulting from the previous operation....
KMIP is used for the communication between clients and servers to perform certain management operations on objects stored and maintained by a key management system. These objects include symmetric and asymmetric cryptographic keys, digital certificates, and templates used to simplify the creation of objects and control their use. KMIP servers will listen on the port by default for connection requests from KMIP clients. Clients will then send requests to locate, create, import, retrieve and otherwise manage key material on the KMIP server. Communications over this channel for all opcodes except one (Query) must be authenticated and encrypted using TLS. The messages for the protocol are defined in the KMIP 1.0 Specification. The protocol is designed to foster interoperability among vendors of encryption endpoints such as tape and storage devices and key managers..." See the posting to the KMIP TC discussion list. Purpose: "The KMIP specification describes two services that would benefit from well known ports assigned by IANA. The IANA website has an online application form with several questions regarding the proposed use of the port. This document contains the answers to the questions for the KMIP Server and the KMIP Client Service." The document was approved by the KMIP TC: see the TC ballot, "KMIP client/server port assignment by IANA: Do you approve the KMIP Port Applications Rev 2 as proposed by Alan Frindell to be submitted to OASIS administration and eventually to IANA? [Source Word/.doc and Kavi reference page] [December 09, 2009] "Protecting Encryption Keys Takes Spotlight in Enterprise Data Security." By Gary Palgon (nuBridges VP Product Management). News article. "As organizations focus on doing a much better job of protecting confidential information, CISOs are wrestling with how to manage and protect encryption keys. Mastering encryption key management is one of the next big obstacles in data protection for chief information security officers to overcome: after a spate of embarrassing and costly data breaches, and a plethora of industry data security mandates, breach notification laws and government privacy laws, organizations have responded and are doing a much better job of protecting payment card data and personally identifiable information from cyber criminals and accidental loss using encryption. A byproduct of encryption is a generation of encryption keys that allow authorized users and applications to lock and unlock the data, all of which need to be managed and protected on an enterprise level... if you're not protecting the keys, you're not protecting the data; second, if you lose keys, you've effectively erased the data. Stolen keys can lead to data breaches. Lost keys result in unrecoverable data. One is costly and reputation-damaging; the other disrupts business... Fortunately, there are data security solutions that incorporate unified key management with strong encryption to automate the protection and management of an unlimited number of keys across the enterprise..." [nuBridges Protect is an integrated encryption, tokenization, key management and logging solution to protect sensitive data at rest in databases, applications and associated backup storage.] [December 03, 2009] Access Control in KMIP Version 1.1 / Version 2.0. See the posting of December 03, 2009 by Robert Haas to the KMIP TC list, with reference to slides showing progress on 'access control' for KMIP v1.1 / v2. Similarly, the posting "Access Control for KMIP" and source, with reference document. "Access Control in KMIP Version 1.0 has the 'Operation Policy Name' placeholder (Object Attribute; Not mandatory; Defines the default permissions). Proposal for Access Control in KMIP v1.1 / v2: We suggest two complementary mechanisms: Basic Access Control and Strict Access Control (SAC). (I) Basic Access Control (BAC): [A] Possibly mandatory, or at least regulated through profiles. [B] Access Control Lists (ACLs) are attached to objects — Object Attribute, Consists of (user/role,permission) pairs. [C] User Permission Lists (UPLs) for operations that refer to not yet existing objects (Create, Create Key Pair, Register). Involves a 'global' list of (user/role, permission pairs), where 'global is meant in the sense of 'unique per key-management domain'; finer granularity (e.g., multiple subdomains) is possible. (II) Strict Access Control (SAC): [A] Possibly optional, and also could be regulated through profiles. [B] To prevent KMIP API attacks introduced by object dependencies, object dependencies are introduced notably through derivation and key wrapping; API might 'leak' information about dependent keys, and this may lead to ACL violation if object interdependencies are not checked. [C] Through standardization of additional SAC specific attributes, in addition to Basic Access Control... With Basic Access Control (BAC), ACLs and UPLs are forseen as lists (user/role, permission) pairs and the ACL is foreseen as a potentially mandatory attribute of an object; A UPL (potentially also mandatory) is not attached to any object.. There is a tight interplay between the standardization of user representation in KMIP (cf. Client Registration Action Item)... Motivation for Strict Access Control (SAC): API attacks on key management APIs, which is a legitimate concern for KMIP. Operation on cryptographic keys might introduce dependencies between keys. Example operations: Derive, Get (wrapped). If only basic ACL/RBAC mechanisms are implemented/specified in KMIP Version 2, these might be circumvented by exploiting the KMIP API. Such API attacks are applicable to existing practical key management interfaces like PKCS #11 [Cryptographic Token Interface Standard]... Slide #8 shows an example of the Attack on BAC..." Some SAC details (KMIP API server attack problem) via two publications: [i] Design and Implementation of a Key-Lifecycle Management System, by Mathias Björkqvist, Christian Cachin, Robert Haas, Xiao-Yu Hu, Anil Kurmus, René Pawlitzek, and Marko Vukolic (Research Report RZ 3739, IBM Research, June 2009)... [ii] A Secure Cryptographic Token Interface, by Christian Cachin and Nishanth Chandran (Proceedings of the IEEE Computer Security Foundations Symposium (CSF-22), pages 141-153, July 2009). [archive] [December 03, 2009] "Proposal for Supporting Rekey of Asymmetric Key Pairs within KMIP." By Judy Furlong (EMC). Version 0.1. December 03, 2009. **Updated: document, per posting of 2009-12-04. This document "Describes a new KMIP operation for rekeying asymmetric key pairs. It also outlines changes to the KMIP Spec and KMIP Usage Guide in light of the addition of this new operation." See the posting of December 03, 2009 by Judith Furlong "Proposal for Supporting Rekey of Asymmetric Key Pairs." Canonical source and reference page. Provisionally: "'Re-key Key Pair'. This operation is used to generate a replacement key pair for an existing public/private key pair. It is analogous to the Create Key Pair operation, except that attributes of the replacement key pair are copied from the existing key pair, with the exception of the attributes listed in Table yy. As replacement of the key pair takes over the name attribute for the existing public/private key pair, Re-key Key Pair SHOULD only be performed once on a given key pair. As a result of the Re-Key Key Pair operation the Link Attribute for both the public key and private key objects are updated to point to the replacement public and private key, respectively. The server SHALL copy the Private Key Unique Identifier of the replacement private key returned by this operation into the ID Placeholder variable. An Offset MAY be used to indicate the difference between the Initialization Date and Activation Date of the replacement private key pair. If the Offset is set and the dates exist for the existing private key, then the dates of the replacement private key pair SHALL be set based on the dates of the existing key pair..." [December 03, 2009] "Proposal for Making Submission of a Certificate Request in the Certify and Re-Certify Operations Optional." By Judy Furlong (EMC). Summary: "This proposal makes the inclusion of the Certificate Request attribute and the associated Certificate Request Type attribute in the Cerify and Re-certify operations as non-mandatory." See the posting of December 03, 2009 to the KMIP TC list. Document source and Kavi reference page. Details: "In the KMIP v1.0 specification, inclusion of the certificate request is a mandatory field for the Certify and Re-certify operations. This requirement means that the client must be in possession of the key pair in order to submit either the Certify or the Re-certify request. While this is reasonable if the client has generated the key pair, it makes supporting a scenario where the assymetric key pair and associated certificate are generated by a key server more difficult. The key pair would need to be transmitted from server to client so the client could compute the certificate request which would then be re-submitted to the server. It would be more efficient if the client could make the Create Key Pair request and then submit the Certify request with only the unique identifier of the public key to be certified. [Note: These two operations could even be batched and let the server fill in the unique identifer once it creates the key pair.] Client specific information for inclusion in the certificate (such as the subject DN) could be provided to the server via the Template-Attribute. This proposal makes the inclusion of the Certificate Request attribute and the associated Certificate Request Type attribute in the Cerify and Re-certify operations as non-mandatory. Instructions for when to include these attributes versus just the Unique Public Key Identifier can be specified in the Asymmetric Key Profile and potentially in the KMIP Usage Guide..."
Certify: This request is used to generate a Certificate object for a public key. This request supports certification of a new public key as well as certification of a public key that has already been certified (i.e., certificate update). Only a single certificate SHALL be requested at a time. Server support for this operation is OPTIONAL, as it requires that the key management system have access to a certification authority (CA). If the server does not support this operation, an error SHALL be returned. Re-certify: This request is used to renew an existing certificate with the same key pair. Only a single certificate SHALL be renewed at a time. Server support for this operation is OPTIONAL, as it requires that the key management system to have access to a certification authority (CA). If the server does not support this operation, an error SHALL be returned. Requests are passed as Byte Strings, which allow multiple certificate request types for X.509 certificates (e.g., PKCS#10, PEM, etc) or PGP certificates to be submitted to the server. The server SHALL copy the Unique Identifier of the new certificate returned by this operation into the ID Placeholder variable. [November 11, 2009] "CA Enters Encryption Key Management Market." By Jon Oltsik. Enterprise Strategy Group (ESG) Blog. "CA [Computer Associates] entered the key management market this week, joining others such as HP, IBM, EMC/RSA, PGP, and Thales. CA's announcement was relatively quiet, but it is still significant because: (1) CA joins the KMIP initiative. CA becomes another leading technology vendor to join the Key Management Interoperability Protocol (KMIP) group within OASIS. The group hopes to have a specification ratified soon and working product next year. CA's engineers will focus on application key management as part of a holistic key management architecture. (2) CA anchors key management to System z... (3) CA understands the link between key management and identity. Many key management leaders are focused on storage alone, while others only care about PKI. CA is one of the few vendors to play in both the infrastructure and identity side of IT. Yes, the obvious link here is PKI, but the combination of encryption, key management, and identity could also be used for entitlement management and data security. For example, a contractor may have rights to a data file for a limited period of time only before the encryption key expires. With its focus on the mainframe, CA didn't get much attention with this announcement, but large enterprises — especially in financial services, defense, law enforcement, and intelligence — will recognize the value here right away..." [October 27, 2009] "Brocade and Thales Announce Integration of Thales Encryption Manager for Storage with Brocade Encryption Switching Solutions. Industry's First Standards-Based Encryption Key Management Appliance and Leading Encryption SAN Switching Solutions Deliver Simplified, Cost-Effective Storage Encryption." Joint announcement. "Brocade and Thales today announced the integration of Thales Encryption Manager for Storage (TEMS) with the Brocade encryption SAN switching solutions. The combination of TEMS, the industry's first standards-based encryption key management appliance for storage, and the Brocade encryption SAN switching solutions protect enterprise data and helps organizations meet growing compliance demands. The solution cost-effectively simplifies the storage encryption process by eliminating the need for storage professionals to deploy multiple storage encryption systems and helps ensure safe and reliable data access. The Brocade Encryption Switch and Brocade FS8-18 Encryption Blade are part of a family of fabric-based encryption platforms that helps organizations meet their security and corporate governance objectives by encrypting critical corporate data with high performance and centralized fabric management. These leading-edge solutions offer an innovative approach to fabric-wide encryption for data-at-rest within the data center. The Brocade encryption SAN switching solutions provide encryption for both disk and tape storage systems... Brocade and Thales are committed to the development and adoption of open standards. TEMS is the first key manager to support the draft IEEE P1619.3 key management specification. Subsequent releases will also support the recently announced OASIS KMIP key management standard, originally co-authored by Thales..." See also Lucas Mearian in ComputerWorld: "Brocade Partners with Thales for Network-Based Encryption Appliance. Later Versions Will Support the OASIS KMIP Key Management Standard." [October 23, 2009] Key Management Interoperability Protocol Specification 1.0. [Candidate] Committee Draft 04. 21-October-2009. 151 pages. Edited by Robert Haas and Indra Fitzgerald. Produced by members of the OASIS Key Management Interoperability Protocol (KMIP) TC. See the source change-marked PDF and Word .doc format, together with the Kavi reference pages: for PDF and for Word. Referenced in the posting of Robert Haas to the KMIP TC discussion list.
"This document is intended for developers and architects who wish to design systems and applications that interoperate using the Key Management Interoperability Protocol specification... The document is intended as a specification of the protocol used for the communication between clients and servers to perform certain management operations on objects stored and maintained by a key management system. These objects are referred to as Managed Objects in this specification. They include symmetric and asymmetric cryptographic keys, digital certificates, and templates used to simplify the creation of objects and control their use. Managed Objects are managed with operations that include the ability to generate cryptographic keys, register objects with the key management system, obtain objects from the system, destroy objects from the system, and search for objects maintained by the system. Managed Objects also have associated attributes, which are named values stored by the key management system and are obtained from the system via operations. Certain attributes are added, modified, or deleted by operations. The protocol specified in this document includes several certificate-related functions for which there are a number of existing protocols — namely Validate (e.g., SVP or XKMS), Certify (e.g. CMP, CMC, SCEP) and Re-certify (e.g. CMP, CMC, SCEP). The protocol does not attempt to define a comprehensive certificate management protocol such as would be needed for a certification authority. However, it does include functions that are needed to allow a key server to provide a proxy for certificate management functions. In addition to the normative definitions for managed objects, operations and attributes, this specification also includes normative definitions for the following aspects of the protocol: (1) The expected behavior of the server and client as a result of operations; (2) Message contents and formats; (3) Message encoding (including enumerations); (4) Error handling..." [October 23, 2009] Key Management Interoperability Protocol Usage Guide 1.0. [Candidate] Committee Draft 03. 21-October-2009. 39 pages. Edited by Indra Fitzgerald. Produced by members of the OASIS Key Management Interoperability Protocol (KMIP) TC. See the source change-marked PDF and Word .doc format, together with the Kavi reference pages: for PDF and for Word. Referenced in the posting of Indra Fitzgerald to the KMIP TC discussion list.
"This document is intended to complement the Key Management Interoperability Protocol Specification by providing guidance on how to implement the Key Management Interoperability Protocol (KMIP) most effectively to ensure interoperability. In particular, the document includes the following guidance: (1) Clarification of assumptions and requirements that drive or influence the design of KMIP and the implementation of KMIP-compliant key management; (2) Specific recommendations for implementation of particular KMIP functionality; (3) Clarification of mandatory and optional capabilities for conformant implementations; (4) Functionality considered for inclusion in KMIP V1.0, but deferred to subsequent versions of the standard. A selected set of conformance profiles and authentication suites are defined in the KMIP Profiles specification. Further assistance for implementing KMIP is provided by the KMIP Use Cases for Proof of Concept Testing document that describes a set of recommended test cases and provides the TTLV (Tag/Type/Length/Value) format for the message exchanges defined by those use cases..." [October 23, 2009] Key Management Interoperability Protocol Use Cases 1.0. [Candidate] Committee Draft 03. 15-October-2009. 87 pages. Edited by Mathias Björkqvist and René Pawlitzek. Produced by members of the OASIS Key Management Interoperability Protocol (KMIP) TC. See the source change-marked PDF and Word .doc format, together with the Kavi reference pages: for PDF and for Word. Referenced in the postings from Mathias Bjorkqvist to the KMIP TC discussion list: for 34709 (.pdf) and 34708 (Word .doc).
"This document is intended for developers and architects who wish to design systems and applications that interoperate using the Key Management Interoperability Protocol specification. Its purpose is to describe use-cases to demonstrate KMIP... The use-cases indicate if all concepts within the protocol are sound and if the protocol is usable when implementing typical scenarios in real life. These use-cases are not intended to fully test an implementation of KMIP. Thus, the use-cases do not contain typical QA scenarios which would stress an implementation. The use-cases are based on v1.0 of the protocol. The use-cases define a number of client-to-server request-response pairs for a number of operations. For each request-response message pair the operation is stated, along with the relevant parameters needed for the request or response message. This is followed by two different illustrations of the messages: first, a human-readable construction which shows the fields tags, types and values, followed by the TTLV encoding of the message. These are included to facilitate the implementation of the message creation and parsing functionality. The use-cases show one possible way to construct the messages, and the messages shown are not necessarily the only correct constructions (e.g. it is possible to omit the attribute index if it is zero). Also note that many values change dynamically when running the use-cases (the server-generated timestamps, Unique Identifiers and key material in responses, as well as Batch Item ID values in client-generated requests). It discusses: Message exchange, Centralized Management, Key life cycle support, Auditing and reporting, Key Interchange, Vendor Extensions, Asymmetric keys, Key Roll-over..." [October 23, 2009] Key Management Interoperability Protocol Profiles Version 1.0. Editors' Draft. 0.99. 23-October-2009. 15 pages. Edited by Robert Griffin (RSA) and Subhash Sankuratripati (NetApp). Produced by members of the OASIS Key Management Interoperability Protocol (KMIP) TC. See the Kavi source .doc and corresponding Kavi reference document, with the posting by Subhash Sankuratripati. Said to be "revision #4 of kmip-1.0-profiles-0.98.doc".
"OASIS requires a conformance section in an approved committee specification [verbatim: 'A specification that is approved by the TC at the Public Review Draft, Committee Specification or OASIS Standard level must include a separate section, listing a set of numbered conformance clauses, to which any implementation of the specification must adhere in order to claim conformance to the specification (or any optional portion thereof)']... This document intends to meet this OASIS requirement by building on the KMIP Server Conformance Target through profiles that define the use of KMIP objects, attributes, operations, message elements and authentication methods within specific contexts of KMIP server and client interaction. These profiles define a set of constraints for employing KMIP within a particular environment or context of use. They may, optionally, require the use of specific KMIP functionality or in other respects define the processing rules to be followed by profile actors. For normative definition of the elements of KMIP specified in these profiles, see the KMIP Specification. Illustrative guidance for the implementation of KMIP clients and servers is provided in the KMIP Usage Guide..." [October 22, 2009] At the October 22, 2009 meeting of the OASIS Key Management Interoperability Protocol (KMIP) TC, members voted to approve the content of three (3 of 4) KMIP documents at Committee Draft level: the KMIP Specification 1.0, the KMIP Usage Guide and KMIP Use Cases. The KMIP Profiles document was identified for further work. See the KMIP TC Meeting Minutes for details. [October 20, 2009] "Emulex and IBM Collaborate on Security for Cloud Storage." By Warwick Ashford. From ComputerWeekly.com. "Emulex is collaborating with IBM to deliver a host-based encryption system to secure data in cloud-based storage, virtualised environments and converged networks. The system is based on the Emulex Secure Host Bus Adapter (HBA) that sits in every physical server in a datacentre and IBM's Tivoli Key Lifecycle Manager. Although due for commercial release in mid 2010, Emulex is to demonstrate the system at the RSA Conference Europe 2009 this week in London at the Hilton London Metropole. Emulex claims this hardware-based approach to encryption provides a cost-effective, easy to use way for enterprises to protect data outside the server. By encrypting every piece of data before it leaves the server, this system avoids the need to classify data and keep track of it, which simplifies data management, said Brandon Hoff, director of security product management at Emulex... The data is encrypted and therefore protected no matter where it goes, for data in-flight on the network and for data at-rest on disc arrays... The Emulex system uses the Key Management Interoperability Protocol (KMIP), which was developed as an industry standard by companies including IBM, RSA, and Emulex.. From the text of the announcement: "Enterprise key management is an essential feature that security conscious companies demand. Emulex and IBM are taking this to the next step by collaborating on the newly developed Key Management Interoperability Protocol (KMIP), according to Steve Daheb: 'With this combined solution, IT managers will have a seamless standards based encryption solution that will enable them to achieve maximum enterprise-wide data center protection, without impacting server performance, delivering better security at a cost point well below other data encryption approaches'... Implementing a host-based encryption security solution improves the data center's security stance and minimizes the window of data vulnerability, because data is protected where it's created, in the host..." See also: the announcement. [October 12, 2009] "Emulex Demonstrates First 8Gb/s Encryption HBA at RSA Conference Europe 2009. Host-based Encryption Security Architecture Protects Data throughout the Enterprise." "... Implementing a host-based encryption security solution improves the data center's security stance and minimizes the window of data vulnerability, because data is protected where it's created, in the host, shielding companies from expensive, embarrassing data loss or theft. With Emulex Secure HBAs, companies benefit from cost-effective, enterprise class security, without upgrading their storage systems, buying expensive appliances that don't scale and add unneeded complexity. Emulex Secure HBAs enable end-users to move away from CPU (Central Processing Unit) intensive host-based encryption software that may either hobble their servers or inhibit the deployment of virtualized servers... This is the first host-based encryption security solution that offloads encryption processing onto the HBA virtually eliminating CPU overhead. Emulex Secure HBA technology is standards-based, leveraging the new Key Management Interoperability Protocol (KMIP) standard, and interoperable with leading key management software and existing encryption solutions. Emulex Secure HBA technology features AES 256-bit encryption, which is deemed unbreakable, and does not require data loss to be reported. In addition, Emulex Secure HBAs simplify mandatory auditing and reporting by placing the required security components (effective access controls, logging, management processes and reporting) at the right place — the host..." [July 16, 2009] "KMIP Proposal to Provide Sufficient Interoperable Key Roles for Financial Applications." Proposal created by Jon Geater, (Thales E-Security). Contributors: Jon Geater (Thales E-Security), Todd Arnold (IBM), and Chris Dunn (Safenet). Proposal Version: 1.6. Publication Date: 2009-07-15. Notification posted to the OASIS KMIP TC on July 16, 2009. Summary: "Proposal for modification to the specification to better accommodate financial crypto applications. This version includes user guide description for supporting asymmetric concepts using symmetric keys." See also: KMIP and Banking-Oriented Key Management," by Todd Arnold (IBM). "To a first approximation, in financial crypto all keys are DES keys of some length or another, and policy is defined at the application layer (e.g., 'VerifyPIN' rather than 'encrypt' or 'decrypt') so basic crypto-level access control does not work: at that level (algorithm, mechanism) all keys are effectively the same. In order to prevent abuse of keys an application layer system of key usage called 'key roles' is employed. By attaching a role to a key it is possible to differentiate it from other keys preventing a PIN validation key from being used as a key encryption key, for example... Augmenting KMIP to cover all the needs of the financial community would be difficult: the world of financial crypto is a complex one with a significant history of regionalization, customization and vendor 'tweaks', making it complex, divergent, and confounding interoperability. However, the financial community, under ANSI X9, has defined an interoperable key block for secure key exchange which captures the set of key roles for keys that are commonly transferred between implementations. While all vendors of financial HSMs/APIs have larger sets of roles with improved security properties or flexibility the workload implications of explicitly supporting all these specializations in the normative document are many. Given that KMIP is an interoperability specification it is deemed sufficient to include only those roles deemed relevant for interchange by the subject matter experts in X9... This proposal completely replaces specification lines 358 (section 3.6) and 1575 (section 9.1.3.2.15) in the version 0.98 KMIP specification. In addition, it adds to the definition of Cryptographic Usage Mask in sections 3.12 and 9.1.3.3.1 to support the new roles definitions. Key Role definitions have been chosen to match those defined in ANSI X9 — TR-31 2005 Interoperable Secure Key Exchange Key Block Specification for Symmetric Algorithms, where Accredited Standards Committee X9, Inc. — Financial Industry Standards contributed to the above table [definitions]. Key role names and descriptions are derived from material in ANSI/X9 TR-31-2005, used with the permission of Accredited Standards Committee X9, Inc. in an effort to improve interoperability between X9 standards and OASIS KMIP..." [Source: reference document and PDF] [June 11, 2009] KMIP and Banking-Oriented Key Management." By Todd Arnold (IBM). Posted to the OASIS KMIP TC List on June 10, 2009. See also the minutes of the KMIP TC meeting June 11, 2009: "Financial services issues (Todd Arnold); key types, symmetric key pairs, hardware-protected attributed AI: write them up as issues and continue discussion of these issues on the reflector..." Excerpts: " [1] I have concerns about KMIP and its ability to provide the features needed in banking-oriented key management... Others in ANSI X9 are also concerned, and they have asked me to act as a liaison between the two groups [See minutes: 'Bob L moves that we recommend Todd Arnold as the liaison from ANSI X9F into KMIP, Markus seconds, unanimous approval']. Key management for banking applications has some special issues that are somewhat different from other more generic key management. For example, requirements are governed by standards such as those from ANSI X9. These standards have very stringent and precise requirements, and they are very difficult to change because of the standards themselves and because of the large set of equipment and software that is in use and must operate together. In many cases, key management techniques and hardware-related security requirements that are acceptable elsewhere are prohibited in the banking applications world. The key types required in banking applications are much more specific than in generic applications, and in many cases they have no analog in non-banking applications. Each hardware HSM vendor has their own proprietary API and cryptographic architecture for their own way of meeting the security requirements in this area. In particular, the key typing and key usage approaches are quite varied, and some are much more complex and granular than others. It is difficult to allow all of these to use KMIP with the very simple and limited set of financial key types that are currently defined..." [2] "I noticed one other thing that is very important, but which I don't think you can do under KMIP. Symmetric keys often come in matched pairs, where the two keys have the same value but have different attributes. An examples would be MAC keys where one can be used for generation or verification, but the other can only be used for verification. Another would be key-encrypting keys where one copy can only be used to export (wrap) and the other copy can only be used to import (unwrap). Symmetric key pairs like this are critical to security in systems like banking, but I see no secure way to create them under KMIP. It only seems to have a function to generate a single copy of the key with whatever attributes are specified. What is needed is an atomic function that generates two copies of a symmetric key, each having different attributes (with reasonable controls so they are matching pairs)..." [3] "Finally, the banking standards have strong requirements that keys be protected at all times by an SCD (Secure Cryptographic Device, often called a TRSM). This means something like an HSM or a secure POS terminal. The keys cannot ever be in plaintext or in any form where plaintext could be recovered, unless they are protected within secure hardware. I think it would be very useful in KMIP to have an attribute that says 'this key must be protected by hardware'..." [June 11, 2009] KMIP and EKMI Credential Bootstrapping." By Anders Rundgren (PrimeKey Solutions). Posting to the OASIS KMIP TC Comment List. "When you are about to perform trustworthy operations between different entities, authentication of the end-points is typically necessary. It seems that KMIP (as well as EKMI) leaves the bootstrapping of end-point authentication credentials to somebody else to cater for. Since this process is both highly device-dependent as well as generally difficult, KMIP interoperability may in practice prove to be quite limited. As a comparison, my own brain-child, KeyGen2, builds on the fact that devices are shipped with a device certificate. One may claim that KeyGen2 requires enhanced devices, and yes this is true! The problem with not requiring enhanced devices is that "the tyranny of the least common denominator" will rule which is a stopgap to progress. That is, the missing bootstrap may severely impede market acceptance. Note: KeyGen2 does not compete with KMIP because KeyGen2 (deliberately) supports a very limited range of devices that are used by everybody (phones) but would be totally useless for storage. I would if I were you consider "borrowing" the device certificate concept. Properly implemented, all kinds of shared secrets and enrollment passwords are eliminated by device certificates. If you are curious on how such a scheme could work you may take a peek in section "Dual-use Device IDs" in [the document] "SKS: Secure Key Store." [It reads, in part:] "The Device Certificate is used as a trusted device ID in a provisioning process. That is, an issuer may reject requests attested by an SKS from an (for the issuer) unknown vendor. A side-effect of using certificate-based device IDs is that you can create efficient and still quite secure on-line enrollment processes where a non-authenticated user signs-up for credentials by sending an SKS-attested request to an issuer. The issuer can then verify the user's identity with an OOB (Out Of Band) method meeting the issuer's policy which can be anything from the classic 'e-mail roundtrip', to requiring the user to show up in an office with an identity card. The final part is asking the user for something like the first 8 characters of the 40 hexadecimal-digit SHA1 certificate hash which is the short-form of the device ID. If the answer is matching the device ID of the request, the issuer returns the completed credential package to the user's SKS. Note that this scheme can completely eliminate enrollment passwords! Improved methods for remote provisioning are primarily needed for consumers, mobile phones, employees in virtual organizations, as well as for replacement credentials for people who have lost their card far away from the main office..." [June 09, 2009] "KMIP Base Objects and Managed Objects." By Rod Wideman (Quantum Corporation). Contribution to the KMIP TC. 3 pages. See the posting of June 09, 2009 to the OASIS KMIP TC List, "Naming and format suggestions for Base Objects and Managed Objects.' Excerpt: 'Observations and suggestions regarding KMIP sections 2.1 (Base Objects) and 2.2 (Managed Objects). Base Objects appear to be consistently structures, and the term 'base objects' seems to be an idea to differentiate them from managed objects. Some of these base objects have additional structures within them. The tables used throughout 2.1 are all consistent in layout though, using the same layout for things called objects and things called structures. The first column header is labeled 'Object', but most of the rows appear to be fields within the object (or structure), and the last column header is labeled either 'Required' or 'Required Field' (the latter label also implying that the rows are fields). Each table includes a row that is the name of the object or structure itself, for which the table defines. Since this row is included along with the rows (fields) that compose the object or structure, it may lead to some confusion, but at least seems distracting (to me anyway). So my suggestions are as follows: (1) Structure the tables slightly differently by using a title for each table and reference the table by title in the text (2) Call 'base objects' something else, like just 'structures'. Then whether or not they contain sub-structures, all the tables and text in 2.1 can be consistent and Managed Objects in 2.2 can more cleanly refer to structures..." [May 29, 2009] "Key Exchange." By Michael Vizard (eWEEK) and Kevin Bocek (Director of Product Management, Thales e-Security). From eWEEK (May 14, 2009). "In this eWEEK podcast hosted by Mike Vizard, the Director of product marketing for Thales, Kevin Bocek [WWW], talks about the impact that a new KMIP (Key Management Interoperability Protocol) standard will have on spurring widespread adoption of encryption. Storage managers, data center operators, and IT security teams are demanding new support for full encryption next step in data security. With encryption comes the need for integrated key management within databases and other applications to cover business continuity and SLA requirements. Encryption is now being deployed as critical part of enterprise infrastructure. The KMIP interoperability specification is a big step for the industry in terms of supporting development of interoperable security products. The standard will be applicable for key management systems and servers, for both software-based applications (databases, web servers) and hardware (tape drives, disk arrays, network switches)... Encryption is is now being deployed to a much larger extent than over before, so key management needs to be commensurable... We've seen an end to crypto wars (e.g., certificate formats) so the focus is on reliability and recoverability of data: we need key management that's stable and tested. Key management is moving away from the point applications (from concern about individual keys) to policy and compliance concerns. The question isn't so much "where are my keys?" but "what are my key management policies? how can I pass an audit?... Data center operators need to be able to know and prove that their encryption supports recoverable data. Where to encrypt: software, hardware, both? It depends: what's the risk: what's threat to the data, and what are the consequeneces of compromise (data breach). If you have high-value transactions, the data may need to be protected (encrypted) early and throughout its life cycle; but some data becomes sensitive only at certain points. For storage systems, encryption is now moving from being an option to being an expectation/requirement. Many devices are shipped with hardware that supports encryption - even if it's not activated initially. Similarly, with databases: expectation is growing that information is encrypted in the database. Cost factors are coming down as encryption gets embedded in applications and hardware devices. A challenge however is management of keys in terms of automation and auditing for operations. KMIP interoperability will help a lot..." [source MP3] [May 28, 2009] Key Management Interoperability Protocol (KMIP): Addressing the Need for Standardization in Enterprise Key Management. Version 1.0. (supersedes draft Version 0.9). May 20, 2009. 22 pages. Copyright © 2009 by the Organization for the Advancement of Structured Information Standards (OASIS).
"The increasing use of encryption, certificate-based device authentication,
asymmetric key pairs and digital signature reflects the critical importance of
cryptography in addressing regulatory requirements, protecting intellectual property and
controlling the exposure of sensitive information. However, the widespread use of these
and other cryptographic technologies is complicated by inconsistencies and duplication in
the key management systems supporting the applications, devices and systems using
these technologies.
For example, each native tape encryption system tends to have its own key
management system, separate from the key management system for application
encryption, or database encryption, or file encryption. Full-disk encryption systems for
laptops have their own key management systems, as do encryption systems for disk-array
storage environments and content management systems. Asymmetric key pairs and
digital certificates similarly have their own key management systems as well. This
proliferation of key management systems results in higher operational and infrastructure
costs for enterprises using encryption, certificates, asymmetric key pairs and other
cryptographic technologies.
Even in those cases where a single key management system can support multiple
types of security objects and multiple kinds of cryptographically-enabled systems, there
are typically different communication protocols between the key management servers and
each of the cryptographic clients that communicate with it. An enterprise key
management system, for example, is likely to have to communicate with an encrypting
tape drive using a communication protocol specific to that tape drive, or with a SAN
switch by means of a communication protocol specific to that switch, or with an
application requiring asymmetric keys with yet another communication protocol and so
on. This proliferation of protocols, even when supported by a single enterprise key
manager, results in higher costs for developing and supporting the key manager; costs
that ultimately get passed on to the enterprises deploying security solutions.
The Key Management Interoperability Protocol (KMIP), recently introduced as a
new technical committee in the Organization for the Advancement of Structured
Information Standards (OASIS), establishes a single, comprehensive protocol for
communication between enterprise key management servers and cryptographic clients.
By defining a protocol that can be used by any cryptographic client, ranging from a
simple automated electric meter to very complex disk-arrays, KMIP enables enterprise
key management servers to communicate via a single protocol to all cryptographic clients
supporting that protocol. Through vendor support of KMIP, an enterprise will be able to
consolidate key management in a single enterprise key management system, reducing
operational and infrastructure costs while strengthening operational controls and
governance of security policy...
KMIP [therefore] represents a significant step forward in securing information infrastructure
throughout the industry. KMIP's creation and subsequent adoption by industry vendors
will reduce the complexity of encryption management for enterprises by building
interoperability into the key management environment. By enabling support for
interoperability between cryptographic clients and enterprise key management systems,
KMIP reduces infrastructure costs and the risks in adopting cryptographic solutions as an
essential element of securing information, identities and infrastructure..." [May 21, 2009] "Proposal for Renaming the Application Specific Identification Attribute." By Rene Pawlitzek (IBM Zurich Research GmbH). Version 1. Updated Version 2 (revision #3) PDF and .DOC, posted 2009-06-11. See the initial posting to the OASIS KMIP TC discussion list. Also in Word .DOC format Purpose: "Rename the Application Specific Identification attribute because the current name does describe the purpose of this attribute accurately. It can be used for a variety of different purposes and not only for storing the intended use of a managed object. Thus, the attribute would benefit from a more generic name." Details: Application Specific Information: "The Application Specific Information is used to store data which is specific to the application(s) using the object. It consists of two parts: a name space and application specific data. The application name spaces are arbitrary text strings so that new types of application data can be used without requiring the standard to be updated. The Usage Guide provides a list of application name spaces. Clients can provide an instance of this attribute with a particular Application Name Space while leaving out Application Data.This results in the server returning a suitable Application Data value provided the server is able to generate Application Data for this particular Application Name Space..." Source: reference page and PDF. [May 16, 2009] "KMIP is the Key." By Blair Semple (NetApp, and Vice-Chair, SNIA Storage Security Industry Forum - SSIF). From Compliance and Security Made Semple (Blog). Posted 04/28/2009. "After attending the Storage Networking World show in Orlando earlier this month, I was struck by the fact that the community of storage security vendors have done a lousy job of establishing viable interoperability standards to help make our customers' operations function more efficiently. I've been involved in the Storage Security industry since 2002... Looking back, I think one of the most significant factors that has limited the ubiquitous deployment of solutions that encrypt data-at-rest within the enterprise is key management — or perhaps more specifically, the lack of a key management standards. In many ways it is shameful that we as a vendor community haven't been able to come up with a standard interoperability protocol that would allow an end-user to purchase different solutions for different applications or datasets but only deploy one key management solution — making the best use of their investment. However, until very recently, each solution had its own proprietary key management system, and end-user organizations are understandable reluctant to deploying multiple key management systems for different encryption solutions. In early 2007 work began on a key management protocol within the IEEE Security in Storage Working Group — a project known as P1619.3 Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data. Member companies of this project include Brocade, Cisco, HDS, HP, IBM, NetApp, RSA and many others... Two years later we still find ourselves without a standard. Now, a new standardization project is being started up called Key Management Interoperability Protocol (KMIP) under the OASIS group. Just announced in February [2009], a similar cast of characters are involved in this new effort to establish a standard. Their estimate is to have something finalized in the next 12 months or so, and hopefully products will appear without to much extra delay. The end-user organizations I work with are clamoring for interoperable key management systems that allow them to deploy what makes the most sense for their applications without having to deploy and manage multiple systems. Please, please, please tell your vendors that this is an important part of your security strategy, and you cannot wait another two years for compatible technologies to appear. As vice-chair of SNIA's Storage Security Industry Forum I have seen evidence of competing vendors working together to advance an industry. Together we have published Solutions Guides, Best Current Practices recommendations among other educational materials. I can only hope that we can effectively work together to nail down a viable key management interoperability standard soon to help fulfill the promise of our storage security solutions..." [May 16, 2009] KMIP: Proposal for Conformance. Posted to the OASIS Key Management Interoperability Protocol (KMIP) TC repository by Robert Lockhart. 5 pages. Summary: "Propose removing Clause 1.8 (Compliance) in the Specification and Usage Guide [Specification Lines 40 to 41; Usage Guide Lines 31 to 32]. Propose removing clause 5 of the Usage Guide, adding conformance clause (clause 13) of the specification and to include four sub-clauses. Sub-clauses include defining claim of conformance using current verbiage listed in Clause 13 (moved to sub-clause 13.1), defining a standard for referencing KMIP within other standards (sub-clause 13.2), defining a standard for using portions of KMIP within another standard without claiming conformance (sub-clause 13.3) and defining extensions to KMIP objects, attributes, operations and profiles (sub-clause 13.4). Propose addition of conformance table in either the conformance section or for server and client requirements to remove ambiguities (having to read) of what is required versus what is not. In this proposal it is shown as an appendix. Consider placing this in the Usage Guide as informational in place of clause 5. It may also be desirable to add a single line table to each object, attribute, operation and message that contains Client and Server requirements for the specific object, attribute, operation and message so there is no misunderstanding about what is required to claim conformance..." Thus: '5.1 Claiming Conformance with KMIP Standard': Server implementations of the KMIP protocol must support all objects, attributes, operations and profiles not specified as optional in the KMIP Specification in order to be conformant to the specification. Server implementations that do not support objects, attributes, operations and profiles defined as optional can claim KMIP conformance, though they may be limited in terms of interoperability with other KMIP implementations. Client implementations of the KMIP protocol may implement any subset of the KMIP protocol. For example, a client may implement only the Get and Locate operations for symmetric keys. In order to claim conformance, however, such a client must implement all aspects of any elements of the protocol (objects, attributes, operations, profiles) that it claims to support. In the example of Get/Locate support for symmetric keys, therefore, a conforming client implementation must support all required attributes for symmetric keys..." [May 15, 2009] "KMIP 64-bit Binary Alignment Proposal." By Matt Ball (Sun Microsystems, Inc). Contribution to the KMIP TC, updating the KMIP 32-bit Binary Alignment Proposal. Document posted by Matthew Ball to the KMIP TC document repository. 10 pages. See also the source .DOC. Summary: The document revision named Sun 64-bit Binary Alignment Proposal v2 has been submitted by Matthew Ball to the OASIS Key Management Interoperability Protocol (KMIP) TC document repository. This document is revision #2 of 'Sun 64-bit Binary Alignment Proposal'. This document is a proposal to change the KMIP binary encoding so that it is aligned to 64-bit boundaries; the document details page will show the complete revision history.' From the 'Introduction': "The binary encoding as defined in the 1.0 version of the KMIP draft does not maintain alignment to 8-byte boundaries within the message structure. This causes problems on hard-aligned processors, such as the ARM, that are not able to easily access memory on addresses that are not aligned to 4 bytes. Additionally, it reduces performance on modern 64-bit processors. For hard-aligned processors, when unaligned memory contents are requested, either the compiler has to add extra instructions to perform two aligned memory accesses and reassemble the data, or the processor has to take a 'trap' (i.e., an interrupt generated on unaligned memory accesses) to correctly assemble the memory contents. Either of these options results in reduced performance. On soft-aligned processors, the hardware has to make two memory accesses instead of one when the contents are not properly aligned. This proposal suggests ways to improve the performance on hard-aligned processors by aligning all data structures to 8-byte boundaries. Summary of Proposed Changes: This proposal includes the following changes to the KMIP 0.98 draft submission to the OASIS KMIP TC: (1) Change the alignment of the KMIP binary encoding such that each part is aligned to an 8-byte boundary. This is done by: (a) Change the Tag field to occupy 3 bytes. In this way, the combined size of the Tag, Type, and Length fields is 8 bytes. (b) Require that all Item Value fields be padded with zero to seven bytes of the value 00 such that the length of the Value field is a multiple of 8 bytes. The Item Length still contains the correct, unpadded length of the Item. (2) Change the length of the Item Value for Binary types to be 4 bytes (instead of 1 byte), with hex values 00000000 for false and 00000001 for true. (3) Change the format of the Big Integer Item Type to require that the Item Value be padded with sign-extended bytes on the left (i.e., most significant bytes) such that the total length is a multiple of 8 bytes..." [May 07, 2009] "OASIS Group Aims to Simplify Crypto-Key Management." By Tom Espiner. From ZDNet.co.uk. "Open-standards consortium OASIS has formed a group to devise a standard aimed at allowing encryption products to work easily with business applications and with each other. Group members include IBM, Cisco, EMC, HP, PGP Corporation, Symantec, and the US National Institute of Standards and Technology (NIST). The OASIS group, called the Key Management Interoperability Protocol (KMIP) Technical Committee, will aim to define a single protocol for communication between encryption systems and enterprise applications, to cover such things as email, databases and storage devices. The companies participating in the new group submitted a key management interoperability standard to OASIS in February. Key management interoperability is vital for businesses to be able to successfully implement encryption and protect data, according to Jamie Cowper, PGP's EMEA marketing manager. 'With the best will in the world, businesses are never going to be using a single encryption product, or a single company to provide that,' Cowper told ZDNet UK on Thursday. 'It's great to see key members of the security and encryption community working together and recognising the business need for key management interoperability.' Key management is a problem for businesses, according to Cowper. As more documents are encrypted throughout an enterprise or shared with third parties, keys proliferate. Managing the administration of those keys until they are revoked is a problem that is exacerbated as companies grow, said Cowper. 'Encryption is really just a standard,' said Cowper. 'To strongly protect and decrypt in an automated way is the clever bit'..." [May 06, 2009] OASIS Announcement 2009-05-06. "OASIS Members Advance Interoperability Standard for Enterprise Encryption Key Management. IBM, Axway, BeCrypt, Brocade, Cisco, EMC, Emulex, HP, PGP Corporation, Red Hat, SafeNet, Skyworth TTG, Symantec, Thales, U.S. National Institute of Standards and Technology (NIST), Venafi, and Others Collaborate on Open Standard for IT Security, Compliance, and Data Recovery." — OASIS announced the formation of a new group to enable interoperability of key management services and clients. The new OASIS Key Management Interoperability Protocol (KMIP) Technical Committee will work to define a single, comprehensive protocol for communication between encryption systems and a broad range of new and legacy enterprise applications, including email, databases, and storage devices. KMIP will enable key lifecycle management, including the generation, submission, retrieval, and deletion of cryptographic keys. Designed for use by both legacy and new encryption applications, KMIP will support symmetric and asymmetric keys, digital certificates, and other 'shared secrets'. "As encryption technologies become more pervasive across the enterprise, key management quickly becomes a mission critical activity for protecting the sensitive data. Without a standard way to integrate encryption technologies and key management systems, data confidentiality and integrity may actually degrade," said Jon Oltsik, Principal Analyst at the Enterprise Strategy Group. "To address this issue, I've long been a strong proponent of key management standards and did what I could to push leading security vendors in this direction. I'm happy to say that the OASIS KMIP effort may finally fill this void." Robert Griffin of EMC, co-chair of the OASIS KMIP Technical Committee: "Our goal is to dramatically simplify the way companies encrypt and secure information." Anthony Nadalin of IBM, co-chair of the OASIS KMIP Technical Committee: "By removing redundant, incompatible key management processes, KMIP will provide better data security while at the same time reducing expenditures on multiple products." [...] [April 30, 2009] "P1619.3 and KMIP: Understanding the Differences and Similarities." By Robert Lockhart (Information Systems Security, Thales). See the posting. 12 slides. This slideset is accompanied by a spreadsheet which shows potential mapping between KMIP version 0.98 and P1619.3 Draft 6 specifications (posting). Excerpts: "P1619.3 is a complete architecture for managing keys used to encrypt stored data. This includes data stored in databases, on disk, on tape, in a file, etc. P1619.3 is composed of: (1) Name Spaces: Key, device and object globally unique identifiers (2) Objects: Keys and all associated attributes; devices and all associated attributes; groups of devices and or keys (3) Policies: Rules for handling of keys by key management servers and encryption devices (4) Operations: Generation, Retrieval, Storage of keys, policies and objects (5) Messaging: Format and syntax required to perform operations (6) Transport: TLS secure transport used to pass messaging from a KM Client to a KM Server... KMIP is an application agnostic messaging format that allows for the management of keys. It allows a Key Client to communicate with a Key Server using a common set of messages. KMIP consists of: Tag, Type, Length, Variable (TTLV) Messaging (including Objects, Attributes, Client to Server Operations, Server to Client Operations, Message Contents, Message Format, Message Encoding, Error Handling... KMIP currently defines the base requirements to provide key management interoperability (a) By not adding a set of architectural requirements KMIP can be used in multiple environments (b) Does not require traditional networks for connectivity... P1619.3 is defining a complete architecture that will ensure interoperability between storage KM Clients and KM Servers — by specifying all requirements such as transports, messaging, name spaces and other components of the architecture interoperability is more likely between the client and server... It is quite possible that P1619.3 could make use of KMIP when it is completed by OASIS. The Mapping Effort is approximately 90% complete; still some attribute mappings that need to occur for P1619.3 areas that are unclear or have proposals pending... Currently KMIP provides for all objects, attributes, policies and operations with one exception; some of these will require use of extensions as defined in current KMIP draft... Exception: P1619.3 defines an additional Server to Client operation (Get Status), allowing the server to request current operational state of the end point, KM Client or Cryptographic Unit (definition not complete). P1619.3 needs additional work to conform with KMIP requirements. Proposals have been put forward to re-define P1619.3 around KMIP. Level of effort still to be determined. Areas that are still 'To Be Defined' (TBD) require proposals... KMIP Required vs. Optional Items: Clarification of required vs. optional objects, attributes, etc..." [Sources: reference page and PDF; see also the .XLS spreadsheet and reference page.] [April 30, 2009] Application Specific Identification. By Scott Kipp (Standards and Technology Group, Brocade). Contributed to the OASIS KMIP TC. 6 pages. See the posting of April 30, 2009 and updated information on May 20, 2009. Author's note: "I took an action item to add text to the usage guide as to how the Application Specific Identification was used for a Brocade requirement. When I investigated the field, I thought that the description of Application Specific Identification doesn't fit the usage model. I suggest changing the description and adding more Application Specific Identifications. I also suggest to change the name to Client Generated Information since this seems to be how the field is used. I would like to get the groups approval for this proposal..." Client Generated Key_ID: (a) Brocade has a need for a Client Generated Key_ID; (b) The Client Generated Key_ID should be separate from the Unique Identifier generated by the Server; (c) Application Specific ID could be used to store the Client Generated Key_ID, but it seems to have a different purpose; (d) Brocade suggests to have multiple Client Generated IDs for multiple uses." Use of Application Specific ID: "The definition of the Application Specific ID is rather limited to specify the intended use of the Managed Objects. The examples don't really explain the intended use but are very useful. We suggest to change the first sentence to: 'The Application Specific Identification is used to store Client-generated information about the Managed Object'. Should this field be renamed to Client Generated Information?" More than One Application Specific ID: "Only one Application Specific ID is available for the client now With the wide range of possible uses for this field, we suggest to enable more than one Application Specific ID. We suggest 4 or 8 Applications Specific IDs." Proposed Additional Text for the Usage Guide [following 4.9 'Unique Identifiers'] "4.10 Application Specific Identification Clients may require a number of Application Specific Identifications and they can be used for a variety of purposes. Up to eight Application Specific Identifications can identify such items as URLs, Client Generated Key IDs and file names." [Source: reference page and PDF] [April 29, 2009] "KMIP Key Naming for Removable Media Interchange." By Stan S. Feather (HP). Version 1.0. See the posting. Author's note: "Attached is an outline for a key naming proposal, to provide interoperability in removable media applications. This provides additional information around a topic we briefly discussed at the 24-April-2009 meeting. Thanks, Stan Feather (HP StorageWorks)." Covers: Use Cases and Problem Statement; Visibility; Proposal Outline. Problem Statement: Mlti-vendor interchange breaks when media is encrypted, even though keys are stored on a KMIP key server. Use Case: Interchange encrypted media between multi-vendor storage systems. Conditions: Media interchange exists normally — without encryption, encryption was transparent to host software, keys created by each vendor's solution are stored on a KMIP key server... Currently, the issue is not visible: Keys are stored on separate servers, no interchange is possible. The issue will become visible after KMIP: (a) Multi-vendor clients will store keys on KMIP server; (b) Each vendor's KMIP client, or an admin, will create named keys; (c) Key names are currently vendor unique; (d) Even with KMIP, multi-vendor media interchange will remain broken... Outline of HP's Proposal: we propose adding a key attribute to assist clients resolve the key's name, and an addition to the the KMIP Usage Guide to explain use cases for the name-resolution attribute. Details: (1) Un-correlated. (default value). The key is not used in removable media applications. Or, none of the keys's names correlate to key name(s) stored on the removable media. (2) Simple correlation. One or more of the key's names is also stored on the media. The media and the server copies of the name can be matched by simple string compare. (3) Public correlation algorithm. The server and media copies of the key name can only be matched using a publicly accessible algorithm. The definition and use of these algorithms is outside the scope of KMIP. The definition may specify a key attribute to identify the specific algorithm. (4) Private correlation algorithm. The server and media copies of the key name can only be matched using a private algorithm. The key may not be accessible in multi-vendor configurations..." [Source and file 'kmip-naming-v1.0.ppt', cache] [April 29, 2009] "KMIP 32-bit Binary Alignment Proposal." Version 1. See update, 64-bit: "KMIP 64-bit Binary Alignment Proposal." [Update: Version 2, Version 3.] By Matthew Ball (Sun Microsystems). Technical Proposal contributed to the OASIS Key Management Interoperability Protocol (KMIP) TC. See the posting and response thread (version -00). Version 1 Summary: A proposed change to the binary encoding such that each part is aligned to a 4-byte boundary. This document is a proposal against KMIP v0.98 to change the alignment of the binary encoding to fall on 32-bit boundaries, optimizing the layout for hard-aligned processors, such as the ARM. Author's note: "Here is version 1 of the Sun 32-bit Binary Alignment Proposal. I'm hoping to discuss this during tomorrow's KMIP meeting, and to move for its acceptance if there is general consensus. Please send me any word-smithing comments beforehand so that we don't use up meeting time unnecessarily." Introduction: "The binary encoding as defined in the 0.98 version of the KMIP draft does not maintain alignment to 4-byte boundaries within the message structure. This causes problems on hard-aligned processors, such as the ARM, that are not able to easily access memory on addresses that are not aligned to 4 bytes. When unaligned memory contents are requested, either the compiler has to add extra instructions to perform two aligned memory accesses and reassemble the data, or the processor has to take a 'trap' (i.e., an interrupt generated on unaligned memory accesses) to correctly assemble the memory contents. Either of these options results in reduced performance." Details: (1) Change the alignment of the KMIP binary encoding such that each part is aligned to a 4-byte boundary. This is done by: [a] Change the size of the Item Type field from one to four bytes. [b] Require that all Item Value fields be padded with zero, one, two, or three bytes of the value 00 such that the length of the Value field is a multiple of 4 bytes. The Item Length still contains the correct, unpadded length of the Item. (2) Change the length of the Item Value for Binary types to be 4 bytes (instead of 1 byte), with hex values 00000000 for false and 00000001 for true. (3) Change the format of the Big Integer Item Type to require that the Item Value be padded with sign-extended bytes on the left (i.e., most significant bytes) such that the total length is a multiple of 4 bytes..." [Source reference page and PDF v1, v2, v3] [April 24, 2009] Roundtable: Informal KMIP Information Session at RSA Conference, 2009-04-22.. — Bob Griffin, KMIP TC Convenor, announced an informal Roundtable session on KMIP at the RSA 2009 Conference in San Francisco, April 22, 2009, 5:00 PM PDT. The session will be held in the Roundtable room next to the keynote auditorium. Anyone interested can just come to the room at 5:00, or contact Bob Griffin for more information. Report: [TBD] [April 14, 2009] "Thales Announces Industry's First Standards-Based Encryption Key Management Appliance. Thales's Encryption Manager for Storage Streamlines Encryption Key Management Processes and Promotes Adoption of Storage Encryption." — Thales, leader in information systems and communications security, has announced Thales's Encryption Manager for Storage (TEMS), "the industry's first standards-based encryption key management appliance for storage managers." TEMS supports IEEE P1619.3 and is designed to support OASIS Key Management Interoperability Protocol (KMIP), along with certain proprietary key management interfaces from leading storage vendors. This eliminates the need for storage professionals to deploy multiple key management systems and gives storage vendors the option to partner with an independent key management provider rather than develop and maintain their own key management systems. TEMS is available as a ready-to-use appliance that consolidates and automates the management of encryption keys for storage systems in a transparent manner, delivering unified, fine-grained and auditable encryption key security controls. This enables organizations to adopt storage encryption with the confidence that their encryption keys are under control and secured in a cost- effective and future proof management system. Jon Oltsik, senior analyst with Enterprise Strategy Group: "As data breaches continue to embarrass companies and incur real costs, security initiatives have naturally focused on the storage infrastructure. The use of encryption within the switching fabric, back-up tapes, drives, arrays, and host adapters is rapidly becoming essential for safeguarding sensitive information, but many organizations are concerned about reliability and data recoverability issues." TEMS is the first standards-based key manager available with draft IEEE P1619.3 key management standard support and will support the final specification, due out early 2010. Subsequent releases will also support the recently announced OASIS KMIP key management standard, originally co-authored by Thales with other leading vendors. Through collaboration with partners TEMS will support legacy or proprietary key management interfaces to provide storage professionals with the flexibility and freedom to utilize encryption at various points within their storage environments and to take advantage of pre-certified integration with their preferred storage systems. TEMS benefits from a secure and highly scalable architecture designed to meet FIPS 140-2 and builds on Thales's core cryptographic expertise and reputation for deploying strong cryptography in support of a wide variety of applications. TEMS will be available in July 2009..." See also "Thales Launches Standards-Based Encryption Key Management Appliance," by Steve Ragan, from The Tech Herald. [April 16, 2009] "Thales Addresses Encryption Key Management." By Dave Simpson. From InfoStor. "Thales (pronounced 'talus') has announced the Thales Encryption Manager for Storage (TEMS) key management appliance. In contrast to proprietary key management systems, TEMS is currently based on the IEEE P1619.3 standard and will eventually support the Key Management Interoperability Protocol (KMIP) standard, which was developed by vendors such as Thales, EMC, HP and IBM, and has been submitted to the Organization for the Advancement of Structured Information Standards (OASIS). The KMIP standard is expected to finalized by the end of this year. Thales will sell the appliance to both storage vendors and end users, with shipments scheduled for July 2009. The key management appliance includes an interface that enables integration of additional key management protocols, including proprietary protocols. The appliance can be used with tape- and disk-based storage devices, as well as switches and host bus adapters (HBAs). TEMS features include automated key management, auditable encryption key security controls, and FIPS 140-2 compliance. Kevin Bocek, Thales' director of product marketing: 'For storage vendors, TEMS provides a ready-to-use appliance for storage devices with embedded encryption, which eliminates the need for vendors to develop and maintain key management systems. For storage managers, TEMS eliminates the concerns associating with encryption, including reliability, data recoverability and the need to maintain multiple key management systems, which reduces time and costs. Theoretically, you could have one key management system for tape, disk, switch and HBA devices'..." [April 09, 2009] "Thales Sees Converging Encryption Standards." By Beth Pariseau. From TechTarget.com. From the article "Sights and Bites From SNW" [Storage Networking World Spring 2009]. "In February [2009], Thales Group was part of a coalition of vendors that submitted a standard for interoperability between key management systems and encryption devices to the Organization for the Advancement of Structured Information Standards (OASIS) called the Key Management Interoperability Protocol (KMIP). If adopted, KMIP would mean users could attach almost any encrypting device to one preferred key management system, regardless of the vendors involved. Meanwhile, the Institute of Electrical and Electronics Engineers (IEEE) approved a standard in January 2008 for managing encryption on storage devices. Now the vendors are working on bridging between the two standards, according to Kevin Bocek, director of product marketing for Thales, so that if product developers want to roll the more-detailed IEEE spec into the more general OASIS spec, the two will be compatible. This interoperability will probably be more valuable to developers than end users, he said, as the IEEE specification contains very granular details for developing products down to specificying protocols. If engineers don't have to re-invent the encryption wheel or ensure interoperability for each of their products, it could get products to market faster or free them to focus on other innovations, he said..." See also "Lack of Data Encryption Standards Hampering Storage Security." [April 05, 2009] Key Management Interoperability Protocol (KMIP): Addressing the Need for Standardization in Enterprise Key Management. See the Version 1.0 document, which supersedes Version 0.9. KMIP White Paper. Draft Version 0.9. April 5, 2009. 22 pages. Copyright © 2009 by Brocade, Cisco, EMC, Hewlett-Packard Development Company, IBM, LSI, NetApp, Seagate, and Thales. [March 30, 2009] "Enterprise Data Protection." By Nigel Stanley. Bloor Research Market Update. "Turmoil in international financial markets, coupled with multiple significant data leak events in both the public and private sectors, has placed enormous pressure on businesses to more actively manage their risk... End user organisations need to be reviewing their data loss and encryption strategies as a matter of urgency to prevent expensive and reputation-damaging incidents. This needs to be approached from a strategic viewpoint so that best use is made of budgets, personnel and systems. In February 2009, Voltage Security released enhancements to Voltage SecureMail. EMC, IBM, HP, and Thales with Brocade, LSI, NetApp, and Seagate announced they were forming an OASIS Key Management (KMIP) group in an effort to improve encryption key management... Encryption key management is still an issue as end user organisations still look for the silver bullet that will ease this complex task... The pressure on most businesses is very high as they contend with financial uncertainty, supply chain disruption and delayed or aborted buying decisions. Part of ongoing risk management must incorporate IT security and, in particular, the mitigation of data losses due to a disrupted employee base. Organisations still need to ensure that data does not leak from their systems and if it does it remains securely encrypted. Vendor solutions available today should be assessed, and partnerships created with the best vendor able to supply an Enterprise Data Protection product set in a realistic time frame that suits your particular organisation..." Note: Companies listed in this report include: 3BView, Adobe, Aladdin, BeCrypt, CA (Orchestria), CheckPoint (Pointsec), Cisco, ClearSwift, Code-Green Networks, Credant Technologies, CryptoForge, Cryptzone, Dekart, DESLock, Fidelis Security Systems, FrontRange Solutions, GTB Technologies, GuardianEdge, Lumension Security, McAfee, Microsoft, Mobile Armor, PGP Corporation, RSA, Safend, Secude, Sophos (Utimaco), Symantec, TrendMicro, Tumbleweed Communications (Axway), Verdasys, Vericept, Voltage Security, Vormetric, Websense, Winmagic, and Workshare. [March 24, 2009] "Keys Multiply Like Rabbits." By [EMC Staff Member, Mark Twomey] Storagezilla [Disclosure: author works for EMC, who offers RSA Key Manager for the Data Center]. From Byte and Switch (Talk) This posting is a response to Howard Marks' article, "Let's Bring Sanity to Disk Encryption", published March 23, 2009. Marks had said: "Given the cost and complexity of today's solutions, I'm not sure solving the drive disposal problem is a good enough reason to invest in SAN encryptors. Now that the Trusted Computing Group has come out with standards for self-encrypting drives, with separate specs for laptop-orientated and enterprise drives, and all five drive manufacturers have endorsed them, a new and better solution should soon emerge. Array manufacturers should build support for self-encrypting drives into the firmware of their RAID controllers. The RAID controller holds the encryption key for each drive. Since we don't expect to be able to move drives from one storage system to another and use the data on the drive, each storage system can be its own key management domain with no need for an enterprise key management infrastructure. The overhead of storing encryption keys for several hundred drives, and retrieving them on array startup, should be minimal. The real work of encrypting and decrypting data happens in each drive, so it is the job of Seagate or Hitachi Global Storage Technologies to make it fast..." Storagezilla replies: "It's not that cut and dried, and things start getting complex if you have array level replication going on as you'll need access to the key on the other side to read the data on the replica. Which means you're no longer dealing with just one domain per device. If you want end to end encryption you might be doing it in the app itself and for legacy gear you might be using software or HBA encryption and before we know it anyone with a large amount of gear on the floor has keys coming out their ears all managed through how many interfaces to whatever number of devices involved. I get the point, encryption should be built in and not bolted on and that's true of all security but encryption keys are like rabbits and before you know it you're up to your neck in them. That's why the Key Management Interoperability Protocol is so important going forward. Yeah build in encryption, yes offer to store and manage the keys locally but via KMIP make sure you can easily tie them all back to an Enterprise Key Manager so you're not burning cycles managing a couple of keys per device across a lot of devices. That's not the best use of anyone's time..." [And Howard replies]: "If we encrypt data from disk drive interface to platter your replication example doesn't happen. Array to array replication is in the clear as data isn't encrypted in the controller which just holds the keys. All your other examples work as it the array wasn't encrypting at all. Yes the array controller should talk KMIP but I don't see real world problems with local keys in this case. Now for tapes, archive data with digital shredding and lots of other apps key management is a much bigger deal..." [March 20, 2009] KMIP Webinar: "An Introduction to the Key Management Interoperability Protocol (KMIP)." [Now] with Presentation Slides. Thursday, April 2, 2009. Time: 9:00 AM - 11:00 AM New York ET (6:00 AM - 8:00 AM San Francisco PT; 3:00 PM - 5:00 PM London; 9:00 PM - 11:00 PM Hong Kong). Presenters: (1) Robert Griffin — Director of Solution Design at RSA, the Security Division of EMC; (2) Robert Haas — Research Staff Member, IBM Zurich Research Lab; (3) Tony Nadalin — Distinguished Engineer, IBM Chief Security Architect; (4) René Pawlitzek — Principal Engineer, IBM Zurich Research Lab. Register online. "The increased use of encryption for securing information in the enterprise reflects the critical importance of this technology in addressing regulatory requirements, protecting intellectual property and controlling the exposure of sensitive information. The widespread use of encryption, however, is complicated by inconsistencies and duplication in the key management systems supporting each of the encryption environments. Full-disk encryption systems for laptops have their own key management systems, as to encryption systems for array-based storage environments and content management systems. This proliferation of key management systems results in higher operational and infrastructure costs for enterprises using encryption. Even in those cases where a single key management system can support multiple encryption systems, there are typically different communication protocols between the key management system and each of the encryption systems. The proliferation of protocols, even when supported by a single enterprise key manager, results in higher costs for developing and supporting the key manager, costs that ultimately get passed on to the enterprises deploying encryption solutions... This presentation will discuss the Key Management Interoperability Protocol (KMIP), recently introduced into the OASIS standards organization, establishes a single, comprehensive protocol for communication between enterprise key management systems and encryption systems. By defining a protocol that can be used in any encryption system, from the smallest encryption devices such as automated electric meters to the most complex storage arrays and server environments, KMIP enables enterprise key management systems to speak a single protocol to all encryption systems supporting the protocol. Through support of KMIP, an enterprise will be able to consolidate key management in a single enterprise key management system, reducing infrastructure costs while strengthening operational controls and governance of security policy..." [March 17, 2009] "[KMIP] Charter Questions." Posted to the KMIP TC comment list by Anders Rundgren. [Note: Since the formal comment period for the KMIP TC charter proposal ended 26-February-2009, it will be appropriate to post feedback to the KMIP TC comment list rather than to the 'oasis-charter-discuss' mailing list. The KMIP TC comment mailing list is open to the public.] Anders writes: "I have a number of questions regarding the current (2009-03-17) charter [Scope, which states] The initial goal is to define an interoperable protocol for standard communication between key management servers, and clients and other actors which can utilize these keys. Secure key management for TPMs (Trusted Platform Modules) and Storage Devices will be addressed. The scope of the keys addressed is enterprise-wide, including a wide range of actors: that is, machine, software, or human participants exercising the protocol within the framework. Actors for KMIP may include Storage Devices, Networking Devices, Personal devices with embedded storage (e.g. Personal Computers, Handheld Computers, Cell Phones), Users, Applications, Databases, Operating Systems, Input/Output Subsystems, Management Frameworks, Key Management Systems, Agents... [Q1:] I can't find any support for PINs in the specification. Does this mean that user-based authentication and signature keys are out of scope? [Q2:] TPMs support attested key-pair generation. Where in the specification is this addressed? [Q3:] Does the enterprise scope mean that KMIP is unsuitable for consumers? [Q4:] Key-provisioning for unregistered end-user devices cannot be through APIs only; there must be a user-acknowledge part as well. Or is the intention that end-users and devices are already authenticated to Active Directory or similar before KMIP can begin its operation? [Q5:] Related to Q4: Is KMIP supposed to be able to power future versions of Microsoft's Autonrollment system? [Q6:] What is the relation between KMIP and browser-invoked schemes like <keygen>, generateCRMFRequest (), and CertEnroll? [...]" [March 16, 2009] IEEE SISWG P1619.3Sub-Committee Status Summary Presentation proposal. By Walt Hubis (Software Architect, Engenio Storage Group, LSI Corporation).. Target date: 4/15/2009. "I have posted to P1619.3 Status Presentation for review... The intention is to present this at the SISWG Plenary on April 15, 2009." Excerpt (as respects KMIP): "[2] KMIP: Should P1619.3 include the mandatory KMIP binary encoding in its entirety for our binary protocol? Plenary Item. Proposal Needed (Hubis). [3] KMIP Future Direction: Create an XML WSDL that is a mechanical translation of a subset of the KMIP binary protocol. A Method to do mechanical translations. Add on P1619.3-specific extensions. [4] KMIP/P1619.3 Mapping: Mapping effort to identify features in P1619.3 that are not in KMIP are in process. Identify P1619.3-specific extensions that were left out of KMIP. Architecture Review (In Process). Formal Liaison (In Process). [5] KMIP: Add P1619.3 Namespace (KMIP does not define any namespaces; the only requirement is that they are unique in the local server context). Convergence is not an issue. [6] KMIP: Define concrete default port bindings for P1619.3/KMIP services. Register ports with IANA (Required for Interoperability). P1619.3 Requirements - need to avoid conflicts. [7] KMIP: Define an optional enrollment protocol (Simplifies client management; Need a proposal - TBD). Define a optional discovery protocol (Simplify management; a proposal is needed - TBD). [8] KMIP: Define Server-to-Server communication. Deferred until a later version of the protocol. [9] P1619.3 Overview: Draft 6 now in Comment Review. Comment Deadline: March 20, 2009. In Process: Messaging (Binary: KMIP Evaluation, XML: KMIP Comparison)... See also the associated email message: "I'd like to propose the following motion for consideration at the SISWG Plenary on April 15, 2009: 'Shall P1619.3 include a subset of the KMIP binary encoding as a part of the binary protocol?'" [Archive: PDF/PPT] [March 11, 2009] "KMIP Report." From 'P1619.3 Weekly Minutes 2009-03-11', written by Matt Ball. Updated in the P1619.3 Weekly Minutes 2009-03-18 ('OASIS Liaisons' and 'Discussion Regarding KMIP Proposal'). "OASIS has issued a call for participation in the KMIP Technical Committee. You must first be a member of OASIS to join. See OASIS KMIP Homepage. On the afternoon of April 20th [2009] during the RSA Conference, there will be a tutorial on KMIP (extra fee applies). The first KMIP face-to-face meeting will be April 24th, 2009 in San Francisco during the RSA Conference. The liaison relationship cannot happen until the first KMIP meeting. The group continued discussion of further ways to work with KMIP and reiterated the need to publish a public statement about how P1619.3 plans to coordinate with KMIP. This information will be included in the presentation that Walt Hubis will publish... [Previous Action Items] Matt: Check into establishing a Liaison between IEEE 1619 and OASIS KMIP. How do we get an official relationship? Carry-over until OASIS official starts KMIP in mid-April. Lockhart: Check whether P1619.3 can get occasional updates on the P1619.3-KMIP mapping effort..." See previous P1619.3 minutes from 2009-02-25 and 2009-02-18. [March 11, 2009] "Enterprise Key Management and KMIP." Tutorial, Part 3 in "TUT-M51: Encryption and Key Management Tutorial" [Pre-Conference 1-Day Tutorials] at the RSA 2008 Conference. April 20, 2009. "The pre-Conference 1-Day tutorials will offer a wide range of technically-oriented sessions from highly regarded RSA Conference presenters. This three part tutorial covers important basics of information security — cryptography, encryption and key management. The fundamentals learned hear will help attendees understand more complex concepts that will be discussed during class sessions. Part 3 (Enterprise Key Management and KMIP) at 1:00 PM, by Joshua Rosenthol: "Encryption is becoming ubiquitous in customer's data centers. Tape vendors, switch vendors, disk vendors, etc are all embedding encryption into their devices to allow seamless protection of data throughout the technology stack. With many different encryption devices, however, comes many different ways to manage keys. This can create an IT governance and management nightmare for companies, and also pose a security risk by blurring the roles and responsibilities within an organization. Josh will go into detail on what Enterprise Key Management is, and how the technology is beginning to take hold in major organizations." Speaker: Joshua Rosenthol, Director Product Management, RSA, The Security Division of EMC. "Mr. Rosenthol is responsible for product management of the RSA Key Manager suite of products. He joined RSA in 2006 and in his position there continues to specify and design the new generation of Enterprise Key Management solutions. He has been a product manager in the high tech space for over 10 years, with a specialization in encryption and data security." [March 04, 2009] OASIS KMIP TC Charter and Call for Participation. Published March 04, 2009. Initial supporting entities include Brocade, Cisco, EMC/RSA, HP, IBM, LSI, NetApp, Seagate, and Thales. Eligible persons wishing to gain TC voting status as of the first meeting (April 24, 2009) should register by April 09, 2009. Detailed information for joining the KMIP TC is provided in the Call for Participation. [March 03, 2009] "Towards a Common Key Management Standard: Making Encryption Work." By Staff. From Computer Business Review Online. "Enterprises are increasingly aware of the need to implement encryption in order to protect their information assets, but this has emphasized the challenges around interoperability and effective key lifecycle management. As a result, a group of storage and security vendors has announced the key management interoperability protocol, which is intended to standardize key management interfaces. The growing trend towards remote and mobile working, combined with the ubiquity of internet access and the prevalence of removable storage, has created a significant increase in the channels through which data can be lost. Unsurprisingly, this growth in loss vectors has resulted in a torrent of high-profile incidents that have led to valuable data being compromised. The higher visibility of the risks of data loss and the awareness of their effects on the bottom line (especially in this challenging economic environment) have encouraged greater investments from enterprises in information protection technologies, particularly encryption. Attempts to resolve these concerns have often been ad hoc and have therefore failed to remove obstacles to the wider and deeper adoption of encryption solutions. This may all change thanks to the welcome introduction of the proposed KMIP standard that has been formulated by a group of prominent enterprise storage and security vendors including Brocade, EMC, HP, IBM, LSI, [NetApp,] Seagate, and Thales. KMIP is intended to standardize and simplify the interactions between disparate key management mechanisms and encryption methods across the entire IT infrastructure. The long list of vendors which have already committed to the standard will almost guarantee its ratification and make it very likely to emerge as the foremost protocol in this marketplace. However, KMIP is still at an early stage of its development and is many steps away from being adopted by the industry..." Similarly, posted to CBR Security by Alaa Owaineh, March 25, 2009. [February 26, 2009] "Enterprise Key Management." By Luther Martin (Chief Security Architect, Voltage Security). Blog. "There's a new report, Enterprise Key Management Systems, from the Burton Group's Ramon Krikken: 'As the use of encryption in an enterprise increases, so do the potential headaches surrounding management of the associated cryptographic key materials. Enterprise key management systems (EKMSs) are designed to address problems with managing cryptographic keys for data at rest...' Many vendors talk a lot about key management, but this report seems to show that many of them don't really have much of an interest in it beyond what's needed to make their own products work. This report lists ten areas that use key management: file encryption, laptop encryption, email encryption, etc. For 13 vendors, including Voltage, RSA/EMC, nCipher, NetApp, SafeNet and eight others, it lists which vendors have an offering in each area. Voltage has more offerings than any other vendor, having something in seven of the 10 areas. RSA/EMC is a close second, offering something in six of the 10. Three more, nCipher, NetApp, and SafeNet offer something in five of the 10. The top five enterprise key management vendors all have an offering in at least half of the 10 areas, and seem to be ones that are fairly serious about enterprise key management. Their offerings overlap in some, but not all, areas, which makes it looks like the five leaders aren't really direct competitors in most cases. There's some overlap between the areas that Voltage covers and the ones that RSA/EMC covers, for example, but not enough to really say that the two companies are really competitors..." [February 25, 2009] IEEE P1619.3 Weekly Minutes 2009-02-25. By Matt Ball. New Business: Work on IEEE P1619.3 plan/roadmap, with regard to KMIP... P1619.3 RoadMap Discussion (Ball). The group generally agreed to the following list of items concerning the P1619.3 roadmap and integration with OASIS KMIP. (1) We should '#include' the mandatory KMIP binary encoding in its entirety for our binary protocol. As needed, providing a mapping description [Plenary Item]. (2) Next, create an XML WSDL that is a mechanical translation of a subset of the KMIP binary protocol, and add on P1619.3-specific extensions. I don't think this is too hard, but will take a little time. The KMIP binary primitives have a clean mapping into standard XML-Schema objects. (3) Add in any P1619.3-specific extensions that were left out of KMIP — Need to research this and identify features in P1619.3 that are not in KMIP [Part of mapping effort]. (4) Add in the P1619.3 Namespace work. KMIP does not appear to define any namespaces, but relies on the users to hopefully create identifiers that are unique — actually, the only requirement is that they are unique in the local server context. (5) Define concrete default port bindings for the P1619.3/KMIP services. I didn't see this in the KMIP proposal. We could register ports with IANA. Maybe allow changing the ports, if needed. (6) Define an enrollment protocol. KMIP doesn't do this, but assumes that you've already whitelisted the certificates used for the SSL/TLS channel. I'm hoping to propose the Sun KMS Agent Toolkit enrollment as one option, and could include others as needed. (7) Define a discovery protocol. I didn't see this in KMIP, and again, I'd like to propose the Sun KMA discovery protocol as a starting point. (8). Deferred until next version: define a Server-to-Server communication. This may creep the scope too much, but this is another part that KMIP punted on, and would make sense to do in XML only instead of binary; KM servers are generally beafy. Ask OASIS KMIP about this, whether they want to add. (9) Review our architecture and make sure it fits well on top of the KMIP effort; KMIP doesn't really talk about architecture much, but instead jumps into the guts of it... The group reviewed these actions, and approved of the general approach. Matt Ball and Walt Hubis will work together to provide this as a roadmap of the group. The KMIP Consortium is currently looking into a mapping between P1619.3 and KMIP, and will be done within the next 2-3 weeks..." [February 18, 2009] IEEE P1619.3 Weekly Minutes 2009-02-18: Discuss group reaction/response to OASIS KMIP announcement. From Matt Ball. "Questions: How does the KMIP announcement impact the work within IEEE 1619.3 What is IEEE 1619.3's stance? Matt (Sun): I think that the KMIP effort can work well with IEEE 1619.3 and that we can find ways to map the two standards onto the other. Landon (Cisco): KMIP is a complemenary effort. It would be a mistake to think of them as competing standards. Bob (Thales): Thales also sees the efforts as complementary. There was some discussion about the Intellectual Property rules of IEEE. The KMIP proposal is under the 'Royal Free under RAND' mode of OASIS. IEEE just offers RAND (Reasonable and Non-Discriminatory) terms. What about establishing a Liaison? Matt will check into this. The general consensus was that we should maintain a liaison between IEEE 1619 and OASIS KMIP. Bob Lockhart mentioned that there is an ongoing effort within the KMIP consortium to do a comparison between IEEE P1619.3 and KMIP, and show the differences. This work should be completed within a month or so. New Action Items: Matt Ball to check into establishing a Liaison between IEEE 1619 and OASIS KMIP..." See Matt Ball's comment: "Overall, I think we had a productive conversation, and found good ways for IEEE P1619.3 to collaborate with the new KMIP effort..." [February 17, 2009] "KMIP: An Important Standard." By Chuck Hollis (EMC). "In my world, the important standards have three key attributes: (1) they solve a really big customer problem, (2) no one vendor can solve the problem by themselves, and (3) the right vendors are working together. Such is the case with KMIP (Key Management Interoperability Protocol). It solves a big hairy customer problem, no one vendor can provide a complete solution, and (at least in this case) IBM, HP, EMC and others have come together to drive an important interoperability standard. I got somewhat involved in this topic a few years ago when EMC acquired RSA, and many of us started asking hard questions about encryption, keys and management. The first (and inevitable) debate was 'where was it best to encrypt storage?' It's not too hard to come up with good arguments about putting it in the SAN, or putting in the devices themselves, or putting it in the HBA, or in the MPIO stack, or in the file system, or perhaps the application itself. We quickly became comfortable in the view that storage encryption was going to be available up and down the I/O stack, and it would be hard to make the case that there was one 'best' approach. Indeed, as we look at EMC's portfolio today, there are multiple places to encrypt your data, depending on your needs. I know, it's yet another 'it depends ...' argument. Certain storage vendors have tried to put forth the idea of encrypting at the disk drive and/or array level. It sounds like a nice feature in the abstract, but the more you think about, the less useful it begins to seem... The second debate was around key management. RSA had a key management appliance known as RKM (RSA Key Manager, naturally), so we started to take a close look at how it could play in the enterprise storage environment we knew so well. Over time, we started to realize that key management, taken by itself, wasn't a particularly interesting capability. Certainly necessary, but there was definitely a need for more — specifically, the ability to seamlessly orchestrate keys and key management as part of day-to-day operations, at least, in the storage domain. The classic example was a disaster recovery test. Imagine thousands of volumes being replicated to a remote site (each encrypted) and imagine you'd like to do a recovery test over the weekend. Many thousands of keys would be involved at a minimum. Not only that, the upper-level management applications would ideally be able to request and receive these enormous key sets as a part of their normal operations. Or consider provisioning secure virtual machines in a multi-tenancy environment? You'd want to provision the app and its storage in one fell (and keyed) swoop. Certainly an opportunity for upper-level integration, no? There were dozens of other similar real-world examples we could come up with — scenarios where management processes and related software needed to be taught how to request and manipulate encryption keys as part of their normal functionality... I'm no expert, but the people close to the KMIP effort at EMC tell me that this particular standard is not hard to implement, nor is it that far off from existing implementations in the marketplace..." [February 17, 2009] "EMC, IBM and HP Back KMIP." By Paul Shread. From Enterprise IT Planet. "Seven IT vendors have banded together to propose an encryption key management standard... 'KMIP addresses an important piece of the secure storage puzzle: key management,' said Walt Hubis, software architect for LSI's Engenio Storage Group. 'Acceptance of the KMIP will eliminate the biggest barrier to the widespread adoption of storage encryption, the fear that encrypted data will be lost. Interoperability across encryption and key management systems is a significant advancement that will enable acceptance of self-encrypting drives (SEDs). There's still work to be done in areas such as network-attached storage, including authentication of users in NAS and storage virtualization environments, but this is a critical step in the right direction.' Enterprise Strategy Group security analyst Jon Oltsik said, 'We don't have a standard yet, but this is very encouraging since all of the industry leaders are behind the effort. This should drive further progress in IEEE P1619.3 as well. This group was a bit overwhelmed by the scope of work, but now KPIM limits what they have to focus on [with respect] to storage devices'..." [February 16, 2009] "Is Interoperable Key Management Dead?" By Luther Martin (Voltage Security). Blog. "Could this be the end of the dream of interoperable key management? At Pulse 2009 last week, IBM talked about its new Key Management Interoperability Protocol (KMIP) that it intends to get standardized through OASIS and then support in its products. KMIP is a fairly complete standard, but it doesn't address many of the issues that need to be addressed in key management products, particularly those that manage keys for encryption of data in storage. That's where the IEEE P1619.3 Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data seems to work the best, which is why this standard has support from a wide range of storage and storage security vendors. But since KMIP doesn't work with any of the other key management standards that are being developed, this means that interoperability can now only be attained in one of two ways: either IBM's products need to support other standards like P1619.3, or vendors that currently plan to support P1619.3 need to also support KMIP. Either of these seems to defeat the purpose of having standards, which means that either is a bad idea. Customers need to provide some loud and clear feedback to key management vendors that explains how they don't need multiple key management standards that will kill any possibility of interoperability between products from different vendors. Othewise, the problems that users of key management products are facing will never be solved..." [February 14, 2009] "Key Management: The Standard is Coming." By Archie Reed (HP, Worldwide Director of Strategy and Planning for Identity Management). From Secure Observations Blog. "[...] Key Management: It's taken some time, but for our partners, my colleagues and most of all for the industry, I am happy to finally see the start of a draft standard for key management that is moving forward through a new OASIS group, the Key Management Interoperability Protocol (KMIP) Technical Committee. Key Management, in a broad sense, deals with the cradle-to-grave processes of secure generation, distribution, and storage of keys that are used to encrypt data... Key Management is very important to HP and its customers as at a high level, security and regulatory considerations drive customers to increasingly consider encrypting data at rest, on removable media such as tape, as well as stationary media such as hard drives, and even portable devices. Data encryption in turn, creates a need for secure and highly available encryption key lifecycle management. That lifecycle is the crux of the matter though. Companies often deploy separate encryption and key management systems for different business uses, such as laptops, storage, databases and applications, and until now, cumbersome (often manual) efforts were necessary to generate, distribute, vault, expire, and rotate encryption keys. This is as much an industry failing as it is an evolutionary challenge. This has resulted in increased costs for IT, difficulty meeting audit and compliance requirements, and sometimes lost data — or worse, lost business. Previously, HP (with its own Secure Key Manager Appliance) and other vendors have addressed this market with vendor-specific and incompatible key management solutions. This array of incompatible solutions from industry has resulted in varied customer hesitation and challenges in deploying encryption solutions to different devices and applications. This additionally increases costs for HP client products supporting encryption, as custom adapters must be developed for each key manager to provide for only limited interoperability. HP began work on this Key Management Interoperability Protocol (KMIP) with EMC/RSA, Thales, and IBM in late 2007 under the sponsorship of the HP Security Office and the HP Secure Advantage program, and is now helping move the completed work to OASIS... As this standard is adopted and deployed, HP will be able to address our customers' Key Management interoperability challenges with interoperable solutions which implement this new standard, both in the Key Management server arena, and also in key management clients, such as StorageWorks products..." [Note: Mark Schiller and Jishnu Mukerji, both of HP, were listed as supporters in the KMIP TC charter proposal. Contact also: Steven Wierenga (HP Secure Advantage, Key Management Interoperability Program)]. [February 13, 2009] "Will Joint Spec Help Secure Enterprise Data? Major Enterprise Encryption Key Management Players Agree on Standardization." By Richard Adhikari. From InternetNews.com. "[...] Key management refers to generating, exchanging, storing, safeguarding, using, vetting and replacing the cryptographic keys that provide access to encrypted files or data... Standardizing key management protocols will make it easier to secure data, which PGP CEO Phil Dunkelberger has said is going to be an important development for security this year. The KMIP protocol will bring enterprise storage on par with end-user storage, for which the storage industry has developed standardized encryption protocols, according to Michael Willett, senior director for security at storage vendor Seagate Technology. Storage management vendors are beginning to offer self-encrypting drives with encryption engines built into the drives' circuitry, Willett said. 'Now with this key management standard, enterprise IT people will be able to buy one set of protocols and manage a variety of clients with a common key management system. And you'll have end-to-end encryption from the low-level management interfaces for hard drives to the top end storage in the data center'..." [February 13, 2009] "Industry Heavyweights Create New Encryption Protocol." By Aharon Etengoff. From IT-Examiner.com. [...] "Our customers' IT environments are growing in complexity and, at the same time, these companies are under extreme pressures to meet compliance regulations and limit costs," Mark Schiller, director of HP's security office told IT Examiner. "KMIP was developed in an effort to simplify the process of encryption key management enterprise-wide and is the broadest and most comprehensive key management standards framework developed to date. According to Schiller, the standard targets multiple layers, including storage, applications, databases and files. "The initial authors of the KMIP framework, HP, IBM, RSA/EMC, and Thales/Ncipher, shared a common vision of making encryption across the enterprise easier and more transparent for our customers," explained Schiller. "These four companies engaged more than 25 senior security engineers and architects in the joint activity. This effort was kicked off in late 2007 by the (original) four, with Brocade, LSI, Seagate, and more recently, NetApp, also joining the effort." Schiller noted that the standard will be provided "royalty-free" to encourage participation by small companies as well as industry heavyweights. Jon Geater, director of strategy at Thales, expressed similar sentiments. "Organisations increasingly understand the need to encrypt data, but often hold back from doing so out of fear of losing access to the data or the prospect of managing multiple non-interoperable key management system," said Geater. "Thales' goal is to empower customers to encrypt data with confidence anywhere in the enterprise, knowing that it is not only secure, but also can be accessed when needed. Unlike other standards which concentrate on specific segments of the infrastructure, KMIP is a comprehensive standard that addresses the broad requirements of key lifecycle management across the entire enterprise." [February 12, 2009] KMIP: A Proposed New Encryption Key Management Standard." By David Dale (NetApp). From Standards Watch Blog. "For the past year or so, a group of vendors including EMC, IBM, Hewlett-Packard, and Thales (who acquired nCipher) have been working on a new encryption key management standard — the Key Management Interoperability Protocol (KMIP). This work has now been moved into OASIS for completion as an open standard. Other companies (including NetApp) were given the opportunity to provide feedback and join the new OASIS workgroup... Details on the announcement can be found in the FAQ about the new initiative. Although NetApp wasn't in the press release that hit the news wire, we fully support this new standards effort, and we are a contributing member of the OASIS KMIP Technical Committee... This isn't the only key management standard in process right now. You may have seen my blog on 27-June-2008 'New IEEE Security Standards: Enabling Ubiquitous Storage Security', which focused on the IEEE P1619.3 activity. The two major differences between the two efforts are that the KMIP effort is broader in scope (addressing many device types, whereas the P1619 effort is focused specifically on a storage infrastructure), and the KMIP protocol uses a low level binary interface to ensure that a broad range of device types can use it. Another difference is that the P1619 effort did not get the support of some major players, whereas the KMIP effort seems on track to get all the key players' support. My take on all of this is that having two standards initiatives going after an encryption key management standard is not a bad thing. In fact it may increase the chances that the industry can come up with a broadly supported standard that will enable ubiquitous data security..."
OASIS KMIP TC
KMIP Technical Committee Charter
KMIP Editor's Draft May 21, 2009
Initial KMIP Draft Specification Version 0.98
KMIP Draft Specifications as Contributed 2009-04-24. Note: In these 'Specifications as Contributed' there have been no edits from the previous publication of these specifications.
KMIP White Paper and Presentation
Context: Key Management Specification Initiatives
- Cryptographic Key Management. This Topic Document from the Cover Pages provides context. It supplies references for several standards efforts and specification development initiatives in the area of key management.
Announcements
- KMIP Industry Announcement, February 12, 2009: "Leading Organizations Unveil New Interoperability Specification for Encryption Key Management to Aid IT Security, Compliance and Data Recovery. Brocade, EMC, HP, IBM, LSI, Seagate, and Thales Work to Remove Barriers to Encryption Across Data Center Systems by Submitting New Specification to OASIS." Note that NetApp, though not named in this announcement, was one the the KMIP TC supporters, and is named as a corporate author in the KMIP specifications.
|
 | Receive daily news updates from Managing Editor, Robin Cover.
 |
|
