Last Call Review of draft-ietf-kitten-gss-loop-04

Request Review of draft-ietf-kitten-gss-loop
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-02-17
Requested 2015-01-29
Authors Benjamin Kaduk
Draft last updated 2015-03-02
Completed reviews Genart Last Call review of -04 by Joel Halpern (diff)
Secdir Last Call review of -04 by Tina Tsou (diff)
Assignment Reviewer Tina Tsou 
State Completed
Review review-ietf-kitten-gss-loop-04-secdir-lc-tsou-2015-03-02
Reviewed rev. 04 (document currently at 05)
Review result Has Nits
Review completed: 2015-03-02


Dear all,

I have reviewed current version of this document as part of the security

directorate's ongoing effort to review all IETF documents being processed by

the IESG.

These comments were written primarily for the benefit of the security area


Document editors and WG chairs should treat these comments just like any

other last call comments.

* Section 3.2, page 5:

  The initiator calls GSS_Init_sec_context(), using the

  input_context_handle for the current proto-security-context and its

  fixed set of input parameters, and the input_token received from the

  acceptor (if not the first iteration of the loop).

Your use of proto-security-context would make it seem like this is a

parameter specified in RFC2473 but it is not. So I'd recommend to remove

the hyphens. (BTW, at times you refer to "proto-security-context" while

at others to just "security context"... why?)

* Section 3.2, Page 5:

(if not the first iteration of the loop)

Please rephrase as "(if this is not...)"

* Section 3.2, page 5:

However, there are some known

     implementations of certain mechanisms which do produce empty

     context negotiation tokens.  For maximum interoperability,

     applications should be prepa

It would be great if you could provide examples of such implementations.

* Section 3.4, page 6

It is likely appropriate

  for the acceptor to report this error condition to the acceptor via

  the application's communication channel.

It should say:

  It is likely appropriate

  for the acceptor to report this error condition to the initiator via

  the application's communication channel.

* Section 3.5, page 7:

  The GSS acceptor calls GSS_Accept_sec_context(), using the

  input_context_handle for the current proto-security-context and the

  input_token received from the initiator

Again, remove the hyphens

* Section 4.1, page 10

Additional information can be

  available in GSS-API Naming Extensions, [RFC6680].

s/can be/is/

* Section 5.1: You should clarify what's the convention for the return

codes of send_token() and receive_token(). Otherwise it's not clear

whether, when you use these functions, you're checking the return codes


Thank you,