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

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

------- start of forwarded message -------
From: "Von Welch" <[email protected]>
To: Nicolas Williams <[email protected]>
Cc: "Douglas E. Engert" <[email protected]>,
   Brian E Carpenter <[email protected]>,
   Steve Bellovin <[email protected]>, Russ Housley <[email protected]>,
   Cees de Laat <[email protected]>, [email protected],
   [email protected]
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 protected]