Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by krbdev.mit.edu (8.9.3p2) with ESMTP id RAA16793; Wed, 5 Oct 2005 17:24:04 -0400 (EDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id j95LNSpx025592 for ; Wed, 5 Oct 2005 17:23:28 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id j95L6epx023224 for ; Wed, 5 Oct 2005 17:06:40 -0400 Received: from mm02snlnto.sandia.gov (mm02snlnto.sandia.gov [132.175.109.21]) j95L6UXX020012; Wed, 5 Oct 2005 17:06:30 -0400 (EDT) Received: from 132.175.109.1 by mm02snlnto.sandia.gov with ESMTP ( Tumbleweed MMS SMTP Relay 01 (MMS v5.6.3)); Wed, 05 Oct 2005 15:06:18 -0600 X-Server-Uuid: 914ACFB1-8EBC-470E-882B-54A00EED9786 Received: from ES22SNLNT.srn.sandia.gov (ec03snlnt.sandia.gov [134.253.164.158] (may be forged)) by mailgate.sandia.gov ( 8.13.3/8.13.3) with ESMTP id j95L6Et7026157; Wed, 5 Oct 2005 15:06:17 -0600 (MDT) Received: from ES20SNLNT.srn.sandia.gov ([134.253.164.29]) by ES22SNLNT.srn.sandia.gov with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Oct 2005 15:06:15 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Oct 2005 15:06:14 -0600 Message-Id: <284C755D981EB84F93CF602904340BEB014DB123@ES20SNLNT.srn.sandia.gov> X-MS-Has-Attach: X-MS-Tnef-Correlator: Thread-Topic: gss_acquire_cred with GSS_C_BOTH or GSS_C_INITIATE should work with keytab creds Thread-Index: AcXJ4Ujg44e0s70kR0iXZg7m3PXkoQACQ4Xg From: "Moore, Patrick" To: krb5-bugs@mit.edu X-Originalarrivaltime: 05 Oct 2005 21:06:15.0284 (UTC) FILETIME=[9F5B9340:01C5C9F0] X-WSS-Id: 6F5A9FC01DK4760967-01-01 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-BY: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id j95L6epx023224 X-Mailman-Approved-At: Wed, 05 Oct 2005 17:21:06 -0400 Subject: gss_acquire_cred with GSS_C_BOTH or GSS_C_INITIATE should work with keytab creds X-Beenthere: krb5-bugs-incoming@mailman.mit.edu X-Mailman-Version: 2.1 Precedence: list Sender: krb5-bugs-incoming-bounces@PCH.mit.edu Errors-To: krb5-bugs-incoming-bounces@PCH.mit.edu X-RT-Original-Encoding: us-ascii Content-Length: 1648 Sam Hartman (see below) suggested I report this as a bug. It has been there for a long time, and I understand Heimdal does not have this problem. Synopsis: When a cred cache is not available, and a keytab cred is available, gss_acquire_cred should obtain an initiator cred cache based on the keytab cred when GSS_C_BOTH or GSS_C_INITIATE flag is set. See RFC 1964, June 1996, Section 3 fourth paragraph. Severity: Probably not high, because there is a somewhat kludgy workaround that many of us use: run a cron or background process that repeatedly generates a cred cache from a keytab. (e.g., "kinit -k -t" or API equivilent) > -----Original Message----- > From: Sam Hartman [mailto:hartmans@mit.edu] > Sent: Tuesday, October 04, 2005 3:15 PM > To: Moore, Patrick > Cc: krbdev@MIT.EDU > Subject: Re: gss_acquire_cred with GSS_C_BOTH usage option > > >>>>> "Moore," == Moore, Patrick writes: > > Moore,> My reading of RFC1964, where it says . . . > > Moore,> "However, when the Kerberos 5 mechanism attempts to > Moore,> obtain initiating credentials for a service principal > Moore,> which are not available in a credentials cache, and the > Moore,> key for that service principal is available in a Kerberos > Moore,> 5 key table, the mechanism should use the service key to > Moore,> obtain initiating credentials for that service." > > Moore,> ... implies that Heimdal has the right approach. > > You're completely right. Would you mind opening a bug by > describing the problem in mail to krb5-bugs@mit.edu. Please > include a RFC 1964 reference. > > --Sam > > >