AFS3 Standardization Group

Issue Tracking: draft-wilkinson-afs3-rxgk-afs

Current work-in-progress draft.

Current open issues for draft-wilkison-afs3-rxgk-afs.

# Issue Resolution
1 We have some inconsistency around the RXGK_TokenInfo structure (there are two separate definitions!) and we say that an otherwise undefined RXGK_Token structure is encrypted (after XDR encoding) and stored in the encrypted_token field of the TokenContainer structure. Fixed. See commit bc9fb357
2 The notes that Andrew took included some uncertainty about how the document treats the attack which having CM-specific keying material prevents, both in the "Client Tokens" section and in the security considerations. Simon replied about this saying basically that he's happy with the current text, but I don't know if Andrew et al are happy with that. Retracted
3 We want to add some more RFC 2119 language, for frequency of the CM renewing its token and maybe more. We may want to remove the RFC 2119 language about removing rxkad keys from the security considerations section, but that is not entirely clear to me. CM renew token text added. Security considerations not updated.
4 We should reference the VL spec (where we mention VL_RegisterAddrs). There is no spec that covers VL_RegisterAddrs. (VL and VVL documents pre-date the VL_RegisterAddrs RPC.) Resolution is unclear.
5 The Deason notes suggested to s/part of the RXAFS_ family/part of the AFSINT protocol/ which did not elicit any further comment that I saw. Fixed. See commit e2b5421a
6 We need a better reference for extended callbacks. Fixed. See commit b7b23186
7 I think Simon's reply clarified why the document forces breaking all callbacks on SetCallbackKey, but again there was not further comment.
8 I don't think there was consensus about the generation and expiry of extended callbacks and which channels need be rxgk-secured, and whether/how a client could upgrade and downgrade to and from them. A proposed text was "Only RPCs issued over an rxgk protected connection should cause rxgk callbacks to be received"; it was also proposed that rxgk clients might change UUID (so as to appear as a differnent client entirely and avoid the downgrading problem). I need to familiarize myself more with the extended callbacks document before I can add much here. Discussed extensively on list. Ben proposed covering callback keying in a subsequent I-D.
9 We will need to pull in the changes we made to CombineTokens for the AFSCombineTokens RPC. Fixed. See commit cfad0561
10 We also need an AFS registry section. Fixed. See commit bd42b12b
11 Acceptor identities for dbservers vs. fileserver/volservers Consensus reached in discussions. Requires a small change to the rxgk and rkgk-afs documents.