Subject: Re: [Ietf-krb-wg] I-D Action: draft-ietf-krb-wg-pkinit-alg-agility-05.txt

From: Margaret Wasserman <[email-masked]>
Date: Mon, 13 Feb 2012 22:48:19 +0000

The -05 version has changes to address all of the issues I know about, and I think it is ready for WG Last Call.  It would be good to start the WG Last Call as soon as possible, so that if any issues do arise, they can hopefully be resolved before IETF 83.

I haven't seen any comments to the list about this draft since I posted it in early January.  If anyone has any remaining issues that are not addressed by the -05 version, please let me know.

Margaret

On Jan 10, 2012, at 2:09 PM, Sam Hartman wrote:

> What's the path to last calling this?
> Obviously as you mentioned, the first step is  to seek review comments
> on the list.
> But what after that?
> Are there other changes you believe need to be made or should we ask
> Jeff to consider this document for last call after resolving any
> comments that come up?
> 
> --Sam

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

---

From: "Burgin, Kelley W." <[email-masked]>
Date: Wed, 15 Feb 2012 09:49:17 -0500

Hi Margaret,

I have a request:

Would you add id-pkinit-kdf-ah-sha384 to the list of new KDFs in section
6? In Suite B, the 192-bit minimum level of security requires the use of
SHA-384 as its hash algorithm.

And a few comments:

You've borrowed text from NIST SP800-56A for the KDF description in
section 6, which is a good idea, but you changed the text of step 1. I'm
confused by your new text, and I'm not even sure it's correct. For
example, reps will usually not be an integer as you have it (without
assuming you floor the result). I suggest using the text from 800-56A:
"reps = ceiling (keydatalen / hash length)"

In step 4 of the KDF description, it's not clear that you truncate the
last block Hash_reps to get K bits. Suggest adding a sentence to this
effect when K/H is not and integer.

In the first two bullets following the KDF description in section 6, you
define K in bits and H in bytes. Suggest representing H in bits to be
consistent with 800-56A. You also refer to "K bytes" in step 4, which is
confusing.

In the second bullet after the KDF description, the output of SHA-1 is
20 bytes (160 bits if you go with my previous suggestion), not 16 bytes.

Some editorial comments:

In the first paragraph of section 3, "tempered" should be "tampered".
Last sentence of the same paragraph, need "on" in "relies the".

In section 6, in the text just before the description of the KDF,
"follows:" is unnecessary

In the paragraph after the PkinitSuppPubInfo structure in section 6, the
sentence "The ticket field is filled with the ticket in the KDC reply"
is no longer needed since you removed the ticket from the structure.

In section 7.4.1, enctype 16 is des3-cbc-sha1-kd, not des-cbc-sha1. 

Kelley

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Margaret
Wasserman
Sent: Monday, February 13, 2012 5:48 PM
To: Sam Hartman; Jeffrey Hutzelman
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] I-D
Action:draft-ietf-krb-wg-pkinit-alg-agility-05.txt

The -05 version has changes to address all of the issues I know about,
and I think it is ready for WG Last Call.  It would be good to start the
WG Last Call as soon as possible, so that if any issues do arise, they
can hopefully be resolved before IETF 83.

I haven't seen any comments to the list about this draft since I posted
it in early January.  If anyone has any remaining issues that are not
addressed by the -05 version, please let me know.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 16 Feb 2012 09:47:16 -0500

Hi Kelley,

> SHA-384 as its hash algorithm.

Unless there is any objection from other members of the WG, I would be happy to add this.

> I suggest using the text from 800-56A:

This would be clearer than what the document says now, and I will make this change.

Just so you know, the way I received this document, it said:

reps = keydatalen/hash length

which was wrong.  The current text reflects my attempt to fix that.  I agree that your wording is a better way to say what I intended to say.

> effect when K/H is not and integer.

I'll look at this.  My guess is that most implementations will not actually truncate the last block, but that they will allocate a bigger buffer than they actually send, and just pass an appropriate length, so I'm trying to figure out a way to make this clear without attempting to mandate a particular way to implement it.  Suggestions are welcome.

I'll incorporate all of your other suggestions.  Although mostly editorial, you caught a few things that will definitely improve the quality of the document.  Thank you!

Margaret