John, you've expressed your views on the topic a number of times and they haven't been shared by others and you keep returning to the same topic.
When implementing any security solution you have to be mindful of a wide range of issues and singling out a particular operation is not something which makes sense to do - it just does not belong within the KMIP documents.
We contain no such statements about any other items.
Your text below is effectively a general warning that if the server implementer doesn't implement things securely then things might not be secure.
If the server vendor forgets to seed their random number generator or uses a poor quality random number generator then the result may not be what the user of the system would want. However there is no warning of that nature in the specification or usage guide
currently (nor should there be). There are a myriad of other such issues.
There is no way for a client to know whether or not a server implementation is secure - that is outside the scope of the specification - which is about
interoperability.
The existence or absence of RNG Seed from a server implementation provides no meaningful guidance to a user of KMIP as to whether or not the system meets the users (unstated) security requirements.
Tim.
On 11/06/2013 3:36 AM, John Leiseboer wrote:
Hi Judy,
Suggested text for section 2:
2.XX Cryptographic Operations
[KMIP-Spec] defines a set of simple cryptographic operations. Implementers of client applications should make themselves aware of
the limitations of these operations, and the potential for introducing vulnerabilities into systems when using these operations.
[KMIP-Spec] places no restrictions on the KMIP Server implementation of the RNG used with the RNG Retrieve and RNG Seed Operations.
Note that a Server is allowed to implement a single, global random bit generator to serve all internal needs (e.g. key generation for the Create, and CreateKeyPair Operations, and nonce generation used in attested operations), as well as for the RNG Retrieve
Operation, and the IV/Counter/Nonce generated for the symmetric key encryption operation.
With appropriate care, a server implementation can be made relatively secure when the server has full control of the internal random
bit generator. However, the RNG Seed Operation may allow a Client to seed "the RNG" with uncontrolled, external material. This can lead to a Client influencing the random material used internally by the Server for key creation, nonce and IV generation, client-server
TLS session key creation, and the random delivered to Clients with the RNG Retrieve Operation.
Client and System implementers should satisfy themselves that their security requirements are met if the KMIP Server supports the
RNG Seed Operation.
Regards,
John
John
I found the text that Tim provided for the UG to fit best in Section 3 since it includes guidance around using these new KMIP services. If you
would like text to be added to Section 2 – Assumption of the UG – would you be willing to a paragraph or two for that section?
Thanks
Judy
I was hoping to see text suitable for inclusion in Sections 2 and 3 of the Usage Guide: assumptions that underlie the KMIP protocol, and guidance on using the
functionality, respectively. The proposed text reads more like an attempt to justify the new crypto services operations rather than provide useful guidance, explanation or clarification.
Text addressing the following might provide more value:
That a client cannot depend on a KMIP server protecting against another client seeding a single instance, whole of server RNG is important information that
should go into Section 2. As a user of KMIP, I would hope to see this sort of information clearly presented so that I can make decisions on how to use KMIP securely in an application, identify potential issues, and frame questions for vendors of KMIP products.
The current wording on this topic (last paragraph of "Cryptographic services (usage guide text)") leaves it to the reader to work out the issues, and, in my opinion, does not go far enough in identifying the possible security issues that a compliant server
could exhibit.
Guidance on how to use the attributes, and precedence treatment of attributes with crypto operations would be useful in Section 3. Recommendations on how algorithms,
modes of operation, and other security relevant attributes can be used, and overridden or not overridden by clients would be of value. That security issues could arise from clients overriding the attributes of a managed cryptographic object should be stated,
and reasons provided as to when and why clients should be allowed to instruct the server to use the client's provided attributes rather than the actual object attributes managed by the server.
John
From:
kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org]
On Behalf Of Tim Hudson
Sent: Thursday, 23 May 2013 7:00 AM
To: kmip@lists.oasis-open.org
Subject: [kmip] Groups - cryptographic-services-usage-guide-v1.docx uploaded