On Tue, 30 Jul 2013 14:39:56 -0400 John Sopko <[email protected]> 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.) > 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: [email protected] > 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/[email protected] > 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/[email protected] > 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? 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 [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
