--On Wednesday, October 14, 2009 11:14:27 AM +0100 Simon Wilkinson
<[email protected]> 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.
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
