(was Re: [AFS3-std] rxgk CombineTokens and enctypes)
On Wed, 2 Jan 2013, Simon Wilkinson wrote:
7a9155e373320bfce4f3f1e87807fa11c7520b78 adds a number of error codes -
I'd like to have a discussion in more detail about these, including the
situations that they might be seen in the wild. I don't think the short
descriptions provide enough detail for two implementations to be sure
that they will use the same errors in the same situations.
jaltman pointed out in the openafs jabber room that it could be nice to
separate protocol/wire error codes from internal API errors (which would
seem to be application-specific, anyway). As such, I think it makes sense
to use the RXGK prefix for wire errors and attempt to use a different
prefix for non-wire errors. Thus, discussion here can be scoped to wire
errors.
I'll list the added codes, and my idea of what they should be used for, to
seed discussion. Note that many of these codes have direct or near-direct
analogues in the RXKAD error table.
% RXGK_INCONSISTENCY, "Security module structure inconsistent"
This is essentially "internal error". E.g., when the incoming packet
flags to the server don't match the server's idea of the connection state,
trying to allocate a new connection where one exists already, etc..
% RXGK_PACKETSHORT, "Packet too short for security challenge"
This directly mirrors RXKAD, when the server can't send a packet big
enough to contain a challenge, or the size of the response packet the
server receives is not the expected size of a valid response, or the
analogous situations on the other end of the challenge/response.
% RXGK_BADCHALLENGE, "Invalid security challenge"
In light of the previous entry, I take this to mean that the challenge or
response was the right size, but otherwise failed to decode or contained
nonsense or useless data. I would not be opposed to merging PACKETSHORT
into BADCHALLENGE; in RXKAD PACKETSHORT is not used outside the
challenge/response.
% RXGK_BADETYPE, "Encryption type negotiation failed"
For the GSSNegotiate and CombineTokens RPCs, when the client-supplied
enctype list is not acceptable to the server.
% RXGK_BADLEVEL, "Security level negotiation failed"
Likewise, but for security level.
% RXGK_BADKEYNO, "Key version number not found"
Analogous to RXKAD's UNKNOWNKEY more than BADKEY (which is for bad-parity
or well-known DES keys), when the server doesn't have the key indicated by
an incoming token.
% RXGK_EXPIRED, "Token has expired"
Seems self-explanatory...
% RXGK_COMPOUND_IDENTITY, "Token's combined identity not usable"
The server doesn't like the compound identity presented by the client
solely because it is a compound identity (as opposed to a single-identity
token) or the structure of the compound identity is too complicated to be
used as input for CombineTokens. (This one is rather speculative.)
% RXGK_PRINTED, "Printed token not allowed"
The client presented a token that was printed, but such tokens are not
allowed for that use case by the server. E.g., AFSCombineTokens (in the
rxgk-afs draft) explicitly MUST NOT accept printed tokens. On the other
hand, we don't talk about printed tokens in this document at all, so
maybe this error code should be deferred.
% RXGK_NOTAUTH, "Caller not authorized"
Analogous to RXKADNOAUTH. RXKAD's use seems a bit unusual, though, such
as if the decoded ticket is flagged as 'invalid' or the token start time
has not yet arrived. I guess most of the "permission denied" errors
currently in the wild stem from service-specific error tables and are not
treated as RX-level errors.
% RXGK_BAD_TOKEN, "Security object was passed a bad token"
Analogous to RXKADBADTICKET. Token not present, wrong size, fails to
decode, zero or negative lifetime, starts too far in the future, too long
a lifetime, etc..
% RXGK_SEALED_INCON, "Sealed data inconsistent"
Analogous to RXKADSEALEDINCON. Bad checksum, sequence/call numer don't
match, etc..
% RXGK_DATA_LEN, "User data too long"
Analogous to RXKADDATALEN. Zero-length iovec entry while
decoding/encoding, or packet is too large.
I think jaltman also wanted some guidance on how these codes should be
used to go into the rxgk document. I am not opposed to this, and once we
get agreement on what things mean (and which ones to include), I can put
them in the document somewhere. It might end up being a new section.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
