[OpenAFS] Re: MIT Kerberos des session key

[Benjamin Kaduk]

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
>