[OpenAFS] Re: MIT Kerberos des session key

[Andrew Deason]

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.)

> 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?

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