[OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document

[Andrew Deason]

On Fri, 26 Jul 2013 13:39:22 -0700
Russ Allbery <rra@stanford.edu> wrote:

> > This plus
> > [kdc]svc-use-strongest-session-key=true
> 
> > Works.
> 
> svc-use-strongest-session-key looks like it still tries to find
> something in the common subset of supported keys between the client
> and server, and legacy aklog sends only des-cbc-crc as its supported
> keys.  So how could this work?  Isn't there still no common subset
> with a principal that has no DES keys?

That's what Sergio's patch above is supposed to fix, is my understanding
(not that I've verified it). That is, with that patch in play, the KDC
can now choose a session key enctype that is not one of the principal
key enctypes. So, legacy aklog will get a des-cbc-crc session key when
the service princ has no des-cbc-crc key.

However, my reading of that patch says that the KDC, as a last resort,
gives the client a session key no matching any principal key enctype.
This is _not_ the same as the behavior in MIT Kerberos and AD; they only
do this for the special case of single DES, not for just any enctype. I
don't know if that's intentional or not, but it is different, and I'm
not sure if that's desirable.

I'm also not sure if it's intended/desirable for this to only be in the
svc-use-strongest-session-key code path, but I may need to take a little
more time to look at this...

> And, in 1.5.2, since the server key is forced to the service key (per
> later discussion), if there *is* a DES key for the afs/* principal,
> doesn't that result in using a DES long-term key, thus making the
> update mostly pointless?

I thought we said that was fixed for 1.5 and beyond. But yes, if the
session key and the service ticket must use the same enctype (1.4
Heimdal and earlier), yes that's a problem, and that's why I'm
recommending _not_ extracting a DES key in any of these scenarios.
That's why you need to upgrade all clients if you have a 1.4 Heimdal
KDC, and don't want to upgrade it or patch it.

-- 
Andrew Deason
adeason@sinenomine.net