DFS/AFS-Kerberos Connectivity

Douglas E. Engert
Argonne National Laboratory


I would like to address the current state-of-the-art of forwarding a Kerberos V5 ticket, using it to establish a DCE/DFS context, and how this can be improved, both for performance and usability.


The use of a distributed file system such as DFS or AFS which requires authentication, presents additional problems to daemon process which are running as "root", and don't have the proper authentication to access the file system. This is especially noticeable when a user's home directory resides in DFS or AFS, when the user is loging in over the network.

In the past, a number of methods have been used to solve this problem. The most basic (and unsecure) method has been sending over the userid and password and getting a new AFS token or DCE/DFS context. A much more secure method of forwarding an AFS token using Kerberos V4, or using Kerberos V5 to forward a Kerberos V5 ticket which can be used to get a DCE/DFS context and/or an AFS token are also being used.

Using Kerberos V5 and forwarded tickets has some advantages and disadvantages.

The primary advantage is that a non DCE client can use Kerberos V5 to communicate with a server which uses DCE/DFS, and gain full access to all the required resources of that machine. This is very useful for rlogin, telnet, and even ssh. But it has not been added to ftp, rsh or rcp yet. Why is discussed later.

The primary disadvantage is in the overhead. Every traditional TCP session, (telnet, FTP, rsh etc.) must get another forwardable TGT from the DCE Security server/KDC even when contacting the same server. These tickets are not currently cached on the client. The server must then create a new DCE/DFS context from this forwarded TGT, which also requires contacting the Security server. This can be relatively very expensive such as when rsh is used to do a trivial operation, the cost of the ticket handling and context creation can be much more expensive then the operation itself. Multiple clients and servers all asking for tickets could also swamp the DCE security servers with requests.

The above is one reason why, I did not added modifications to the ANL_DCE mods to Kerberos V5 for rsh. (As a footnote, a user can use rsh to forward a ticket, and get a DCE context, but it currently requires a command like: "rsh -x -F host /krb5/sbin/k5dcelogin command args" This has krshd exec k5dcelogin to get the DCE/DFS context and exec the user's command.)

This was never added to FTP for two reasons. The MIT FTP currently does not forward a ticket (but the man page says it should), and the trick of exec'ing a k5dcelogin won't work from the middle of the ftpd process. See below.


DCE and Kerberos can share the same ticket cache, and follow RFC 1510 for the protocols and ticket formats. Need I saw more. Without this interoperability I would not be writing this proposal. And we can do a lot with this minimal interoperability.

The FTP complication is aggravated by the way DCE partially exposes the DCE version of Kerberos, and by the way DCE handles the context.

DCE authentication is based on an earlier version of Kerberos, and the API for this has never been exposed. But the same routine names are in the DCE libraries, and the same structure names are used in the header files, but the structures are different, and the routines take different parameters then the current MIT Kerberos release. Some of the static data structures have the same names as well. This means that if the application needs both DCE routines and Kerberos routines, you need to link the application against both libraries, which does not work. The k5dcelogin avoids this by only linking against the DCE libraries, but reads the ticket cache created by the MIT Kerberos library which contains the forwarded ticket.

When establishing a DCE/DFS context, the DCE sec_login_set_context routine which is used in k5dcelogin will establish a Process Authentication Group (PAG) for the current process, and all its new child processes. It also creates at the same time the /opt/dcelocal/var/security/creds/dcecred_xxxxxxxx ticket cache and related files and sets the KRB5CCNAME environment variable. xxxxxxxx is used to identify the PAG.

How the PAG is associated with a process and passed on to subprocesses is operating system dependent, and each DCE vendor has ported this in their own way. But the creation of the PAG is a simple syscall. sec_login_set_context then uses other routines to populate it with the needed information.


If the PAG can be created, but not initialized, in one process with a simple syscall, then filled in using set_login_set_context from some child process, then this would solve a number of problems. Separating the creation of the PAG from filling it in with information is exactly the way AFS did it, the pagsh program for example creates the PAG, and the klog program running as a child process adds the AFS tickets. I don't know why DCE was not designed to do the same from the beginning.

I have successfully created a DCE version of the pagsh which gets the PAG using the syscall, and a program k5dcelog which uses sec_login_set_context to fill it in. These currently runs on the Solaris 2.5. I will be trying them on at least AIX 4.2 and HPUX 10.20 using DCE 1.1 based systems. Looking at the DCE 1.2.2 source, this sould continue to work.

The /usr/include/dcedfs/syscall.h on Solaris 2.5 and HPUX 10 define the syscall to be used to set the PAG. Basicly a daemon program can set the PAG for the current process with the following statement:

pag = syscall(AFS_SYSCALL, AFSCALL_SETPAG, 0, 0, 0, 0, 0);

The k5dcelog which fills this in still uses sec_login_set_context which eventually calls the setpag() routine contained in libdce.* The trick which works, at least with the Transarc DCE 1.1 port for Solaris 2.5, is to provide a replacement version of setpag() which rather then doing:

pag = syscall(AFS_SYSCALL, AFSCALL_SETPAG, 0, 0, 0, 0, 0);

does :

pag = syscall(AFS_SYSCALL, AFSCALL_GETPAG, 0, 0, 0, 0, 0);

The replacement for setpag() is included in the k5dcelog.c routine.

This then returns the current uninitialized pag which was obtained by the parent process, to the sec_login_set_context routine, and it continues to fill it in. All that is left is to pass back to the parent the KRB5CCNAME environment variable via sdtout. (The parent could actually generate the name itself, given the pag value which it already knows.

This is a modification which works today, but may not work in the future, or may not work on all systems. A better solution for future versions of DCE/DFS would be to separate out the setpag() routing from the DCE lib, and to add a new call to the sec_login_* family to specify to use the PAG already setup, but uninitialized.


If a rsh, for example, could use the fact that it has been authenticated by Kerberos to access a PAG which has been created for the same Kerberos principal by some previous request, it could improve performance, by not requiring additional requests to the security server etc.

In effect if a process could join a PAG, then rshd for example could check if the same Kerberos principal is logging in, and there is a previously created PAG for the same principal, rshd could assign the new process to the previous PAG.

Currently this does not appear to be possible without kernel modifications. But the sec_login_pvt_link_ccache routine has some promise.

But DCE does have the ability to export and import a context, which also appears to include the initial TGT. If a routine was written to export the context when the first PAG was initialized for a principal, subsequent sessions for the same principal could start with this context and not require a forwardable ticket with all its overhead.

Joining a PAG, or sharing a context is not a change from the Kerberos philosophy, where the ticket cache is defined by the userid, and shared among all the user's processes. But it is a change from the DCE philosophy which is session based. Comments in the cm_xsyscalls.c source imply that the use of a PAG help protect from a superuser sneaking in and making use of someone's authentication. I don't believe that it really does a good job of protection from the super user, since the users TGT is sitting in the cache file, and the superuser could use it to get the DCE context and a new PAG, with the same access privileges.


So, I am looking for comments. Are these modification useful? Do they introduce any new security problems? Is there any support to having these added to future DCE versions?

I think the answers are Yes, No and Yes.



Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

FOLLOWUP (June 20, 1997)

I now have modifications to the MIT Kerberos 5 release 1.0pl1 which allows kshd, klogind, ftpd, telnet and rcpd to gain access to DFS.

This is done by sharing the DCE context and Process Authentication Group (PAG) among all of a uses processes. The above deamons have been modified to "exec" a new program k5dcecon, which returns the name and PAG of the DCE context to be shared.

K5dcecon can take a forwarded K5 TGT, and create a new DCE context or update an existing DCE context. If a forwarded TGT is not available, it can return the name of a DCE context to join.

The daemon then uses this context to obtain the PAG, and issues the  DFS setpag() system call for its process, and any new children processes.

Not only do these modifications give DFS access to commands like rsh, rcp and ftp, they can greatly improve performance, by cutting down on requests for tickets.
The modifications are based on being able to set the PAG value to a previously created PAG. These modifications are not in the DCE 1.1 or DCE 1.2.2 source, but are in the Transarc and AIX ports at least.  I am in the process of requesting that these modifications be submitted to the Opengroup so they can be distributed as a patch.

Beta versions of these changes can be found at:
See the readme file, k5dce.970620.tar for the DCE routines and k5101.cdiffx.970620 for the Kerberos modifications.

I call this beta, since it has only be well tested on AIX, and partial tested on Solaris. Integration with the AFS and the ak5log  which uses a forwarded K5 ticket to get an AFS token, is also not complete.

But the concept of sharing of the context and PAG is new, and solves many of the integration problems, so I am releasing it now.

So I am now ready for comments.

 Douglas E. Engert  <DEEngert@anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439
 (630) 252-5444

FOLLOWUP  (July 29, 1997)

Modifications to the MIT Kerberos 5 Release 1.0pl1 have been made which allow kshd, klogind, ftpd, telnetd, rcpd and sshd to gain access to DFS and/or AFS using a forwarded K5 ticket.

See the README.txt at ftp://achilles.ctd.anl.gov/pub/kerberos.v5

This is done by sharing the DCE context and Process Authentication Group (PAG) among all of a user's processes. The above daemons have  been modified to "exec" a new program k5dcecon, which returns the  name and PAG of the DCE context to be shared.

Since last month, when I sent out a similar note, I have added AFS  support, and have added signal handlers in case the AFS or DFS kernel  extensions are not operational. Most of the code has been localized to  two new routines k5dfspag.c and k5afspag.c which are added to libkrb5.

I have also included a ssh-1.2.19 modification to sshd to use the above  modifications too.

As I said last month, the DFS code relies on an undocumented feature  of the Solaris DFS port from Transarc and the AIX port from IBM. I  have been in contact with a number of the vendors. The OpenGroup and  HP have expressed an interest in this modification. So if you find  this code useful, please contact your vendor and request this  modification.

A sample of the modification can be found in the README.txt file in  the k5dce.970728.tar file.