Re: Bug in 1.5.1 KDC is session key selection

Andreas Haupt <[email protected]>
Newsgroups gmane.comp.encryption.kerberos.heimdal.general
Organization DESY
Message-ID <[email protected]>
Hi Nico, Jeffrey,

well, I'm not really an expert here. This is what Andrew Deason wrote on
the OpenAFS mailing list some time ago:

---
klog doesn't specify the enc type (for any code path, as far as I can
tell). It appears to work if I set des-cbc-crc with
krb5_get_init_creds_opt_set_etype_list, but shouldn't the kdc be
restricted to the enctypes that actually exist for the princ, though, or
am I misunderstanding something here?
---

The whole thread is archived here:
https://lists.openafs.org/pipermail/openafs-info/2011-October/036935.html

So, klog.krb5 of the OpenAFS master branch has been fixed (tested with
version 1.7.4). But even the latest stable versions of the 1.4 and 1.6
trees don't have it (yet?).

To my understanding Heimdal 1.2.1 used the strongest enctype for the
session key from the list of available keys in the db during the AS
request. For the afs principal this is a des-cbc-... enctype. Heimdal
1.5 selects aes256-cts-hmac-sha1-96 which the buggy klog.krb5 versions
don't expect. If I could tell Heimdal to use a specific des-cbc- enctype
for all operations concerning the afs principal, this would restore the
former behaviour (to my understanding ...).

Cheers & thanks
Andreas

On Wed, 2012-01-18 at 11:59 -0600, Nico Williams wrote:
> What etype list should be assumed when the client sends an empty one?
> 
> I'm guessing that for TGS exchanges that should be {<ticket's session
> key>, des-cbc-crc, des-cbc-md5}.
> 
> For AS it'd be {<enctypes available for pre-auth for the given client
> principal>}.
> 
> But I need to know.
> 
> Nico
> --

-- 
| Andreas Haupt             | E-Mail: [email protected]
|  DESY Zeuthen             | WWW:    http://www-zeuthen.desy.de/~ahaupt
|  Platanenallee 6          | Phone:  +49/33762/7-7359
|  D-15738 Zeuthen          | Fax:    +49/33762/7-7216
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.