[OpenAFS-devel] understanding rxkad

[Marcus Watts]

John Hascall <john@iastate.edu> writes:
> > > What I'm not understanding are the first 8 bytes of payload.
> > > If this command is executed with '-noauth' they are replaced
> > > with 4 bytes (0000 007d) aka XListOneVolume.
> > > 
> > > Why would just those bytes be encrypted?  Are they encrypted?
> > > Or is it some encoding I just don't understand?  How does the
> > > receiving end know that just those bytes are encrypted?  Etc?
> > > And with what key (since the two packets that follow are
> > > challenge, response) [then the reply and ackall].
> 
> > rxkad is sort of stateless: The client starts sending encrypted data (in 
> > this case only the command). When the server has no security data for 
> > this connection he replies with the challange packet which then by the 
> > client is replied by the challange response packet which contains the 
> > security data. These are decrypted with the KeyFile on the server and 
> > allow then the server to extract the session key to decrypt the 1st packet.
> 
> > The advantage is that a server restart between RPCs doesn't really 
> > matter because both sides resynchronize their security data automatically.
> 
> > If you would have called the vos command with -encrypt then probably 
> > also the whole payload would have been encrypted.
> 
> Thanks,
> 
> 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!)
> 
> 
> John

Actually, the server doesn't know at this point, any more than you do.  The
only thing it can do is save the initial data and send a challenge back.
The client response contains the encryption level (clear,auth,crypt) selected,
plus the kerberos ticket.  Once the server gets that, it can decode the
ticket (using the key of afs), acquire the session key, and also get the
encryption level.  At *that* point, it has enough information to decode
those 8 bytes and verify the checksum.

As for *why* it does this -- the initial version of rxkad (in AFS 3.0) had no
checksum support, at all.  The only thing it could do to check the integrity
was to encrypt the first bit of the payload.  The integrity check, then,
consists of checking to see if the decoded opcode is actually valid.
This may sound perverse (and it is), but it's actually not much different
than the integrity check that kerberos 4 does using pcbc on its packets
(which also have no checksum).

				-Marcus