[OpenAFS] False replay error with 1.7 on Win 7 client (fwd)

[Sergio Gelato]

* Harald Barth [2012-12-11 23:07:07 +0100]:
> > Thanks. My next question is: if I do this, will it break existing
> > sessions using tokens obtained via afs@?
> 
> If you merge a new secret into the AFS key file on the server with a
> new (high, say 10001) kvno, it should not. I have not tested this
> though.

I haven't tested kvno's that high, but with more mundane values it does work.
When I did this some years ago, the afs@ principal had kvno=3 or 4 so I
simply gave the new afs/cell.name@ principal kvno=1. The only requirement
is that all kvno's in the keyfile be unique at any given time.

> Methinks between 1. and 3. tokens with the new key may fail.

There are two schools of thought about this. One is "just keep that window
short and at a time of low usage, and hope no one will notice". The other
involves suggestions like yours. Here is what my AFS rekeying procedure says
(assumes Heimdal):
1. Generate a new DES key on the master AFS server, store it in a temporary 
   keytab. The command is:
   ktutil -k afs.keytab add -p afs/cell.name -V kvno -e des-cbc-crc -r
   The key version number should be one more than the current value for
   this principal. 
2. Add the key to the AFS keyfile:
   asetkey add kvno afs.keytab afs/cell.name
   (again, with the appropriate key version number). 
3. Wait for the AFS keyfile to propagate to all servers. One can use
   bos listkeys server -localauth
   to verify that the named server has been updated. 
4. Use asetkey list to get the 16-byte hexadecimal string representation of
   the new key. This can also be extracted from the keytab using
   ktutil -k afs.keytab list --keys
5. Add the new key to the KDC database:
   kadmin cpw --key=hexvalue afs/cell.name
   If the afs/cell.name principal doesn't exist yet, kvno must be 1 and
   one should use add instead of cpw. 

[I'm not sure that last sentence is still relevant; it was written years ago.
If Heimdal now supports creating principals with kvno>1, feel free to do that.
If not, and if afs@MATH.CORNELL.EDU still has kvno=1, I'd suggest rekeying it
and removing the old kvno=1 key before creating afs/math.cornell.edu@...]

Then there are a couple of cleanup steps:
6. When migrating from afs@ to afs/cell.name@ only: remove the afs@ principal
   from the KDC database (once you've verified that the new afs/cell.name@
   principal works for all clients).
7. Wait one maximum token lifetime.
8. Remove the old key from the AFS keyfile.

> What do the experts think about this:
> 
> 1. Start empty heimdal KDC for MATH.CORNELL.EDU on laptop.
> 2. Create afs/math.cornell.edu@MATH.CORNELL.EDU on laptop with known 
>    (long, random) password and high kvno.
> 3. Extract AFSKEY with ktutil from KDC on laptop.
> 4. Merge AFSKEY for afs/math.cornell.edu into testserver's KeyFile.
> 5. Try to access something on testserver from laptop with key
>    material created with kimpersonate.
> 6. Merge AFSKEY into all production servers.
> 7. Create identical afs/math.cornell.edu@MATH.CORNELL.EDU on real KDC.
> 
> Warning: I have not tried this in practice, but I think in this manner
> you can back out each step without problem.

It looks similar to my (well-tested: I've rekeyed in this way many times now)
procedure above, except I don't need a laptop (and I skip your test step 5).