Skip to main content

Last Call Review of draft-ietf-kitten-rfc4402bis-01

Request Review of draft-ietf-kitten-rfc4402bis
Requested revision No specific revision (document currently at 02)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-12-15
Requested 2015-11-29
Authors Shawn M Emery , Nicolás Williams
I-D last updated 2015-12-12
Completed reviews Genart Last Call review of -01 by Christer Holmberg (diff)
Secdir Last Call review of -01 by Charlie Kaufman (diff)
Opsdir Last Call review of -01 by Susan Hares (diff)
Assignment Reviewer Susan Hares
State Completed
Review review-ietf-kitten-rfc4402bis-01-opsdir-lc-hares-2015-12-12
Reviewed revision 01 (document currently at 02)
Result Has nits
Completed 2015-12-12

Shawn and Nicholas:

I have reviewed this document as part of the Operational directorate's

ongoing effort to review all IETF documents being processed by the IESG.  These

comments were written with the intent of improving the operational aspects of

IETF drafts. Comments that are not addressed in last call may be included in AD

during the IESG review.  Document editors and WG chairs should treat these

just like any other last call comments.


  Ready with minor editorial changes

Summary comment:

  Thank you for a clear and concise document to replace rfc4402 to make it
  operationally viable (with counter of 0).  I have two editorial suggestions

Suggestion 1:

Page 3:

In  the following two bullet items:

   o  GSS_C_PRF_KEY_FULL -- use the sub-session key asserted by the

      acceptor, if any, or the sub-session asserted by the initiator, if

      any, or the Ticket's session key

   o  GSS_C_PRF_KEY_PARTIAL -- use the sub-session key asserted by the

      initiator, if any, or the Ticket's session key

change /if any/to /if any exists/  - Otherwise, your English text is vague.

Suggestion 2

Since this will be the future standard for the algorithm, it is important make
sure the variables are easily understood.   The exact definition of the
variable “K” is not specified in your draft.   You may assume something, but
this review is for the naïve OPS person.


 it defines K as:

   key-generation seed length, K

      This is the length of the random bitstring needed to generate a

      key with the encryption scheme's random-to-key function (described

      below).  This must be a fixed value so that various techniques for

      producing a random bitstring of a given length may be used with

      key generation functions.

If this is the definition, it would be helpful useful to state give a
definition such as:

“K is the key-generation seed length”  [See RFC3961].

 After glancing through RFC3961, I am not 100% sure this is the right value. 
 I’m sure you are wise and can place a clear definition of “K” in the text.


Sue Hares