[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
types:
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.
Summary:
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