Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by krbdev.mit.edu (8.9.3) with ESMTP id QAA00353; Tue, 29 Apr 2003 16:23:19 -0400 (EDT)
Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3TKNI9j001951 for <krb5-bugs@mit.edu>; Tue, 29 Apr 2003 16:23:18 -0400 (EDT)
Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 2E99215226A; Tue, 29 Apr 2003 16:23:18 -0400 (EDT)
To: krb5-bugs@mit.edu
Subject: GSSAPI can fail to generate error in GSS_C_NO_CREDENTIAL case
Message-Id: <20030429202318.2E99215226A@konishi-polis.mit.edu>
Date: Tue, 29 Apr 2003 16:23:18 -0400 (EDT)
From: hartmans@MIT.EDU (Sam Hartman)
X-RT-Original-Encoding: iso-8859-1
Content-Length: 341


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.