[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [kmip] Groups - cryptographic-services-usage-guide-v1.docx uploaded
|
>
So although I understand the spirit of your comments, it does appear to be oddly specific to a single cryptographic function I would like to see more guidance too, but with limited time, and limited patience, I’ve only contributed text for the most severe
security issue – RNG Seed. Note that it is only now with the proposed RNG Seed operation that the KMIP standard actually provides a means for a Client to “take control” of a Server’s RNG. No other operation opens up a vulnerability of this severity. So, while
I would like to see more guidance, I need to prioritise my criticisms and submissions, and hence I have elected to only propose text for this particular issue. I would be happy to work with others on more extensive guidance on the Server RNG, as well as the
other crypto services issues that are fully documented in the TC archives. John From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org]
On Behalf Of Burns, Robert John, I definitely agree with your statements below – getting the RNG stuff right is essential to these systems, and providing guidance is a reasonable
thing to do – in fact, I’m a bit surprised there isn’t already any guidance on this, (e.g. key gen has to be done right, entropy sources, etc.). I don’t have a long enough history with this committee, so I went back and looked at the previous user guides
and couldn’t find any similar guidance on this topic (‘random’ only appears twice, and one is a title of a NIST SP, and ‘entropy’ never appears). So although I understand the spirit of your comments, it does appear to be oddly specific to a single cryptographic function (e.g. RNG Reseed),
and seems to leave the details up to the reader to determine how to ‘satisfy themselves’ that the security is sufficient. In my opinion, the recommendation seems to fall short in both depth (e.g. providing enough detail for everyone to measure) and breadth
(e.g. cover all KMIP functions, not just an RNG function or even cryptographic services). I feel that if we are of the mindset to provide that level of guidance, we should do so in a balanced fashion across the entire API, and in a manner
which provides mechanisms which customers, vendors, and implementers can communicate in a common way, (e.g. “our RNG is a singular instance”, or “a unique RNG is instantiated for each unique TKLM session”, etc.). Sorry this is a bit late, but hopefully it helps. Bob From:
kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org]
On Behalf Of John Leiseboer 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 From:
kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org]
On Behalf Of Furlong, Judith 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?
Judy From:
kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org]
On Behalf Of John Leiseboer 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]