.so ../ADM/mac .XX authmgr 531 "Authmgr \(em An Authentication Service for Datakit" .TL Authmgr \(em An Authentication Service for Datakit .AU David Cohrs .AI Computer Sciences Dept. .br University of Wisconsin \(em Madison* .AB .PP \fIAuthmgr\fP is a service available on Ninth Edition .UX systems for authenticating users. It can be used to authenticate users inside an organization, to authenticate a terminal or workstation, or to help protect the organization from network intrusions, while allowing legitimate outside users to access the organization's computers. \fIAuthmgr\fP receives calls from users, challenges them for a password or for some other response, such as the outcome of encrypting some challenge message. When the user is authenticated, \fIauthmgr\fP makes use of the redial mechanism provided by Datakit to redial the newly authenticated call to a new service, such as a remote login service. This paper describes the design and implementation of \fIauthmgr\fP, as well as the re-implementation of call redial in the research Datakit control computer, and the administrative options used to implement \fIauthmgr\fP's policy decisions. .AE .2C .FS * This work was performed while the author was a summer intern at .MH .FE .NH 1 Introduction .PP \fIAuthmgr\fP allows users to authenticate themselves and to make authenticated calls within a trusted hardware environment, even if their call originated outside that trusted environment. To make authenticated calls, \fIauthmgr\fP makes use of a redial mechanism supported by the network interface. It was written to work in a Datakit environment, however, any virtual circuit network that supports the necessary redial mechanism could use \fIauthmgr\fP. \fIAuthmgr\fP itself runs on a .I "security computer" , currently a 10th Edition .UX system. It interfaces with the Datakit network via the Datakit interface manager (also running on the security computer) and the control channel from the security computer to the Datakit node to which it is attached. .PP \fIAuthmgr\fP serves three basic purposes. First, it allows users from outside the trusted part of the network (the .I "untrusted domain" ) to access the trusted part (the .I "trusted domain" ), without the use of ``in the clear'' passwords. This helps to protect legitimate users in the untrusted domain from other, less honorable, users also in the untrusted domain. .PP Second, all calls from outside the trusted domain can be shunted through to the authentication manager, rather than allowing them to be placed directly, as shown is Figure 1. This allows a security check on the untrusted user before allowing them to even attempt to access any service provided in the trusted domain. If the user fails the check, they have no way of accessing any of the services inside the trusted domain, even those unprotected services that are available to all users inside the trusted domain. This is useful in the environment at AT&T Bell Laboratories, where the trusted domain is made up of the various labs inside the company, and the untrusted domain is the experimental XUNET network, connecting the Murray Hill location to a number of universities around the country. .1C .KF .so fig1.x .DS C Figure 1. Rerouted call from an untrusted trunk .DE .KE .2C .PP The third purpose of \fIauthmgr\fP is to allow users of Gnot terminals to authenticate themselves to the network (equivalent to logging into a host computer), and have that terminal remain authenticated throughout the duration of their session, as shown in Figure 2. The Gnot terminal|reference(locanthi gnot) is a small computer with a video display and a network interface, but no disk. When powered on or reset, the Gnot makes a network call to a file server and retrieves an operating system kernel that allows it to run window systems, editors, and make network connections to other computers. The session terminates when the user resets or powers down the Gnot. The file server needs to have an authenticated username associated with a session, in order that it may do privilege checking. That is .I authmgr 's job. .1C .KF .so fig2.x .DS C Figure 2. Authenticating a Gnot .DE .KE .2C ......... .NH 2 The Software Architecture .PP Providing the three services described above required implementing the authentication manager itself, and also making changes to the software on the Datakit control computer. The control computer changes allow it to redial authenticated calls, to redirect calls coming in over untrusted trunks and to store the authentication information for the Gnots. The authentication manager handles all interactions with the user, obtaining a login name and a unique authenticator from the user. The controller software must be able to pass back the dialstring to the originating point of the call and either redial the call from that point, or store the authentication information if the caller was a Gnot. In addition, the trunk module software must be able to automatically redirect calls that come from an untrusted domain to the authentication manager. Implementing these functions required changes to both the trunk module processes and the host computer module processes. .PP An implementation of the redial mechanism had previously been done by Wetzel|reference(wetzel radian) for the generic Radian controller, which is slightly different from the Datakit controller used inside Murray Hill, so redial was reimplemented, with some improvements, for the research controller. Because of the direct application of redial we had in mind, the redial mechanism is currently supported only for hosts and on trunks (a Gnot looks like a host to the Datakit controller). If a user at a normal terminal attempts to call \fIauthmgr\fP and then redial their call, the redial will fail, because the necessary synchronization and redial code has not been added to the terminal module software. .PP The paper proceeds as follows. The second section describes the functions of the authentication manager and its implementation. The third section describes the redial mechanism implemented for the Datakit, and how it is used in conjunction with the authentication manager. The administrative hooks that were added to the system are also described in this section. Some final comments and conclusions constitute the fourth section. .NH 1 The Authentication Manager .PP The purpose of the authentication manager is to determine whether a user is really who they claim to be. One common way of determining the authenticity of a user is by asking them to enter a password (once we know the username they claim to be). The problem with using this approach over a network is that the password is usually sent ``in the clear'', although it isn't echoed at the user's terminal. If someone manages to tap into the user's line or the network itself, the password will be compromised. Obviously, a simple password is not a good way to authenticate users over an untrusted network. .PP A simple solution is to ask the user for the appropriate response to some challenge, something that can be sent as normal, character data, but won't be easily compromised. This is the approach taken by \fIauthmgr\fP. Currently, the challenge that \fIauthmgr\fP transmits is a decimal number, up to 8 digits long. The user must obtain an encryption calculator from the system administrators to encrypt this number. \fIAuthmgr\fP was designed so that it could be quickly extended to support any manufacturer's encryption calculator, but at the current time, only one is supported. This box, an Atalla .I Confidante terminal (despite the designation ``terminal'', the calculator is a small, 2" \(mu 3" \(mu \(14" box), is programmed to encrypt data with a key, the key having been entered into the terminal by the system administrator at the time the terminal is assigned. The .I Confidante box uses standard DES encryption to encrypt the numeric data with this key. The terminal also requires a password, which the user must enter before encrypting the challenge. When the user enters the challenge, the terminal displays an 8 hex digit number, which the user enters at their keyboard. Assuming this was the correct response, \fIauthmgr\fP can proceed. .PP \fIAuthmgr\fP also allows some users to enter the normal login and password sequence they are used to. This is useful inside the trusted organization, where the problem of compromising a password are much less, and carrying around a challenge box becomes a bother. This option can be specified on the basis of the source of the call, or on a per-user basis. .PP Another important choice in designing \fIauthmgr\fP was whether calls coming from outside the trusted domain should go first to the service the untrusted user requested (for example, the user could request to log into a trusted machine, and the call would go directly to the remote login service on that machine), and have that service call \fIauthmgr\fP for authentication purposes, or whether calls should automatically be rerouted to \fIauthmgr\fP. The former case would have required no changes to the network software, but is much too trusting. Many services in the trusted domain (AT&T Bell Labs, in this case) were written assuming that only the trusted domain existed. Allowing untrusted users to access these services could breach the security of the trusted domain, or give away information that the trusted domain is not allowed to give out (due to licensing or other similar restrictions). .PP In the interest of the security of all of the services in the trusted domain, \fIauthmgr\fP was designed assuming that calls from outside its domain would be rerouted to \fIauthmgr\fP first, before they could reach any unprotected services. This requires that the networking software reroute calls, and also requires that \fIauthmgr\fP be able to redial a call to a new destination once authentication is completed. The benefits of reducing the chances of information leaking out of the trusted domain far outweigh the added complexity to the networking software. In addition, none of the existing services need to change to benefit from the added authentication step. .NH 2 Authmgr Operation .PP \fIAuthmgr\fP operates in three different modes, depending on the command line arguments and its environment at the time it is executed. In the first mode, \fIauthmgr\fP assumes it is interacting with a human user at a terminal. This mode is used when a user connects directly to \fIauthmgr\fP. The user is prompted for a login name (unless \fIauthmgr\fP can determine the user's login name from its environment), and then is challenged to encrypt a number or enter a password. The user encrypts the number using their encryption calculator and in any case, enters the response. \fIAuthmgr\fP tests this against the correct response, and, if it is correct, prompts the user for a new destination. The user enters a new destination, and \fIauthmgr\fP attempts to redial the call. Figure 3 shows an example of such a session. .1C .KF .sp .5v .DS B .CW coma(cohrs): con -l security.security Security Authentication check login: cohrs Enter response code for 31746735: 41a46474 Number please: seki.whoami source=dk!nj/astro/security user=cohrs line=astro2.57.27.F Eof coma(cohrs): .R .DE .DS C Figure 3. A simple, interactive Authentication Session .DE .KE .2C .PP The second form is also interactive, but is used when the user is using a Gnot terminal. In this mode, the Gnot, when it is powered up, automatically connects to \fIauthmgr\fP using a special service name. \fIAuthmgr\fP again prompts the user for a login name and a challenge. However, when the user correctly enters the response, \fIauthmgr\fP does not ask for another destination. Instead, it redials the call to a special destination that the network software understands as being an ``authentication only'' message. When the source receives the redial message, it saves the authenticated name and location of the user in a safe place, and closes the connection to \fIauthmgr\fP. Until the Gnot is reset, all subsequent calls go out using this authenticated login name and security ID. .PP The third form is meant to be used in conjunction with the various remote login services available on the Datakit networks, especially the .CW dcon service (used by the .I con program), and the call rerouting option available at the trunk from an untrusted domain of the network to the trusted domain. Here, an untrusted user requests to connect to the remote login service of a computer in the trusted domain. When the call reaches the trunk to the trusted domain, the control process on the trunk reroutes the call to \fIauthmgr\fP (the details of this will be explained later). When \fIauthmgr\fP is executed to handle the call, one of the parameters in its environment is the original destination of the call, namely the login service of some host in the trusted domain. .PP \fIAuthmgr\fP sends out a special message understood by .I con . .I Con prompts the user for a login name, and sends this back to \fIauthmgr\fP. \fIAuthmgr\fP uses the login name to find the key (or password) for this user, and sends back the appropriate challenge. .I Con requests that the user encrypt the challenge or enter a password, if this is a connection inside the trusted domain. Once it receives the information, .I con sends a message back to \fIauthmgr\fP containing the response from the user. If this is the correct response, the remote login protocol continues as normal, otherwise, \fIauthmgr\fP again sends a challenge, and the cycle repeats. An example of this usage is shown in Figure 4. While the actual prompts are similar, it should be noted that con is prompting the user for the data in this example, not \fIauthmgr\fP; \fIauthmgr\fP communicates with con over the network connection. Pseudocode for \fIauthmgr\fP's side of the protocol with .I con is shown in Figure 5. .1C .KF .DS .CW fishonaplatter(cohrs): con seki login: cohrs Enter response for 55374202: 57406251 seki(cohrs): .R .DE .DS C Figure 4. A Rerouted Call to a Remote Login Service .DE .KE .2C .PP \fIAuthmgr\fP is executed once for each session that requires authentication. Upon startup, it reads some initial configuration information from its configuration file. This includes such things as the maximum number of tries a user gets before \fIauthmgr\fP closes the connection, and mappings between original source identifiers and new security identifiers. This configuration file is explained in detail in the accompanying manual page for \fIauthmgr\fP, found at the end of this paper. .PP The keys are also stored in a file on the security computer's disk. This file contains extremely sensitive information, because the keys are necessarily stored unencrypted, unlike the passwords in the .UX password file. For this reason, access to the security computer must be severely limited, not even allowing a remote login service. At the present time, the key file is stored in a protected place, but the file itself is not encrypted. In some future version on \fIauthmgr\fP, this file could be encrypted, but that would require human intervention to enter the encryption key when \fIauthmgr\fP starts up. For the purpose of simplicity, and to remove the need for human intervention, the current version relies on the physical security of the keys file. .PP The final aspect of \fIauthmgr\fP's operation is its use of the redial feature. \fIAuthmgr\fP redials the call through use of a new .I ipcredial library call in the Tenth Edition .UX IPC library. \fIAuthmgr\fP generates a message containing the authenticated name of the user, the new authenticated security identifier, and the new destination to redial. For security reasons, the ipcredial only works for the superuser. Once the call has been redialed, either successfully or unsuccessfully, the connection from \fIauthmgr\fP to the remote user is closed, and \fIauthmgr\fP exits. All in all, implementing \fIauthmgr\fP itself was straightforward, and the system support was easily adapted to the redial application. .1C .KF bottom .DS .CW int d; char user[]; char response[]; char challenge[]; con!"CH";\h'8n'/* the magic challenge protocol string */ *[ \h'8n':: con?user -> \h'16n'challenge = makechallenge(getkeyinfo(user)); \h'16n'con!challenge; \h'16n'con?response; \h'16n'encrypt(getkeyinfo(user),challenge) == response -> \h'24n'redial();\h'8n'/* \fIauthmgr\fP exits */ \h'16n'con!"CH"; \h'8n':: con?EOF -> \h'16n'exit(); ] .R .DE .DS C Figure 5. The \fIAuthmgr\fP Remote Login Protocol .DE .KE .2C .NH 1 The Datakit Redial Mechanism .PP The redial mechanism itself is supported in the network control software. In the case of the Datakit, where this work was done, this control software exists inside the network itself, in the Datakit nodes. Each Datakit node has an associated control computer; the research Datakit nodes use Digital PDP-11/23 style computers for the control computer, which directly controls the switch memory of the Datakit node. The redial mechanism is implemented as part of the software running on this control computer. .PP Each device that connects to the Datakit network connects to the Datakit node via a module, an interface card that lives on the Datakit backplane. A process inside the Datakit controller is in charge of controlling this module. In addition, if the module is multiplexed, there is a line process in the Datakit controller to control each line of the multiplexer (for our purposes, we can consider almost any module to be multiplexed, especially the host and trunk modules, in which a line is a single, logical channel on the module). .PP Datakit includes a standard signaling protocol, called VLP, which is used for setting up and taking down calls. VLP defines the interactions between the control processes for the source and destination modules in the Datakit controller. There are additional control messages between the line and control processes within the same module, but these are not defined as part of VLP. .PP Implementing the redial mechanism in the Datakit controller required changing VLP, and adding two new messages, CALLMOD and SIREQ. These messages are defined to occur only when a connection has been established; in most control processes, this is called the TALKING state. CALLMOD is a completely new message and is used for passing the new dialstring back to the point at which the call will be redialed. SIREQ already exists in the generic Datakit controller, and is used by the splice mechanism, but did not exist in the research controller. This message informs the originating point of the call (the end of the original connection that still exists in the new, redialed connection) that it needs to resynchronize its higher level protocols with its new peer. .PP Basically, a redial consists of two phases. The first phase uses CALLMOD messages to pass the new dialstring from the module that wants to redial the call to the module that will actually redial the call. At the same time, this portion of the original connection is closed down. When the CALLMOD message reaches the .I "redial point" , the module that should actually redial the call, the line process for this connection at that module generates a CALL message to open up a new connection to the new dialstring. This is the second phase of the redial. The redial point eventually receives an ANSWER or a NAK message back from the new destination of the call. This part of the protocol works just as if this were a normal call. .PP When the ANSWER reaches the redial point, instead of propagating it back to the source, we instead send the source an SIREQ message, telling it to resynchronize its protocols, and the new connection is established. The sending of the SIREQ message here differs from Wetzel's redial implementation, which assumes that the higher level protocols are using URP, and puts an URP initialization request into the datastream. We considered this to be incorrect, and possibly harmful to correct communication, and opted for fully integrating redial into the VLP protocol instead, even to the point of reinitializing the source of the original call. .1C .KF .so fig6.x .DS C Figure 6. Redialing a call on Datakit using VLP .DE .KE .2C .PP Figure 6 shows an example of these two phases of call redial. In this example, a user on the host .CW coma has connected to the host .CW security , presumably to use \fIauthmgr\fP (this step is labeled 1 in the figure). After authentication, \fIauthmgr\fP redials the call from itself to the host named .CW west . This causes the connection from the node1 Datakit to the security host to close (this step is labeled 2, and is phase 1 of the redial). When the redial request reaches node1, the control process starts a new call to the host .CW west . This call completes in step 3, and now the user on .CW coma is connected to .CW west . .PP In the example, the redial took place on the originating Datakit node. This makes for the most optimal path from .CW coma to .CW west . If we had performed the redial at node2 instead of node1, all messages between .CW coma and .CW west would have had to go through 3 Datakit nodes, rather than 2, increasing the delay and increasing the load on node2 unnecessarily. However, in cases where the original call comes from an untrusted domain, we would want the redial message (phase 1) to be intercepted by the node at the edge of the trusted domain, and have the new call be placed from there. .PP This scenario is shown in Figure 7. Here, .CW pokey is a computer in the untrusted domain, and is connected to the Datakit node, nodex. Once again, the user on pokey calls the security host, and has their call redialed to .CW west (steps 1 and 2). However, node1 intercepts the redial message and performs phase 2 of the redial itself, rather than forwarding it on to nodex, which it doesn't trust. After the call is redialed from node1, the connection is resynchronized, and .CW pokey is now connected to .CW west . .1C .KF top .so fig7.x .DS C Figure 7. Intercepting a redialed call .DE .KE .2C .NH 2 Message Flow to Implement Call Redial .PP The message flow to implement call redial is more involved than forwarding on the CALLMOD, CALL and SIREQ message, due to the software structure of the Datakit controller. All VLP messages travel out-of-band of the data, and messages between module pairs, such as the two sides of a trunk, must travel via the control channel between these two sides. This amounts to a 4 way communication to pass VLP information around in the network. I will first detail the messages necessary to implement phase 1 of the redial, both from the host to the Datakit, and between trunks, and terminating in the initiation of a new call. Next, I will explain the messages necessary to resynchronize the connection. You may want to compare this implementation with Wetzel's. ....... .NH 3 Phase 1 Host Control Module Messages .PP Initiating a redial from a host requires the use of two Datakit channels, the host's control channel, and the data channel that will be redialed. All changes on the host were done in user level servers, no kernel modifications were necessary, not even to the stream handlers. Because the host modifications were straightforward and were not made by me, I will not detail them here. .PP The message sequence is shown in Figure 8. When \fIauthmgr\fP redials its connection, it uses the .I ipcredial library call to pass the call back to the Datakit call manager .I dkmgr on the security host. The call manager passes a control message of type T_CHG over the Datakit control connection containing a D_REDIAL request and the line identifier for the data channel (step 1). The control process, unixcscp, notifies the line process, unixp, identified in the D_REDIAL message of the redial, with an EXTFUNC (for extended function) message, with subtype D_REDIAL (step 2). When it receives this message, the line process changes the switch setting in the Datakit so when the host sends data on the data channel, the line process will receive this data, rather than having the data sent to the originating end of the call. The line process notifies .I dkmgr that it is ready for the dialstring by sending an ``O'' character as a dialtone (step 3). The host responds with the dialstring, and closes its end of the data channel (step 4). The dialstring sent by the host is exactly the same as the dialstring used when placing new calls; no changes were made to the format. .1C .KF bottom .so fig8.x .DS C Figure 8. Phase 1 Host Control Messages .DE .KE .2C .PP Unixp is not the process that should actually perform the redial, because it was the destination of the old call, so it must forward the new dialstring back along the path of the call to the process that originated the call, or a trunk process that will intercept the redial. It does this in step 5, by sending a CALLMOD message, which contains the new dialstring, to the module that originated the call. Unixp then hangs up its end of the old connection by sending a HANGUP message to unixcscp in step 6. This ends the host's involvement in phase 1 of the redial. .NH 3 Phase 1 Trunk Control Module Messages .PP The redial in the trunk is even more complicated than that of the host, because the trunk must be able to both pass a redial through, if it is not the redial point, or intercept the redial message, if this trunk goes to an untrusted domain. Once again, there are four processes involved, the control processes on each side of the trunk, tdkp, and the line processes, tdktrkp, which control the data channel of this connection. .PP Figure 9 shows the control flow for a trunk that passes CALLMOD requests through, unchanged. First, the tdktrkp on the redialing side receives a CALLMOD from a unixp or another tdktrkp. It wants to pass this on through the trunk, but must use the control process, tdkp to do so, and sends tdkp an EXTFUNC/D_REDIAL message (step 2). Tdkp responds to this by sending a T_CHG/D_REDIAL message to its peer on the other side of the trunk, along with the line identifier for the data channel (step 3). The remote tdkp sends an EXTFUNC/D_REDIAL message down to the correct line process (step 4), which causes that tdktrkp to give a dialtone for the new dialstring (step 5). The redialing tdktrkp responds by sending the dialstring (step 6). It is now completed with this call, but waits for the remote tdktrkp to complete sending the dialstring on. .1C .KF .so fig9.x .DS C Figure 9. Phase 1 Trunk Control Messages .DE .KE .2C .PP The remote tdktrkp once again packages up the dialstring in a CALLMOD message, which it sends on to its peer (presumably the line process for another trunk or a host) in step 7. The remote tdktrkp is also finished with this call and sends a CLOSE to its trkp (step 8). This causes the normal tear down to take place between the trunk processes, which eventually causes an ONHOOK message to be received by the other tdktrkp (step 9), which then finishes cleaning up this connection. In this way, the CALLMOD gets forwarded through the network, and the old portion of the call gets torn down at the same time. .NH 3 Phase 2 Trunk Control Module Messages .PP Eventually, the CALLMOD reaches the originating host control process or a trunk to an untrusted domain, and phase 2 begins. Because phase 2 is more interesting in the intercept case, the trunk intercept case is described here The host redial case is similar, and somewhat simpler. .PP Figure 10 shows the messages involved in phase 2 of a trunk that intercepts the redial message. The trunk first receives the CALLMOD message from its peer, just like it would if it were forwarding the redial. However, when it checks its administrative database, it determines that it should intercept the redial. It sends out a new CALL message to the new destination (step 2) and waits for a response. In this example, the call succeeds, and the tdktrkp receives an ANSWER message from its new peer (step 3). .1C .KF .so fig10.x .DS C Figure 10. Phase 2 Trunk Control Messages .DE .KE .2C .PP In Wetzel's redial implementation, phase two ends here. However, we really need to send back to the originating host, via the control channels, a resynchronization message. Wetzel's method of inserting control bytes into the data stream is unacceptable \- a trunk process cannot know the high level protocol the endpoints were using, and assuming that they use URP, while correct in the current state of the Datakit, may not work in the long run. In addition, this choice violates the abstraction presented by VLP. .PP Phase 2 continues by telling the originating host to resynchronize its high level protocols with the new peer. Tdktrkp, after it receives the ANSWER, notifies its tdkp about this with an SIREQ message (step 4). The tdkp then sends a T_CHG/D_XINIT message across the control channel to its peer on the other side of the trunk (step 5), along with the line identifier for the data channel that needs resynchronization. The remote tdkp notifies the correct tdktrkp line process with an SIREQ message as well (step 6). The receiving tdktrkp forwards the synchronization message along by sending an SIREQ message to its peer module (step 7). If step 1 were the receipt of an SIREQ rather than a CALLMOD, the sequence would be the same, without the CALL or ANSWER. .NH 3 Phase 2 Host Control Module Messages at the Originating Host .PP When a line process on a host interface module receives an SIREQ message from its peer (either a trunk or another host module), it must notify the host itself of the synchronization request. This message sequence is shown in Figure 11. The unixp process receives the SIREQ (step 1), and sends an SIREQ to its controlling unixcscp (step 2). In the generic Datakit, the splice operation resynchronizes a host by sending it a T_SRV/D_XINIT message. Because this message does not depend on the splice operation at all, we use it here. Unixcscp sends the host a T_SRV/D_XINIT message over the control channel. A modification was necessary in the streams modules in the kernel to process this message. This message is intercepted by the streams modules, and causes the data channel to resynchronize (it resets sequence numbers and any other necessary end-to-end negotiations). At this point, the redial is completed. .1C .KF bottom .so fig11.x .DS C Figure 11. Phase 2 Host Control Messages .DE .KE .2C .NH 2 Administrative Changes to Implement Call Redial .PP The redial mechanism, by itself, is not enough to support \fIauthmgr\fP. Additional changes were necessary in the administrative and configuration portions of the Datakit control software. One of these changes, the redial intercept, has already been mentioned. This and other changes will be detailed in this section. .PP In order to restrict the use of the redial operation, a new option was added to the host module configuration description. This option is a simple boolean, which says whether the host is allowed to issue redial operations or not. There are two reasons for this. First, to support \fIauthmgr\fP, the redial dialstring from the host includes not only the name of the new destination, but an authenticated username and the authenticated security ID for \fIauthmgr\fP. Only the security host should be allowed to send out such messages. In general, only the Datakit is allowed to put the security ID into the dialstring. Furthermore, allowing anyone to perform a redial confuses the authentication system already in place. A redialed call from anyone but \fIauthmgr\fP would contain the username of the .I redialer , not the username of the original caller (the other end of the connection), and the security ID of the redialed call would be that of the redialer as well. This would foil the authentication checks made by the recipient of the redialed call, making the redialed call appear as if it came from the host that redialed the call, rather than from the original caller. For this reason, redial is completely restricted to specific, secure hosts, and only the superuser (\fIauthmgr\fP runs as the superuser) can take full advantage of the redial feature. .PP Another boolean option was added to the host module configuration description to support the authentication of Gnots. In this case, we wish the entire module to retain the knowledge that this Gnot is currently authenticated. Therefore, on a module that is connected to a Gnot rather than a regular, .UX host, the Datakit administrator can set this option to retain the authentication information. When a CALLMOD request comes into a unixp line process on such a module, it stores the authenticated username and security ID in the control database. All further calls from the Gnot use these values for the username and security ID instead of anything the Gnot or the normal database entries contain. When the Gnot is reset, or its power is cycled, this information is erased, and the next user will have to be re-authenticated. .PP The previously mentioned redial intercept option was added to the trunk module configuration description. This is also a boolean, and, if set, marks the trunk as untrusted. If a CALLMOD arrives from another module on this side of the trunk, it will be intercepted, and the redial will take place at the trunk, rather than being forwarded. .PP Two more configuration options are available for the trunk. The first is necessary to guarantee the authenticity of \fIauthmgr\fP's security ID. The Datakit administrator can enter \fIauthmgr\fP's security ID into one of the fields in the configuration for an untrusted trunk. When a call comes in over the untrusted trunk, the security ID on the call is compared with the security ID of \fIauthmgr\fP. If it is the same, the security ID on the call is changed to be that of someone who is completely unknown and untrusted. This keeps unscrupulous people in the untrusted domain from making fake, ``authenticated'' calls through the trunk. .PP The other option protects the integrity of the trusted domain. Here, the Datakit administrator can define a destination through which all calls from the untrusted trunk should be .I rerouted . When this field is set (this is known as the Predefined Destination field) on a trunk, any call arriving from the trunk will be rerouted to this predefined destination. The name of the old destination, as specified in the dialstring, is also passed along. This is used, for example, to reroute all calls from an untrusted domain to \fIauthmgr\fP. In this way, no service in the trusted domain can be accessed from outside without authenticating the untrusted user first. .NH 2 Experience .PP In implementing call redial, a good portion of the time was spent reading the existing code to implement other parts of VLP in the host and trunk control modules and also studying Wetzel's call redial implementation. Implementing the basic call redial itself was straightforward, especially given the references. Making the administrative modifications work and integrating them with the control processes themselves was the most challenging. .PP The worst part of the implementation was in saving the authentication information for the Gnots. The database inside the Datakit control computer is highly structured, and is not extendible. That is, it is impossible, without making major changes to the database code and structure, to add new data types and objects to the database. Therefore, the authenticated username and security ID were stored in two database objects that were otherwise unused for the database information on host interface modules. The actual purpose of these objects was meant to be somewhat different than the way they have been applied in this case. A better solution would have been to modify the database structure, but there was no time for such a major job this summer. .NH 1 Conclusions .PP \fIAuthmgr\fP is, as far as I know, the first major application of call redial in Datakit. It allows a trusted domain to interact with a number of untrusted domains, while not compromising the trust implicit inside the trusted domain. The additional use of \fIauthmgr\fP in authenticating Gnots shows its versatility, and that it can centralize the authentication tasks inside the trusted domain as well. The re-implemented redial mechanism points out a problem with resynchronization in the generic datakit redial mechanism that should be addressed at some point. The ease with which \fIauthmgr\fP and call redial fit into the large body of existing networking and datakit control code was extremely encouraging, and the structure difficulties within the control database should be fixable in future versions of the datakit control software. .NH 1 Acknowledgements .PP This work would have been impossible to complete in one summer without the direction of my mentor, David Presotto, and the help of Bill Marshall and Caryl Carr. I extend my thanks to them and to the various other members of 1127 that helped make this happen. .NH References .LP |reference_placement