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

Russ Allbery rra@stanford.edu
Fri, 26 Jul 2013 14:21:02 -0700

Andrew Deason <adeason@sinenomine.net> writes:
> Russ Allbery <rra@stanford.edu> wrote:

>> 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.

Oh!  Oh, I understand now.  (But *only* in the
svc-use-strongest-session-key path?  That's kind of weird.  I would have
expected that to be the behavior in either all paths or in only the path
that's !svc-use-strongest-session-key.  Oh, I see you say that below.)

> 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.

Indeed.  Although we're replacing one type of error with another type of
error in the worst case, so it doesn't seem like a serious problem.

> 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...

Yeah, indeed.

>> 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.

1.5.2 still has the code pattern that was mentioned elsewhere in this
thread, and, if the afs/* principal has DES keys, I'm seeing 1.5.2 return
a ticket in which both the session and server key are des-cbc-crc.  Sergio
said that was fixed on the master branch.

Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>