On Fri, 28 Jun 2013, Jeffrey Hutzelman wrote:
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.
This was something of a conscious decision, as the client need not know
the server's gss_accept_sec_context() return value directly. Even in
RFC4462, it is only "the server MAY send a message informing the client of
the details of the error" and "SHOULD send the error token [if it
exists]". The failure of context establishment will become clear quite
soon, regardless; either gss_init_sec_context() will fail due to a
missing/invalid token, or the server will have failed to return a token.
Do you really want explicit text here?
I suppose I should consider whether to permit sending a GSSAPI error from
routines other than GSS_Accept_sec_context(); my implementation at least
used to do this, I may have cleaned it up since then.
- 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.
You are taking issue with the synthesis of GSS_S_BAD_QOP?
To represent this error case (GSS_Accept_sec_context returns
GSS_S_COMPLETE but ret_flags & (GSS_C_CONF_FLAG | GSS_C_INTEG_FLAG) !=
GSS_C_CONF_FLAG | GSS_C_INTEG_FLAG) as a com_err error, I believe we would
need to introduce a new RXGK error code. Do you have suggestions for this
error code name and text?
- In step 4, if the GSSNegotiate() fails for any reason, the client
should consider the negotiation to have failed.
Well, the client should not decide to downgrade to rxkad because
GSSNegotiate returns -1! I can add explicit text for what to do if the
RPC fails if you want, though I think the intent was that the last
paragraph of 6.2 would cover this case.
- 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...
Right.
+ 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.
These will both be caught by the counterparty's next GSS call and need not
be handled explicitly.
+ 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.
Yes, this is the "half round trip" mentioned at the top of 6.2.
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...
Hmm, saying "the major status code" here is a bit ambiguous as to whether
it is from initiator or acceptor (it's supposed to be the acceptor, if I
remember correctly.
(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.
This is a valid decomposition, but I would prefer to not introduce the
notion of the client "expecting" a token; instead, I like to refer only to
what has already happened. Thus, "the most recent call to
GSS_Init_sec_Context() returned the major status code GSS_S_COMPLETE"
instead of "the client was not expecting a token".
Are you claiming that the breakdown in step 4 is an invalid decomposition?
If the server is not GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED, it is in
error, of course (as your (c), my first bullet point). If the client was
not expecting a token (second bullet point) and gave one to the server,
the server cannot be setting GSS_S_CONTINUE_NEEDED (right?) because the
client is already GSS_S_COMPLETE and will produce no further tokens.
Thus, the conditions from the first bullet point mean that the server
returned GSS_S_COMPLETE as well, so both sides are done and the
negotiation was successful (your (b)). If Init_sec_context was not
GSS_S_COMPLETE and also did not fail the negotiation, the client was
expecting another token, and thus we should proceed with the loop and call
GSS_Init_sec_context() again to examine that (the third bullet point, your
(a)).
I believe I used to have an explicit case for the client expecting a token
and the server not returning one, but Simon noted that we can just
continue the loop and the next Init_sec_context call will detect the
error.
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.
That text at the end of 6.2 was intended to call to mind the security
considerations 12.1. I guess the description as written is not really
consistent with the class of errors for which the security consideration
applies, though.
Thanks for the comments.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
