[kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Benjamin Kaduk-2
This message begins the Working Group Last Call (WGLC) of "AES Encryption
with HMAC-SHA2 for Kerberos 5" <draft-ietf-kitten-aes-cts-hmac-sha2-06>.
The WGLC will last two weeks, ending on Monday, April 13th.  The draft is
available at:

https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-06

Please review the document and send comments to the Working Group mailing
list <[hidden email]> or the co-chairs <[hidden email]>
before the end of the WGLC.  Any and all comments on the document are
sought in order to access the strength of consensus.  Even if you have
read and commented on this or earlier versions of the draft, please feel
free to comment again.  This is particularly important if you found issues
with the previous version.

As a reminder, comments can be anything from "this looks fine" to "this is
a horrible idea"; they can include suggestions for minor editorial
corrections to significant editorial changes.


- Your Kitten Chairs

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Greg Hudson
On 03/30/2015 12:40 PM, Benjamin Kaduk wrote:
> This message begins the Working Group Last Call (WGLC) of "AES Encryption
> with HMAC-SHA2 for Kerberos 5" <draft-ietf-kitten-aes-cts-hmac-sha2-06>.
> The WGLC will last two weeks, ending on Monday, April 13th.

I put together a simple implementation of this draft in Python, and
verified some of the test vectors (but not all; see below).

There are several aspects of the enctype design whose motivations are
unclear to me.  They affect performance but not security.  They are:

* For the 192-bit security level, why use SHA-384 and truncate to 192
bits?  Why not use SHA-256 and truncate to 192 bits?

* Why use a 192-bit HMAC key for Ki and Kc but not for Kp?

* Why use 128/256-bit PRF output lengths?  Why not just output the full
hash?  It can't be for consistency with RFC 3962, as
aes256-cts-hmac-sha1-96 has a 128-bit PRF output length.  It can't be
out of some desire to consistently truncate SHA-2 results in half, or we
would have 128/192-bit output lengths.

I have one concern about formal correctness:

* Following the lead of the simplified profile, the formulation of the
key derivation function in section 3 ends by calling random-to-key() as
if the result had the same abstract type as a protocol key.  But for the
AES256 variant, Ki and Kc have a 192-bit length, so it cannot be of the
same abstract type as a 256-bit protocol key.  The formalism is also
sloppy because it depends on context; instead of taking a length
parameter, it uses an implicit length based on what operation the
invoker is performing.  In a similar vein, section 3 talks about what
the input constant is for each derivation use; this is not the case for
RFC 3961 or RFC 6803 and seems out of place.

I have several concerns about the presentation of the test vectors:

* The PRF test vectors do not list a base key; instead it lists a Kp
value.  This requires tests to exercise only a component of the PRF
implementation, which may be inconvenient.  The base keys are present in
the key derivation test vectors, but this is not immediately clear.

* The encryption test vectors do not list base keys and key usages;
instead they only list "AES key" and "HMAC key" values which are
presumably Kc and Ki.  For the first 128-bit test vector, the base key
and usage is recoverable from the key derivation test vectors, but that
does not appear to be the case for any of the other encryption test
vectors.  Because of this, I only verified the first encryption test vector.

* The checksum test vectors do not list a base key or key usage.  The
base keys and usages are present in the key derivation test vectors, but
this is not immediately clear.

(It looks like RFC 6803 is missing key usages for encryption test
vectors, which may have contributed to some of the above issues.  I will
submit an erratum.)

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Benjamin Kaduk-2
In reply to this post by Benjamin Kaduk-2
Sorry for the slighty-late reminder; there is less than a week remaining
in this WGLC period.

-Ben

On Mon, 30 Mar 2015, Benjamin Kaduk wrote:

> This message begins the Working Group Last Call (WGLC) of "AES Encryption
> with HMAC-SHA2 for Kerberos 5" <draft-ietf-kitten-aes-cts-hmac-sha2-06>.
> The WGLC will last two weeks, ending on Monday, April 13th.  The draft is
> available at:
>
> https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-06
>
> Please review the document and send comments to the Working Group mailing
> list <[hidden email]> or the co-chairs <[hidden email]>
> before the end of the WGLC.  Any and all comments on the document are
> sought in order to access the strength of consensus.  Even if you have
> read and commented on this or earlier versions of the draft, please feel
> free to comment again.  This is particularly important if you found issues
> with the previous version.
>
> As a reminder, comments can be anything from "this looks fine" to "this is
> a horrible idea"; they can include suggestions for minor editorial
> corrections to significant editorial changes.
>
>
> - Your Kitten Chairs
>
> _______________________________________________
> Kitten mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten
>

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Benjamin Kaduk-2
In reply to this post by Greg Hudson
On Thu, 2 Apr 2015, Greg Hudson wrote:

> On 03/30/2015 12:40 PM, Benjamin Kaduk wrote:
> > This message begins the Working Group Last Call (WGLC) of "AES Encryption
> > with HMAC-SHA2 for Kerberos 5" <draft-ietf-kitten-aes-cts-hmac-sha2-06>.
> > The WGLC will last two weeks, ending on Monday, April 13th.
>
> I put together a simple implementation of this draft in Python, and
> verified some of the test vectors (but not all; see below).

Thank you!

> There are several aspects of the enctype design whose motivations are
> unclear to me.  They affect performance but not security.  They are:
>
> * For the 192-bit security level, why use SHA-384 and truncate to 192
> bits?  Why not use SHA-256 and truncate to 192 bits?

I did not go on a full trawl through the archives, but
http://www.ietf.org/mail-archive/web/kitten/current/msg05307.html implies
that NIST is generating a document covering "what you get from what you
used" indicating that SHA-256 only gives you 128 bits, under some set of
assumptions.

> * Why use a 192-bit HMAC key for Ki and Kc but not for Kp?

I don't think there is logic supporting this choice in the list archives;
if I remember correctly, Kp was added rather late in the document's
history, and the decision to have an explicit intermediate Kp instead of
just making the PRF use the base key direction (in some form) was made
pretty arbitrarily ("it feels better to keep the behavior parallel across
enctypes" or thereabouts).

Leaving k as 256 allows the PRF = k-truncate(HMAC-SHA2(Kp, octet-string))
to produce a pseudo-random function output which is a multiple of the
random-to-key input size (and the underlying cipher block size), which is
a nice feature to retain.  I don't know of a reason why we could not
retain 256-truncate using a 192-bit Kp, though.

> * Why use 128/256-bit PRF output lengths?  Why not just output the full
> hash?  It can't be for consistency with RFC 3962, as
> aes256-cts-hmac-sha1-96 has a 128-bit PRF output length.  It can't be
> out of some desire to consistently truncate SHA-2 results in half, or we
> would have 128/192-bit output lengths.

I think there is some desire to always truncate SHA-2 results in half,
though, for the reasons mentioned above.  But a 192-bit output would not
be a multiple of the blocksize or random-to-key input size, so in that
sense (random-to-key input), 256 bits makes more sense.  This is probably
"okay" in the sense of wanting to always cut SHA-2 outputs in half,
because the aes256-...-192 enctype only claims to provide 192 bits of
security.

> I have one concern about formal correctness:
>
> * Following the lead of the simplified profile, the formulation of the
> key derivation function in section 3 ends by calling random-to-key() as
> if the result had the same abstract type as a protocol key.  But for the
> AES256 variant, Ki and Kc have a 192-bit length, so it cannot be of the
> same abstract type as a 256-bit protocol key.  The formalism is also

So random-to-key() only applies for generating base keys, and the
derivation of Kc/Ki/Ke/Kp should just be k-truncate(...)?

Or is the argument rather that since we are not using the simplified
profile, we just don't need random-to-key() at all because we are defining
things manually and can make use of the fact that it is the identity
function for these enctypes?

> sloppy because it depends on context; instead of taking a length
> parameter, it uses an implicit length based on what operation the
> invoker is performing.  In a similar vein, section 3 talks about what
> the input constant is for each derivation use; this is not the case for
> RFC 3961 or RFC 6803 and seems out of place.

So you want to rely just on the (type of the) key being derived and not
mention the last octet of the constant?  I think that would be a valid way
to specify things, but want to confirm the nature of your comment.

> I have several concerns about the presentation of the test vectors:
>
> * The PRF test vectors do not list a base key; instead it lists a Kp
> value.  This requires tests to exercise only a component of the PRF
> implementation, which may be inconvenient.  The base keys are present in
> the key derivation test vectors, but this is not immediately clear.

We could add text so the PRF test vectors say "Kp value (repeated from
above):"; would that help?

> * The encryption test vectors do not list base keys and key usages;
> instead they only list "AES key" and "HMAC key" values which are
> presumably Kc and Ki.  For the first 128-bit test vector, the base key
> and usage is recoverable from the key derivation test vectors, but that
> does not appear to be the case for any of the other encryption test
> vectors.  Because of this, I only verified the first encryption test vector.

Hmm.  I don't really want to propose removing test vectors to replace them
with new ones, but could we add some additional test vectors which do
possess the desired properties?  (I.e., that the Kc and Ki are listed in a
previous test vector from base key and usage, or that they are test
vectors starting from base key.)

> * The checksum test vectors do not list a base key or key usage.  The
> base keys and usages are present in the key derivation test vectors, but
> this is not immediately clear.

Similarly to the PRF, does "HMAC key (repeated from above):" help enough?

> (It looks like RFC 6803 is missing key usages for encryption test
> vectors, which may have contributed to some of the above issues.  I will
> submit an erratum.)

Thanks.


My own review notes that section 8.2 contains an extra space in "The
encryption".  It additionally claims that this document is proposing "the
use of [...] AES-256 with a 192-bit key", but this is confusing since
AES-256 definitionally requires a 256-bit encryption key, and the base key
is also a 256-bit key.  Perhaps "AES-256 with some derived keys of length
192 bits" is better, albeit clunky.


-Ben

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Greg Hudson
On 04/08/2015 05:26 PM, Benjamin Kaduk wrote:
> I did not go on a full trawl through the archives, but
> http://www.ietf.org/mail-archive/web/kitten/current/msg05307.html implies
> that NIST is generating a document covering "what you get from what you
> used" indicating that SHA-256 only gives you 128 bits, under some set of
> assumptions.

I do not understand what assumptions would yield a security level of 128
bits from SHA-256 truncated to 192 bits, and a security level of 192
bits from SHA-384 truncated to 192 bits.  If there is a concern about
birthday attacks on the integrity tag, then we can't get away with
truncating at all; we would need to send a 256-bit tag for the 128-bit
security level, and a 384-bit tag for the 192-bit security level.

I wonder if NIST finished its document in the interim.

>> * Why use a 192-bit HMAC key for Ki and Kc but not for Kp?

This was probably a dumb question, and really devolves into "why use a
256-bit PRF output length?"  For the 192-bit security level, Ki and Kc
are used to generate a 192-bit tag, but Kp is used to generate a 256-bit
PRF.

[Regarding truncation of the PRF output:]
> I think there is some desire to always truncate SHA-2 results in half,
> though, for the reasons mentioned above.

I would like to better understand these reasons.

> So random-to-key() only applies for generating base keys, and the
> derivation of Kc/Ki/Ke/Kp should just be k-truncate(...)?

Yes.  RFC 3961 defines random-to-key() as producing a protocol key.  It
is probably a conceptual error that RFC 3961 section 5.1 uses
random-to-key() as the last step of its key derivation function.  That
error would be especially confusing in the new context, where derived
HMAC keys can have different lengths than protocol keys.

> Or is the argument rather that since we are not using the simplified
> profile, we just don't need random-to-key() at all because we are defining
> things manually and can make use of the fact that it is the identity
> function for these enctypes?

No, we need a random-to-key(); it is part the RFC 3961 definition of an
encryption algorithm profile.  By contrast, key derivation is not part
of this definition; it's just an internal feature of every
non-single-DES encryption type so far.

>> sloppy because it depends on context; instead of taking a length
>> parameter, it uses an implicit length based on what operation the
>> invoker is performing.  In a similar vein, section 3 talks about what
>> the input constant is for each derivation use; this is not the case for
>> RFC 3961 or RFC 6803 and seems out of place.

> So you want to rely just on the (type of the) key being derived and not
> mention the last octet of the constant?  I think that would be a valid way
> to specify things, but want to confirm the nature of your comment.

My suggestion is to:

* Give the key derivation function KDF-HMAC-SHA2() an explicit length
parameter, and remove the discussion of what its value is for each use.
 Provide a length argument in each use of KDF-HMAC-SHA2() elsewhere in
the document.  This argument will probably need to be given
symbolically, as it varies between the 128-bit and 192-bit security levels.

* Remove the discussion of what the constant values are from section 3.

>> I have several concerns about the presentation of the test vectors:
>>
>> * The PRF test vectors do not list a base key; instead it lists a Kp
>> value.  This requires tests to exercise only a component of the PRF
>> implementation, which may be inconvenient.  The base keys are present in
>> the key derivation test vectors, but this is not immediately clear.

> We could add text so the PRF test vectors say "Kp value (repeated from
> above):"; would that help?

I think it would be better to explicitly list the base key.  If it
happens to be the same as the base key from a previous test vector,
that's not really important.

>> * The encryption test vectors do not list base keys and key usages;
>> instead they only list "AES key" and "HMAC key" values which are
>> presumably Kc and Ki.  For the first 128-bit test vector, the base key
>> and usage is recoverable from the key derivation test vectors, but that
>> does not appear to be the case for any of the other encryption test
>> vectors.  Because of this, I only verified the first encryption test vector.

> Hmm.  I don't really want to propose removing test vectors to replace them
> with new ones, but could we add some additional test vectors which do
> possess the desired properties?  (I.e., that the Kc and Ki are listed in a
> previous test vector from base key and usage, or that they are test
> vectors starting from base key.)

I don't think there's anything precious about the currently listed test
vectors.  If the draft authors possess the base keys they used for the
encryption test vectors, they can provide them; otherwise they can
generate new test vectors and we can discard the old ones.  Including
encryption test vectors with missing base keys just seems frustrating to
an implementor.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Jeffrey Altman-2
Greg,

Thank you for performing this important review.   The questions you have
raised are significant.   Do we have independent review from trusted
cryptographers?  I'm not one so will not try to review the math.

On 4/8/2015 6:48 PM, Greg Hudson wrote:

> On 04/08/2015 05:26 PM, Benjamin Kaduk wrote:
>
>> Hmm.  I don't really want to propose removing test vectors to replace them
>> with new ones, but could we add some additional test vectors which do
>> possess the desired properties?  (I.e., that the Kc and Ki are listed in a
>> previous test vector from base key and usage, or that they are test
>> vectors starting from base key.)
>
> I don't think there's anything precious about the currently listed test
> vectors.  If the draft authors possess the base keys they used for the
> encryption test vectors, they can provide them; otherwise they can
> generate new test vectors and we can discard the old ones.  Including
> encryption test vectors with missing base keys just seems frustrating to
> an implementor.
>
My personal opinion is that the last call should not complete
successfully if it is not possible to verify all of the test vectors.

It would also be my preference that there be two interoperable
implementations before the working group approves the document.

Sincerely

Jeffrey Altman


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Michael Jenkins
In reply to this post by Greg Hudson
Hi, sorry for the silence. I've been on travel and I wanted to make sure I got one of the original authors to help respond. So, we should be able to address all of Greg's concerns shortly. In the meantime, I can comment generally if simplistically on two things:

Bit string lengths and bits-o'-security: When this draft was originally introduced to kitten, it was stated that it was to support draft-burgin-kerberos-suiteb <http://www.ietf.org/mail-archive/web/kitten/current/msg03802.html>. So there's an implicit presumption that one is working in one of two modes, 192-bit or 128-bit security, and consequently using either SHA-384 or SHA-256, respectively. 

In general, though, it's designed to make sense - you can't use SHA-256 to get a 192 bit key because a SHA-256 output has at most 128 bits of security no matter how you slice it. I am not an expert in attacks on hashes nor on hash-function construction (boy howdy!), so I'm not going to argue about whether this particular application is susceptible to this-or-that attack - ultimately the answer is "because Suite B". I'm not saying that as a hammer; I'm saying that's how the thing was pitched and accepted as a work-item back at version -02.

Test vectors: I can nearly guarantee (see inheritance disclaimer above) that the Ke for the encryption test vector sets beyond the first 128-bit one came straight out of /dev/random, no doubt based on the fact that it was easier to do so than to figure out how to get access to Kelley's abandoned workfiles after he left for greener pastures (go him!). I can regenerate them taking a more soup-to-nuts approach.

Mike J

On Wed, Apr 8, 2015 at 6:48 PM, Greg Hudson <[hidden email]> wrote:
On 04/08/2015 05:26 PM, Benjamin Kaduk wrote:
> I did not go on a full trawl through the archives, but
> http://www.ietf.org/mail-archive/web/kitten/current/msg05307.html implies
> that NIST is generating a document covering "what you get from what you
> used" indicating that SHA-256 only gives you 128 bits, under some set of
> assumptions.

I do not understand what assumptions would yield a security level of 128
bits from SHA-256 truncated to 192 bits, and a security level of 192
bits from SHA-384 truncated to 192 bits.  If there is a concern about
birthday attacks on the integrity tag, then we can't get away with
truncating at all; we would need to send a 256-bit tag for the 128-bit
security level, and a 384-bit tag for the 192-bit security level.

I wonder if NIST finished its document in the interim.

>> * Why use a 192-bit HMAC key for Ki and Kc but not for Kp?

This was probably a dumb question, and really devolves into "why use a
256-bit PRF output length?"  For the 192-bit security level, Ki and Kc
are used to generate a 192-bit tag, but Kp is used to generate a 256-bit
PRF.

[Regarding truncation of the PRF output:]
> I think there is some desire to always truncate SHA-2 results in half,
> though, for the reasons mentioned above.

I would like to better understand these reasons.

> So random-to-key() only applies for generating base keys, and the
> derivation of Kc/Ki/Ke/Kp should just be k-truncate(...)?

Yes.  RFC 3961 defines random-to-key() as producing a protocol key.  It
is probably a conceptual error that RFC 3961 section 5.1 uses
random-to-key() as the last step of its key derivation function.  That
error would be especially confusing in the new context, where derived
HMAC keys can have different lengths than protocol keys.

> Or is the argument rather that since we are not using the simplified
> profile, we just don't need random-to-key() at all because we are defining
> things manually and can make use of the fact that it is the identity
> function for these enctypes?

No, we need a random-to-key(); it is part the RFC 3961 definition of an
encryption algorithm profile.  By contrast, key derivation is not part
of this definition; it's just an internal feature of every
non-single-DES encryption type so far.

>> sloppy because it depends on context; instead of taking a length
>> parameter, it uses an implicit length based on what operation the
>> invoker is performing.  In a similar vein, section 3 talks about what
>> the input constant is for each derivation use; this is not the case for
>> RFC 3961 or RFC 6803 and seems out of place.

> So you want to rely just on the (type of the) key being derived and not
> mention the last octet of the constant?  I think that would be a valid way
> to specify things, but want to confirm the nature of your comment.

My suggestion is to:

* Give the key derivation function KDF-HMAC-SHA2() an explicit length
parameter, and remove the discussion of what its value is for each use.
 Provide a length argument in each use of KDF-HMAC-SHA2() elsewhere in
the document.  This argument will probably need to be given
symbolically, as it varies between the 128-bit and 192-bit security levels.

* Remove the discussion of what the constant values are from section 3.

>> I have several concerns about the presentation of the test vectors:
>>
>> * The PRF test vectors do not list a base key; instead it lists a Kp
>> value.  This requires tests to exercise only a component of the PRF
>> implementation, which may be inconvenient.  The base keys are present in
>> the key derivation test vectors, but this is not immediately clear.

> We could add text so the PRF test vectors say "Kp value (repeated from
> above):"; would that help?

I think it would be better to explicitly list the base key.  If it
happens to be the same as the base key from a previous test vector,
that's not really important.

>> * The encryption test vectors do not list base keys and key usages;
>> instead they only list "AES key" and "HMAC key" values which are
>> presumably Kc and Ki.  For the first 128-bit test vector, the base key
>> and usage is recoverable from the key derivation test vectors, but that
>> does not appear to be the case for any of the other encryption test
>> vectors.  Because of this, I only verified the first encryption test vector.

> Hmm.  I don't really want to propose removing test vectors to replace them
> with new ones, but could we add some additional test vectors which do
> possess the desired properties?  (I.e., that the Kc and Ki are listed in a
> previous test vector from base key and usage, or that they are test
> vectors starting from base key.)

I don't think there's anything precious about the currently listed test
vectors.  If the draft authors possess the base keys they used for the
encryption test vectors, they can provide them; otherwise they can
generate new test vectors and we can discard the old ones.  Including
encryption test vectors with missing base keys just seems frustrating to
an implementor.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten



--
Mike Jenkins
[hidden email] - if you want me to read it only at my desk
[hidden email] - to read everywhere else
443-634-3951

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Benjamin Kaduk-2
In reply to this post by Jeffrey Altman-2
Hi Jeffrey,

On Thu, 9 Apr 2015, Jeffrey Altman wrote:

> My personal opinion is that the last call should not complete
> successfully if it is not possible to verify all of the test vectors.
>
> It would also be my preference that there be two interoperable
> implementations before the working group approves the document.

The authors have used two independent implementations to verify the test
vectors; I have done some additional verification and Greg has done some
different verification as well.

The last I checked, two interoperable implementations was a requirement
for full Internet Standard, and not required even for Proposed Standard
documents, let alone the Information status this document claims to be
targetting. Could you say a bit more about why you feel the situation is
different here?

-Ben

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Greg Hudson
In reply to this post by Michael Jenkins
On 04/09/2015 06:21 PM, Michael Jenkins wrote:
> Bit string lengths and bits-o'-security: When this draft was originally
> introduced to kitten, it was stated that it was to support
> draft-burgin-kerberos-suiteb
> <http://www.ietf.org/mail-archive/web/kitten/current/msg03802.html>. So
> there's an implicit presumption that one is working in one of two modes,
> 192-bit or 128-bit security, and consequently using either SHA-384 or
> SHA-256, respectively.

I am not familiar with what Suite B requires in detail.  Looking at
https://www.nsa.gov/ia/programs/suiteb_cryptography/
I do see that Suite B indicates the use of SHA-384 for TOP SECRET.  I
assume that it requires this because the weakest inherent aspect of a
hash is its collision resistance, and SHA-384 has (we hope) a collision
resistance strength of 192 bits.  Some uses of a hash may not require
collision resistance, but using SHA-384 means you're covered regardless.

However, SHA-384 truncated to 192 bits does not have a collision
resistance strength of 192 bits; it has a collision resistance strength
of 96 bits.  This is described in detail in SP 800-107 section 5.1,
which is referenced by FIPS 180-4 section 7.

I don't think any meaningful review would deem
192-truncate(HMAC-SHA-384(k, m)) to be stronger than
192-truncate(HMAC-SHA-256(k, m)) by any metric.

> In general, though, it's designed to make sense - you can't use SHA-256
> to get a 192 bit key because a SHA-256 output has at most 128 bits of
> security no matter how you slice it.

I think it very much does matter how you slice it.  For key derivation
using an HMAC, collision resistance is not required, so it is entirely
reasonable to use SHA-256 to generate a 192-bit key.  In fact, the key
derivation function used in this draft (from SP 800-108 section 5.1) can
work securely even if more keying material is required than the HMAC
output size.

For the encryption integrity tag and checksum, collision resistance may
be required for Suite B compliance (but I don't really know).  But as
mentioned above, if we're going to truncate the HMAC result down to 192
bits, we cannot achieve collision resistance strength greater than 96
bits no matter what hash function we use in the HMAC.

In conclusion, to the best of my knowledge:

* If the goal is to meet a checklist of Suite B requirements, using
SHA-384 over SHA-256 internally might be necessary, but it really is
just a meaningless checklist tick.  Moreover, the small integrity tag
and checksum lengths could mean that the draft doesn't actually satisfy
Suite B--I can't speak confidently either way on that point.

* If the goal is to achieve some real security strength, using truncated
SHA-384 is not an improvement over using truncated SHA-256.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Jeffrey Altman-2
In reply to this post by Benjamin Kaduk-2
On 4/9/2015 6:26 PM, Benjamin Kaduk wrote:

> Hi Jeffrey,
>
> On Thu, 9 Apr 2015, Jeffrey Altman wrote:
>
>> My personal opinion is that the last call should not complete
>> successfully if it is not possible to verify all of the test vectors.
>>
>> It would also be my preference that there be two interoperable
>> implementations before the working group approves the document.
>
> The authors have used two independent implementations to verify the test
> vectors; I have done some additional verification and Greg has done some
> different verification as well.
I am glad to hear this.  Are there 3961 implementations available for
public review?

> The last I checked, two interoperable implementations was a requirement
> for full Internet Standard, and not required even for Proposed Standard
> documents, let alone the Information status this document claims to be
> targetting. Could you say a bit more about why you feel the situation is
> different here?

The requirements that you mention are lower bounds that apply to all
RFCs regardless of the IETF Area.  Kitten is not any working group.  It
is a security working group whose RFCs are implemented and deployed as
the basis for securing computer systems around the globe.  The last
"informational" Kerberos encryption type RC4-HMAC (RFC 4757) became one
of the most widely deployed enc-types used for Kerberos authentication.

Due to BCP 179 / RFC 6649 and draft-kaduk-kitten-des-des-des-die-die-die
the Kerberos protocol is left with two related AES*-CTS-SHA1 encryption
types for RFC 3961 based protocols.  Regardless of what track this
document is placed on it is going to be widely and rapidly deployed.  As
a result it is important that the working group ensure that the
encryption type is correct and that independent implementations for the
most widely used Kerberos implementations are available and are
demonstrated to be interoperable.

Without interoperable implementations there is very little justification
in my opinion for publishing a security framework building block as an
RFC.  Its not as if the working group is going to come back and revise
the RFC once it is deployed.

Sincerely,

Jeffrey Altman



_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Greg Hudson
On 04/09/2015 09:54 PM, Jeffrey Altman wrote:
> I am glad to hear this.  Are there 3961 implementations available for
> public review?

My Python implementation is at:

  https://github.com/greghudson/pyk5

in crypto.py.  No stability guarantees for that repository, though.

I should note that my implementation assumes the default cipher state,
as do all of the test vectors in the draft.  (That's true of test
vectors for all past enctypes, I'm pretty certain.)

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Weijun Wang
In reply to this post by Benjamin Kaduk-2
I also verified the test vectors with Java:

https://gist.github.com/wangweij/49d98745a461f12c1f54

Thanks
Weijun

On 4/10/2015 6:26 AM, Benjamin Kaduk wrote:
> Hi Jeffrey,
>
> On Thu, 9 Apr 2015, Jeffrey Altman wrote:
>
>>
>> It would also be my preference that there be two interoperable
>> implementations before the working group approves the document.
>

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Luke Howard
In reply to this post by Greg Hudson

> On 10 Apr 2015, at 10:11 am, Greg Hudson <[hidden email]> wrote:
>
> * If the goal is to meet a checklist of Suite B requirements, using
> SHA-384 over SHA-256 internally might be necessary, but it really is
> just a meaningless checklist tick.  Moreover, the small integrity tag
> and checksum lengths could mean that the draft doesn't actually satisfy
> Suite B--I can't speak confidently either way on that point.
>
> * If the goal is to achieve some real security strength, using truncated
> SHA-384 is not an improvement over using truncated SHA-256.

I am not a cryptographer but Greg’s arguments make sense to me. Why not always truncate the hash to 256 bits when using 256-bit AES keys?

— Luke
_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Viktor Dukhovni
In reply to this post by Greg Hudson
On Thu, Apr 09, 2015 at 08:11:50PM -0400, Greg Hudson wrote:

> > In general, though, it's designed to make sense - you can't use SHA-256
> > to get a 192 bit key because a SHA-256 output has at most 128 bits of
> > security no matter how you slice it.
>
> I think it very much does matter how you slice it.  For key derivation
> using an HMAC, collision resistance is not required, so it is entirely
> reasonable to use SHA-256 to generate a 192-bit key.  In fact, the key
> derivation function used in this draft (from SP 800-108 section 5.1) can
> work securely even if more keying material is required than the HMAC
> output size.

Yes.  A n-bit HMAC used as a key-derivation PRF is sound for deriving
n-bit keys.  The n/2 collision resistance is not in scope.  Combine
your nonces with the raw DH secret and key-purpose-specific salt,
and away you go.

--
        Viktor.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

D.Rogers
In reply to this post by Luke Howard
Hi Luke,
 
as I understand it truncating introduces potential predicablities and therefore weeknesses.
Here the argument is that truncating from a 384 set to 196, is no more secure than truncating from 256 to 196.
Starting from a larger set and truncating to the same end result does improve security, it may reduce it.
As would truncating 256 to 256, could be less secure than using straight 256, but it would be interesting to know if anyone has examined that.
SHA-256 of the SHA-2 family is a significant improvement over its predecessor SHA-1. So, where the ouput size has to be limited, using anything more than 256 is not necessary.
In terms of performance though, SHA-384 computes slightly faster than SHA-256.
 
Dean
Gesendet: Mittwoch, 15. April 2015 um 06:59 Uhr
Von: "Luke Howard" <[hidden email]>
An: "Greg Hudson" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>
Betreff: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

> On 10 Apr 2015, at 10:11 am, Greg Hudson <[hidden email]> wrote:
>
> * If the goal is to meet a checklist of Suite B requirements, using
> SHA-384 over SHA-256 internally might be necessary, but it really is
> just a meaningless checklist tick. Moreover, the small integrity tag
> and checksum lengths could mean that the draft doesn't actually satisfy
> Suite B--I can't speak confidently either way on that point.
>
> * If the goal is to achieve some real security strength, using truncated
> SHA-384 is not an improvement over using truncated SHA-256.

I am not a cryptographer but Greg’s arguments make sense to me. Why not always truncate the hash to 256 bits when using 256-bit AES keys?

— Luke
_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Luke Howard

On 15 Apr 2015, at 7:54 pm, [hidden email] wrote:

Starting from a larger set and truncating to the same end result does improve security, it may reduce it.

My understanding is that as long as the hash function has strong diffusion this is not a problem. The different SHA-2 variants are all truncated versions of SHA-512 (with different initial values). Also, not relevant here (because HMAC is used) but truncating hashes can actually improve security by avoiding length extension attacks.

Feel free to correct me as I’m not a cryptographer, I don’t even play one on TV… :)

— Luke

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Viktor Dukhovni
On Thu, Apr 16, 2015 at 01:13:26AM +1000, Luke Howard wrote:

> My understanding is that as long as the hash function has strong
> diffusion this is not a problem. The different SHA-2 variants are
> all truncated versions of SHA-512 (with different initial values).

This is not the case.  There are algorithms SHA2-512 and SHA2-256
(either smaller internal state, fewer rounds or both).  SHA2-384
is a truncated SHA2-512 (with different initialization).  SHA2-224
is a truncated SHA2-256 (with different initialization).

--
        Viktor.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

D.Rogers
In reply to this post by Luke Howard
Hi Luke,
 
quite right, i should have sensed a trap when you wrote you are "not a crytographer" :-)
 
I would not presume to correct anyone, just that this a big topic, and attempting to generalise always leaves room for further comment.
The SHA-2 family has six members, falling into two architectural groups, meaning that SHA 512 truncated to 256 can be thought of as a version of SHA-512, this cannot be said for SHA-256.
But as you say, this may be going off at a tangent as HMAC is not suseptible to length extension attacks anway.
 
Dean
Gesendet: Mittwoch, 15. April 2015 um 17:13 Uhr
Von: "Luke Howard" <[hidden email]>
An: [hidden email]
Cc: "Greg Hudson" <[hidden email]>, "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>
Betreff: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06
 
On 15 Apr 2015, at 7:54 pm, D.Rogers@... wrote:
 
Starting from a larger set and truncating to the same end result does improve security, it may reduce it.
 
My understanding is that as long as the hash function has strong diffusion this is not a problem. The different SHA-2 variants are all truncated versions of SHA-512 (with different initial values). Also, not relevant here (because HMAC is used) but truncating hashes can actually improve security by avoiding length extension attacks.
 
Feel free to correct me as I’m not a cryptographer, I don’t even play one on TV… :)
 
— Luke

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Nico Williams
In reply to this post by Greg Hudson
On Thu, Apr 02, 2015 at 12:20:05PM -0400, Greg Hudson wrote:
> * For the 192-bit security level, why use SHA-384 and truncate to 192
> bits?  Why not use SHA-256 and truncate to 192 bits?

I've no objection to the construction

    MAC(k, x) = trunc(HMAC(k,H), output_size(H)/2.

It's simple and obvious.

> * Why use a 192-bit HMAC key for Ki and Kc but not for Kp?

This I dont' understand.  The HMAC key should be the same size as the
cipher key.

I suspect this is an editing error.

There should be two or three enctypes:

 - aes128-cts-hmac-sha256-128

   AES with 128-bit keys, and
     MAC = trunc-128(HMAC-SHA256) with 128-bit HMAC keys

 - aes192-cts-hmac-sha384-192

   AES with 192-bit keys, and
     MAC = trunc-192(HMAC-SHA384) with 192-bit HMAC keys

 - aes256-cts-hmac-sha512-256

   AES with 256-bit keys, and
     MAC = trunc-256(HMAC-SHA512) with 256-bit HMAC keys

Generally, the security level of the components should match the overall
security level of the enctype.

I suppose an aes256-cts-hmac-sha384-192 would be OK, but only if we
reject AES-192 and such an enctype is noticeably faster than
aes256-cts-hmac-sha512-256.

> * Why use 128/256-bit PRF output lengths?  Why not just output the full
> hash?  It can't be for consistency with RFC 3962, as
> aes256-cts-hmac-sha1-96 has a 128-bit PRF output length.  It can't be
> out of some desire to consistently truncate SHA-2 results in half, or we
> would have 128/192-bit output lengths.

Eh?  The KDF is a truncation of the PRF.  The PRF is not truncated.

>From the draft:

   When the encryption type is aes128-cts-hmac-sha256-128, the output
   key length k is 128 bits for all applications of KDF-HMAC-SHA2(key,
   constant) which is computed as follows:

     K1 = HMAC-SHA-256(key, 00 00 00 01 | constant | 00 | 00 00 00 80)
     KDF-HMAC-SHA2(key, constant) = random-to-key(k-truncate(K1))
              ^^^^

The "SHA2" there must be a cut-n-paste error, otherwise it looks right
to me.

(RFC3962 does not define a PRF, just a KDF.)

Nico
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Nico Williams
In reply to this post by Greg Hudson
On Wed, Apr 08, 2015 at 06:48:36PM -0400, Greg Hudson wrote:
> I do not understand what assumptions would yield a security level of 128
> bits from SHA-256 truncated to 192 bits, and a security level of 192
> bits from SHA-384 truncated to 192 bits.  If there is a concern about
> birthday attacks on the integrity tag, then we can't get away with
> truncating at all; we would need to send a 256-bit tag for the 128-bit
> security level, and a 384-bit tag for the 192-bit security level.

I expect HMAC-SHA-256 with 128-bit HMAC keys provides 128-bit security
against forgeries (which is all we're after if we encrypt-then-MAC) no
matter length the result is truncated to as long as that length is 128
or more bits.

The reason is: the attacker has a 128-bit key search space, and any
forgery attack that requires more work than a key brute-force attack is
not worth it, so using a MAC length of more than 128 bits is not likely
to be useful (it will cause defenders to waste bandwidth) unless there
are forgery attacks at least a few bits better than the MAC length, for
HMAC with any given MAC length.

The critical thing here is the size of the HMAC key.

Perhaps HMAC-SHA256-192 with 192-bit keys could also provide 192-bit
security against distinguishing attacks and forgeries.  But if there are
such attacks depending only attacking the hash against collisions then
HMAC-SHA256-192 can't provide 192-bit security against forgeries -- it
seems prudent to assume such attacks.

ISTM prudent to use HMAC with keys of size matching the advertised
collision resistance of the base hash function and then truncate the
result to that same size.

So, HMAC-SHA256-128 w/ 128-bit keys is OK, but HMAC-SHA256-192 is not
(even if the keys are 192-bit).

Nico
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
123