Re: GGF's extensions to GSS in Public Comment

Nico,

If I can try to summarize your message:

1) You seem to accept the use case of wanting to export/store
credentials in stores other than the default and be able to use those
stores in a generic manner.

2) You assert that the proper path to solve this is through extensions
which separate the storing of credentials from the administration of
the credential store. (And this is the crux of your disagreement with
gss_export_cred()?)

3) Your current draft handles the storing of credentials and you have
a new draft coming that handles credential store administration.

4) I think you imply that the the credential store administration can
be done in such a way as to abstract the notion of environment
variables (or any other mechanism-specific details) out of the API yet
still support that functionality.

Am I with you?

If so, I'd be interested in seeing your second draft. I think I can
see the benefits of your approach, but need see how the rubber and
road meet.

Von

Nicolas Williams writes (11:19 April 2, 2004):
 > On Fri, Apr 02, 2004 at 08:30:29AM -0600, Von Welch wrote:
 > > Nicolas,
 > > 
 > >  I haven't been privy to any of the hallway conversations you mention
 > > or known that they have existed. My impression from scanning the
 > > mailling lists has been that your draft was basically uncommented on,
 > > so I mistook this for a lack of interest.
 > 
 > An unfortunate case of miscommunication.  I will write separately about
 > how to avoid this in the future, after I think about this some more.
 > 
 > >  I'll respond here to your critique of our use of environmental
 > > variables in gss_export_cred() from your ID[1]. Perhaps you can give me
 > > pointers to the other critiques from you and Sam that you refer to. I
 > > don't remember these and am not having any luck with google.
 > 
 > Sam, myself, (and others?) have posted our critiques on the KRB WG list,
 > and, maybe, on the old CAT WG list, in response to Doug's posts
 > referring to the GGF's proposal or updates thereto.
 > 
 > You may want to search the KRB and CAT WG mailing list archives[1].
 > 
 > >  In regards to your comment regarding our exposure of environmental
 > > variables in our gss_export_cred() call: The reason why we chose this
 > > route is that we've had bad experiences with functions that manipulate
 > > the environment without providing knowledge of that manipulation to
 > > their calling applications. Doing this leads to the problem that if
 > > that an application wants to clean up its environment, typically in
 > > preparation for passing just the needed subset to a child, it has no
 > > way of knowing that a particular environment variable is meaningful as
 > > a pointer to a credential (unless it assumes knowledge of the
 > > underlying GSS mechanism and its use of the environment, which is what
 > > most apps seem to do).
 > 
 > I answer this below.  BTW, I have implementation experience with my
 > proposal.
 > 
 > >  As I understand your proposal to avoid environmental variables in
 > > gss_store_cred(), it seems implicit that when storing credentials in
 > > some location other than the default (i.e. default_cred == FALSE) some
 > > mechanism-specific environment variable would need to be set by the
 > > underlying mechanism (at least for the implementations of GSSAPI I'm
 > > familar with) to allow the credential to be found at later time,
 > > leading to the problem I mention above.
 > 
 > You've misunderstood the proposal.  The default_cred parameter is NOT
 > about the default credential _store_: it's about the default
 > _credential_, that which would be acquired if using GSS_C_NO_NAME, the
 > GSS_C_NO_CREDENTIAL.
 > 
 > Do not confuse "default credential store" and "default credential" --
 > these are two very different concepts.
 > 
 > The issue for both proposals is about addressing a credential store.  I
 > deliberately chose to leave that as a platform-specific matter, though I
 > gave some examples of how credential stores would be manipulated on some
 > platforms.  More below.  Please bear with me.
 > 
 > >  Using only the default credential store is fine if a user only has
 > > one set of credentials on a given system, but if a user has, for
 > > example, multiple sessions with a different delegated credential for
 > > each (so that each delegated credential can be removed on closure of
 > > its associated session) this breaks down as there is no way
 > > store_cred() can store a credential in a location other than default
 > > location and pass it through an exec() call that I can tell.
 > 
 > Again, you've misunderstood the proposal.  The following may be long,
 > but please bear with me.
 > 
 > GSS_Store_cred() stores credentials into whatever is the caller's
 > "current" credential store.  The matter of how to manipulate one's
 > "current" credential store is a platform-specific matter.
 > 
 > On Windows, for example, the current credential store might be tied to
 > user impersonation tokens.
 > 
 > On Solaris, where only a single credential store per-user is supported
 > (well, for use with Secure NFS anyways) the current credential store is
 > tied to the EUID of the caller.
 > 
 > On *nix platforms with PAM support the current credential store might be
 > settable like so:
 > 
 > extern char **environ;
 > 
 > static uid_t saved_euid = (uid_t)-1;
 > static char **saved_environ = NULL;
 > int
 > set_gss_cred_store(pam_handle_t pamh, struct passwd *pw)
 > {
 > 	int retval;
 > 
 > 	if ((retval = pam_setcred(pamh, PAM_ESTABLISH_CRED)) != PAM_SUCCESS)
 > 		return 0;
 > 	saved_environ = environ;
 > 	environ = pam_getenvlist(pamh);
 > 
 > 	saved_euid = geteuid();
 > 	if (seteuid(pw->pw_uid) < 0) {
 > 		environ = saved_environ;
 > 		saved_environ = NULL;
 > 		saved_euid = (uid_t)-1;
 > 		return 0;
 > 	}
 > 
 > 	return 1;
 > }
 > 
 > int
 > revert_gss_cred_store(pam_handle_t pamh)
 > {
 > 	char **tmp_env, **p;
 > 
 > 	if (uid_t == (uid_t)-1)
 > 		return 0;
 > 		
 > 	tmp_env = environ;
 > 	environ = saved_environ;
 > 
 > 	/* Free PAM env */
 > 	for (p = tmp_env ; p != NULL && *p != NULL ; p++) {
 > 		free(*p);
 > 	}
 > 	if (tmp_env != NULL)
 > 		free(tmp_env);
 > 
 > 	if (seteuid(saved_euid) < 0) 
 > 		return 0;
 > 
 > 	return 1;
 > }
 > 
 > Solaris 10 won't require this in that it only supports one credential
 > store per-user (again, for Secure NFS anyways), but this will be
 > perfectly ok to do on Solaris 10.
 > 
 > 
 > This can actually be abstracted more, and I have an Internet-Draft
 > waiting in the wings that provides for a very basic credential store
 > manipulation API that consists of:
 > 
 >  - GSS_Get_current_cred_store() ->
 > 	Get a handle to current cred store.  There are no store "names"
 > 	-- just handles.
 > 
 > 
 >  - GSS_Set_current_cred_store() ->
 > 	Set a current cred store; creates a new cred store if the given
 > 	store handle is GSS_C_NULL_CRED_STORE.  There are no store
 > 	"names" -- just handles.
 > 
 > 	This function cannot and does not change the user context of the
 > 	caller; that remains the caller's responsibility.
 > 
 > 
 >  - GSS_Inquire_mechs_for_cred_context() ->
 > 	List the mechs which the current store supports.
 > 
 > 
 > I hope it's clear now that gss_store_cred() does succeed in keeping
 > platform-specific details (e.g., environment variables) out of the spec,
 > and that it does so by punting (with some recommendations and examples)
 > on the matter of how to manipulate one's current credential store.
 > 
 > At the risk of repeating too much of the I-D's content here I'll remind
 > you that GSS_Acquire/Add_cred(), and all GSS-API functions that can use
 > GSS_C_NO_CREDENTIAL, implicitly assume that there is a credential store
 > in the background to acquire credentials from.  Merely adding a
 > GSS_Store_cred() patterned on GSS_Acquire/Add_cred(), and relaying on
 > the notion of an implicit credential store does not require that we add
 > an abstraction for manipulating one's credential store anymore than
 > having GSS_Acquire/Add_cred() did in the first place.
 > 
 > Cheers,
 > 
 > Nico
 > -- 
 > 
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email protected]