* Ragnar Sundblad [2013-07-26 11:43:57 +0200]:
>
> On 26 jul 2013, at 10:57, Sergio Gelato <sergio.gel...@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
>
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
