[00:08:30] --- kula has left [03:56:54] --- Stephan Wiesand has become available [04:50:03] --- Simon Wilkinson has become available [04:50:28] --- Stephan Wiesand has left [05:06:30] --- Simon Wilkinson has left [06:09:53] --- Stephan Wiesand has become available [06:22:29] --- mvitale has become available [06:32:15] --- Simon Wilkinson has become available [07:14:33] --- deason has become available [08:19:57] --- Stephan Wiesand has left [11:42:45] --- Brandon Allbery has become available [12:30:08] [looking at what things to crib from the RXKAD error table for an RXGK error table] Hmm, we generate RXKADPACKETSHORT but never really check for it explicitly. [13:04:53] Remember the difference between wire errors and application errors. [13:05:04] Lots of the stuff in the rxkad error table is never sent on the wire. [13:07:24] The only errors we need to standardise are ones that can be sent in abort codes, and those which are in the Negotiate error field. [13:08:00] Well, and the CombineTokens error field, now. [13:08:26] Yeah, but I think that's probably the same set of errors. [13:09:29] My current working copy has an RXGK_COMPOUND_IDENTITY "Token's combined identity not usable" that I think is not useful for Negotiate. [13:10:48] Is that error worth standardising, though? [13:10:59] I'm not sure. [13:11:06] I'm really inclined to keep the CombinedTokens errors as minimal as possible [13:12:18] if we need more, we can add more later; you don't need to stall the whole thing for this [13:12:28] The lack of abort codes is a definite omission in the current drafts, though. [13:12:47] And == deason - we should keep CombineTokens as simple as possible, and extend it later. [13:12:49] Yeah, I'm not planning to spend too much time here. [13:13:14] One thing to consider, from an implementation perspective, is that any error that you return from your packet checking routine becomes a wire abort code. [13:13:18] Now that jhutz has convinced me to just use com_err values, I have no incentive to try and standardize everything. [13:13:23] It's really easy to end up with krb5 errors on the wire :) [13:13:37] Right, most of these RXKAD errors are ~only used in the packet checking routine. [13:13:43] Using com_err values is definitely the way to go - it's the way that everything else works. [13:14:12] Yeah, so if you return RXKAD_INCONSISTENCY there, then RX turns it into a connection abort code, which is sent to the peer. [13:14:53] But errors you return elsewhere in the security module are only seen locally. It's a bit of a mess, really. [13:15:40] It seems a little weird to define codes for values that are only used ~once (OUTOFSEQUENCE, DATALEN) as opposed to a general catch-all code (which we don't really have?). [13:20:20] You want to provide some information to the peer, but not to much. [13:21:49] The error table in the YFS implementation is INCONSISTENCY, PACKETSHORT, BADCHALLENGE, SEALEDINCON, NOTAUTH, EXPIRED, BADLEVEL, BADKEYNO, NOTRXGK and UNSUPPORTED [13:22:45] (UNSUPPORTED and NOTRXGK are not sent on the wire) [13:24:18] Is BADCHALLENGE analogous to RXKADOUTOFSEQUENCE? [13:24:53] Oh, and I guess you stick to the rxkad convention of avoiding underscores? [13:25:03] Yeah, for no real reason. [13:25:17] I'd need to go and check how RXKAD uses RXKADOUTOFSEQUENCE. [13:25:58] We use BADCHALLENGE for any of the various ways that a challenge, or response, can fail to be decoded. [13:26:29] It's just if the incremented sequence number doesn't match with what the server has on that connection /* replay attack */ [13:27:19] No, Bad Challenge is much wider - it covers XDR decoding failures and decryption failures [13:27:36] SEALEDINCON in used for inconsistencies in the encoded data - cid and epoch not matching and so on. [13:27:52] Okay. [13:29:24] So my current list of "speculative" codes (which we may shoot down on the list) is COMPOUND_IDENTITY, PRINTED, and BAD_TOKEN (analogous to RXKADBADTICKET) [13:30:49] I think I'd disagree with COMPOUND_IDENTITY and PRINTED - I don't think they are generic errors. [13:33:05] I guess I'm starting to be convinced of it. [13:33:47] The discussion we need to have with jhutz is the use of the in-response-payload error field, versus the RX abort code [13:34:27] Oh, he feels strongly? [13:34:54] Well, there is the view that RX has an error mechanism, we should use that rather than growing our own. [13:35:44] The only reason for the in-payload error field is to convey errors that are security sensitive. So, if an attacker could make you downgrade by faking an error, that error should be in the payload, rather than in an abort packet. [13:36:02] Does my AFS-3 Registry Considerations section need any more preamble than This document requests that the AFS-3 registrar include a com_err error table for the RXGK module, as follows: ? [13:36:26] I think that's fine [13:52:36] You wanted Negotiate tweaked to allow RXGK error codes in major_status, too, right? [13:54:04] I don't think so, no. [13:54:27] Oh, I must have misread. [13:55:00] I'd need to check the GSSAPI spec, but I'm not sure if we can squat on their error codes :) [13:55:24] (I was thinking of "The only errors we need to standardise are ones that can be sent in abort codes, and those which are in the Negotiate error field.") [13:56:08] The "errorcode" field of RXGK_ClientInfo [13:57:09] Oh, right. Sorry, reading too fast. [15:56:31] --- mvitale has left [16:02:22] --- deason has left [16:07:34] --- kula has become available