[AFS3-std] New Version Notification for draft-wilkinson-afs3-rxgk-06.txt (fwd)

[Jeffrey Hutzelman]

On Mon, 2013-06-24 at 18:30 -0400, Benjamin Kaduk wrote:
> For those following along, I finally got around to putting in extra markup 
> to split out the control flow of the GSS negotiation loop into enumerated 
> steps.  There are no changes to the body text.

I've taken a look at this, and the structural changes look pretty good.
I've also reviewed the description of the negotiation loop in section
6.2, and have a few comments...

- In step 3, you don't say anything about the case where the major
  status code from GSS_Accept_sec_context indicates an error.

- If the server decides that negotation has failed for a reason other
  than GSS_Accept_sec_context returning an error status, , it should
  indicate this to the client by returning an error from the RPC or
  by some other indicator.  It should not synthesize a GSS-API status
  code that was not actually returned by the GSS-API.

- In step 4, if the GSSNegotiate() fails for any reason, the client
  should consider the negotiation to have failed.

- Don't conflate GSS_S_CONTINUE_NEEDED with an output token.  The
  GSS_S_CONTINUE_NEEDED flag indicates that another call with an input
  token is expected, not that an output token was provided.  So...

  + If GSS_Init_sec_context produced a token when the server wasn't
    expecting one, or failed to produce one when it was, that is an
    error, and negotiation fails.

  + If GSS_Accept_sec_context produced a token when the client was
    not expecting one, or failed to produce one when it was, that is
    an error, and negotiation fails.
    
  + If GSS_Accept_sec_context produces an output token but does not
    set GSS_S_CONTINUE_NEEDED, that is _not_ an error -- it means the
    client needs to call GSS_Init_sec_context() once more, and that
    call is expected to succeed without producing an output token.
    Of course, at this point, the acceptor believes the context has
    been established, but the initiator may need to process that last
    token in order to finish setting up the context.

So in step 4, if the GSSNegotiate RPC failed, or returned a GSS status
indicating an error, then negotiation has failed.  Otherwise, there
are three cases...

  (a) The server returned GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED, with
  an output token, and the client was expecting a token.  In this case,
  the client begins the next cycle.

  (b) The server returned GSS_S_COMPLETE without an output token, and
  the client was not expecting a token.  In this case, negotiation
  succeeds.

  (c) All other combinations are failures.


GSSNegotiate is intended to be called over an unprotected channel.
So, there is no security reason to favor reporting results via an
output parameter instead of via an Rx abort.


-- Jeff