[AFS3-std] rxgk: The initial packet problem

[Jeffrey Hutzelman]

--On Wednesday, October 14, 2009 11:14:27 AM +0100 Simon Wilkinson 
<sxw@inf.ed.ac.uk> wrote:

> This is the first of a couple of emails to raise issues that were
> identified and discussed with rxgk at the Edinburgh Hackathon. I am, of
> course, going to produce a revised document which addresses them, but I'm
> sending this separately in the hope of getting further feedback before
> that document appears.
>
> The initial packet problem is caused by the current behaviour of rx's
> challenge/response system, where the client sends a packet to the server
> using its desired security level. The server then responds with a
> challenge, the client sends a response, and providing the security level
> permitted by the server matches that requested by the client, the
> connection is established. The issue here is if the client is trying to
> do clear but the server requires encryption - the client has already sent
> a cleartext data packet before the server tells it isn't permitted to.
> For RPCs such as StoreData, this can obviously result in undesired
> information disclosure.

That is not anywhere close to the entire scope of the problem.  What it 
boils down to is that the client must send its first data packet before 
there is an opportunity for any sort of in-band negotiation.  The client 
cannot be assured that the server already knows about a connection; _any_ 
packet could be treated by the server as a "first" packet, resulting in a 
challenge.  Thus, the "first" packet cannot be empty, nor can it be 
discarded after a negotiation which takes place in the challenge/response 
process.

Further, as Simon notes, even when the client knows that a packet is the 
"first" packet, it must know how to prepare that packet before there has 
been any communication on the connection.  It must actually _send_ the 
correct, final version of the first packet, including a full packet's worth 
of data (or all the data in the call, whichever is smaller) before there is 
any opportunity for negotiation.


What the original rxgk design did instead was to perform all negotiation 
out-of-band, at the time that an rxgk token is established.  The token then 
contains everything the server needs to know about the outcome of 
negotiation, including encryption keys, operating modes, and so on.  By the 
time the client sends a data packet, everything is already decided and 
agreed by both parties.  This includes the security level.

Thus, no "security header" is necessary for this purpose.  If the server 
requires encryption, this has already been negotiated.