Question about keytabs and ktutil

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