Feedback on KMIP

Per the call for public comments on the KMIP documents, please consider the following:

Comments on the KMIP Specification:

· Section 1.2 provides no normative references to support the Section 10 (Transport) statement that KMIP “SHALL support SSL v3.1/TLS v1.0 or later”.

· Given the sparse detail is Section 10, it would probably better to just delete this section and let the profile(s) cover the specifics. Alternatively, Section 10 could simply state that the profiles handle the details associated with the Transport.

· Since Section 10 does indicated that “SSL v3.1/TLS v1.0 or later” is required, it is probably worth pointing out the following:

o Perpetuating the use of SSL rather than the real protocol (TLS) is unwise; anybody who has not figured out what TLS is at this point should not be implementing KMIP

o TLS 1.0 and TLS 1.1/1.2 have very different mandatory cipher suites; this means that “compliant” clients and servers may not be able to negotiate a secure tunnel

Comments on the KMIP Profiles:

· None of the TLS RFCs are listed in the normative references

· Section 3.1.1 (Protocols) has the following problems:

o In reality, SSL v3.1 is “slang” for TLS v1.0, which is defined in RFC2246; there is no reason to mention SSL in any of the KMIP documents

o In an ideal world, TLS 1.2 should be specified as the mandatory version of TLS. If this is not possible, then nothing below TLS 1.1 should be used because of the security issues and the change of the mandatory cipher suite (i.e., TLS 1.0 uses a different cipher suite that TLS 1.1 and 1.2). Also note that versions of TLS prior to v1.2 use SHA-1 and there is no way to completely change this (even if a cipher suite specifies SHA256); TLS 1.2 uses SHA-256 by default.

· Section 3.1.2 (Cipher Suites) has the following problems:

o There is no such cipher suite “SSL_RSA_WITH_AES_128_CBC_SHA”; AES is only available with the “TLS…” cipher suites.

o To ensure that KMIP is capable of meeting the NIST 112-bit security requirements (see draft NIST SP 800-131), suggest including something like “TLS_RSA_WITH_AES_256_CBC_SHA25” as a mandatory to implement. This give some measure of assurance that the 112-bit security can be successfully negotiated.

· Section 3.1.3 (Client Authenticity)

o Unless someone is a TLS expert, it will be very difficult to understand this section, which means it is likely that it will not be implemented in a way that conforms to the authors’ original thoughts

o It is important to note that client-side certificates are not common, and further, user-unique client certificates are relatively rare. It is possible that the client certificate would be for “companyxyz.com” and that every user and server in the company would use the same certificate; this likely scenario is unlikely to provide the desired authenticity.

o No statement is made about the use of self-signed certificates (for server and/or client). If they are prohibited, this section should make a statement; if they are permitted, then some guidance should be provided to make sure they are handled correctly.

o Specifying something (Credential information in the request header) as mandatory and then stating that the specifics are out of the scope of the specification is likely to be a source of problems

Thank you for your attention.

-Eric

kmip-comment message