[OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document
Derrick Brashear
shadow@gmail.com
Fri, 26 Jul 2013 17:26:24 -0400
--e89a8ff24855787f3004e270cb1e
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Jul 26, 2013 at 5:09 PM, Andrew Deason <adeason@sinenomine.net>wrote:
> 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 couldn't come up with any situation here where it did, but I didn't do an
in-depth check of things.
--
Derrick
--e89a8ff24855787f3004e270cb1e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, Jul 26, 2013 at 5:09 PM, Andrew Deason <span dir=3D"ltr">&l=
t;<a href=3D"mailto:adeason@sinenomine.net" target=3D"_blank">adeason@sinen=
omine.net</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Fri, 26 Jul 2013 13:39:=
22 -0700<br>
Russ Allbery <<a href=3D"mailto:rra@stanford.edu">rra@stanford.edu</a>&g=
t; wrote:<br>
<br>
> > This plus<br>
> > [kdc]svc-use-strongest-session-key=3Dtrue<br>
><br>
> > Works.<br>
><br>
> svc-use-strongest-session-key looks like it still tries to find<br>
> something in the common subset of supported keys between the client<br=
>
> and server, and legacy aklog sends only des-cbc-crc as its supported<b=
r>
> keys. =A0So how could this work? =A0Isn't there still no common su=
bset<br>
> with a principal that has no DES keys?<br>
<br>
</div>That's what Sergio's patch above is supposed to fix, is my un=
derstanding<br>
(not that I've verified it). That is, with that patch in play, the KDC<=
br>
can now choose a session key enctype that is not one of the principal<br>
key enctypes. So, legacy aklog will get a des-cbc-crc session key when<br>
the service princ has no des-cbc-crc key.<br>
<br>
However, my reading of that patch says that the KDC, as a last resort,<br>
gives the client a session key no matching any principal key enctype.<br>
This is _not_ the same as the behavior in MIT Kerberos and AD; they only<br=
>
do this for the special case of single DES, not for just any enctype. I<br>
don't know if that's intentional or not, but it is different, and I=
'm<br>
not sure if that's desirable.<br>
<br></blockquote><div>I couldn't come up with any situation here where =
it did, but I didn't do an<br>in-depth check of things. <br></div></div=
>-- <br>Derrick
</div></div>
--e89a8ff24855787f3004e270cb1e--