[OpenAFS] Separating AFS tokens generation from Authentication
Douglas E. Engert
deengert@anl.gov
Wed, 10 Oct 2001 12:37:35 -0500
"Neulinger, Nathan" wrote:
>
> Have you built this on recent krb5?
>
> It doesn't link in -lresolv, and also causes symbol duplication due to
> inclusion of afs's comerr as well as krb5's.
Yes comerr this is a probelm, as both had a comerr, and some of the AFS
calls some entry points which are not in the k5 version. I am using shared
libs for krb5, so include the AFS comerr as static. See below.
>
> I haven't had any luck getting it to link yet, but will keep trying.
> Different combinations/ordering of the comerr includes doesn't help.
> Removing either results in add_to_error_table undefined, and similar.
Hmm, on Solaris 5.7 with Krb5-1.2.2 (shared libs) and AFS 3.6 and GCC-2.9.3 I get
gcc -o gsiklog gsiklog.o gsiklog_afs.o \
gsiklog_gss.o gsiklog_comm.o \
-Wl,-dy,-R,/lib:/usr/lib:/lib -R/krb5/lib -L/krb5/lib -L/usr/afsws/lib -L/usr/afsws/lib/afs
-lprot -lubik -lauth -lcmd -lsys -lrxkad -lrx -llwp /usr/afsws/lib/afs/util.a
/usr/afsws/lib/afs/libcom_err.a -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -ldes425 -lsocket
-lnsl
gcc -o gsiklogd gsiklogd.o gsiklogd_afs.o gsiklog_comm.o \
gridmap.o \
-Wl,-dy,-R,/lib:/usr/lib:/lib -R/krb5/lib -L/krb5/lib -L/usr/afsws/lib -L/usr/afsws/lib/afs
-lauth -lcmd -lsys -lrx -llwp /usr/afsws/lib/afs/util.a -lgssapi_krb5 -lkrb5 -lk5crypto
-lcom_err -ldes425 -lsocket -lnsl
And LDD shows lresolve is included.
% ldd gsiklog
libgssapi_krb5.so.2 => /krb5/lib/libgssapi_krb5.so.2
libkrb5.so.3 => /krb5/lib/libkrb5.so.3
libk5crypto.so.3 => /krb5/lib/libk5crypto.so.3
libcom_err.so.3 => /krb5/lib/libcom_err.so.3
libdes425.so.3 => /krb5/lib/libdes425.so.3
libsocket.so.1 => /lib/libsocket.so.1
libnsl.so.1 => /lib/libnsl.so.1
libc.so.1 => /lib/libc.so.1
libgen.so.1 => /usr/lib/libgen.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
libdl.so.1 => /usr/lib/libdl.so.1
libmp.so.2 => /usr/lib/libmp.so.2
/usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1
>
> -- Nathan
>
> > -----Original Message-----
> > From: Douglas E. Engert [mailto:deengert@anl.gov]
> > Sent: Wednesday, October 10, 2001 10:19 AM
> > To: OpenAFS-info@openafs.org
> > Cc: security@gobus.org
> > Subject: [OpenAFS] Separating AFS tokens generation from
> > Authentication
> >
> >
> > AFS authentication and authorization have been based on Kerberos V4.
> > When used with Kerberos V5,either the KDC must issue a K4 ticket,
> > or a krb524d is required to convert V5 tickets to V4 tickets so they
> > can be used for AFS tokens.
> >
> > We would like to separate the method used for authentication from the
> > generation/use of the AFS tokens.
> >
> > As part of the Globus Project(tm), http://www.globus.org we
> > working on an
> > alternate solution, which allows other authentication methods
> > to be used to
> > obtain AFS tokens.
> >
> > This is accomplished by using GSSAPI from the client,
> > gsiklog, to authenticate
> > to a daemon, gsiklogd, running on one or more of the AFS
> > database server
> > machines. A request is then sent protected by the GSS to the
> > daemon, who
> > returns an AFS token, also protected by the GSS. The daemon
> > used the gss_inquire
> > functions to get the client's identity, and lifetime, and
> > used these to construct
> > an AFS token, using a simple mapping database which maps GSS
> > identities to AFS users.
> >
> > Since the token is sent using the GSS wrap/unwrap, it is not
> > encrypted is
> > a Kerberos tgt session key. This completely separates the
> > authentication from
> > the token generation, and in our case the GSSAPI is based on SSL.
> >
> > The gsiklog is a modified klog based on OpenAFS, and the
> > gsiklogd is a modified
> > gss demo program which calls routines based on OpenAFS to
> > generate tokens. You
> > will need the Transarc or OpenAFS libs and includes and a
> > GSSAPI implementation.
> >
> > The gsiklog and gsiklog could also be used with the Kerberos
> > GSSAPI. Doing this
> > means you don't need a KDC which understands V4, or a
> > krb524d. It also means that
> > one could use stronger keys for authentication with Kerberos
> > V5, yet still
> > use the DES keys with the tokens, or even update the keys in
> > the tokens, separate
> > from the authentication. It also means that future tokens are
> > not required to be
> > based on V4 or V5 tickets, but could use some other format.
> >
> > If anyone is interested a beta version of this is available at:
> > ftp://achilles.ctd.anl.gov/pub/DEE/gsiklog-0.9.tar
> >
> > Comments?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> >
> > Douglas E. Engert <DEEngert@anl.gov>
> > Argonne National Laboratory
> > 9700 South Cass Avenue
> > Argonne, Illinois 60439
> > (630) 252-5444
> > _______________________________________________
> > OpenAFS-info mailing list
> > OpenAFS-info@openafs.org
> > https://lists.openafs.org/mailman/listinfo/openafs-info
> >
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444