[OpenAFS] Question about migration to stronger encryption for AFS

[Benjamin Kaduk]

On Tue, Dec 05, 2017 at 08:28:11PM +0000, Sebby, Brian A. wrote:
> I would reply inline, but Outlook is being uncooperative, so to reply to your questions:

Understandable; thanks for not trying to force it.

> I used ‘kinit -e’ to see what encryption type was being used for the afs/<cell>@<REALM> token when I did the aklog.  The kvno of the older DES keys that had issued the older tokens was kvno = 6, while the new keys have kvno = 7.  I did not replace the DES keys in the KeyFile with the kvno = 7 DES keys since I assumed that the older tokens would need to be decrypted using the kvno = 6 key.  I don’t really need the DES version of the kvno = 7 key going forward, since my main concern is for the ~10 hours or so that any existing tokens may still be used, especially for a few longer-running processes that use AFS.

Older tokens will need to be decrypted using the kvno=6 key, yes.
But you don't need to replace the kvno=6 keys in the KeyFile; you
can add the kvno=7 ones and keep the kvno=6 ones as well.  The
incoming token has an attached kvno that tells the server which key
to use.

> Worse comes to worse, I can just restart a few things that need to access AFS and tell users to re-authenticate.

True, and that's not so bad, all things considered.

-Ben

> 
> Brian
> 
> --
> Brian Sebby  (sebby@anl.gov)  |  Information Technology Infrastructure
> Phone: +1 630.252.9935        |  Business Information Services
> Cell:  +1 630.921.4305        |  Argonne National Laboratory
> 
> 
> From: Benjamin Kaduk <kaduk@mit.edu>
> Date: Tuesday, December 5, 2017 at 1:30 PM
> To: "Sebby, Brian A." <sebby@anl.gov>
> Cc: openafs-info <openafs-info@openafs.org>
> Subject: Re: [OpenAFS] Question about migration to stronger encryption for AFS
> 
> On Tue, Dec 05, 2017 at 05:47:22PM +0000, Sebby, Brian A. wrote:
> I’m working on finally upgrading our AFS cell from DES to stronger encryption keys, and I was able to successfully follow the instructions on the OpenAFS web page to get a new keytab issued for my test cell with stronger encryption.
> However, after installing the new keytab file on my test AFS servers and restarting the processes, I found that tokens that had been issued with my previous key were no longer working - I had to do a kinit with the updated Kerberos principal and run aklog again to get a working token.
> My goal would be to make sure that existing tokens didn’t stop working when I upgrade my production cell, so I’m wondering if I did something wrong or accidentally disabled something too early.  Here are the steps I ran:
> 1.)     Have new keytab created by our AD admin that has all of the newer encryption types, as well as the older DES encryption, with a new KVNO.
> 2.)     Removed the DES keys from the keytab file.
> 3.)     Deploy the new keytab file to all of my servers as rxkad.keytab.  The old KeyFile was still in place.
> 
> The combination of 2 and 3 is probably suboptimal, in that you no
> longer have access to the DES key of the new kvno.  OpenAFS will
> attempt to look for it in the KeyFile when receiving a DES-encrypted
> ticket using that kvno, so it's best to keep it in the rxkad.keytab
> (even thoug it will not be used from there by AFS; just to keep all
> the keys in one place), and also use 'asetkey add' to insert the new
> DES key into the KeyFile.
> 
> 4.)     Restarted the AFS servers.
> 5.)     Ran kinit, and verified that the afs/<cell>@<REALM> key was still listed as des-cbc-crc.
> 
> By using kvno(1) or aklog or what?  Did the resulting token work?
> (I expect it to not work even here.)
> 
> 6.)     Had the AD admin unset the ‘DES only’ box on the account tied to the afs/<cell>@<REALM> identity.
> 7.)     Restarted the AFS servers again.
> 8.)     Ran kinit again, and verified that the afs/<cell>@<REAM> key is now listed as one of the higher encryption types.
> 
> Again, via aklog or kvno(1) or otherwise?
> 
> 9.)     Ran aklog, verified that I could write to AFS.
> 10.) Tried to write with session that had an older token, and got permission denied.  After re-kinit-ing, it worked as expected.
> 
> This older token is one from circa step 5?
> 
> I am planning to do the cell upgrade on a weekend to minimize the potential disruption, but I would still like to have my old tokens work if possible.  Did I do something wrong or restart any servers too early?
> 
> You should be able to get a more seamless upgrade than that, with
> old tickets/tokens continuing to work until they expire.
> 
> -Ben
>