[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]