Subject: [Ietf-krb-wg] AES-CBC Mode with HMAC-SHA2 and Suite B in Kerberos 5 Internet-Drafts

From: "Peck, Michael A" <[email-masked]>
Date: Thu, 9 Jun 2011 09:03:34 -0400

Hello -
	
Kelley Burgin and I have submitted "AES-CBC Mode with HMAC-SHA2 for Kerberos 5".  This document specifies two new encryption types and corresponding checksum types for Kerberos 5.  They use AES-128 and AES-256 in CBC mode along with HMAC-SHA-256 and HMAC-SHA-384.
http://www.ietf.org/internet-drafts/draft-burgin-kerberos-aes-cbc-hmac-sha2-00.txt

Also, Kelley Burgin and Kevin Igoe have submitted "Suite B in Kerberos 5".  This document profiles Suite B compliant use of Kerberos 5, referring to the above document and others.  It also relies on the PKINIT algorithm agility draft (draft-ietf-krb-wg-pkinit-alg-agility).
http://www.ietf.org/internet-drafts/draft-burgin-kerberos-suiteb-00.txt

We would appreciate your feedback on these drafts.

Thanks,
Mike Peck
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Thu, 09 Jun 2011 11:46:58 -0400

On Thu, 2011-06-09 at 09:03 -0400, Peck, Michael A wrote:
> Kelley Burgin and I have submitted "AES-CBC Mode with HMAC-SHA2 for
> Kerberos 5".  This document specifies two new encryption types and
> corresponding checksum types for Kerberos 5.  They use AES-128 and
> AES-256 in CBC mode along with HMAC-SHA-256 and HMAC-SHA-384.

I have four high-level comments:

1. I believe Sam Hartman raised some concerns about the use of
self-describing padding in a Kerberos enctype, having to do with the way
Microsoft uses Kerberos encryption in DCE RPC.  Unfortunately, I can't
find the message.  But there may be a problem with adding 16 bytes of
padding to a message which is a multiple of 16 bytes.  This is primarily
why I chose to continue to use CTS in camellia-cts-cmac (after
determining that I couldn't get CCM or GCM to work acceptably within the
constraints of RFC 3961).  This may be a blocking concern, although I
don't understand it well enough to make it blocking from my own point of
view.

2. Instead of composing the plaintext with a confounder, you use a
random CBC IV, and your integrity tag is HMAC(Ki, plaintext | pad).
This means attackers can easily determine when two ciphertext tokens
encrypted with the same key have the same plaintext, because they will
have the same integrity tag.  This is a blocking concern; I think it can
be addressed simply be making the integrity tag HMAC(Ki, N | plaintext |
pad).

On a related note, as described, the enctype generates a cipher state
but does not make use of it for subsequent encryptions.  XORing the
cipher state with the nonce would probably be sufficient.

3. Within the context of a Kerberos enctype using 128-bit block
encryption, I think CMAC is superior to HMAC for integrity tags and
checksums.  It means that with the exception of string-to-key, the
enctype's security depends only on the security of the cipher.  I didn't
find any drawbacks to using CMAC in the development of
camellia-cts-cmac.  This is not necessarily a blocking concern for me,
but I would like to hear a justification for HMAC over CMAC.

4. For camellia-cts-cmac, I made the string-to-key function depend on
the enctype name, so that different enctypes produce different keys for
the same password.  (This was on Ken Raeburn's advice.)  The same should
be done for this enctype.

At an editorial level (this is probably not complete):

* pad is described as the "shortest string to bring plaintext to a
length that is a multiple of m".  For a message which is already a
multiple of m bytes, RFC 5652 padding would add m additional bytes, not
0 bytes.  Otherwise there is no way to distinguish a 32-byte message
which happens to end in 0x1 from a 31-byte message, etc..

* The decryption function does not describe the removal of the pad.

* The security considerations section should mention padding oracle
attacks, and advise that implementations return the same error for
integrity failures as for invalid padding.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Jun 2011 13:38:34 -0400

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:

    Greg> On Thu, 2011-06-09 at 09:03 -0400, Peck, Michael A wrote:
    Greg> 1. I believe Sam Hartman raised some concerns about the use of
    Greg> self-describing padding in a Kerberos enctype, having to do
    Greg> with the way Microsoft uses Kerberos encryption in DCE RPC.
    Greg> Unfortunately, I can't find the message.  But there may be a
    Greg> problem with adding 16 bytes of padding to a message which is
    Greg> a multiple of 16 bytes.  This is primarily why I chose to
    Greg> continue to use CTS in camellia-cts-cmac (after determining
    Greg> that I couldn't get CCM or GCM to work acceptably within the
    Greg> constraints of RFC 3961).  This may be a blocking concern,
    Greg> although I don't understand it well enough to make it blocking
    Greg> from my own point of view.

One of the issues that may apply to a Kerberos enctype that has padding
is interactions with IOV-like APIs including Microsoft's SSPI and the
IOV-based APIs included in MIT Kerberos and Heimdal.  These APIs provide
in-place encryption.

As a result, the caller needs to allocate the padding if there is going
to be padding.  It seems fairly likely that DCE-related applications
will only allocate 8 bytes of padding.  At least when I was looking at
this case, the Microsoft APIs did not provide a way to know how long of
a pad buffer was needed, but DES was the only enctype that might require
padding.

This may not be a huge issue for RFC 4121-based applications; I think
the RRC will typically allow you to stuff all this into the header
chunk.

I think it would be good to have someone familiar with both SSPI and the
other IOV-based APIs and with their common uses to comment onthe
implications of a new enctype with padding--particularly more than 8
bytes of padding.

--Sam

---

From: Luke Howard <[email-masked]>
Date: Thu, 9 Jun 2011 22:50:43 +0000

> the RRC will typically allow you to stuff all this into the header

RIght, and that's what you'd want to do. MS RPC always pads to N bytes at the application layer, I believe N is 8 but I could be wrong.

> implications of a new enctype with padding--particularly more than 8

Unfortunately I don't have this swapped in anymore -- at one point I would have been able to give you a precise answer to this question. I suspect you would need to ask Larry. But I believe it's fine because you can use EC and RRC to get this in the header. Now, Windows doesn't implement this properly for AES CTS, but maybe they'd get it right if padding was really required. :-)

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Thu, 9 Jun 2011 18:25:39 -0500

> RIght, and that's what you'd want to do. MS RPC always pads to N bytes at the application layer, I believe N is 8 but I could be wrong.

My memory is also not very good on this but I'm pretty sure that N is
always 8, and is a side-effect of old SSPI interfaces.

This kinda rules out any combinations of block ciphers with block size
larger than 64-bit and cipher modes that require padding -- so CBC is
out.  That leaves counter modes and CTS, but counter modes are out due
to their extreme weaknesses on IV re-use, which is hard to prevent in
Kerberos PDUs other than KRB-SAFE/PRIV/CRED or outside the context of
GSS per-message tokens.  So CTS it has to be.  CTS is rather
obnoxious, but it will do.  OTOH, if CTS were as weak in the face of
confounder and key reuse as counter modes are for IV and key reuse,
then I'd rather pick a counter mode.

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Fri, 10 Jun 2011 10:11:13 +0000

> always 8, and is a side-effect of old SSPI interfaces.

Here's a comment which "git blame" says I wrote :-)

/*
 * [MS-RPCE] states that the stub data is padded to the underlying
 * blocksize (or four bytes, if that is greater). In practice they
 * use the underlying keysize when the blocksize is one. For now,
 * a constant 16 bytes works for all known ciphers and mechanisms
 * (at the expense of 8 bytes extra padding for DES), but we should
 * eventually fix it to use gss_context_query_attributes().
 */

Make of that what you will.

-- Luke

---

From: "Burgin, Kelley W." <[email-masked]>
Date: Fri, 17 Jun 2011 11:00:20 -0400

Greg,

Thanks for your comments. My responses keep your numbering:

1. [MS-RPCE] section 2.2.2.13 says "Client implementations MAY send stub
padding octets after the stub data" without limiting the number of
octets of padding and that "server implementations SHOULD NOT assume
that the verification trailer immediately follows the stub data but
instead SHOULD search for a sequence of octets that matches the value of
the signature [which begins the verification trailer], as specified in
section 2.2.2.13.1, starting immediately after the end of the stub data
and continuing until the end of the PDU". This seems to indicate that
CBC mode with PKCS#5 padding will not cause problems in implementations
that follow the documentation.

2. We will change to H = HMAC(Ki, N | plaintext | pad). Also, since
cipher state is neither required nor useful to us, we will delete it
altogether from the next draft.

3. The enctype draft was written to accommodate the needs of the other
draft submitted, Suite B in Kerberos 5 (draft-burgin-kerberos-suiteb).
When a minimum level of security of 192 bits is required in Suite B, we
wanted a matching MAC length of 192 bits which is not possible with
CMAC. Using HMAC instead of CMAC also lessens the likelihood of using
the wrong key with the encryption algorithm (using Ke for integrity, for
example).

4. OK, will update in the next draft.

Editorial comments also noted and will be addressed in the next draft.

Kelley

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Greg Hudson
Sent: Thursday, June 09, 2011 11:47 AM
To: Peck, Michael A
Cc: [email-masked]; [email-masked]
Subject: Re: [Ietf-krb-wg] AES-CBC Mode with HMAC-SHA2 and Suite B in
Kerberos 5 Internet-Drafts

> AES-256 in CBC mode along with HMAC-SHA-256 and HMAC-SHA-384.
http://www.ietf.org/internet-drafts/draft-burgin-kerberos-aes-cbc-hmac-s
ha2-00.txt

---

From: Greg Hudson <[email-masked]>
Date: Fri, 17 Jun 2011 11:21:48 -0400

> altogether from the next draft.

Cipher state is not optional.  From RFC 3961 section 3: "This state must
be non-empty and must influence encryption so that messages are
decrypted in the same order they were a encrypted, if the cipher state
is carried over from one encryption to the next."

> CMAC.

Thanks for the explanation.  This seems like an adequate reason to use
HMAC.

---

From: Ken Raeburn <[email-masked]>
Date: Sat, 18 Jun 2011 04:20:00 -0400

> * The decryption function does not describe the removal of the pad.

Is the very specific padding handling actually a requirement for Suite B?  Or is this based on an assumption that the "decrypt" operation can't leave padding cruft tacked on the end of the message in Kerberos?  Kerberos cryptosystems can be very lax about padding in some cases, for historical reasons -- the initial DES use was lame this way, so the messages have to be self-describing in terms of where they end, so other cryptosystems can be lame too... so padding with zero or more randomized bytes works just fine.

Ken

---

From: "Burgin, Kelley W." <[email-masked]>
Date: Sat, 18 Jun 2011 06:07:19 -0400

Ken,

Thanks for the information. Suite B does not have any requirements on
padding, just that the encryption algorithm be AES (there are other
requirements that don't apply to encryption). The intention is to use
CBC mode with RFC 5652 padding which will be removed during decryption.
We will add a sentence about removing the padding to the next draft and
require the padding length to be nonzero.

Kelley 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ken Raeburn
Sent: Saturday, June 18, 2011 4:20 AM
To: Greg Hudson
Cc: [email-masked]; [email-masked]
Subject: Re: [Ietf-krb-wg] AES-CBC Mode with HMAC-SHA2 and Suite B
inKerberos 5 Internet-Drafts

> * The decryption function does not describe the removal of the pad.

Is the very specific padding handling actually a requirement for Suite
B?  Or is this based on an assumption that the "decrypt" operation can't
leave padding cruft tacked on the end of the message in Kerberos?
Kerberos cryptosystems can be very lax about padding in some cases, for
historical reasons -- the initial DES use was lame this way, so the
messages have to be self-describing in terms of where they end, so other
cryptosystems can be lame too... so padding with zero or more randomized
bytes works just fine.

Ken

---

From: "Burgin, Kelley W." <[email-masked]>
Date: Sat, 18 Jun 2011 06:19:33 -0400

Greg,

You're right - cipher state is required to be defined but not carried over to the next encryption, which is why I originally put the current nonce in there but did not make use of it in the next encryption. I misread the statement you quoted below from RFC 3961 after you commented previously "On a related note, as described, the enctype generates a cipher state but does not make use of it for subsequent encryptions.  XORing the cipher state with the nonce would probably be sufficient." But now I think the original text is OK. I will put in some additional text about cipher state being defined to satisfy the statement below, but that it is not to be carried over.

Kelley

---

From: Greg Hudson <[email-masked]>
Date: Sat, 18 Jun 2011 10:32:55 -0400

On Sat, 2011-06-18 at 06:19 -0400, Burgin, Kelley W. wrote:
> You're right - cipher state is required to be defined but not carried
> over to the next encryption

An enctype specification must carry cipher state over to the next
encryption.  "If the cipher state is carried over from one encryption to
the next" describes the possible behavior of the caller, not of the
enctype specification.

---

From: "Burgin, Kelley W." <[email-masked]>
Date: Sat, 18 Jun 2011 11:15:41 -0400

OK, I got it now. Thanks for explaining this.