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

[Benjamin Kaduk]

On Wed, 23 Jan 2013, Michael Meffie wrote:

>> Hmm, when I first read this mail I read this as open issues with the rxgk
>> draft, but now I think you meant the rxgk-afs draft.
>
> Yes, that is what I meant, a timeline so we can move forward with the
> rxgk-afs i-d.
>
>> I will plan to do the same historical research for rxgk-afs that I did for
>> rxgk, hopefully this week.  I won't have an idea of what the timeline will
>> be until I've done that research.  I seem to recall that this document
>> needed more work than the base rxgk document, though.
>
> 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 (!).

Most of the typos have been taken care of, though there are a few that 
remain.

I won't enumerate the trivial changes that remain, here; rather, I'll just 
make them.

As per the rxgk draft, Dave Botsch wants more definitions, for "client", 
"host", and "connection".  I'm inclined to say that this is standard RX 
background material that we can safely assume.

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.

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.

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.

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

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.

We need a better reference for extended callbacks.

I think Simon's reply clarified why the document forces breaking all 
callbacks on SetCallbackKey, but again there was not further comment.

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.

We will need to pull in the changes we made to CombineTokens for the 
AFSCombineTokens RPC.

We also need an AFS registry section.

I have pushed the latest I have from Simon to my github branch, on top of 
draft-wilkinson-afs3-rxgk-afs-01 so we can see what has already been 
changed.  (https://github.com/kaduk/openafs/commits/prot).  It's the same 
branch as the rxgk document, though hopefully I won't need to 
destructively rebase.


Modulo the extended callbacks stuff that I can't comment on yet, the rest 
of the document seems pretty straightforward for the token format and 
whatnot.  I guess I'd say maybe 2 weeks for a new version, then.

-Ben