Re: [secdir] Secdir review of draft-ietf-kitten-gss-loop-04

[Benjamin Kaduk <[e-mail]>]

On Sun, 15 Feb 2015, Tina TSOU wrote:

> 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
> directors.
> Document editors and WG chairs should treat these comments just like any
> other last call comments.

Thank you for the review.

> * 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?)

The use of "proto-" was to indicate that this was a security context which
is not fully established; that is, one for which the establishment process
is still under way.  Since this is confusing, I think I would rather
change it to "security context being established" instead of just removing
the hyphens.

> * Section 3.2, Page 5:
>
> (if not the first iteration of the loop)
>
> Please rephrase as "(if this is not...)"

Okay.

> * 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.

I believe the NTLMSSP mechanism is the main example.  I am not sure what
the best reference to use for it is, though.

> * 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.

Thank you for spotting this (Gen-ART did as well).

> * 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

As above.

> * Section 4.1, page 10
> Additional information can be
>   available in GSS-API Naming Extensions, [RFC6680].
>
> s/can be/is/

I believe that "can be" is appropriate, since the naming extensions from
RFC 6680 are not universally deployed.

> * 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
> correctly.

I think that the intent is clear from the return code checking where they
are used, but will add a comment above the implementations, "Returns 0 on
success, non-zero on failure."

Thank you,

Ben