Replying to myself with some comments, trawling for other input...
On Wed, 28 Nov 2012, Benjamin Kaduk wrote:
On Tue, 27 Nov 2012, Simon Wilkinson wrote:
I haven't reviewed the series completely yet, but I wonder if initial error
list for CombineTokens is far too verbose. It isn't clear to me the
situation in which many of the suggested errors would occur, and I'm wary
of over specifying here.
It's quite possible that the current list is too large. I was essentially
brainstorming when coming up with it, and some of the scenarios may be
application-specific (and thus end up in the high half of the range).
I consider the list quite flexible at the moment and welcome more input.
I'll include the current list below for the mailing list to comment.
-Ben
RXGK_CT_SUCCESS The CombineTokens operation completed successfully.
RXGK_CT_NOT_IMPL The server will refuse all CombineTokens requests.
RXGK_CT_BAD_ENCTYPE None of the enctypes supplied by the client are
acceptable to the server.
RXGK_CT_BAD_LEVEL None of the security levels supplied by the client
are acceptable to the server.
These first four seem pretty straightforward. (I added things in the
order I thought of them, so this is not terribly surprising.)
RXGK_CT_RECURSE One or more of the supplied tokens was the result of
a previous CombineTokens operation, and the server will refuse
to perform the CombineTokens operation recursively.
This could plausibly be application-specific, as it delves into the
territory of what combined identities mean. On the other hand, one could
imagine multiple applications that forbid the combination of combined
tokens.
RXGK_CT_EXPIRED One or more of the input tokens was already expired.
This seems similar to BAD_{LEVEL,ENCTYPE}.
RXGK_CT_ENCTYPE_MISMATCH The client supplied a list of enctypes
disjoint from the enctypes used by the two input tokens, and
the server is configured to reject such enctype renegotiation.
RXGK_CT_LEVEL_MISMATCH The client supplied a list of security levels
disjoint from the security levels used by the two input tokens,
and the server is configured to reject such security level
renegotiation.
These two are for use if an application wants to enforce a policy that
enctype or security level cannot be renegotiated to something different
from an input token or tokens. They are probably better off in
application-specific territory.
RXGK_CT_TOPOLOGY The compound identity of the two input tokens
cannot be represented in the application's scheme because the
topology of the tree of CombineTokens operations involved is
too complicated.
Again, this delves into application-specific territory of compound
identity representation. It should probably be relegated to the
application-specific block.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
