[OpenAFS] Heimdal KDC bug mentioned in rekeying document

[Sergio Gelato]

* Ragnar Sundblad [2013-07-26 11:43:57 +0200]:
> 
> On 26 jul 2013, at 10:57, Sergio Gelato <Sergio.Gelato@astro.su.se> wrote:
> 
> > Secondly, the following patch is required:
> > --- a/kdc/kerberos5.c
> > +++ b/kdc/kerberos5.c
> > @@ -183,9 +183,10 @@
> > 	    }
> > 	}
> > 	if (clientbest != (krb5_enctype)ETYPE_NULL &&
> > -	    enctype == (krb5_enctype)ETYPE_NULL)
> > +	    enctype == (krb5_enctype)ETYPE_NULL) {
> > 	    enctype = clientbest;
> > -	else if (enctype == (krb5_enctype)ETYPE_NULL)
> > +	    ret = 0;
> > +	} else if (enctype == (krb5_enctype)ETYPE_NULL)
> > 	    ret = KRB5KDC_ERR_ETYPE_NOSUPP;
> > 	if (ret == 0 && ret_enctype != NULL)
> > 	    *ret_enctype = enctype;
> > 
> > I'll submit it to heimdal-bugs for consideration.
> 
> 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.

> 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.

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.

As for whether my change works, I'll admit that my testing was limited to
verifying that I could get a service ticket (with AES for the ticket and
DES for the session key) and a token with 1.6.4's aklog. Checking that the
token is actually acceptable to AFS servers will come next.

> But maybe I read it incorrectly, it is a bit... involved...
> 
> /ragge
>