[kitten] shepherd review of draft-aes-cts-hmac-sha2-09

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

[kitten] shepherd review of draft-aes-cts-hmac-sha2-09

Benjamin Kaduk-2
Hi Michael et al,

As I was preparing the shepherd writeup for this document, I noticed some
things that do not block the progression of the document but do require
changes, and one item that may require further WG input.  Can you prepare
a new version with the changes mentioned below?

The one item which would potentially affect the actual protocol: at the
end of Section 5, the pseudo-random function seems to be using a SP800-108
KDF but omits the zero byte between label and context.  I think it would
be better to have the zero byte -- do you remember whether there was a
reason to omit it?  (Adding the zero byte would require re-rolling some
test vectors, to be clear.)

Additionally, all document authors will need to confirm compliance with
BCPs 78 and 79 for this document, namely that there are no intellectual
property concerns with the document that are not already disclosed.

Please add a normative reference to RFC 2104 for HMAC, first mentioned at
the end of Section 1.

In Section 3, it might aid clarity to mention that the 0x00000001 input to
HMAC() is the 'i' parameter from SP800-108 [indicating that this is the
first block of output, even though it is the only block of output as
well].

In Section 4, it might be worth re-mentioning "where PBKDF2 is the
function of that name from RFC 2898" after the algorithm block, since most
everything else used there also gets clarified.  (It is already cited at
the beginning of the section, in the overview paragraph.)

The document should be consistent about using "cipher state" as one word
or two (RFC 3961 prefers the two-word form).  It also makes a rather
sudden appearance at the beginning of Section 5 with no explanatory
introduction; it might help the reader to instead start with "The RFC 3961
cipher state that maintains cryptographic state across different
encryption operations using the same key is used as the formal
initialization vector [...]" On the next page, "cipherstate" is defined as
"a 128-bit initialization vector derived from the ciphertext", which is
potentially misleading, since it can't be both used as the IV for and
derived from the same ciphertext!  Probably it's better to say "derived
from a previous (if any) ciphertext using the same encryption key, as
specified below".

Still in Section 5, in the definition of the encryption function (well,
computing the cipherstate, really), I'm of two minds whether it's worth
mentioning that the case of L < 128 is impossible because of the 128-bit
confounder.

In the decryption function, can you add a note to the right of "(C, H) =
ciphertext" that "[H is the last h bits of the ciphertext]"?

In the pseudo-random function, please replace "base-key" with "input-key",
since the key input to the PRF is not expected to be a kerberos protocol
long-term base key.

In Section 6, the "associated cryptosystem"s are supposed to be
"AES-128-CTS" or "AES-256-CTS", but those strings do not appear elsewhere
in the document.  While the meaning is pretty clear, it's probably better
to just say "aes128-cts-hmac-sha256-128 or aes256-cts-hmac-sha384-192 as
appropriate".  This does duplicate the preceding text, but we do want to
explicitly list the "associated encryption algorithm" as listed in the
Checksum Algorithm Profile of Section 4 of RFC 3961.

In Section 8.1, the acronym "TGT" is used, the only instance in the
document.  It's also potentially misleading, since ticket-granting tickets
are generally objects that are issued to client principals by the AS.
I'd go with "Cross-realm krbtgt keys" instead.

The test vectors for key derivation have a parenthetical "constant =
0x...", but the term "constant" does not appear elsewhere in the document.
The hex values are the label input for the HMAC, so we should call them
that.


Thanks,

Ben

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

Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09

Luke Howard
> The one item which would potentially affect the actual protocol: at the
> end of Section 5, the pseudo-random function seems to be using a SP800-108
> KDF but omits the zero byte between label and context.  I think it would
> be better to have the zero byte -- do you remember whether there was a
> reason to omit it?  (Adding the zero byte would require re-rolling some
> test vectors, to be clear.)

The PRF is defined in terms of KDF-HMAC-SHA2() which implicitly inserts the zero byte when invoking HMAC-SHA-256(), e.g.:

        PRF = KDF-HMAC-SHA2(base-key, "prf" | octet-string, 256)
        = k-truncate(HMAC-SHA-256(key, 0x00000001 | "prf" | octet-string | 0x00 | 256))

if I’m not mistaken? Pretty sure our implementation passed the test vectors.

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

Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09

Benjamin Kaduk-2
On Mon, 27 Jun 2016, Luke Howard wrote:

> > The one item which would potentially affect the actual protocol: at the
> > end of Section 5, the pseudo-random function seems to be using a SP800-108
> > KDF but omits the zero byte between label and context.  I think it would
> > be better to have the zero byte -- do you remember whether there was a
> > reason to omit it?  (Adding the zero byte would require re-rolling some
> > test vectors, to be clear.)
>
> The PRF is defined in terms of KDF-HMAC-SHA2() which implicitly inserts
> the zero byte when invoking HMAC-SHA-256(), e.g.:
>
> PRF = KDF-HMAC-SHA2(base-key, "prf" | octet-string, 256)
> = k-truncate(HMAC-SHA-256(key, 0x00000001 | "prf" | octet-string | 0x00 | 256))
>
> if I’m not mistaken? Pretty sure our implementation passed the test vectors.
I think that SP800-108 would have it be

[counter] | [label] | 0x00 | [context] | [output-length]

with the NUL between label and context, not between context and
output-length.

Its definitions are:

%%%%%%%%%%%

3) Label
 A string that identifies the purpose for the derived keying material,
which is encoded as a binary string. The encoding method for the Label is
defined in a larger context, for example, in the protocol that uses a KDF.

4) Context
 A binary string containing the information related to the derived keying
material. It may include identities of parties who are deriving and/or
using the derived keying material and, optionally, a nonce known by the
parties who derive the keys.

%%%%%%%%%%%

For the PRF, the octet-string input is pretty clearly something
specifically known to the parties who derive the keys, which seems like a
context.

For the use of KDF-HMAC-SHA2 elsewhere in the document, e.g. for deriving
Kc, Ke, and Ki, the line between label and context is less clear, since we
invoke it as (e.g.)

Kc = KDF-HMAC-SHA2(base-key, usage | 0x99, 128)

and the 0x99 is defined by the protocol and would plausibly still be part
of the label.

As I recall, the PRF was something of a late addition, and if the
KDF-HMAC-SHA2 construct was defined originally for password key derivation
and deriving Kc/Ke/Ki, that would explain why there was not thought about
having a proper SP800-108 context that would also need separation.
(SP800-108 has the context as optional ("One or more of these fixed input
data fields may be omitted unless required for certain purposes as
discussed in Section 7.5 and Section 7.6."), which is fine and would apply
for the non-PRF cases here.)

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

Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09

Michael Jenkins
In reply to this post by Benjamin Kaduk-2
Ben,

we'll get started on these.

On Sun, Jun 26, 2016 at 11:03 PM, Benjamin Kaduk <[hidden email]> wrote:
Hi Michael et al,

As I was preparing the shepherd writeup for this document, I noticed some
things that do not block the progression of the document but do require
changes, and one item that may require further WG input.  Can you prepare
a new version with the changes mentioned below?

The one item which would potentially affect the actual protocol: at the
end of Section 5, the pseudo-random function seems to be using a SP800-108
KDF but omits the zero byte between label and context.  I think it would
be better to have the zero byte -- do you remember whether there was a
reason to omit it?  (Adding the zero byte would require re-rolling some
test vectors, to be clear.)

Additionally, all document authors will need to confirm compliance with
BCPs 78 and 79 for this document, namely that there are no intellectual
property concerns with the document that are not already disclosed.

Please add a normative reference to RFC 2104 for HMAC, first mentioned at
the end of Section 1.

In Section 3, it might aid clarity to mention that the 0x00000001 input to
HMAC() is the 'i' parameter from SP800-108 [indicating that this is the
first block of output, even though it is the only block of output as
well].

In Section 4, it might be worth re-mentioning "where PBKDF2 is the
function of that name from RFC 2898" after the algorithm block, since most
everything else used there also gets clarified.  (It is already cited at
the beginning of the section, in the overview paragraph.)

The document should be consistent about using "cipher state" as one word
or two (RFC 3961 prefers the two-word form).  It also makes a rather
sudden appearance at the beginning of Section 5 with no explanatory
introduction; it might help the reader to instead start with "The RFC 3961
cipher state that maintains cryptographic state across different
encryption operations using the same key is used as the formal
initialization vector [...]" On the next page, "cipherstate" is defined as
"a 128-bit initialization vector derived from the ciphertext", which is
potentially misleading, since it can't be both used as the IV for and
derived from the same ciphertext!  Probably it's better to say "derived
from a previous (if any) ciphertext using the same encryption key, as
specified below".

Still in Section 5, in the definition of the encryption function (well,
computing the cipherstate, really), I'm of two minds whether it's worth
mentioning that the case of L < 128 is impossible because of the 128-bit
confounder.

In the decryption function, can you add a note to the right of "(C, H) =
ciphertext" that "[H is the last h bits of the ciphertext]"?

In the pseudo-random function, please replace "base-key" with "input-key",
since the key input to the PRF is not expected to be a kerberos protocol
long-term base key.

In Section 6, the "associated cryptosystem"s are supposed to be
"AES-128-CTS" or "AES-256-CTS", but those strings do not appear elsewhere
in the document.  While the meaning is pretty clear, it's probably better
to just say "aes128-cts-hmac-sha256-128 or aes256-cts-hmac-sha384-192 as
appropriate".  This does duplicate the preceding text, but we do want to
explicitly list the "associated encryption algorithm" as listed in the
Checksum Algorithm Profile of Section 4 of RFC 3961.

In Section 8.1, the acronym "TGT" is used, the only instance in the
document.  It's also potentially misleading, since ticket-granting tickets
are generally objects that are issued to client principals by the AS.
I'd go with "Cross-realm krbtgt keys" instead.

The test vectors for key derivation have a parenthetical "constant =
0x...", but the term "constant" does not appear elsewhere in the document.
The hex values are the label input for the HMAC, so we should call them
that.


Thanks,

Ben



--
Mike Jenkins
[hidden email] - if you want me to read it only at my desk
[hidden email] - to read everywhere
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] shepherd review of draft-aes-cts-hmac-sha2-09

Luke Howard
In reply to this post by Benjamin Kaduk-2
Our implementation assumes that the context is always empty and only the label is used. But it’s trivial to change if you update the draft to use the context for the PRF.

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

Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09

Benjamin Kaduk-2
On Mon, 27 Jun 2016, Luke Howard wrote:

> Our implementation assumes that the context is always empty and only the
> label is used. But it’s trivial to change if you update the draft to use
> the context for the PRF.

Yeah, I don't expect much trouble for implementations if this does change.
A big reason I'm inclined to treat the PRF input as context and not label
is that in some scenarios it can be attacker-controlled, so having the
forced separation from the prf prefix could be useful.

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

Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09

Benjamin Kaduk-2
In reply to this post by Michael Jenkins
Thanks, Michael.

If the WG does want to treat the PRF octet-string input as a SP800-108
context and use a zero-byte separator, it seems like the "quick-and-dirty"
patch would be to just stick one in after "prf" and then there would be
another (somewhat superfluous) one appended after the octet-string by
KDF-HMAC-SHA2.  That might be easier than essentially inlining the
definitino of KDF-HMAC-SHA2 for just the PRF calculation.

-Ben

On Mon, 27 Jun 2016, Michael Jenkins wrote:

> Ben,
>
> we'll get started on these.
>
> On Sun, Jun 26, 2016 at 11:03 PM, Benjamin Kaduk <[hidden email]> wrote:
>
> > Hi Michael et al,
> >
> > As I was preparing the shepherd writeup for this document, I noticed some
> > things that do not block the progression of the document but do require
> > changes, and one item that may require further WG input.  Can you prepare
> > a new version with the changes mentioned below?
> >
> > The one item which would potentially affect the actual protocol: at the
> > end of Section 5, the pseudo-random function seems to be using a SP800-108
> > KDF but omits the zero byte between label and context.  I think it would
> > be better to have the zero byte -- do you remember whether there was a
> > reason to omit it?  (Adding the zero byte would require re-rolling some
> > test vectors, to be clear.)
> >
> > Additionally, all document authors will need to confirm compliance with
> > BCPs 78 and 79 for this document, namely that there are no intellectual
> > property concerns with the document that are not already disclosed.
> >
> > Please add a normative reference to RFC 2104 for HMAC, first mentioned at
> > the end of Section 1.
> >
> > In Section 3, it might aid clarity to mention that the 0x00000001 input to
> > HMAC() is the 'i' parameter from SP800-108 [indicating that this is the
> > first block of output, even though it is the only block of output as
> > well].
> >
> > In Section 4, it might be worth re-mentioning "where PBKDF2 is the
> > function of that name from RFC 2898" after the algorithm block, since most
> > everything else used there also gets clarified.  (It is already cited at
> > the beginning of the section, in the overview paragraph.)
> >
> > The document should be consistent about using "cipher state" as one word
> > or two (RFC 3961 prefers the two-word form).  It also makes a rather
> > sudden appearance at the beginning of Section 5 with no explanatory
> > introduction; it might help the reader to instead start with "The RFC 3961
> > cipher state that maintains cryptographic state across different
> > encryption operations using the same key is used as the formal
> > initialization vector [...]" On the next page, "cipherstate" is defined as
> > "a 128-bit initialization vector derived from the ciphertext", which is
> > potentially misleading, since it can't be both used as the IV for and
> > derived from the same ciphertext!  Probably it's better to say "derived
> > from a previous (if any) ciphertext using the same encryption key, as
> > specified below".
> >
> > Still in Section 5, in the definition of the encryption function (well,
> > computing the cipherstate, really), I'm of two minds whether it's worth
> > mentioning that the case of L < 128 is impossible because of the 128-bit
> > confounder.
> >
> > In the decryption function, can you add a note to the right of "(C, H) =
> > ciphertext" that "[H is the last h bits of the ciphertext]"?
> >
> > In the pseudo-random function, please replace "base-key" with "input-key",
> > since the key input to the PRF is not expected to be a kerberos protocol
> > long-term base key.
> >
> > In Section 6, the "associated cryptosystem"s are supposed to be
> > "AES-128-CTS" or "AES-256-CTS", but those strings do not appear elsewhere
> > in the document.  While the meaning is pretty clear, it's probably better
> > to just say "aes128-cts-hmac-sha256-128 or aes256-cts-hmac-sha384-192 as
> > appropriate".  This does duplicate the preceding text, but we do want to
> > explicitly list the "associated encryption algorithm" as listed in the
> > Checksum Algorithm Profile of Section 4 of RFC 3961.
> >
> > In Section 8.1, the acronym "TGT" is used, the only instance in the
> > document.  It's also potentially misleading, since ticket-granting tickets
> > are generally objects that are issued to client principals by the AS.
> > I'd go with "Cross-realm krbtgt keys" instead.
> >
> > The test vectors for key derivation have a parenthetical "constant =
> > 0x...", but the term "constant" does not appear elsewhere in the document.
> > The hex values are the label input for the HMAC, so we should call them
> > that.
> >
> >
> > Thanks,
> >
> > Ben
> >
>
>
>
> --
> Mike Jenkins
> [hidden email] - if you want me to read it only at my desk
> [hidden email] - to read everywhere
> 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] shepherd review of draft-aes-cts-hmac-sha2-09

Luke Howard
I reckon let's do it "properly" even if at the expense of redundant text.

Sent from my iPhone

> On 28 Jun 2016, at 11:49, Benjamin Kaduk <[hidden email]> wrote:
>
> Thanks, Michael.
>
> If the WG does want to treat the PRF octet-string input as a SP800-108
> context and use a zero-byte separator, it seems like the "quick-and-dirty"
> patch would be to just stick one in after "prf" and then there would be
> another (somewhat superfluous) one appended after the octet-string by
> KDF-HMAC-SHA2.  That might be easier than essentially inlining the
> definitino of KDF-HMAC-SHA2 for just the PRF calculation.
>
> -Ben
>
>> On Mon, 27 Jun 2016, Michael Jenkins wrote:
>>
>> Ben,
>>
>> we'll get started on these.
>>
>>> On Sun, Jun 26, 2016 at 11:03 PM, Benjamin Kaduk <[hidden email]> wrote:
>>>
>>> Hi Michael et al,
>>>
>>> As I was preparing the shepherd writeup for this document, I noticed some
>>> things that do not block the progression of the document but do require
>>> changes, and one item that may require further WG input.  Can you prepare
>>> a new version with the changes mentioned below?
>>>
>>> The one item which would potentially affect the actual protocol: at the
>>> end of Section 5, the pseudo-random function seems to be using a SP800-108
>>> KDF but omits the zero byte between label and context.  I think it would
>>> be better to have the zero byte -- do you remember whether there was a
>>> reason to omit it?  (Adding the zero byte would require re-rolling some
>>> test vectors, to be clear.)
>>>
>>> Additionally, all document authors will need to confirm compliance with
>>> BCPs 78 and 79 for this document, namely that there are no intellectual
>>> property concerns with the document that are not already disclosed.
>>>
>>> Please add a normative reference to RFC 2104 for HMAC, first mentioned at
>>> the end of Section 1.
>>>
>>> In Section 3, it might aid clarity to mention that the 0x00000001 input to
>>> HMAC() is the 'i' parameter from SP800-108 [indicating that this is the
>>> first block of output, even though it is the only block of output as
>>> well].
>>>
>>> In Section 4, it might be worth re-mentioning "where PBKDF2 is the
>>> function of that name from RFC 2898" after the algorithm block, since most
>>> everything else used there also gets clarified.  (It is already cited at
>>> the beginning of the section, in the overview paragraph.)
>>>
>>> The document should be consistent about using "cipher state" as one word
>>> or two (RFC 3961 prefers the two-word form).  It also makes a rather
>>> sudden appearance at the beginning of Section 5 with no explanatory
>>> introduction; it might help the reader to instead start with "The RFC 3961
>>> cipher state that maintains cryptographic state across different
>>> encryption operations using the same key is used as the formal
>>> initialization vector [...]" On the next page, "cipherstate" is defined as
>>> "a 128-bit initialization vector derived from the ciphertext", which is
>>> potentially misleading, since it can't be both used as the IV for and
>>> derived from the same ciphertext!  Probably it's better to say "derived
>>> from a previous (if any) ciphertext using the same encryption key, as
>>> specified below".
>>>
>>> Still in Section 5, in the definition of the encryption function (well,
>>> computing the cipherstate, really), I'm of two minds whether it's worth
>>> mentioning that the case of L < 128 is impossible because of the 128-bit
>>> confounder.
>>>
>>> In the decryption function, can you add a note to the right of "(C, H) =
>>> ciphertext" that "[H is the last h bits of the ciphertext]"?
>>>
>>> In the pseudo-random function, please replace "base-key" with "input-key",
>>> since the key input to the PRF is not expected to be a kerberos protocol
>>> long-term base key.
>>>
>>> In Section 6, the "associated cryptosystem"s are supposed to be
>>> "AES-128-CTS" or "AES-256-CTS", but those strings do not appear elsewhere
>>> in the document.  While the meaning is pretty clear, it's probably better
>>> to just say "aes128-cts-hmac-sha256-128 or aes256-cts-hmac-sha384-192 as
>>> appropriate".  This does duplicate the preceding text, but we do want to
>>> explicitly list the "associated encryption algorithm" as listed in the
>>> Checksum Algorithm Profile of Section 4 of RFC 3961.
>>>
>>> In Section 8.1, the acronym "TGT" is used, the only instance in the
>>> document.  It's also potentially misleading, since ticket-granting tickets
>>> are generally objects that are issued to client principals by the AS.
>>> I'd go with "Cross-realm krbtgt keys" instead.
>>>
>>> The test vectors for key derivation have a parenthetical "constant =
>>> 0x...", but the term "constant" does not appear elsewhere in the document.
>>> The hex values are the label input for the HMAC, so we should call them
>>> that.
>>>
>>>
>>> Thanks,
>>>
>>> Ben
>>
>>
>>
>> --
>> Mike Jenkins
>> [hidden email] - if you want me to read it only at my desk
>> [hidden email] - to read everywhere
>> 443-634-3951
>
> _______________________________________________
> 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] shepherd review of draft-aes-cts-hmac-sha2-09

Jeffrey Altman-2
+1

On 6/28/2016 3:21 AM, Luke Howard wrote:

> I reckon let's do it "properly" even if at the expense of redundant text.
>
> Sent from my iPhone
>
>> On 28 Jun 2016, at 11:49, Benjamin Kaduk <[hidden email]> wrote:
>>
>> Thanks, Michael.
>>
>> If the WG does want to treat the PRF octet-string input as a SP800-108
>> context and use a zero-byte separator, it seems like the "quick-and-dirty"
>> patch would be to just stick one in after "prf" and then there would be
>> another (somewhat superfluous) one appended after the octet-string by
>> KDF-HMAC-SHA2.  That might be easier than essentially inlining the
>> definitino of KDF-HMAC-SHA2 for just the PRF calculation.
>>
>> -Ben
>>
>>> On Mon, 27 Jun 2016, Michael Jenkins wrote:
>>>
>>> Ben,
>>>
>>> we'll get started on these.
>>>
>>>> On Sun, Jun 26, 2016 at 11:03 PM, Benjamin Kaduk <[hidden email]> wrote:
>>>>
>>>> Hi Michael et al,
>>>>
>>>> As I was preparing the shepherd writeup for this document, I noticed some
>>>> things that do not block the progression of the document but do require
>>>> changes, and one item that may require further WG input.  Can you prepare
>>>> a new version with the changes mentioned below?
>>>>
>>>> The one item which would potentially affect the actual protocol: at the
>>>> end of Section 5, the pseudo-random function seems to be using a SP800-108
>>>> KDF but omits the zero byte between label and context.  I think it would
>>>> be better to have the zero byte -- do you remember whether there was a
>>>> reason to omit it?  (Adding the zero byte would require re-rolling some
>>>> test vectors, to be clear.)
>>>>
>>>> Additionally, all document authors will need to confirm compliance with
>>>> BCPs 78 and 79 for this document, namely that there are no intellectual
>>>> property concerns with the document that are not already disclosed.
>>>>
>>>> Please add a normative reference to RFC 2104 for HMAC, first mentioned at
>>>> the end of Section 1.
>>>>
>>>> In Section 3, it might aid clarity to mention that the 0x00000001 input to
>>>> HMAC() is the 'i' parameter from SP800-108 [indicating that this is the
>>>> first block of output, even though it is the only block of output as
>>>> well].
>>>>
>>>> In Section 4, it might be worth re-mentioning "where PBKDF2 is the
>>>> function of that name from RFC 2898" after the algorithm block, since most
>>>> everything else used there also gets clarified.  (It is already cited at
>>>> the beginning of the section, in the overview paragraph.)
>>>>
>>>> The document should be consistent about using "cipher state" as one word
>>>> or two (RFC 3961 prefers the two-word form).  It also makes a rather
>>>> sudden appearance at the beginning of Section 5 with no explanatory
>>>> introduction; it might help the reader to instead start with "The RFC 3961
>>>> cipher state that maintains cryptographic state across different
>>>> encryption operations using the same key is used as the formal
>>>> initialization vector [...]" On the next page, "cipherstate" is defined as
>>>> "a 128-bit initialization vector derived from the ciphertext", which is
>>>> potentially misleading, since it can't be both used as the IV for and
>>>> derived from the same ciphertext!  Probably it's better to say "derived
>>>> from a previous (if any) ciphertext using the same encryption key, as
>>>> specified below".
>>>>
>>>> Still in Section 5, in the definition of the encryption function (well,
>>>> computing the cipherstate, really), I'm of two minds whether it's worth
>>>> mentioning that the case of L < 128 is impossible because of the 128-bit
>>>> confounder.
>>>>
>>>> In the decryption function, can you add a note to the right of "(C, H) =
>>>> ciphertext" that "[H is the last h bits of the ciphertext]"?
>>>>
>>>> In the pseudo-random function, please replace "base-key" with "input-key",
>>>> since the key input to the PRF is not expected to be a kerberos protocol
>>>> long-term base key.
>>>>
>>>> In Section 6, the "associated cryptosystem"s are supposed to be
>>>> "AES-128-CTS" or "AES-256-CTS", but those strings do not appear elsewhere
>>>> in the document.  While the meaning is pretty clear, it's probably better
>>>> to just say "aes128-cts-hmac-sha256-128 or aes256-cts-hmac-sha384-192 as
>>>> appropriate".  This does duplicate the preceding text, but we do want to
>>>> explicitly list the "associated encryption algorithm" as listed in the
>>>> Checksum Algorithm Profile of Section 4 of RFC 3961.
>>>>
>>>> In Section 8.1, the acronym "TGT" is used, the only instance in the
>>>> document.  It's also potentially misleading, since ticket-granting tickets
>>>> are generally objects that are issued to client principals by the AS.
>>>> I'd go with "Cross-realm krbtgt keys" instead.
>>>>
>>>> The test vectors for key derivation have a parenthetical "constant =
>>>> 0x...", but the term "constant" does not appear elsewhere in the document.
>>>> The hex values are the label input for the HMAC, so we should call them
>>>> that.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Ben
>>>
>>>
>>>
>>> --
>>> Mike Jenkins
>>> [hidden email] - if you want me to read it only at my desk
>>> [hidden email] - to read everywhere
>>> 443-634-3951
>>
>> _______________________________________________
>> Kitten mailing list
>> [hidden email]
>> https://www.ietf.org/mailman/listinfo/kitten
>
> _______________________________________________
> Kitten mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten
>

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

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

Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09

Stephen Farrell

Hiya,

I nearly just started the IETF last call for this, but then
noticed these emails;-) Please ignore any status change
emails you may have seen.

Chairs - please tell me when you want me to start IETF LC.

I did my AD review of it, and modulo this discussion being
resolved, I think it's ready to go ahead.

Thanks,
S.

On 28/06/16 12:58, Jeffrey Altman wrote:

> +1
>
> On 6/28/2016 3:21 AM, Luke Howard wrote:
>> I reckon let's do it "properly" even if at the expense of redundant text.
>>
>> Sent from my iPhone
>>
>>> On 28 Jun 2016, at 11:49, Benjamin Kaduk <[hidden email]> wrote:
>>>
>>> Thanks, Michael.
>>>
>>> If the WG does want to treat the PRF octet-string input as a SP800-108
>>> context and use a zero-byte separator, it seems like the "quick-and-dirty"
>>> patch would be to just stick one in after "prf" and then there would be
>>> another (somewhat superfluous) one appended after the octet-string by
>>> KDF-HMAC-SHA2.  That might be easier than essentially inlining the
>>> definitino of KDF-HMAC-SHA2 for just the PRF calculation.
>>>
>>> -Ben
>>>
>>>> On Mon, 27 Jun 2016, Michael Jenkins wrote:
>>>>
>>>> Ben,
>>>>
>>>> we'll get started on these.
>>>>
>>>>> On Sun, Jun 26, 2016 at 11:03 PM, Benjamin Kaduk <[hidden email]> wrote:
>>>>>
>>>>> Hi Michael et al,
>>>>>
>>>>> As I was preparing the shepherd writeup for this document, I noticed some
>>>>> things that do not block the progression of the document but do require
>>>>> changes, and one item that may require further WG input.  Can you prepare
>>>>> a new version with the changes mentioned below?
>>>>>
>>>>> The one item which would potentially affect the actual protocol: at the
>>>>> end of Section 5, the pseudo-random function seems to be using a SP800-108
>>>>> KDF but omits the zero byte between label and context.  I think it would
>>>>> be better to have the zero byte -- do you remember whether there was a
>>>>> reason to omit it?  (Adding the zero byte would require re-rolling some
>>>>> test vectors, to be clear.)
>>>>>
>>>>> Additionally, all document authors will need to confirm compliance with
>>>>> BCPs 78 and 79 for this document, namely that there are no intellectual
>>>>> property concerns with the document that are not already disclosed.
>>>>>
>>>>> Please add a normative reference to RFC 2104 for HMAC, first mentioned at
>>>>> the end of Section 1.
>>>>>
>>>>> In Section 3, it might aid clarity to mention that the 0x00000001 input to
>>>>> HMAC() is the 'i' parameter from SP800-108 [indicating that this is the
>>>>> first block of output, even though it is the only block of output as
>>>>> well].
>>>>>
>>>>> In Section 4, it might be worth re-mentioning "where PBKDF2 is the
>>>>> function of that name from RFC 2898" after the algorithm block, since most
>>>>> everything else used there also gets clarified.  (It is already cited at
>>>>> the beginning of the section, in the overview paragraph.)
>>>>>
>>>>> The document should be consistent about using "cipher state" as one word
>>>>> or two (RFC 3961 prefers the two-word form).  It also makes a rather
>>>>> sudden appearance at the beginning of Section 5 with no explanatory
>>>>> introduction; it might help the reader to instead start with "The RFC 3961
>>>>> cipher state that maintains cryptographic state across different
>>>>> encryption operations using the same key is used as the formal
>>>>> initialization vector [...]" On the next page, "cipherstate" is defined as
>>>>> "a 128-bit initialization vector derived from the ciphertext", which is
>>>>> potentially misleading, since it can't be both used as the IV for and
>>>>> derived from the same ciphertext!  Probably it's better to say "derived
>>>>> from a previous (if any) ciphertext using the same encryption key, as
>>>>> specified below".
>>>>>
>>>>> Still in Section 5, in the definition of the encryption function (well,
>>>>> computing the cipherstate, really), I'm of two minds whether it's worth
>>>>> mentioning that the case of L < 128 is impossible because of the 128-bit
>>>>> confounder.
>>>>>
>>>>> In the decryption function, can you add a note to the right of "(C, H) =
>>>>> ciphertext" that "[H is the last h bits of the ciphertext]"?
>>>>>
>>>>> In the pseudo-random function, please replace "base-key" with "input-key",
>>>>> since the key input to the PRF is not expected to be a kerberos protocol
>>>>> long-term base key.
>>>>>
>>>>> In Section 6, the "associated cryptosystem"s are supposed to be
>>>>> "AES-128-CTS" or "AES-256-CTS", but those strings do not appear elsewhere
>>>>> in the document.  While the meaning is pretty clear, it's probably better
>>>>> to just say "aes128-cts-hmac-sha256-128 or aes256-cts-hmac-sha384-192 as
>>>>> appropriate".  This does duplicate the preceding text, but we do want to
>>>>> explicitly list the "associated encryption algorithm" as listed in the
>>>>> Checksum Algorithm Profile of Section 4 of RFC 3961.
>>>>>
>>>>> In Section 8.1, the acronym "TGT" is used, the only instance in the
>>>>> document.  It's also potentially misleading, since ticket-granting tickets
>>>>> are generally objects that are issued to client principals by the AS.
>>>>> I'd go with "Cross-realm krbtgt keys" instead.
>>>>>
>>>>> The test vectors for key derivation have a parenthetical "constant =
>>>>> 0x...", but the term "constant" does not appear elsewhere in the document.
>>>>> The hex values are the label input for the HMAC, so we should call them
>>>>> that.
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ben
>>>>
>>>>
>>>>
>>>> --
>>>> Mike Jenkins
>>>> [hidden email] - if you want me to read it only at my desk
>>>> [hidden email] - to read everywhere
>>>> 443-634-3951
>>>
>>> _______________________________________________
>>> Kitten mailing list
>>> [hidden email]
>>> https://www.ietf.org/mailman/listinfo/kitten
>>
>> _______________________________________________
>> Kitten mailing list
>> [hidden email]
>> https://www.ietf.org/mailman/listinfo/kitten
>>
>
>
>
> _______________________________________________
> Kitten mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten
>

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

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

Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09

⌘ Matt Miller
Hello All,

Thanks to Mike for submitting the update so quickly.

It appears to me that -10 addresses all the concerns raised.
Are there any objections to moving forward with IETF Last Call
with this revision?

For convenience, the latest revision can be found here:
https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-10


Thanks,

- Kitten Chairs

> On Jul 3, 2016, at 03:57, Stephen Farrell <[hidden email]> wrote:
>
>
> Hiya,
>
> I nearly just started the IETF last call for this, but then
> noticed these emails;-) Please ignore any status change
> emails you may have seen.
>
> Chairs - please tell me when you want me to start IETF LC.
>
> I did my AD review of it, and modulo this discussion being
> resolved, I think it's ready to go ahead.
>
> Thanks,
> S.
>
> On 28/06/16 12:58, Jeffrey Altman wrote:
>> +1
>>
>> On 6/28/2016 3:21 AM, Luke Howard wrote:
>>> I reckon let's do it "properly" even if at the expense of redundant text.
>>>
>>> Sent from my iPhone
>>>
>>>> On 28 Jun 2016, at 11:49, Benjamin Kaduk <[hidden email]> wrote:
>>>>
>>>> Thanks, Michael.
>>>>
>>>> If the WG does want to treat the PRF octet-string input as a SP800-108
>>>> context and use a zero-byte separator, it seems like the "quick-and-dirty"
>>>> patch would be to just stick one in after "prf" and then there would be
>>>> another (somewhat superfluous) one appended after the octet-string by
>>>> KDF-HMAC-SHA2.  That might be easier than essentially inlining the
>>>> definitino of KDF-HMAC-SHA2 for just the PRF calculation.
>>>>
>>>> -Ben
>>>>
>>>>> On Mon, 27 Jun 2016, Michael Jenkins wrote:
>>>>>
>>>>> Ben,
>>>>>
>>>>> we'll get started on these.
>>>>>
>>>>>> On Sun, Jun 26, 2016 at 11:03 PM, Benjamin Kaduk <[hidden email]> wrote:
>>>>>>
>>>>>> Hi Michael et al,
>>>>>>
>>>>>> As I was preparing the shepherd writeup for this document, I noticed some
>>>>>> things that do not block the progression of the document but do require
>>>>>> changes, and one item that may require further WG input.  Can you prepare
>>>>>> a new version with the changes mentioned below?
>>>>>>
>>>>>> The one item which would potentially affect the actual protocol: at the
>>>>>> end of Section 5, the pseudo-random function seems to be using a SP800-108
>>>>>> KDF but omits the zero byte between label and context.  I think it would
>>>>>> be better to have the zero byte -- do you remember whether there was a
>>>>>> reason to omit it?  (Adding the zero byte would require re-rolling some
>>>>>> test vectors, to be clear.)
>>>>>>
>>>>>> Additionally, all document authors will need to confirm compliance with
>>>>>> BCPs 78 and 79 for this document, namely that there are no intellectual
>>>>>> property concerns with the document that are not already disclosed.
>>>>>>
>>>>>> Please add a normative reference to RFC 2104 for HMAC, first mentioned at
>>>>>> the end of Section 1.
>>>>>>
>>>>>> In Section 3, it might aid clarity to mention that the 0x00000001 input to
>>>>>> HMAC() is the 'i' parameter from SP800-108 [indicating that this is the
>>>>>> first block of output, even though it is the only block of output as
>>>>>> well].
>>>>>>
>>>>>> In Section 4, it might be worth re-mentioning "where PBKDF2 is the
>>>>>> function of that name from RFC 2898" after the algorithm block, since most
>>>>>> everything else used there also gets clarified.  (It is already cited at
>>>>>> the beginning of the section, in the overview paragraph.)
>>>>>>
>>>>>> The document should be consistent about using "cipher state" as one word
>>>>>> or two (RFC 3961 prefers the two-word form).  It also makes a rather
>>>>>> sudden appearance at the beginning of Section 5 with no explanatory
>>>>>> introduction; it might help the reader to instead start with "The RFC 3961
>>>>>> cipher state that maintains cryptographic state across different
>>>>>> encryption operations using the same key is used as the formal
>>>>>> initialization vector [...]" On the next page, "cipherstate" is defined as
>>>>>> "a 128-bit initialization vector derived from the ciphertext", which is
>>>>>> potentially misleading, since it can't be both used as the IV for and
>>>>>> derived from the same ciphertext!  Probably it's better to say "derived
>>>>>> from a previous (if any) ciphertext using the same encryption key, as
>>>>>> specified below".
>>>>>>
>>>>>> Still in Section 5, in the definition of the encryption function (well,
>>>>>> computing the cipherstate, really), I'm of two minds whether it's worth
>>>>>> mentioning that the case of L < 128 is impossible because of the 128-bit
>>>>>> confounder.
>>>>>>
>>>>>> In the decryption function, can you add a note to the right of "(C, H) =
>>>>>> ciphertext" that "[H is the last h bits of the ciphertext]"?
>>>>>>
>>>>>> In the pseudo-random function, please replace "base-key" with "input-key",
>>>>>> since the key input to the PRF is not expected to be a kerberos protocol
>>>>>> long-term base key.
>>>>>>
>>>>>> In Section 6, the "associated cryptosystem"s are supposed to be
>>>>>> "AES-128-CTS" or "AES-256-CTS", but those strings do not appear elsewhere
>>>>>> in the document.  While the meaning is pretty clear, it's probably better
>>>>>> to just say "aes128-cts-hmac-sha256-128 or aes256-cts-hmac-sha384-192 as
>>>>>> appropriate".  This does duplicate the preceding text, but we do want to
>>>>>> explicitly list the "associated encryption algorithm" as listed in the
>>>>>> Checksum Algorithm Profile of Section 4 of RFC 3961.
>>>>>>
>>>>>> In Section 8.1, the acronym "TGT" is used, the only instance in the
>>>>>> document.  It's also potentially misleading, since ticket-granting tickets
>>>>>> are generally objects that are issued to client principals by the AS.
>>>>>> I'd go with "Cross-realm krbtgt keys" instead.
>>>>>>
>>>>>> The test vectors for key derivation have a parenthetical "constant =
>>>>>> 0x...", but the term "constant" does not appear elsewhere in the document.
>>>>>> The hex values are the label input for the HMAC, so we should call them
>>>>>> that.
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Ben
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Mike Jenkins
>>>>> [hidden email] - if you want me to read it only at my desk
>>>>> [hidden email] - to read everywhere
>>>>> 443-634-3951
>>>>
>>>> _______________________________________________
>>>> Kitten mailing list
>>>> [hidden email]
>>>> https://www.ietf.org/mailman/listinfo/kitten
>>>
>>> _______________________________________________
>>> Kitten mailing list
>>> [hidden email]
>>> https://www.ietf.org/mailman/listinfo/kitten
>>>
>>
>>
>>
>> _______________________________________________
>> Kitten mailing list
>> [hidden email]
>> https://www.ietf.org/mailman/listinfo/kitten
>>
>
> _______________________________________________
> Kitten mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten

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

signature.asc (507 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09

Jeffrey Altman-2
On 7/5/2016 6:23 PM, Matt Miller (mamille2) wrote:

> Hello All,
>
> Thanks to Mike for submitting the update so quickly.
>
> It appears to me that -10 addresses all the concerns raised.
> Are there any objections to moving forward with IETF Last Call
> with this revision?
>
> For convenience, the latest revision can be found here:
> https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-10
>
>
> Thanks,
>
> - Kitten Chairs
Thanks to Luke Howard the Heimdal implementation has been updated to
draft 10 and the test vectors have been confirmed.

https://github.com/heimdal/heimdal/commit/7e4f9f433132611b717c853d732a2b522443a42a

I am in favor of moving forward with the IETF Last Call for this document.

Jeffrey Altman




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

smime.p7s (5K) Download Attachment