Skip Menu |
 

History Show all quoted text — Show full headers
# Tue Mar 03 12:16:01 2015 ghudson@mit.edu (Greg Hudson) - Ticket created
Subject: gss_acquire_cred_with_password() ignores expired creds
Download (untitled) / with headers
text/plain 830B
When Luke originally implemented gss_acquire_cred_with_password(), he
had it use a memory ccache and not cache the resulting ticket. I
didn't like the performance implications of that and changed it to
use the default cache. I also made it not get tickets if the default
cache already contains creds. This has some unfortunate
implications.

At a minimum, gss_acquire_cred_with_password() needs to get new creds
if the current cache's creds are expired or close to expiring
(perhaps "more than halfway").

Another option is for gss_acquire_cred_with_password() to always get
new creds, and document that applications should first call
gss_acquire_cred() with just the name to see if there is a suitable
cred present.

It may be worth checking on Heimdal's behavior to make sure that we
aren't gratuitously divergent.
# Tue Mar 03 12:26:41 2015 hartmans (Sam Hartman) - Correspondence added
From: Sam Hartman <hartmans@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #8152] gss_acquire_cred_with_password() ignores expired creds
Date: Tue, 03 Mar 2015 12:26:39 -0500
RT-Send-Cc:
Download (untitled) / with headers
text/plain 446B
I'd say it's fairly important that gss_acquire_creds_with_password not
change the default credential that will be used by the default ccache.
If you're storing in a DIR cache it's probably OK to store in that
cache.
however I've certainly been telling application authors (and have done
so myself) it's reasonable to assuming that
gss_acquire_creds_with_password will not affect the external environment
such as the default credential.

--Sam
# Wed Mar 04 12:26:43 2015 ghudson@mit.edu (Greg Hudson) - Correspondence added
Download (untitled) / with headers
text/plain 386B
gss_acquire_cred_with_password() will not change the default cred of
the default cache, and I don't propose to change that.

Right now, if the default cache isn't collection-enabled and contains
creds for a different principal, gss_acquire_cred_with_password() will
fail, as would gss_acquire_cred() with the same name. We could
conceivably use a memory cache in that case instead.
# Thu Mar 19 15:42:48 2015 ghudson@mit.edu (Greg Hudson) - Comments added
Download (untitled) / with headers
text/plain 896B
Simo points out that it's possible to write password-verifying code
using gss_acquire_cred_with_password() and
gss_init/accept_sec_context to a locally controlled service, and the
current semantics of gss_acquire_cred_with_password() are completely
broken for that.

At this point I think it's probably best to revert to the Solaris
behavior of gss_acquire_cred_with_password(), and make any existing
applications change to use gss_store_cred() if they want. We also
need to fix gss_store_cred() as described in ticket #8010.

Unfortunately, applications won't have an easy way to tell which
behavior they will get, until everyone upgrades away from old
versions (and that's assuming Heimdal also makes the changes). The
best way to fix this is to deprecate gss_acquire_cred_with_password()
in favor of a more general function, but that requires a non-trivial
amount of design work.
# Thu Mar 19 15:43:31 2015 ghudson@mit.edu (Greg Hudson) - Ticket 8152 RefersTo ticket 8010.
# Thu Mar 19 17:13:16 2015 hartmans (Sam Hartman) - Correspondence added
From: Sam Hartman <hartmans@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #8152] gss_acquire_cred_with_password() ignores expired creds
Date: Thu, 19 Mar 2015 17:13:14 -0400
RT-Send-Cc:
Download (untitled) / with headers
text/plain 503B
Show quoted text
>>>>> "Greg" == Greg Hudson via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
Greg> Simo points out that it's possible to write password-verifying
Greg> code using gss_acquire_cred_with_password() and
Greg> gss_init/accept_sec_context to a locally controlled service,
Greg> and the current semantics of gss_acquire_cred_with_password()
Greg> are completely broken for that.

How does this break?
I think Luke has in fact written such a PAM module and it worked OK the
last time I checked.
# Thu Mar 19 17:21:37 2015 ghudson@mit.edu (Greg Hudson) - Comments added
Download (untitled) / with headers
text/plain 420B
If you don't carefully manage your KRB5CCNAME, there is the potential
that gss_acquire_cred_with_password() might succeed without making an
AS request, and the creds you have might verify correctly even though
the password was never used.

I guess that's not "completely broken" as it's possible to work around,
but it's dangerous, and it requires mechanism-specific application
knowledge or configuration to avoid.
# Thu Mar 19 17:32:21 2015 hartmans (Sam Hartman) - Correspondence added
From: Sam Hartman <hartmans@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #8152] gss_acquire_cred_with_password() ignores expired creds
Date: Thu, 19 Mar 2015 17:32:20 -0400
RT-Send-Cc:
Download (untitled) / with headers
text/plain 446B
Show quoted text
>>>>> "Greg" == Greg Hudson via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
Greg> If you don't carefully manage your KRB5CCNAME, there is the
Greg> potential that gss_acquire_cred_with_password() might succeed
Greg> without making an AS request, and the creds you have might
Greg> verify correctly even though the password was never used.

Was this true when it generated a memory ccache?
Is that the behavior you want to go back to?
# Thu Mar 19 19:25:30 2015 ghudson@mit.edu (Greg Hudson) - Comments added
Download (untitled) / with headers
text/plain 227B
Yes, the Solaris behavior (and the behavior Luke initially implemented)
is that an AS request is always made and the creds always land in a
unique MEMORY ccache. The caller can store those with
gss_store_creds() if desired.
# Mon Jul 06 15:04:12 2015 ghudson@mit.edu (Greg Hudson) - Given to ghudson@mit.edu (Greg Hudson)
# Mon Jul 06 15:04:12 2015 ghudson@mit.edu (Greg Hudson) - Status changed from 'open' to 'review'
# Mon Jul 06 15:04:12 2015 ghudson@mit.edu (Greg Hudson) - Correspondence added
From: ghudson@mit.edu
Subject: git commit
Download (untitled) / with headers
text/plain 805B

Use memory cache in gss_acquire_cred_with_password

gss_acquire_cred_with_password() was originally introduced in Solaris.
When we introduced it in 1.9, we unfortunately gave it different and
less useful semantics. Restore this function to the Solaris
semantics, which are to always get credentials and store them in a
private memory ccache. The caller can use gss_store_cred() to make
the resulting creds visible to other processes if desired.

https://github.com/krb5/krb5/commit/1be1c3593e6a50cbed2e5d2d52b98d4413f669d4
Author: Greg Hudson <ghudson@mit.edu>
Commit: 1be1c3593e6a50cbed2e5d2d52b98d4413f669d4
Branch: master
src/appl/gss-sample/t_gss_sample.py | 11 ++++++++---
src/lib/gssapi/krb5/acquire_cred.c | 24 +++++++++++++++---------
2 files changed, 23 insertions(+), 12 deletions(-)
# Fri Sep 18 12:54:13 2015 tlyu (Taylor Yu) - Status changed from 'review' to 'resolved'
# Fri Sep 18 12:54:13 2015 tlyu (Taylor Yu) - Version_Fixed 1.14 added