Ticket History #1445: GSSAPI can fail to generate error in GSS_C_NO_CREDENTIAL case

Nico points out that in accept_sec_context, cred->princ is used as the
server component of the call to krb5_mk_error.


This is problematic because sname and srealm are required fields and
cred->princ can be null in the gss_c_no_credential case.


I believe that if cred->princ is null you can get the principal out of
the decoded ap_req.

Which brings us back to a discussion we had at Cthon03: why not always
decode the ap-req and use krb5_rd_req_dec() instead of krb5_rd_req().

IIRC you did not like having the decoding API exposed, so I suggested an
API for querying encoded AP-REQs. It would also be nice to have an
exposed API to query DER encoded objects for their tag and length.

Cheers,

Nico

On Tue, Apr 29, 2003 at 04:23:24PM -0400, Sam Hartman via RT wrote:

On Thu, May 01, 2003 at 07:42:26PM -0400, Sam Hartman via RT wrote:

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.


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


This is the correct solution, of course.

Cheers,

Nico
--

Fix gss_accept_sec_context error tokens

A GSS krb5 error response contains a KRB-ERROR message, which is
required to have a server principal name, although few recipients
actually use it. Starting in 1.3, accept_sec_context would fail to
encode the error in the GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL case
(introduced by #1370) because cred->princ (which became
cred->name->princ in 1.8) is unset.

This problem got worse in 1.10 because we stopped setting the server
field in all cases due to the changes for #6855. In 1.11 the problem
got worse again when a misguided change to the mechglue started
discarding output tokens when the mechanism returns an error; the
mechglue should only do so when it itself causes the error.

Fix krb5 gss_accept_sec_context by unconditionally decoding the AP-REQ
and using krb5_rd_req_decoded, and then using the requested ticket
server in the KRB-ERROR message. Fix the mechglue
gss_accept_sec_context by reverting that part of commit
56feee187579905c9101b0cdbdd8c6a850adcfc9. Add a test program which
artificially induces a replay cache failure (the easiest failure we
can produce which has an associated RFC 4120 error code) and checks
that this can be communicated back to the initiator via an error
token.

(cherry picked from commit c547bc16f2ab6ee66c076ef944c3fbac8a66f5d4)

https://github.com/krb5/krb5/commit/5df4b25fe8e64ca1555662a11a4b8d8b042e048a
Author: Greg Hudson <ghudson@mit.edu>
Committer: Tom Yu <tlyu@mit.edu>
Commit: 5df4b25fe8e64ca1555662a11a4b8d8b042e048a
Branch: krb5-1.12
src/lib/gssapi/krb5/accept_sec_context.c | 43 ++++-----
src/lib/gssapi/mechglue/g_accept_sec_context.c | 6 +-
src/lib/krb5_32.def | 1 +
src/tests/gssapi/Makefile.in | 19 ++--
src/tests/gssapi/t_err.c | 121 ++++++++++++++++++++++++
src/tests/gssapi/t_gssapi.py | 4 +
6 files changed, 157 insertions(+), 37 deletions(-)