Received: from konishi-polis.mit.edu (STRATTON-ONE-NINETY-SEVEN.MIT.EDU [18.187.5.197]) by krbdev.mit.edu (8.9.3) with ESMTP id TAA12278; Thu, 1 May 2003 19:42:21 -0400 (EDT)
Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id BB1BE15226A; Thu,  1 May 2003 19:42:19 -0400 (EDT)
To: rt@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
From: Sam Hartman <hartmans@mit.edu>
Date: Thu, 01 May 2003 19:42:19 -0400
In-Reply-To: <rt-1445-5886.5.8695020757564@krbdev.mit.edu> (Nicolas Williams via's message of "Tue, 29 Apr 2003 17:02:28 -0400 (EDT)")
Message-Id: <tslhe8ekzdw.fsf@mit.edu>
User-Agent: Gnus/5.090018 (Oort Gnus v0.18) Emacs/21.2 (gnu/linux)
References: <rt-1445-5886.5.8695020757564@krbdev.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
RT-Send-Cc: 
X-RT-Original-Encoding: us-ascii
Content-Length: 818

>>>>> "Nicolas" == Nicolas Williams via RT <rt-comment@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.

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


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.