[OpenAFS] False replay error with 1.7 on Win 7 client (fwd)
Wed, 12 Dec 2012 08:57:00 +0100
* 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
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
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
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).