On Fri, Jul 26, 2013 at 5:09 PM, Andrew Deason <[email protected]>wrote:
> On Fri, 26 Jul 2013 13:39:22 -0700 > Russ Allbery <[email protected]> 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 couldn't come up with any situation here where it did, but I didn't do an in-depth check of things. -- Derrick
