[kitten] Moving forward with draft-ietf-kitten-aes-cts-hmac-sha2

["Peck, Michael A" <[e-mail]>]

Hi -

I believe two primary issues have been raised with the AES and SHA-2 encryption type drafts: ciphertext stealing vs padding, and IV options.

1: CTS vs. CBC with PKCS7 padding

We first submitted draft-ietf-kitten-aes-cts-hmac-sha2 (uses CTS mode, also known as CBC mode with ciphertext stealing), then submitted draft-ietf-kitten-aes-cbc-hmac-sha2 (uses CBC mode with PKCS7 padding).

A consensus call decided on CBC mode with PKCS7 padding, but immediately afterwards Paul Miller from Microsoft stated that CBC with PKCS7 padding could cause compatibility problems.  Based on that feedback, I suggest we go with CTS mode – are there any objections?

2: Initialization vector

RFC 3961/3962 sets the formal CBC IV to the cipherstate (the next-to-last ciphertext block of the previous message)  - (it's my understanding the purpose of the cipher state is to enforce message sequencing) - and sets the first block of plaintext to a 128-bit random value (called a confounder).  The cipherstate is not sent with the message since it can be implicitly inferred from the ciphertext of the previous message.  The confounder (first block of plaintext) plays the cryptographic role of the IV.

Draft-ietf-kitten-aes-cts-hmac-sha2 currently sets the CBC IV to a 128-bit nonce XORed with the cipher state (in this draft, the cipher state is currently the previous message's 128-bit nonce).  The nonce is sent in the clear along with the ciphertext and the MAC.  We followed this approach to be aligned with the CTS definition found in the NIST Special Publication 800-38A Addendum, which treats the IV as a parameter to be passed into the encrypt and decrypt operations (and expects it to meet the required properties of a CBC IV).
(Side note: Currently the draft states that the MAC is computed over the nonce and ciphertext.  Upon another look, I'm thinking the MAC should instead be computed over the IV and ciphertext, so that message reorderings are detected by the MAC verification.)

Some have indicated interest in sticking with the RFC 3961/3962 confounder approach.
I'd like to suggest some options to choose from:

Option 1:

Define separate Kerberos enctypes for each of the two IV approaches.

Define the cipherstate to be the next-to-last ciphertext block of the previous message (like in RFC 3961/3962).

If the confounder approach is being used (as signaled by the enctype), don't include an explicit nonce.  Set the CBC IV = cipherstate.  Set the first block of plaintext to a 128-bit nonce.  Omit the first block of plaintext from the decrypt operation's plaintext output.
ciphertext || MAC is transmitted.

If the explicit nonce approach is being used (as signaled by the enctype), set the CBC IV = cipherstate XOR nonce.
nonce || ciphertext || MAC is transmitted.

The MAC is computed over the IV || ciphertext in both cases.

This option seems to provide the ability to deployers to decide which IV approaches they're comfortable with (both or just one) through the allowed enctypes.

Option 2:

Define the cipher state to be the next-to-last ciphertext block of the previous message (like in RFC 3961/3962).

If the sender chooses the confounder approach, set the explicit nonce field to the cipher state, and set the first block of plaintext to a 128-bit nonce (confounder).

If the sender chooses to use an explicit nonce, set the explicit nonce field to a 128-bit nonce, and set the first block of plaintext to the cipherstate.

Either way, the CBC IV is set to the explicit nonce field.
The MAC is computed over the explicit nonce field || ciphertext.

Explicit nonce field || cipher text || MAC is transmitted.

The recipient always omits the first block of plaintext from the decrypt operation's plaintext output.
The recipient needs to make sure the cipherstate transmitted with the message is consistent with the previous message's ciphertext.

Two downsides of this approach:
It adds an unnecessary 128 bits to each message.
It doesn't easily allow deployers to decide which IV techniques to allow based on policy considerations.

Option 3:

Pick one IV approach.

Thanks,
Mike