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 <[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.)
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: [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?
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
[email protected]
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
