Subject: Fwd: Re: GGF's extensions to GSS in Public Comment

From: Von Welch <[email-masked]>
Date: Fri, 2 Apr 2004 08:30:29 -0600

[Resending note to Nicolas to lists with right from address for list]

------- start of forwarded message -------
From: "Von Welch" <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: "Douglas E. Engert" <[email-masked]>,
   Brian E Carpenter <[email-masked]>,
   Steve Bellovin <[email-masked]>, Russ Housley <[email-masked]>,
   Cees de Laat <[email-masked]>, [email-masked],
   [email-masked]
Subject: Re: GGF's extensions to GSS in Public Comment
Date: Fri, 2 Apr 2004 01:38:11 -0600

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.

 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.

 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).

 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.

 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.

Von

[1] http://www.ietf.org/internet-drafts/draft-williams-gssapi-store-deleg-creds-00.txt 

------- end of forwarded message -------
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 2 Apr 2004 11:19:28 -0600

> 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.

> 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].

> underlying GSS mechanism and its use of the environment, which is what

I answer this below.  BTW, I have implementation experience with my
proposal.

> 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.

> 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
--

---

From: Von Welch <[email-masked]>
Date: Mon, 5 Apr 2004 13:46:46 -0500

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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 5 Apr 2004 19:39:05 -0500

> stores in a generic manner.

I accept the first part.  And I agree that it would be nice to have a
generic interface for manipulating what is the "current credential
store" view, but I do not agree that it is necessary.

I have given examples of how GSS-API applications can manipulate their
current credential store view on various platforms.

And I've described (but not fully specified) a generic interface for
manipulating one's current credential store view.  But do note the
limiting factor to designing such a generic interface:  user context
changes cannot now be easily abstracted in a platform-independent way,
but user context switching generally implies a change in the current
credential store view.

> the credential store. (And this is the crux of your disagreement with

My disagreement with gss_export_cred() is all about its use of
environment variables.  I'm about to post separately on this.

> a new draft coming that handles credential store administration.

Yes.

> still support that functionality.

Yes.

> Am I with you?

Yes.

> see the benefits of your approach, but need see how the rubber and

I'll send you a draft draft privately.

Please see my next post about the problems with environment variables.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 5 Apr 2004 19:44:59 -0500

Having addressed your comments on GSS_Store_cred(), I'll now re-iterate
and expand on the problems with using environment variables in the GGF
proposal.

The problems with the use of environment variables are:

1.  Environment variables are PLATFORM-SPECIFIC:

     - not all platforms can be expected to have this facility
     - not all platforms can be expected to have the same semantics it

2.  GSS_Export_cred() w/ export-to-env-var CANNOT BE MADE THREAD-SAFE

    Environment variables are generally global to a process, not local
    to a thread, which means that exporting credentials to env vars is
    inherently not thread safe, at least not if the variable names
    intended to be used are the same for every call.

    The GGF text says that putenv(3) on the output env var makes the
    credentials available.  There can be no more than one current
    credential store at any given time, so I conclude that that
    gss_export_cred() with option_req == 1 followed by putenv(3) cannot
    be made thread-safe.

    This precludes any future evolution, of operating systems that
    support the GGF gss_export_cred() function, towards having
    multi-threaded GSS-API acceptors w/ PER-THREAD GSS credential
    stores.  (Please don't assume that this means something about the
    future evolution of Solaris.)

3.  Environment variables are ill-suited for sharing credentials with
    AFS, DFS, NFS, CIFS, etc...

    Think of AFS tokens, Secure NFS, etc..., where the kernel must know
    about the current credential store of a thread or process...

    How can environment variables tell the kernel where those
    credentials are located?  How can putenv(3) do it?

    putenv(3) doesn't tell the kernel anything.

    Changing putenv(3) to interpret "special" variables and take special
    action for them to address this problem is simply not acceptable.

    Since many operating systems support features such as AFS, DFS,
    Secure NFS, CIFS, etc... using GSS-API credentials (or similar[1]),
    we MUST have a way to make credentials available to the OS kernel
    (or, perhaps, through IPC to special daemons, such as Solaris'
    gssd(1M) or Windows' LSA).

    And surely you do not propose that GSS acceptors on AFS/DFS/NFS/CIFS
    clients do additional platform-specific things to make delegated
    credentials available to the kernel/gssd/LSA/..., or do you?

    Have you discussed this at all with any implementors of
    kerberized/GSSified networked filesystem protocols?

One gets the impression that the GGF GSS_Export_cred() model is based on
the existing practice of several Kerberos V implementations of using
environment variables to address credential stores.

(Doesn't the new Kfw MLSA ccache type pretty much mean that Kfw has a
single credential store peruser on Windows?  Yes, it can still use
KRB5CCNAME for other ccache types, but those aren't shared with the
LSA...)

GSS_Store_cred() does not suffer from any of these problems.

The GSS_Store_cred() proposal does acknowledge that manipulation of the
caller's view of the "current credential store" is a platform-specific
matter, though I've also proposed (not in I-D form) a generic interface
to address this (as well as it can be addressed w/o abstracting user
impersonation).

The only matter that is definitely platform-specific and cannot be
addressed by any proposal in this space is the matter of how to switch
user contexts, on multi-user systems (which most GSS-API acceptors run
on).

[1]  AFS uses Kerberos IV, though it seems possible to use it with
     Kerberos V and, in any case, with krb524 it's possible to use
     GSS-API initiator credentials for the Kerberos V mechanism with
     AFS.

Cheers,

Nico

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 05 Apr 2004 22:06:46 -0400

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 05 Apr 2004 22:12:03 -0400

>KRB5CCNAME for other ccache types, but those aren't shared with the
MIT krb5_ccache API provides access to multiple
ccache types.  These include "FILE:", "API:",
"MEMORY:", and "MSLSA:" at the current time.
On Windows and Macintosh, the default krb5_ccache type
is "API:" (aka CCAPI).  The "MSLSA:" krb5_ccache type
provides shared access to the LSA cache allowing the
same credentials to be used by both MIT Krb5 API clients
and Kerberos SSP clients.

>     GSS-API initiator credentials for the Kerberos V mechanism with
OpenAFS and Arla support both Kerberos IV and Kerberos 5 tickets
types.  krb524d is not required when an appropriate aklog is
provided.  MIT KfW 2.6.1 will provide such an aklog.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 5 Apr 2004 23:59:13 -0500

[Off topic]

> and Kerberos SSP clients.

This was my understanding.  Is there only one LSA cache per-user?  This
is interesting here because where there's one cache per-user the
environment variable thing makes no sense at all.

> provided.  MIT KfW 2.6.1 will provide such an aklog.

Sure, but that's not interesting here.  What's interesting is the need
to share a credential store with another entity (the kernel, gssd, the
LSA, whatever) -- putenv(3) hardly fits the bill for that.

Nico

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 06 Apr 2004 01:19:08 -0400

>environment variable thing makes no sense at all.
There is one cache associated with the LSA session.
A process or thread can create a new cache which is not
associated with the session.  However, it would be
inappropriate to use an environment variable in this case. 

Within the context of a logon session a krb5_ccache name is unique.
There is no guarantee that the krb5_ccache name will be unique across
the entire system.   Using an environment variable would certainly
fail in any situation in which you either had a single process (a 
multi-threaded
server) in which each thread must maintain its own cache reference
or where the processes exist in different logon session spaces.  For example
a user process communicating with a daemon process.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 6 Apr 2004 00:24:20 -0500

> a user process communicating with a daemon process.

You have just proven one of my points.  Thank you.  Perhaps this was not
so off-topic after all :)

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 6 Apr 2004 00:31:14 -0500

> I'll send you a draft draft privately.

Or publically.  Attached.

I've not yet updated my I-D template, and this draft I-D needs more
text, particularly an intro.

Cheers,

Nico
--

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 06 Apr 2004 10:19:12 -0500

There seams to be a more underlying problem here, and that is how 
to store credentials to be used by the kernel for uses like 
NFSv4, AFS, DFS or even IPSEC. The problem gets tied in with what AFS 
and DFS call a Process Authentication Group (PAG) which is a way of 
associating processes which share credentials in the kernel.  

Nico appears to be arguing that there is a credential store capability
that a process is running under that gssapi needs to be able to store into,
where as the GGF is saying, there is not such a credential store
and each mechanism has its own way to store credentials and a process may 
have multiple sets of credentials available, and that gssapi needs to
be able to store delegated credentials in such a way that they can be used
by gss_acquire_cred in a child process. These are not inconsistent, see below. 

I think that the older DCE/DFS tried to address both of these situations,
i.e. having Kerberos credentials available for use by applications and by 
DFS via the kernel and PAGs. They did this by constraining the the 
KRB5CCNAME to be a file in /opt/dcelocal/var/security/dcecreds/krb5cc.XXXXXXXX
I may have the exact location wrong, but the idea is it was a well known 
location with XXXXXXXX being the DFS PAG number. This allowed DFS in the kernel
to use the dced process (or some helper process of the kernel) to get 
additional kerberos tickets to be used in the kernel. (I believe on AIX
each thread could have its own PAG, but my memory could be failing.) 

AFS did not have this problem, as the AFS token in the kernel was only acquired
once and there was no need for the kernel to need to acquire additional tokens
using credentials stored outside of the kernel. 

The GGF gss_export_cred returns a string suitable to be used by putenv.
But this does not mean that it has to be a file name, it is a URL that can be
used by the gssapi in subsequent processes to locate credentials.
On a system where credentials are handled by a credential manager, the URL could 
even be ignored.  

I don't think we are that far apart. We need to look at the larger picture of
how credential management can be done by the operating system, so credentials
can be used by the kernel as well as used by the application. We also need
to realize that an application may be using multiple credentials for its
own purposes i.e. SSL, TCP where the kernel isn't involved at all. 
We need for gssapi to be able address both needs.   

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 6 Apr 2004 13:19:27 -0500

> by gss_acquire_cred in a child process. These are not inconsistent, see below. 

[...]
> On a system where credentials are handled by a credential manager, the URL could 

Doug, this does not address the issues with the use of environment
variables in GSS_Export_cred().

> own purposes i.e. SSL, TCP where the kernel isn't involved at all. 

GSS_Store_cred() does not care what sort of credential store you're
storing into -- GSS_Store_cred() assumes there's a "current" credential
store available when it is called.

> We need for gssapi to be able address both needs.   

I think GSS_Store_cred() + GSS_Get/Set_current_cred_store() proposal
covers both needs.  The GSS_Get/Set_current_cred_store() proposal needs
more text to cover this, but I'm convinced it can cover your needs.

If you don't care about the user-land+kernel vs. user-land-only
distinction then GSS_Store_cred() may be all you need.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 6 Apr 2004 22:24:24 -0500

> distinction then GSS_Store_cred() may be all you need.

Actually, I don't think GSS_Store_cred()/GSS_Get/Set_current_cred_store()
should directly distinguish between credential stores of one kind
(user-land only) and another (kernerl+user-land).  I believe that the
default_cred parameter of GSS_Store_cred() provides enough of a hint to
the implementation as to what kind of store to use, where such a hint is
needed at all.

I don't think we should saddle generic interfaces with platform-specific
details.

Cheers,

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 7 Apr 2004 12:13:21 -0500

> the implementation as to what kind of store to use, where such a hint is

To further clarify this: NFS/AFS/DFS/CIFS/etc... generally use the
default credential (GSS_C_NO_CREDENTIAL), in fact, they have to because
the interfaces[1] through which an application uses filesystems do not
provide for an initiator name or credential input parameter.

Therefore the default_cred input parameter of GSS_Store_cred() provides
enough information for the implementation to decide whether or not to
make the given credentials available for use by remote file system
protocols.

[1]   Think of Unix system calls, such as open(2).

Cheers,

Nico

---

From: "Douglas E. Engert" <[email-masked]>
Date: Wed, 07 Apr 2004 12:58:00 -0500

> [1]   Think of Unix system calls, such as open(2).

Ah, but applications like a web server may wish to have multiple credentials
one for each sesion, and may wish to keep track of these, and to pass then
on to child preocesses  or scripts where they ae used for access to 
NFS/AFS/DFS/CIFS/etc ...

The web server itself may wish to access files using different sets of credentials
too form the same process too.  

So how do you propose that the application handle multiple delegated credentials?

--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 7 Apr 2004 13:05:56 -0500

> on to child preocesses  or scripts where they ae used for access to 

So?  They can do so just fine with GSS_Store_cred().  Just keep the
delegated credential handle around and GSS_Store_cred() it when
switching to the context of the user being impersonated.

> too form the same process too.  

A process (or thread, depending on the platform) can only have one set
of default credentials for use when accessing the file system.  This is
true on every *nix platform and on Windows.

> So how do you propose that the application handle multiple delegated credentials?

Keep all of those delegated credential handles around and store them as
necessary when impersonating users.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 7 Apr 2004 13:24:08 -0500

> true on every *nix platform and on Windows.

This should have read: "A process ... can only have one set of default
credentials at any given time for use ..."
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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-masked]

---

From: Martin Rex <[email-masked]>
Date: Thu, 8 Apr 2004 01:57:57 +0200 (MET DST)

>      - not all platforms can be expected to have this facility

Correct.  I was told that MacOS up to 9.x didn't have environment variables.

>      - not all platforms can be expected to have the same semantics it

Someone who thinks that environment variables are a good idea probably
has very little programming experience on Microsoft Windows platforms.

On Microsoft Win32 (and Win64 of course) an EXE and every single one
of the DLLs that are loaded by the EXE can bring along it's own
code instance of a C runtime library with it's own private STDC
objects (i.e. private FILE * handles, private heap allocators,
private environment variables).  And this is not only a theoretical
possibility, it actually happens.  It can even happen if both,
EXE and DLL were linked against the multi-threaded DLL "MSVCRT.DLL",
but built with different compiler versions (i.e. one was built with
Visual Studio 98 and the other with Visual Studio .NET).

The result is that environment variables created/updated by the EXE
via putenv() are not visible to the code in the DLL...

This is a pretty surprising (mis-)feature of the Win32 platform and
the result of indepedent instances of the C-Runtime library.
Unfortunately very few developers seem to be aware of this problem.

On most Unix systems this is impossible, because the commonly used "brk()"
interface for process heap management and this is a highlander interface
that cannot be used by several independent heap allocators within a
single process.

-Martin

---

From: Von Welch <[email-masked]>
Date: Wed, 7 Apr 2004 18:03:24 -0500

Nico,

This text from your draft describing set_current_cred_store() gets at
the problem we were trying to solve by including env variables in the
output of gss_export_cred():

>    Calls to this function MAY have platform-specific side effects (e.g.,
>    setting environment variables, setting a process' "pag," etc...), but
>    an implementation of it MUST NOT change the user context of the
>    application, a restriction applicable only on multi-user platforms.

For credential stores that are meaningful to the kernel, the
application doesn't in general have to be aware of them since the
kernel will generally make sure the process doesn't accidentially
meddle with them. (E.g. if a process changes its PAG it typically
knows what it is doing.)

But for GSS mechanisms that don't have kernel support for their
creentials stores and use environment variables, this isn't the
case. A process might decide to clean up its environment for a number
of reasons and accidentially effect the GSS mechanism's current
credential store or fail to pass the meaningful env variable to a
child process as in SSHD.

This is what led us to have a mechanism that allowed the GSS mechanism
to tell the calling application that a particular env variable was
meaningful to it so that a well behaved application could treat that
variable appropriately.

You are right in that our use of environment variables was focused on
a couple of specific mechanisms (GSI & Krb5) in which we were
interested. I agree the approach does not generalize well to
mechanisms that use other methods besides env variables.

However I still believe it solves a problem for those mechanisms that
I don't undertstand how your approach solves yet.

(BTW, is the intent that gss_set_current_cred_store() can create a new
credential store, presumably if cred_store_handle has some special
value?)

Von

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 7 Apr 2004 22:19:09 -0500

> Correct.  I was told that MacOS up to 9.x didn't have environment variables.

Thank you.

> has very little programming experience on Microsoft Windows platforms.

Thanks...  Sounds, er, fun?

[...]
> that cannot be used by several independent heap allocators within a

You'd be surprised at the fun you can have with a modern runtime
linker...  :)

Cheers,

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 7 Apr 2004 22:14:41 -0500

> >    application, a restriction applicable only on multi-user platforms.

Yes.  See below.

> child process as in SSHD.

The calls to [GSS_Set_cred_store()/]GSS_Store_cred() need to happen
where your application today would go about setting up the environment
(and here I don't mean just variables) of the process it will spawn or
exec.

> meaningful to it so that a well behaved application could treat that

But you failed to abstract the matter sufficiently.  See above.

> mechanisms that use other methods besides env variables.

I said (or should have, if I said "mechanisms" instead)
"implementations."  Nothing in rfc1964 (the Kerberos V mechanism) says
[or ought say] anything whatsoever about environment variables.

The implementation(s) of the Kerberos V mechanism that you are used to
happen to use environment variables, but I dare say that this is mostly
a result of those implementations being alien to the operating systems
on which they are used.  Native implementations (e.g., Microsoft's)
don't have anything at all to do with environment variables.

> I don't undertstand how your approach solves yet.

I make another attempt to explain it below.  To me it's clear as it can
be.

> credential store, presumably if cred_store_handle has some special

 - The intent of GSS_Get_cred_store() is to get a handle for the current
   credential store.

 - The purpose of GSS_Set_cred_store() is to set the current cred store
   to the given handle OR, if the NULL handle is given, to a *new*
   store.

 - The intent of GSS_Store_cred() is to store the given credential into
   the current credential store.

I consider GSS_Get_cred_store()/GSS_Set_cred_store() to be optional
because the one factor that cannot be easily abstracted is user context
switching (e.g., setuid(2)), yet user context switching generally does
[must!] change the current credential store (switching user context
means giving up access to some objects and gaining access to others).

So you see, on platforms with one credential store per-user, as opposed
to per-session, there is no need at all for GSS_Get/Set_cred_store()...
-- user context switching suffices, and all multi-user platforms have a
way to do that already!

If this is still not clear maybe we should have a conference call, or
perhaps we can discuss this in person at the next IETF meeting, or
perhaps at the next KRB WG interim meeting, if one is held and you and I
manage to be able to attend it.

Cheers,

Nico

---

From: Wyllys Ingersoll <[email-masked]>
Date: Thu, 08 Apr 2004 09:59:11 -0400

> meaningful to it so that a well behaved application could treat that

Maybe I'm misunderstanding, but wouldn't this mean that the application
has to make assumptions about the underlying mechanisms implementation
in order to get the variable correctly?

> mechanisms that use other methods besides env variables.

I think that specifying the use of environment variables as an
interface for manipulating the configuration of the mechanisms
is a really ulgy solution.   Use of environment variables may
be acceptable in a particular implementation of a spec, but they
should definitley not be part of any standards document for a
generic interface such as this.

-Wyllys Ingersoll

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 8 Apr 2004 12:30:24 -0500

On Thu, Apr 08, 2004 at 12:17:14PM -0500, Von Welch wrote:
> 
> This statement captures what I was missing:
> 
> I think you are right, if the applicaiton understands that
> gss_store_cred() may impact the operating environment and makes sure
> to call it at the right point, this should solve the issue of setting
> up a child's environment.
> 
> However, it doesn't cover the case of an application spawning a child
> through an execle() right?

Depends.

Before I go into this I should point out that even before the advent of
either of our proposals execle()/execve() were a problem on platforms
where the current credential store is determined by environment
variables.  I.e., this is not a new problem, it's not new with my
proposal and it's not solved by yours either.

Anyways, for platforms where GSS_Set_cred_store()/GSS_Store_cred() deal
in environment variables, then yes, the application will have to be
careful to preserve parts of its environment when doing any execle() or
execve() call.

And for other platforms, where GSS_Set_cred_store()/GSS_Store_cred()
deal in per-user credential stores, or per-session credential stores
where a system call informs the kernel about a process' (or thread's)
current credential store, no, there's no execle()/execve() gotcha.

Just look at OpenSSH code, for example, and you'll see that it has to be
careful about environment variables even without throwing in the
GSS-API.

Nico

---

From: Von Welch <[email-masked]>
Date: Thu, 8 Apr 2004 12:17:14 -0500

Von

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 8 Apr 2004 12:33:51 -0500

On Thu, Apr 08, 2004 at 12:21:51PM -0500, Von Welch wrote:
> For implementations that aren't integrated with the Kernel, I don't
> think its a question of environment variables being a good idea or
> not, it's a question of "what other choice do you have?"

Oh, you have a choice: per-user credential stores instead of per-session
credential stores.

> Ideally, I agree - it would be nice we didn't have to use environment
> variables and didn't have to mess with this. But since we do, it seems
> like the best idea is to expose it so that it can be handled
> reasonably.

You don't have to use environment variables.  Looks like you used them
only because MIT krb5 did (and does).

Nico

---

From: Von Welch <[email-masked]>
Date: Sat, 10 Apr 2004 15:02:56 -0500

> in order to get the variable correctly?

The specification is that the returned variable is feedable to putenv,
so to the extent that is a de facto standard, no.

Von

---

From: Sam Hartman <[email-masked]>
Date: Fri, 23 Apr 2004 21:23:44 -0400

[ggf security group dropped; I'm not sure my comments are useful to
that forum.]

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    >> Ideally, I agree - it would be nice we didn't have to use
    >> environment variables and didn't have to mess with this. But
    >> since we do, it seems like the best idea is to expose it so
    >> that it can be handled reasonably.

    Nicolas> You don't have to use environment variables.  Looks like
    Nicolas> you used them only because MIT krb5 did (and does).

Sorry for the long delay on this issue; somehow this thread got
missorted in my mail and I just now noticed it.

Random comments Nico has been making on the phone over the last week
all start to make more sense;)

MIT Kerberos only uses environment variables on some platforms.
Fundamentally the putenv solution does not even work with all the
common instances of the mechanisms for which it is designed.

In the interests of full disclosure, I was one of two reviewers
assigned to review this proposal for the security area.  My comments
were submitted to the ADs about two weeks ago, I believe they have
been sent to parties within the GGF, although Google suggests that no
one has made them available to the public.

--Sam

---

From: Von Welch <[email-masked]>
Date: Fri, 23 Apr 2004 20:58:32 -0500

I posted the comments from Sam and John Lynn, the other reviewer Sam
mentioned, and sent out a pointer to the GGF list . You can see them
at the url below by clicking on the "View Comments" for the
GSS-Extensions document:

http://www.ggf.org/Public_Comment_Docs/Public_Comment_Documents.htm

 To provide an update on the GGF process, I have suggested to the
working group that we change the nature of the GGF extensions document
from a recommendated standard to a Experimental document (to quote
from the GGF document process, an experimental document is "To inform
the community about a useful experiment, testbed, or implementation of
an idea of set of ideas.") The intent being this would serve to
capture the implementation and requirements without confusing the
standards space. So far there has been only agreement with the
suggestion, so at this time I expect that change to happen.

Von