OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [kmip] Groups - kmip-cs-profile-v1.0-wd01-review.doc uploaded


Continuing review of kmip-cs-profile-v1.0-sd01-review.doc.

 

Section 4

All tests start with either registration or creation of a key. This will result in a key that is in the pre-active state. The tests then proceed with Encrypt and Decrypt operations on the pre-active key. Surely the keys should be moved to the active state first. (Noting that the server profile requires that the server conforms with the KMIP Baseline Server Profile (“Client” typo previously commented on, and acknowledged as such), which in turn requires that the server support the State attribute.)

 

Section 4

Assuming that the crypto operations observe and comply with the value of the key state, and the keys are put into the active state prior to being used, then keys will have to be moved to the deactivated state before being destroyed.

 

Sections 2, 3 and 4 – Base Cryptographic stuff

Is it intended that conformance with this profile simply means that a client can request, and a server can perform, encrypt and decrypt operations using an AES key in ECB mode? If so, then apart from questioning the usefulness of this profile, shouldn’t the profile name be changed to something that better reflects this very limited capability? Perhaps “Basic AES ECB Mode Cryptographic Profile”?

 

Seriously, shouldn’t these sorts of profiles be more comprehensive in their test coverage? Here is an incomplete dump of some basic things that should be tested for conformance. I stress this is just a quick dump. Other reviewers will undoubtedly identify more.

 

Correct behaviour when the State attribute for a key is set to different modes; e.g. pre-active: encrypt/decrypt should fail, destroyed: encrypt/decrypt should fail.

Correct behaviour for values of Process Start Date and Protect Stop Date; i.e. Encrypt and Decrypt should only work when the dates permit.

Correct behaviour with Usage Limits; e.g. server correctly updates Usage Limits Count after Encrypt, server deny Encrypt when Usage Limit Total is reached.

 

I’m pretty sure that Tim will object to this one (and this should really be discussed at specification level, but it will impact conformance, so I’ll risk raising it here now):

Current defined behaviour (I believe) is for Crypto Parameters (such as BCM) defined in the client’s Encrypt/Decrypt request take precedence over the Crypto Parameters managed by the server. I would like to see this changed, such that the client can still request, for example, that ECB mode be used, but if ECB mode is not already defined as a mode for a managed key, that the server deny the Encrypt/Decrypt request; i.e. the Crypto Parameters that are associated with a key become a “white list” of allowed parameters. If the “white list” is empty, then the client can ask for whatever it wants, and if it’s possible, the server complies. But if mode, or padding method, for example is requested that is not on the “white list”, the server denies the operation. So if we can go with this change, then we need to test for conformance.

 

Structure of tests – Base Crypto profiles.

The conformance requirements reference Baseline profiles, and add Encrypt and Decrypt operations as requirements. They also require that the mandatory tests be successful. The mandatory tests include operations such as Create, Register and Destroy. Is it really intended that a Base Crypto Client must support these operations? If yes, that should be stated and not implied by the test cases. If no, and I think a better, more generic approach regardless, then the tests should be reformatted into at least three sections:

 

Test setup

This is where pre-conditions for the test are stated and established; e.g. load keys onto a server; issue credentials for client-server communications; set values of attributes that are relevant to tests, etc.

 

Test

This is where the actual conformance tests are run. No client, and no server, should be required to perform operations that are not explicitly stated in the conformance requirements.

 

Test teardown

This is where all the post processing stuff is performed; e.g. confirm attributes were updated correctly; test keys and other objects are removed from the server, etc.

 

Section 11

All the 11.x conformance statements: “…for each supported protocol version (major and minor)…”

 

Can this be clarified please? As Crypto Services are possibly being introduced into KMIP 1.2, I take this to mean that it is not possible to claim conformance to this profile for 1.0 and 1.1. That would mean retrospective changes to earlier released specifications. So can we clarify that this means from KMIP 1.2 going forward?

 

John

 

From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of John Leiseboer
Sent: Friday, 28 June 2013 12:21 PM
To: Tim Hudson; kmip@lists.oasis-open.org
Subject: RE: [kmip] Groups - kmip-cs-profile-v1.0-wd01-review.doc uploaded

 

Only had time to review through to Section 7. I’ll try to find more time next week for the remainder of the document.

 

kmip-cs-profile-v1.0-sd01-review.doc

 

Line 63

"KMIP Baseline Client" should be "KMIP Baseline Server".

 

Line 67

Which "Mandatory Test Cases" are being referred to? (The tests in Section 4?)

 

Line 81

Which "Mandatory Test Cases" are being referred to? (The tests in Section 4?)

 

Line 86

Are these the "Mandatory Test Cases" referred to in lines 67 and 81?

 

Line 87

This conflicts with lines 78, 79 and 80. Line 87 allows a client to support any one of the test cases; e.g. Create/Encrypt/Destroy, but lines 78-80 require that a client support BOTH Encrypt and Decrypt.

 

Starting at line 110, Test case 4.1.6, CS-BC-M-6-12 - Encrypt and Decrypt with Known Symmetric Key

The block cipher mode is not specified. It should be specified either in the key Registration request, or in both of the Encrypt and Decrypt requests.

 

For better interoperability coverage, additional tests for at least the following are required:

 

- Additional block cipher modes. Testing only with the (insecure) ECB mode will not flush out potential implementation mistakes with the various feedback modes.

- In conjunction with additional block cipher modes, some different padding methods should be specified.

- In conjunction with additional block cipher modes, initialisation vector, counter, and nonce (where applicable) input by the client should be specified.

- It is still unclear to me whether Block Cipher Mode and Padding Method attributes specified by the client in Encrypt and Decrypt requests can force the server to override these normally immutable attributes. Some tests illustrating expected behaviour are necessary.

- Some error test cases would be useful; e.g. trying to perform an Encrypt operation using the wrong type of managed object; specifying incompatible or conflicting attributes like mode or padding; providing an IV and/or padding method for ECB mode; etc.

 

Line 117

"KMIP Baseline Client" should be "KMIP Baseline Server".

 

Line 120

Typo: missing "]"

 

Line 121

Which "Mandatory Test Cases" are being referred to? (The tests in Section 7?)

 

Line 134

Typo: missing "]"

 

Line 135

Which "Mandatory Test Cases" are being referred to? (The tests in Section 7?)

 

Line 140

Are these the "Mandatory Test Cases" referred to in lines 121 and 135?

 

Line 141

Does this mean that the vendor decides which test cases are mandatory for the client?

 

Line 142

This says that the server must support all of the test cases listed. Any suggestions on how to perform these tests, as they require different, incompatible server behaviour? Are you assuming some out of band communication (KMIP extension, non-KMIP, server management channel, human to human, etc.) to set up the server behaviour prior to running the tests in question?

 

Seed RNG with Server Accept, Seed RNG with Server partial Accept, Seed RNG with Server Ignore, and Seed RNG with Server Deny each return different responses (and presumably invoke different internal server behaviour - although the specification does not require this) for exactly the same request.

 

If Seed RNG with Server Accept is supported by the server, and performed multiple times, each followed by RNG Retrieve, must each returned random be identical? If not, is it allowed to be identical? If so, under what conditions is it allowed to be identical, or can it be forced to be identical?

 

John

 

From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Tim Hudson
Sent: Friday, 28 June 2013 12:25 AM
To: kmip@lists.oasis-open.org
Subject: [kmip] Groups - kmip-cs-profile-v1.0-wd01-review.doc uploaded

 

Submitter's message
Updated conformance wording style. Updated test case style. Included test cases for 1.2. Applied new OASIS template.

Note: the byte values for the test data in the "Advanced Cryptographic Tests" remains to be updated from the placeholder values.
-- Tim Hudson

Document Name: kmip-cs-profile-v1.0-wd01-review.doc


Description
Cryptographic Services Profile
Download Latest Revision
Public Download Link


Submitter: Tim Hudson
Group: OASIS Key Management Interoperability Protocol (KMIP) TC
Folder: Drafts
Date submitted: 2013-06-27 07:25:14

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]