Re: Document editors

Martin Rex wrote:
> 
> Douglas E. Engert wrote:
> >
> > I thing it would be important to have the WG members and editors who
> > have dealt with multiple GSSAPI implementations. The extensions
> > need to address the needs of more then just Kerberos.
> 
> violent agreement.
> 
> >
> > We need to strive to provide the generic hooks so calls to mech specific
> > routines can be made via the GSSAPI and not be calling the underlying
> > mechanisms routines directly. I believe that this is one of the traps a
> > mechanism developer can fall into as they only have to deal with their
> > own mechanism, and this has lead to applications being tied to
> > specific mechs or even specific implementations of a mech.
> 
> I don't think it is as easy as that.
> You seem to underestimate the width of the scope and the level
> of abstraction of the GSS-API spec.

Yes, I wrote the original Globus GSI. And I realiaze that there will
be situations where one needs to bypass the GSS. But we need to look 
at history and see why we needed to do this, and see if we can extend 
the GSS so this is is not nessesary. 

Storing of a delegated credential by a deamon such as SSHD is a good example.
The GGF version of gss_export_cred was designed to work with at least 
GSI and Kerberos. (See the Kerberos code below.)    

Access to internal information is another. The GGF does this by quering
by OIDs. 
  
> 
> There's nothing wrong with trying to create a model that can be used
> with several gss-api mechanisms within your framework.  But you should
> be aware that it is impossible to do any kind of that stuff with
> the level of abstraction that the GSS-API high level spec would
> require to make it part of the base spec.
> 
> Why do so many here have a problem with creating a document for an optional
> extension for GSS-API?

I agree with you. I am not yet convinced that the base document needs to 
be replaced. 

> 
> DCE has gss-api extensions (it needs it for authorization stuff),
> and so does SESAME.  Both of these are middlewares that provide
> POSIX-style access control, and both of them absolutely require
> authorization extensions.  Even Microsoft requires such extensions.

I agree with this too for pratical reasons. Even though Kerberos
is authention only, the implementations provide a simple
authoirization function, krb5_kuserok. The GSS needs to address the
need for such a simple authorization system. 


> 
> SESAME hat their extensions submitted to the IETF, but nobody
> was interested to work on it.  There was another proposal
> during 1997/98 (Generic Authorization Extensions), the last
> draft (draft-ietf-cat-gaa-cbind-05.txt) expired April 2001,
> and CAT didn't catch on.
> 
> Many authentication systems don't come with Authorization
> features -- only the middleware infrastructures like
> DCE, SESAME and Microsoft Domains have it, and maybe there
> are some home-brew concoctions using central server/repository
> (maybe even LDAP) for their access control mappings.
> But other than that, the majority of authentication system is
> just that, an authentication system. (Just wondering: are
> there any kind of SASL-extensions supporting authorization,
> or is it all either black magic (e.g. Microsoft impersonation)
> or plain authentication?
> 
> 
> Now if you think that you can come up with an abstract spec
> for moving around (delegated) credentials, 

I am not interested in moving them around, just storing a delegated
credential from a deamon so it can be used later by the user. 

> then here's a little
> work for you:
> http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/constdel.mspx
> 
> This URL links to a description of a new feature in Windows 2003.
> Besides the regular delegation it also describes an awkward new
> possibility to forge Service tickets impersonating arbitrary
> not-present users (with the option to limit the services for which
> service tickets can be forged).  TGT-less delegation and forged
> forwardable service tickets--that's the first time I see this.

Yuk!

> 
> If you come up with an abstract spec which I could then implement
> in gsskrb5.dll to map to this "fancy new feature", then we might
> have a level of abstraction that might be worth discussing.
> (btw. I don't like that new W2K3 feature, it actually sounds like
>  a big security hole to me).
> 
> However we should still go for a seperate extension document,
> since there are whole classes of gssapi mechanism where such
> kind of fiddling with credentials is architecturally impossible.
> 
> -Martin

--------------------------
export_cred.c for krb5-1.3.2:

#include "gssapiP_krb5.h"
#include <stdio.h>
#include <sys/stat.h>


#ifdef USE_GLOBUS_GGF_EXTENSIONS

OM_uint32
krb5_gss_export_cred(minor_status, 
                        cred_handle, 
                        desired_mech,  
                        option_req,
                        output_buffer)
     OM_uint32 *minor_status;
     const gss_cred_id_t cred_handle;
     const gss_OID       desired_mech;
     OM_uint32     option_req;
         gss_buffer_t  output_buffer;
{
        OM_uint32 major;
        krb5_context context;
        krb5_error_code code;
        krb5_ccache ccache;
    krb5_gss_cred_id_t  cred = NULL;
        char ccname[128];
        char tmpfname[L_tmpnam];
        char * tfp;
        struct stat stx;
        int i;

/*
    GSSAPI does not define an export_cred routine. We need to
    have the delegated cred written to a ccache, and the application
    needs to know where it is.

    We will overload the inquire_cred routine to return the
    name of the ccache, suitable for a putenv.

    If on entry the minor_status is set to a value of 57056 0xdee0
    this will cause a new copy of this
    credential to be written, and it is the user's responsibility
    to free the file when done.
    The name will be a pointer to a char * which can be used
    in a putenv.  i.e. "KRB5CCNAME=FILE:<filename>"
    The minor_status will be set to 57057 0xdee1 to indicate this.

*/


   if (GSS_ERROR(kg_get_context(minor_status, &context)))
      return(GSS_S_FAILURE);

   /*SUPPRESS 29*/
   if (cred_handle == GSS_C_NO_CREDENTIAL) {
         return(GSS_S_FAILURE);
   }
           
   major = krb5_gss_validate_cred(minor_status, cred_handle);
   if (GSS_ERROR(major))
          return(major);

   cred = (krb5_gss_cred_id_t) cred_handle;

   i = 0;
   /*
    * use the unique part of the Posix, ANSI C tmpnam
    * as part of our file name for thread safty.
    * P_tmpdir is defined as the directory part.
    */
   tfp = tmpnam(tmpfname);
   tfp = strrchr(tfp,'/');
   tfp ++;

   do {
       sprintf(ccname,"KRB5CCNAME=FILE:/tmp/krb5cc_p%d.%s.%d",
           getpid(),tfp,i++);
   }
   while(stat(ccname+16,&stx) == 0);

   if (code = krb5_cc_resolve(context, ccname+11, &ccache)) {
       *minor_status = code;
       return(GSS_S_FAILURE);
   }
   if  (code = krb5_cc_initialize(context, ccache, cred->princ)) {
       *minor_status = code;
       return(GSS_S_FAILURE);
   }
   if (gss_krb5_copy_ccache(minor_status, cred, ccache)
       != GSS_S_COMPLETE) {
                krb5_cc_destroy(context,ccache);
       return(GSS_S_FAILURE);
   }

        krb5_cc_close(context, ccache); 

        output_buffer->length = strlen(ccname) + 1;
        output_buffer->value = xmalloc(output_buffer->length);
        if (output_buffer->value == NULL) {
                        *minor_status = ENOMEM;
                return(GSS_S_FAILURE);
        }

        memcpy(output_buffer->value, ccname, output_buffer->length);

    *minor_status = 0;
    return(GSS_S_COMPLETE);
}

#endif /* USE_GLOBUS_GGF_EXTENSIONS */
-- 

 Douglas E. Engert  <[email protected]>
 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 protected]