[OpenAFS-devel] understanding rxkad

[John Hascall]

> --John Hascall <john@iastate.edu> wrote:
> > So *how* does the server know that only the function-number is encrypted
> > vs. all of the payload?   (not to mention why bother encrypting the
> > least sensitive bit of the whole thing!)

Chaskiel M Grundman <cg2v@andrew.cmu.edu> replies:
> One of the things that is negotiated is the "rxkad level", that is, the 
> level of data protection ostensibly provided. this data is only in the 
> encrypted challenge/response packets and is not visible at the rx layer. 

  Thanks.
  I'd like to make sure I have this straight...
  The TCP dump seem to indicated that:

  1) The client sent XListOneVolume in rxkad_auth,
  2) The server seeing it had not exchanged a session key
     saved this packet and sent back a challenge packet,
  3) The client replied with a response and now the
     server can go back to working on the XListOneVolume,
  4) The server sent the reply data packet back,
  5) The client sent ack-all.

  Is that correct?


> There are three levels:

> rxkad_clear: no protection beyond the 16bit checksum in the header.

> rxkad_auth: nominal integrity protection. an exta 4 byte value is prepended...

> rxkad_auth: confidentiality. the same 4 byte value is prepended to the 
> packet and the entire payload is encrypted.

   I'm guessing you mean rxkad_crypt for the last one.


> I'm not sure how you got rxkad_auth in a vos request. As far as I can tell, 
> vsu_ClientInit still defaults to rxkad_clear.

   Possibly I was using an Arla client at the time.

John