Andrew Deason <[email protected]> writes:
> Russ Allbery <[email protected]> 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 ([email protected])             <http://www.eyrie.org/~eagle/>
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info

Reply via email to