dbentry_supports_enctype and 1DES enctypes

[Will Fiveash]

On Tue, Sep 06, 2005 at 02:19:07PM -0400, Sam Hartman wrote:
> >>>>> "Will" == Will Fiveash <William.Fiveash at sun.com> writes:
> 
>     Will> On Mon, Aug 29, 2005 at 11:36:03PM -0400, Jeffrey Altman
>     Will> wrote:
>     >> Will:
>     >> 
>     >> Telnet specifically requests a single DES session key because
>     >> the MIT version of Telnet does not support the 3DES TELNET
>     >> ENCRYPT option.
> 
>     Will> My point is that if the remote host service princ does not
>     Will> have 1DES keys then why should the KDC issue 1DES session
>     Will> keys to the client that requests a service ticket
>     Will> (regardless of whether it's telnet or whatever)?  I can
>     Will> imagine an admin thinking that by restricting the service
>     Will> princ keys to some stronger enctype they would be
>     Will> restricting the session keys generated by KDC for that
>     Will> service to that stronger enctype.  Instead, the MIT krb code
>     Will> hard codes issuance of 1DES session keys if the client
>     Will> requests them (assuming there are no other enctype
>     Will> restricting parameters in play).
> 
> I think the concern is that we'd rather issue a ticket that may not
> work than issue an error response that is guaranteed to work.
> 
> Are you seeing cases where we issue a 1des ticket and could have
> issued something stronger?

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

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

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

-- 
Will Fiveash
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)