reviving rxgx-afs (was re: [AFS3-std] rxgk (protocol) error codes)

Benjamin Kaduk kaduk@MIT.EDU
Fri, 1 Feb 2013 18:51:02 -0500 (EST)


On Mon, 28 Jan 2013, Benjamin Kaduk wrote:

> On Wed, 23 Jan 2013, Michael Meffie wrote:
>
>> Ok, thank you. Re-reading the previous threads, I see Andrew started some
>> dicussions in June 2012. There were three categories; trivial/typo's,
>> non-trival comments, and section 10 (callbacks). Simon mentioned he had 
>> made
>> corrections for the typos, and it seems some updates for the non-trival
>> comments to his draft.  There was a long response from Simon regarding the
>> background for section 10 (callbacks).
>
> Yup, that seems to be just about all of the discussion (!).

I fixed a bunch of the stuff mentioned in the trimmed parts of the quoted 
mail.

> We should reference the VL spec (where we mention VL_RegisterAddrs).

vvl-spec.pdf is too old to have VL_RegisterAddrs.
I don't think there's anything reasonable to use as a reference for this.
I'm undecided whether to just leave it as-is, or to import actual 
specifications for the parameters that we currently describe by reference.

> 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.

The central.org registry places this as the RXAFS_ service, so I used 
that.

> 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.

I haven't done anything on this front yet.


I'll put a shortlog of the changes so far, below.  Almost all of them 
should be uncontroversial, but an extra pair of eyes would be great.

-Ben

(git log --oneline)
cfad056 Pull in CombineTokens changes for AFSCombineTokens
6ae6385 Rework the rxgk and AFS introduction
f4be672 Use defined constant instead of literal number
1991b63 Do not use vague "earlier" reference
5fc9d50 Use explicit reference for CM tokens
a020e08 Add the concatenation operation
4768011 Add clarity to per-server key negotiation
92bf5b7 Add comma around parenthetical clause
950e878 s/renew token/regenerate token/
286e152 Grammar-o
c7af442 More RPC-L tweaks
b3c33ee Title case for section headings
faa72d9 Semicolon police (in artwork)
f307e6a Edit for grammar, punctuation, spelling, etc.
ceb2cb6 Fix typo (startTime for starttime)
70edbc5 Clarify requirements on AFSCombineTokens connections
b7b2318 Add reference for extended callbacks
3d41e96 Spell as SetCallBackKey for consistency
e2b5421 Wordsmith around RXAFS
660a077 Wordsmith appdata within RXGK_Authenticator
b2e54f5 Wordsmith VL_RegisterAddrsAndKey
bc9fb35 Don't define RXGK_TokenInfo twice
8d8fddc Place automatic key generation in context
1690c40 No SHOULDs in the security considerations
cf63b59 Less trivial things from Deason's notes
cb0491f Improve language for securing AFSCombineTokens
bd42b12 Add AFS registry section for rxgk-afs
f00b638 Trivial rxgk-afs fixes from Deason's notes
02c1463 Cross-reference from security considerations
293069b Excise "Network Working Group" from xml2rfc output
fc02249 Fix some XML nits
7b723a4 Standardize whitespace
cba6449 Make xmllint happy