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.
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.
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.
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.
I think the answers are Yes, No and Yes.
Thanks.
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
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:
ftp://achilles.ctd.anl.gov/pub/kerberos.v5
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
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.