dbentry_supports_enctype and 1DES enctypes

[Sam Hartman]

>>>>> "Will" == Will Fiveash <William.Fiveash at sun.com> writes:

    Will> I was surprised to find out that in the case of a service
    Will> principal only have a aes256-cts-hmac-sha1-96 key that the
    Will> KDC would issue a des-cbc-crc session key for that service
    Will> principal if the client requested it in the TGS_REQ.
    Will> However if the client requests a aes128 session key (and no
    Will> des keys) then the KDC will reject the TGS_REQ.  This is
    Will> inconsistent behavior and could lead one to erroneously
    Will> assume that the service princ key enctypes in the princ DB
    Will> will restrict what session key enctypes the KDC will
    Will> generate.

Well, the list of enctypes in the KDB is supposed to be all the
enctypes that a service supports.  So it does restrict enctypes, but
more for interoperability reasons than for security reasons.

It happens to be true that everything out there today does in fact support des.

    Will> And if the admin is trying to limit the skey enctypes for a
    Will> particular service on a particular system, are they supposed
    Will> to use the permitted_enctypes krb5.conf parameter?  If so,
    Will> doesn't this affect all services on that system?

Yes.  We have not seen a customer need to limit enctypes on a
per-service (instead of per-system) basis.

Certainly any policy on what the service will accept needs to be
validated at the service.

    Will> Having the KDC restrict the session key enctype based on the
    Will> service princ keys provides some finer granularity of
    Will> control of skey enctypes as compared to permitted_enctypes
    Will> (if I am correct in assuming that permitted_enctypes is a
    Will> libdefaults section parameter).

I think what we're reluctant to do is introduce new cases where the
KDC returns an error response instead of issuing a possibly invalid
ticket.  If there are cases where the KDC returns the wrong ticket
we'd like to fix them.

Also, we'd be interested in information about significant customer
demand for per-service policy configuration.  So far we have not  seen it
materialize.