Subject: Re: Section 3 Kerberos Revisions for comment

From: Ken Raeburn <[email-masked]>
Date: 17 Oct 2000 10:52:04 -0400

Joe Salowey <[email-masked]> writes:
> I have run into some problems with they way encryption types are used, and I
> think the RFC could be a little clearer. The typical problems go something
> like this
> 
> The KDC services an AS-REQ with one encryption type and does not allow the
> same encryption type when used to request a Service ticket.

That's an implementation bug.  (MIT's current release has this problem
in some cases, including certain interactions with Heimdal, but it
should be fixable by adding des-cbc-md5 and des-cbc-md4 to the
enctypes lists in krb5.conf, I think.)  The KDC should not issue
session keys of a type that the service (in this case, the TGS) will
not accept.

> The KDC uses different encryption types for the encryption of the session
> key for the client and for the encryption type of the TGT in the AS-REP.
> (This may not be a problem in itself, but if the client does not support the
> TGT encryption type then it may cause problems for the implementation
> further down the road).

The client shouldn't care about the encryption type of anything it
doesn't need to decrypt itself.  (Old MIT 1.0 clients did, it was a
bug.  The library code that made the check can be safely deleted, but
I don't have a patch handy.)

> Should the ticket for the KDC be encrypted in this encryption type or may it
> be of a different type?

The encryption type for the part of the ticket to be decoded by the
application server should be something decided between the KDC and the
application server (or its description in the Kerberos database)
alone; it has nothing to do with the client.  If the application
server has only one key, a 3000-bit key for some spiffy new
Triple-Rijnfishserpent algorithm, the client shouldn't care.

> Section 3.1.3 states
> 
> >>The encryption method used to respond to a TGS request 
> >>is taken from the keytype of the session key found in 
> >>the ticket granting ticket.  
> 
> This indicates that you want to use the same etype for the user session key
> and the TGT and that both KDC and client must support that etype. 

I read the "used to respond" part as describing how the response sent
back to the client should be encrypted, not controlling the contents.
If you don't use the encryption method and key from the TGS request,
how else would you securely get the information from KDC to client?
(Perhaps you can propose wording to make this clearer?)

Ken

P.S.  Please don't quote all of a thousand-line message just to
respond to a few lines of it.