Skip Menu |
 

Download (untitled) / with headers
text/plain 2.2KiB
From kenh@cmf.nrl.navy.mil Thu Sep 26 16:49:15 2002
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 QAA28215; Thu, 26 Sep 2002 16:49:15 -0400 (EDT)
Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161])
by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA20365
for <krb5-bugs@mit.edu>; Thu, 26 Sep 2002 16:49:15 -0400 (EDT)
Received: from elvis.cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38])
by ginger.cmf.nrl.navy.mil (8.12.5/8.12.4) with ESMTP id g8QKnCCj018667
for <krb5-bugs@mit.edu>; Thu, 26 Sep 2002 16:49:12 -0400 (EDT)
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Received: (kenh@localhost) by elvis.cmf.nrl.navy.mil (8.6.12/8.6.11) id QAA27850; Thu, 26 Sep 2002 16:49:11 -0400
Date: Thu, 26 Sep 2002 16:49:11 -0400
Message-Id: <200209262049.QAA27850@elvis.cmf.nrl.navy.mil>
To: krb5-bugs@mit.edu
Reply-To: kenh@cmf.nrl.navy.mil
X-send-pr-version: 3.99
X-Spam-Score: hits=2.4 (**)
X-Virus-Scanned: NAI Completed
X-Scanned-By: MIMEDefang 2.17 (www . roaringpenguin . com / mimedefang)


Show quoted text
>Submitter-Id: net
>Originator: Ken Hornstein
>Organization: Naval Research Laboratory

Show quoted text
>Confidential: no
>Synopsis: Local host login results in host ticket that expires in 5 minutes
>Severity: non-critical
>Priority: medium
>Category: krb5-libs
>Class: sw-bug
>Release: krb5-1.2.6
>Environment:
System: SunOS elvis 5.8 Generic_108528-07 sun4u sparc SUNW,Ultra-1
Architecture: sun4

Show quoted text
>Description:

I noticed with the new release of Kerberos when doing login to a system using
login.krb5, I get a ticket for my local host that expires in 5 minutes. This
presents a problem when I want to connect to my local host (which isn't
admittedly normal usage, but it _should_ work, and it used to work just fine).

The reason for this is because krb5_verify_init_creds() gets a service ticket
for the local host, and takes great pains in copying it out to the application;
and then login.krb5 happily writes it to the user's credential cache.
Show quoted text
>How-To-Repeat:

Login to a machine using login.krb5; do a klist.
Show quoted text
>Fix:
It's not clear to me if the right answer is to get a longer ticket from within
verify_init_creds, or just not return it.
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1199] Local host login results in host ticket that expires in 5 minutes
From: Sam Hartman <hartmans@mit.edu>
Date: Sun, 29 Sep 2002 15:27:02 -0400
RT-Send-Cc:
It seems to me a bigger problem that the code doesn't deal with
service tickets with shorter lifetime than the TGT.


I'd recommend getting a full lifetime ticket and also causing the
ccache routines not to return expired tickets when being called by
something like mk_req.
To: rt-comment@krbdev.mit.edu
Cc: krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #1199] Local host login results in host ticket that expires in 5 minutes
Date: Sun, 29 Sep 2002 23:36:25 -0400
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
RT-Send-Cc:
Show quoted text
>It seems to me a bigger problem that the code doesn't deal with
>service tickets with shorter lifetime than the TGT.

I've never figured out what the "right" thing is here, since every
other time I've seen a service ticket with a shorter lifetime than
the TGT it's been a realm misconfiguration or cross-realm with
different lifetimes in different realms. In those two cases,
getting a new ticket from the KDC wouldn't help. Just my $0.02.

--Ken
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1199] Local host login results in host ticket that expires in 5 minutes
From: Ken Raeburn <raeburn@MIT.EDU>
Date: Mon, 30 Sep 2002 13:51:30 -0400
RT-Send-Cc:
"Sam Hartman via RT" <rt-comment@krbdev.mit.edu> writes:

Show quoted text
> I'd recommend getting a full lifetime ticket and also causing the
> ccache routines not to return expired tickets when being called by
> something like mk_req.

Not quite that simple -- under what circumstances should we still
return "ticket expired" instead of "no ticket"? Presumably for the
TGT, but that's information the ccache layer shouldn't be dealing
with. Probably the next layer up should be checking for expired
tickets.

But yes, it makes no sense to have the acquired host ticket have a
shorter lifetime than the TGT.

Ken