Question about keytabs and ktutil

[Brian Candler]

Could someone please explain to me why there needs to be a separate entry in
the keytab for each encryption type which might be encountered? Is the key
somehow partially-processed before it is stored?

In some circumstances I'd like to add a principal in the KDC with a
manually-chosen passphrase, and enter the same passphrase into a keytab at
the host side, rather than use kadmin on that host or use kadmin on another
host and then copy the keytab across.

But ktutil makes it clear that separate entries are needed for each
encryption type:

$ ktutil
ktutil: addent -password -p HTTP/foo.example.com -k 4 -e aes256-cts
Password for HTTP/foo.exa...@EXAMPLE.COM:
ktutil: addent -password -p HTTP/foo.example.com -k 4 -e arcfour-hmac
Password for HTTP/foo.exa...@EXAMPLE.COM:
ktutil: addent -password -p HTTP/foo.example.com -k 4 -e des3-hmac-sha1
Password for HTTP/foo.exa...@EXAMPLE.COM:
wkt /etc/apache2/krb5/krb5.keytab

and I was just wondering what's the fundamental constraint which means this
is necessary.

(It might also be convenient if ktutil could ask for the passphrase once and
create multiple entries for the different ciphers, but that's a different
point)

---+++---

Supplementary question about allow_weak_crypto.

I'm running mit 1.8.1 under Ubuntu 10.04.1 LTS, with mostly out-of-the-box
config. I don't have allow_weak_crypto in /etc/krb5.conf. kdc.conf was
autogenerated by debconf at install time:

[kdcdefaults]
kdc_ports = 750,88

[realms]
EXAMPLE.COM = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 750,88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-hmac-sha1
supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3
default_principal_flags = +preauth
}

Now, if I create a principal in kadmin and look at it with getprinc, it
tells me it has 8 keys, including those weak ciphers listed in
supported_enctypes.

Number of keys: 8
Key: vno 4, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
Key: vno 4, ArcFour with HMAC/md5, no salt
Key: vno 4, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 4, DES cbc mode with CRC-32, no salt
Key: vno 4, DES cbc mode with RSA-MD5, Version 4
Key: vno 4, DES cbc mode with RSA-MD5, Version 5 - No Realm
Key: vno 4, DES cbc mode with RSA-MD5, Version 5 - Realm Only
Key: vno 4, DES cbc mode with RSA-MD5, AFS version 3

So does this mean a KDC will still generate keys for weak algorithms, but
won't actually use them unless allow_weak_crypto=true ?

Thanks,

Brian.

[Greg Hudson]

On Thu, 2010-12-23 at 13:53 -0500, Brian Candler wrote:
> Could someone please explain to me why there needs to be a separate entry in
> the keytab for each encryption type which might be encountered? Is the key
> somehow partially-processed before it is stored?

Different enctypes have different keys. If the key is based on a
password, then there is an enctype-specific method ("string-to-key") for
turning the password into a key. String-to-key functions are difficult
to reverse, so if a keytab is compromised, the password itself might not
become known (relevant if it was also used for a different purpose).

> In some circumstances I'd like to add a principal in the KDC with a
> manually-chosen passphrase, and enter the same passphrase into a keytab at
> the host side, rather than use kadmin on that host or use kadmin on another
> host and then copy the keytab across.
>
> But ktutil makes it clear that separate entries are needed for each
> encryption type:

Yeah, that's not the friendliest UI for this operation. I'll make a
note.

In a more perfect world, you would only need one enctype for a service
principal. Unfortunately, because our KDC assumes that the enctypes
present for a service also indicate the session key enctypes handled by
the service, there must be overlap between the client's
permitted_enctypes and the server principal's enctypes.

> So does this mean a KDC will still generate keys for weak algorithms, but
> won't actually use them unless allow_weak_crypto=true ?

Yes. allow_weak_crypto does not filter supported_enctypes (which is
used when a principal is keyed without specifying a key-salt list), but
does filter the enctypes the KDC will actually permit in requests.