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 the 

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

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

just like any other last call comments.

 

Status:

  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 below: 

 

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. 

 

 

In RFC 

https://tools.ietf.org/html/rfc3961

 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. 

 

Cheerily, 

 

Sue Hares