RE: KMIP Spec v1.2 wd05: CTR and GCM Mode Cryptographic Parameters

[John Leiseboer <JL@quintessencelabs.com>]

Sorry, we also need to specify CTR Initial Count Value. (For RFC3686 this is 1. It can be different for other uses.)

John

-----Original Message-----
From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of John Leiseboer
Sent: Wednesday, 3 July 2013 4:46 PM
To: kmip@lists.oasis-open.org
Subject: [kmip] KMIP Spec v1.2 wd05: CTR and GCM Mode Cryptographic Parameters

KMIP Spec v1.2 wd05

The table in Section 3.6 does not include cryptographic parameters that I think are necessary for successful interop when using keys with block ciphers in GCM and CTR modes.

GCM Mode

Encryption operations in GCM mode take three inputs: an initialisation vector (IV), plain text (PT), and additional authentication data (AAD). Two outputs are produced: cipher text (CT), and an authentication tag (t).

Decryption operations in GCM mode take four inputs: IV, CT, AAD, t. One output is produced: the recovered plain text (PT), or an indication of inauthenticity.

The following prerequisites are required in order for encryption/decryption to be interoperable:
- An agreed block cipher 128-bit block size;
- A common key;
- Agreed definitions of supported input-output lengths; and
- Known supported tag (t) length associated with the key.

NIST SP-800-38D states:
"For IVs, it is recommended that implementations restrict support to the length of 96 bits, to promote interoperability, efficiency, and simplicity of design."

"The bit length of the tag, denoted t, is a security parameter, as discussed in Appendix B. In general, t may be any one of the following five values: 128, 120, 112, 104, or 96. For certain applications, t may be 64 or 32..."

RFC4106 (GCM in IPsec ESP) states:
"The ICV [JL: Integrity Check Value] consists solely of the AES-GCM Authentication Tag. Implementations MUST support a full-length 16-octet ICV, and MAY support 8 or 12 octet ICVs, and MUST NOT support other ICV lengths."

From the above, we can see that there are parameters that can have different values that will impact the result of encryption and decryption operations.

We're covered in KMIP for the agreed block cipher size provided keys that work with 128-bit block cipher algorithms are specified. This is implied by the Cryptographic Algorithm. We're also okay with the common key requirement. It's pretty obvious that using different symmetric keys for encryption and decryption will usually not produce the desired result. We can probably get away with agreed definitions of supported input-output lengths, but we might need to think about this - I'm not sure.

Where we're deficient is in specification of IV length, and tag length. These can, and do, vary between uses. (I extracted relevant bits from RFC4106 in the example above.) 

A new Cryptographic Parameter, perhaps named "GCM IV Length" would fix the IV length problem.
A new Cryptographic Parameter, perhaps named "GCM Tag Length" would fix the tag length problem.
Should the server disallow GCM mode to be assigned to non 128-bit block-mode ciphers?


CTR Mode

Encryption/decryption operations in CTR mode take two inputs: initial counter block (ICB), and PT/CT. There is one output: CT/PT.

The following prerequisites are required in order for encryption/decryption to be interoperable:
- An agreed block cipher;
- A common key; and
- Agreed structure of the counter block (which impacts the counter incrementing function).

NIST SP-800-38A Appendix B provides guidance on choosing the initial counter block. Two methods are described, although others a permitted. In general, it is probably okay to model the ICB as a structure consisting of up to three variable length fields: nonce, IV, and block counter.

RFC3686 (AES CTR Mode, IPsec ESP) states:
"The components of the counter block are as follows:

Nonce
      The Nonce field is 32 bits.  As the name implies, the nonce is a
      single use value.  That is, a fresh nonce value MUST be assigned
      for each security association.  It MUST be assigned at the
      beginning of the security association.  The nonce value need not
      be secret, but it MUST be unpredictable prior to the beginning of
      the security association.

Initialization Vector
      The IV field is 64 bits.  As described in section 3.1, the IV MUST
      be chosen by the encryptor in a manner that ensures that the same
      IV value is used only once for a given key.

Block Counter
      The block counter field is the least significant 32 bits of the
      counter block.  The block counter begins with the value of one,
      and it is incremented to generate subsequent portions of the key
      stream.  The block counter is a 32-bit big-endian integer value.

Using the encryption process described in section 2.1, this
construction permits each packet to consist of up to:

      (2^32)-1 blocks  =  4,294,967,295 blocks
                       = 68,719,476,720 octets"

RFC3686 has chosen 32-bit nonce, 64-bit IV, and 32-bit block counter for the counter block structure. Other uses may have different values.

As with GCM, we're okay in KMIP for block cipher and key. Where we're deficient is in specification of the structure of the counter block. 

A new Cryptographic Parameter, perhaps named "CTR Block Counter Structure" with the following content would fix the problem:
- CTR Nonce Length
- CTR IV Length
- CTR Block Counter Length

It is possible that other cipher modes have similar problems, but I haven't had time to look at these yet. I'm also sure (without checking for the details yet) that these issues break the new Encrypt/Decrypt operations if they are meant to support GCM and CTR modes.

John

----------------------------------------------------------------------
John Leiseboer                          QuintessenceLabs Pty Ltd
Chief technology Officer                Suite 23, Physics Building #38
Phone:  +61 7 5494 9291 (Qld)           Science Road
Phone:  +61 2 6125 9498 (ACT)           Australian National University
Mobile: +61 409 487 510                 Acton ACT 0200
Fax:    +61 2 6125 7180                 AUSTRALIA
Email:  JL@quintessencelabs.com         www.quintessencelabs.com
----------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php