[OpenAFS] Re: MIT Kerberos des session key

John Sopko sopko@cs.unc.edu
Wed, 31 Jul 2013 08:25:54 -0400

Ok thanks for all the input. Seems pretty straight forward for MIT
kerberos. Note I updated my /var/kerberos/krb5kdc/kdc.conf encryption

supported_enctypes = aes256-cts:normal aes128-cts:normal
des3-hmac-sha1:normal arcfour-hmac:normal

I had to restart the kadmin server, (a reload did not work), to get
the new encryption types while changing a password.
I tested ktadd on a test user and the only the above keys get created.


upgrade all servers to openafs 1.6.5
ktadd -k /tmp/rxkad.keytab afs/cell
cp rxkad.keytab to /usr/afs/etc/rxkad.keytab on all servers
restart all servers
keep KeyFile in place for a day or more then rename and touch CellServDB

On Tue, Jul 30, 2013 at 7:55 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> Andrew is spot-on, just two minor clarifications (inline)
> On Tue, 30 Jul 2013, Andrew Deason wrote:
>> On Tue, 30 Jul 2013 14:39:56 -0400
>> John Sopko <sopko@cs.unc.edu> wrote:
>>> Where is the session key for the afs/cell@REALM service principal
>>> derived from?
>> Session keys aren't usually derived from anything in the principal;
>> they're chosen randomly. There is a situation for OpenAFS specifically
>> where we derive a DES key from other things, but that only happens if
>> you disable DES for the entire KDC. That is, for an MIT KDC, it doesn't
>> have anything to do with changing the enctypes on the service principal,
>> but rather if you disable DES entirely in the KDC configuration. (As you
>> may have seen on the list, things here are different for various Heimdal
>> versions, but for MIT krb5 you don't need to deal with that.)
>>> If I remove the des-cbc-crc encryption type from both the
>>> afs/cell@REALM and the user principals will things still work without
>>> having to upgrade all clients to openafs 1.6.5?
>> Yes, probably. You should really try testing with a test environment or
>> test principal if you're unsure about what's going on, though. (You also
>> do need to upgrade and configure the _servers_ if that's not clear.)
> The MIT KDC is happy to generate a DES session key even if a service does
> not have a DES enctype in the KDB, for KDC's prior to the 1.11 release. The
> 1.11 release gives more control over this feature.
>>> But when I create a user or a user changes their passwd they do not
>>> get the "des-cbc-crc" encryption type, for example kadmin for a user
>>> shows:
>>> Principal: sopko@CSX.UNC.EDU
>>> Number of keys: 6
>>> Key: vno 38, aes256-cts-hmac-sha1-96, no salt
>>> Key: vno 38, aes128-cts-hmac-sha1-96, no salt
>>> Key: vno 38, des3-cbc-sha1, no salt
>>> Key: vno 38, arcfour-hmac, no salt
>>> Key: vno 38, des-hmac-sha1, no salt
>>> Key: vno 38, des-cbc-md5, no salt
>>> Notice there is no des-cbc-crc encryption type for a user principal, I
>>> believe this is done on purpose.
>> You have other des-* enctypes in there, though, just by the way.
>>> Using MIT "klist -e" command to show the encryption types while logged
>>> in shows:
>>> Valid starting     Expires            Service principal
>>> 07/30/13 14:16:12  07/31/13 14:16:12  krbtgt/CSX.UNC.EDU@CSX.UNC.EDU
>>>         renew until 07/31/13 14:16:12, Etype (skey, tkt):
>>> des3-cbc-sha1, des3-cbc-sha1
>>> 07/30/13 14:16:12  07/31/13 14:16:12  afs/cs.unc.edu@CSX.UNC.EDU
>>>         renew until 07/31/13 14:16:12, Etype (skey, tkt): des-cbc-crc,
>>> des-cbc-crc
>>> So currently the skey (session key) and tkt key for afs/cs.unc.edu
>>> is des-cbc-crc.
>>> So if I re-key afs/cs.unc.edu service principal to NOT USE des-cbc-crc
>>> my understanding is you still need a des-cbc-crc session key unless
>>> you upgrade all clients which is not feasible at this time. Will I be
>>> ok without a des-cbs-crc key for the user and the service principal?
> AFS doesn't care whether it's des-cbc-crc or des-cbc-md5; any DES enctype
> will do.
> -Ben Kaduk
>> You should be fine without a des-cbc-crc key. The session key is not
>> something stored in the database or anything like that; it is generated
>> every time someone gets an AFS token. MIT krb5 always permits single DES
>> session keys, unless the KDC has turned off single DES entirely, or
>> unless you twiddle with some really new options that I think don't exist
>> in 1.10.
>> If you want to see an example after the AFS service princ no longer has
>> a DES key:
>> kadmin.local:  getprinc afs/localcell
>> Principal: afs/localcell@LOCALCELL
>> [...]
>> Number of keys: 4
>> Key: vno 7, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
>> Key: vno 7, AES-128 CTS mode with 96-bit SHA-1 HMAC, no salt
>> Key: vno 7, Triple DES cbc mode with HMAC/sha1, no salt
>> Key: vno 7, ArcFour with HMAC/md5, no salt
>> $ kinit adeason
>> Password for adeason@LOCALCELL:
>> $ aklog
>> $ klist -e
>> Ticket cache: FILE:/tmp/krb5cc_1000
>> Default principal: adeason@LOCALCELL
>> Valid starting     Expires            Service principal
>> 07/30/13 14:13:37  07/31/13 14:13:37  krbtgt/LOCALCELL@LOCALCELL
>>        Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES
>> cbc mode with HMAC/sha1
>> 07/30/13 14:13:43  07/31/13 14:13:37  afs/localcell@LOCALCELL
>>        Etype (skey, tkt): DES cbc mode with CRC-32, AES-256 CTS mode with
>> 96-bit SHA-1 HMAC
>> You can also test out some of this service principal and enctype stuff
>> without any AFS infrastructure, if you want. If you run:
>> $ kvno -e des-cbc-crc afs/cellname@REALMNAME
>> You'll be doing pretty much the same thing that any old aklog does, in
>> terms of interacting with the krb5 KDC. You can try that out and test
>> other service principals if you want, to see what happens with them.
>> --
>> Andrew Deason
>> adeason@sinenomine.net
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info

John W. Sopko Jr.                    University of North Carolina
email: sopko AT cs.unc.edu      Computer Science Dept., CB 3175
Phone: 919-590-6144                Fred Brooks Building; Room 140
                                               Chapel Hill, NC 27599-3175