[krbdev.mit.edu #1445] GSSAPI can fail to generate error in GSS_C_NO_CREDENTIAL case

[Nicolas Williams via RT]

On Thu, May 01, 2003 at 07:42:26PM -0400, Sam Hartman via RT wrote:
> >>>>> "Nicolas" == Nicolas Williams via RT <rt-comment at krbdev.mit.edu> writes:
> 
>     Nicolas> Which brings us back to a discussion we had at Cthon03:
>     Nicolas> why not always decode the ap-req and use
>     Nicolas> krb5_rd_req_dec() instead of krb5_rd_req().
> 
> Not really.  Or at least I fail to see how your comment is actually
> related to the bug or the code.
> 
> Note that the code in question already has access to the server
> principal from the ap_req because it is in the path that is decoding
> it.
> 
> Correct solutions include:
> 
> * Removivg that code path and not sending back an error token if the ap_req cannot be read.

Er, no, please don't do that.  I know that there's no explicit
requirement in RFC2743 that error tokens be sent when there are errors
(heck, rfc2743 does not explicitly mention error tokens, at all) but
it's clear that always sending an error token when there's an error on
the acceptor side while processing a context token is the correct thing
to do.

> * Grabbing the server principal out of the ap-req not out of the credential.

This involves decoding the AP-REQ.

So the code as it stands needs two things, when krb5_rd_req() fails,
from the AP-REQ that krb5_rd_req() does not provide as outputs: the
AP-REQ flags and the target principal name.

So the code decodes the AP-REQ, but does not use krb5_rd_req_dec(),
which means that the decoding happens twice (once inside krb5_rd_req())
for no good reason.

Hence my suggestion that krb5_gss_accept_sec_context() always decode the
AP-REQ and always use krb5_rd_req_dec().

> What I'll probably do when I get around to it is grab the the server
> princ out of the ap-req if cred->princ is null.

This is the correct solution, of course.

Cheers,

Nico
--