Date: Tue, 29 Apr 2003 13:59:41 -0700
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Sam Hartman via RT <rt-comment@krbdev.mit.edu>
Cc: krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #1445] GSSAPI can fail to generate error in GSS_C_NO_CREDENTIAL case
Message-Id: <20030429135941.E4352@binky.central.sun.com>
References: <rt-1445@krbdev.mit.edu> <rt-1445-5878.12.1970095716365@krbdev.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <rt-1445-5878.12.1970095716365@krbdev.mit.edu>; from rt-comment@krbdev.mit.edu on Tue, Apr 29, 2003 at 04:23:24PM -0400
RT-Send-Cc: 
Content-Length: 949

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:
> 
> 
> 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.
> 
> _______________________________________________
> krb5-bugs mailing list
> krb5-bugs@mit.edu
> http://mailman.mit.edu/mailman/listinfo/krb5-bugs