[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/>