[OpenAFS] Heimdal KDC bug mentioned in rekeying document

Sergio Gelato Sergio.Gelato@astro.su.se
Fri, 26 Jul 2013 13:33:08 +0200


* Ragnar Sundblad [2013-07-26 13:01:00 +0200]:
> >> I believe you should change the test to also check that ret_key == NULL:
> >>        if (clientbest != ETYPE_NULL && enctype == ETYPE_NUL && ret_key == NULL) {
> >>            enctype = clientbest;
> >>            ret = 0;
> >> 	}
> >> since if there is no common key-type, key will be NULL, and the later
> >>        if (ret == 0 && ret_key != NULL)
> >>            *ret_key = key;
> >> will return a NULL pointer.
> > 
> > Yes, good point.
> 
> (Please double check that this is correct, I haven't tried it, only read it. :-)

I'm compiling my next (and hopefully final) iteration right now.
I went for this variant:
        if (clientbest != (krb5_enctype)ETYPE_NULL &&
            enctype == (krb5_enctype)ETYPE_NULL) {
            enctype = clientbest;
            if (ret_key == NULL)
                ret = 0;
	}

> >> Does your change really work as expected? (I am a bit surprised,
> >> since in krb5tgs.c:tgs_build_reply() the result of the enctype is
> >> ignored and the key is the one used (strangely!).
> > 
> > What version of krb5tgs.c are you looking at? What I see is
> >            ret = _kdc_find_etype(context,
> >                                  krb5_principal_is_krbtgt(context, sp) ?
> >                                  config->tgt_use_strongest_session_key :
> >                                  config->svc_use_strongest_session_key, FALSE,
> >                                  server, b->etype.val, b->etype.len, &etype,
> >                                  NULL);
> > so ret_key (the last argument) is NULL.
> 
> Aha! I am looking at 1.5.2, and there it is:
> ...
>                                   server, b->etype.val, b->etype.len, NULL,
> 	                          &skey);
> 
> What version are you using?

I'm testing with Debian's 1.6~git20120403+dfsg1 but also looked at the tip
of the master branch on github.

> > This is also consistent with my understanding that the session key is
> > randomly generated by the KDC at the time of printing the ticket; it
> > should be unrelated to any long-term keys.
> 
> It does generate a random key in 1.5.2 too, but the enctype of the
> session key is taken from the enctype of "skey" above, instead of
> from "etype" in your excerpt.

Yes, that was changed by commits 12cd2c9cbd1ca027a3ef9ac7ab3e79526b1348ae
and 4c6976a6bdf8a76c6f3c650ae970d46c931e5c71 (on the master branch).