Re: GGF's extensions to GSS in Public Comment

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
-- 
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]