![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to auth.ms CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10dc / vol2 / auth|
Return to auth.ms CVS log | Up to [Research Unix] / researchv10dc / vol2 / auth |
1.1 root 1: .so ../ADM/mac
2: .XX authmgr 531 "Authmgr \(em An Authentication Service for Datakit"
3: .TL
4: Authmgr \(em An Authentication Service for Datakit
5: .AU
6: David Cohrs
7: .AI
8: Computer Sciences Dept.
9: .br
10: University of Wisconsin \(em Madison*
11: .AB
12: .PP
13: \fIAuthmgr\fP is a service available on Ninth Edition
14: .UX
15: systems for authenticating users.
16: It can be used to authenticate users inside an organization, to
17: authenticate a terminal or workstation, or to help protect the
18: organization from network intrusions, while allowing legitimate
19: outside users to access the organization's computers.
20: \fIAuthmgr\fP receives calls from users, challenges them for a password
21: or for some other response, such as the outcome of encrypting
22: some challenge message.
23: When the user is authenticated, \fIauthmgr\fP makes use of the redial
24: mechanism provided by Datakit to redial the newly authenticated
25: call to a new service, such as a remote login service.
26: This paper describes the design and implementation of \fIauthmgr\fP,
27: as well as the re-implementation of call redial in the research
28: Datakit control computer, and the administrative options used
29: to implement \fIauthmgr\fP's policy decisions.
30: .AE
31: .2C
32: .FS
33: * This work was performed while the author was a summer intern at
34: .MH
35: .FE
36: .NH 1
37: Introduction
38: .PP
39: \fIAuthmgr\fP allows users to authenticate themselves and to make authenticated
40: calls within a trusted hardware environment, even if their call
41: originated outside that trusted environment.
42: To make authenticated calls, \fIauthmgr\fP makes use of a redial mechanism
43: supported by the network interface.
44: It was written to work in a Datakit environment, however,
45: any virtual circuit network
46: that supports the necessary redial mechanism could use \fIauthmgr\fP.
47: \fIAuthmgr\fP itself runs on a
48: .I "security computer" ,
49: currently a 10th Edition
50: .UX
51: system.
52: It interfaces with the Datakit network via the Datakit
53: interface manager (also running on the
54: security computer) and the
55: control channel from the security computer to
56: the Datakit node to which it is attached.
57: .PP
58: \fIAuthmgr\fP serves three basic purposes.
59: First, it allows users from outside the trusted part of the network
60: (the
61: .I "untrusted domain" )
62: to access the trusted part (the
63: .I "trusted domain" ),
64: without the use of ``in the clear'' passwords.
65: This helps to protect legitimate users in the untrusted domain
66: from other, less honorable, users also in the untrusted domain.
67: .PP
68: Second, all calls from outside the trusted domain can be shunted
69: through to the authentication manager, rather than allowing them
70: to be placed directly, as shown is Figure 1.
71: This allows a security check on the untrusted user before allowing
72: them to even attempt to access any service provided in the
73: trusted domain.
74: If the user fails the check, they have no way of accessing any of
75: the services inside the trusted domain, even those unprotected
76: services that are available to all users inside the trusted domain.
77: This is useful in the environment at AT&T Bell Laboratories, where the
78: trusted domain is made up of the various labs inside the company, and
79: the untrusted domain is the experimental XUNET network, connecting
80: the Murray Hill location to a number of universities around the
81: country.
82: .1C
83: .KF
84: .so fig1.x
85: .DS C
86: Figure 1. Rerouted call from an untrusted trunk
87: .DE
88: .KE
89: .2C
90: .PP
91: The third purpose of \fIauthmgr\fP is to allow users of
92: Gnot terminals to authenticate themselves to the network (equivalent
93: to logging into a host computer), and have
94: that terminal remain authenticated throughout the duration of their
95: session, as shown in Figure 2.
96: The Gnot terminal|reference(locanthi gnot)
97: is a small computer with a video display and a network
98: interface, but no disk.
99: When powered on or reset, the Gnot makes a network call to a file server
100: and retrieves an operating system kernel that
101: allows it to run window systems, editors, and make network connections
102: to other computers.
103: The session terminates when the user resets or powers down the Gnot.
104: The file server needs to have an authenticated username associated
105: with a session, in order that it may do privilege checking.
106: That is
107: .I authmgr 's
108: job.
109: .1C
110: .KF
111: .so fig2.x
112: .DS C
113: Figure 2. Authenticating a Gnot
114: .DE
115: .KE
116: .2C
117: .........
118: .NH 2
119: The Software Architecture
120: .PP
121: Providing the three services described above required
122: implementing the authentication manager
123: itself, and also making changes to the software on the Datakit
124: control computer.
125: The control computer changes allow it to redial authenticated calls,
126: to redirect calls coming in over untrusted trunks and
127: to store the authentication information for the Gnots.
128: The authentication manager handles all interactions with the
129: user, obtaining a login name and a unique authenticator from the user.
130: The controller software must be able to pass back the dialstring
131: to the originating point of the call and either redial the call from
132: that point, or
133: store the authentication information if
134: the caller was a Gnot.
135: In addition, the trunk module software must be able to
136: automatically redirect calls that come from an untrusted domain
137: to the authentication manager.
138: Implementing these functions required changes to both the trunk
139: module processes and the host computer module processes.
140: .PP
141: An implementation of the redial mechanism had previously been
142: done by Wetzel|reference(wetzel radian)
143: for the generic Radian controller, which is slightly different from the
144: Datakit controller used inside Murray Hill, so redial was
145: reimplemented, with some improvements, for the research controller.
146: Because of the direct application of redial we had in mind,
147: the redial mechanism is currently supported only for hosts and
148: on trunks (a Gnot looks like a host to the Datakit controller).
149: If a user at a normal terminal attempts to call \fIauthmgr\fP
150: and then redial their call, the redial will fail, because the necessary
151: synchronization and redial code has not been added to
152: the terminal module software.
153: .PP
154: The paper proceeds as follows.
155: The second section describes the functions of
156: the authentication manager and its implementation.
157: The third section describes the redial mechanism implemented
158: for the Datakit, and how it is
159: used in conjunction with the authentication manager.
160: The administrative hooks that were added to the system are also described
161: in this section.
162: Some final comments and conclusions constitute the fourth section.
163: .NH 1
164: The Authentication Manager
165: .PP
166: The purpose of the authentication manager is to determine
167: whether a user is really who they claim to be.
168: One common way of determining the authenticity of a user is
169: by asking them to enter a password (once we know the username
170: they claim to be).
171: The problem with using this approach over a network is that
172: the password
173: is usually sent ``in the clear'', although it isn't echoed
174: at the user's terminal.
175: If someone manages to tap into the user's line or the network
176: itself, the password will be compromised.
177: Obviously, a simple password is not a good way to authenticate
178: users over an untrusted network.
179: .PP
180: A simple solution is to ask the user for the appropriate response
181: to some challenge, something that can be sent as normal,
182: character data, but won't be easily compromised.
183: This is the approach taken by \fIauthmgr\fP.
184: Currently, the challenge that \fIauthmgr\fP transmits is a decimal
185: number, up to 8 digits long.
186: The user must obtain an encryption calculator from the system
187: administrators to encrypt this number.
188: \fIAuthmgr\fP was designed so that it could be quickly extended
189: to support any manufacturer's encryption
190: calculator, but at the current time, only one is supported.
191: This box, an Atalla
192: .I Confidante
193: terminal (despite the designation ``terminal'', the calculator is a small,
194: 2" \(mu 3" \(mu \(14" box), is programmed to encrypt
195: data with a key, the key having been
196: entered into the terminal by the system administrator at
197: the time the terminal is assigned.
198: The
199: .I Confidante
200: box uses standard DES encryption to encrypt the
201: numeric data with this key.
202: The terminal also requires a password, which the user must enter
203: before encrypting the challenge.
204: When the user enters the challenge, the terminal displays an 8 hex
205: digit number, which the user enters at their keyboard.
206: Assuming this was the correct response, \fIauthmgr\fP can proceed.
207: .PP
208: \fIAuthmgr\fP also allows some users to enter the normal login and
209: password sequence they are used to.
210: This is useful inside the trusted organization, where the problem
211: of compromising a password are much less, and
212: carrying around a challenge box becomes a bother.
213: This option can be specified on the basis of the source of the call,
214: or on a per-user basis.
215: .PP
216: Another important choice in designing \fIauthmgr\fP was whether calls coming
217: from outside the trusted domain should go first to the service the
218: untrusted user requested (for example, the user could request to
219: log into a trusted machine, and the call would go directly to the
220: remote login service on that machine), and have that service call
221: \fIauthmgr\fP for authentication purposes, or whether calls should automatically
222: be rerouted to \fIauthmgr\fP.
223: The former case would have required no changes to the network software,
224: but is much too trusting.
225: Many services in the trusted domain (AT&T Bell Labs, in this case)
226: were written assuming that only the trusted domain existed.
227: Allowing untrusted users to access these services could breach the
228: security of the trusted domain, or give away information that the
229: trusted domain is not allowed to give out (due to licensing or other
230: similar restrictions).
231: .PP
232: In the interest of the security of all of the services in the trusted
233: domain, \fIauthmgr\fP was designed assuming that calls from outside its
234: domain would be rerouted to \fIauthmgr\fP first, before they could reach any
235: unprotected services.
236: This requires that the networking software reroute calls, and also
237: requires that \fIauthmgr\fP be able to redial a call to a new destination
238: once authentication is completed.
239: The benefits of reducing the chances of information leaking out
240: of the trusted domain far outweigh the added complexity to the
241: networking software.
242: In addition, none of the existing services need to change to benefit
243: from the added authentication step.
244: .NH 2
245: Authmgr Operation
246: .PP
247: \fIAuthmgr\fP operates in three different modes, depending on the command
248: line arguments and its environment at the time it is executed.
249: In the first mode, \fIauthmgr\fP assumes it is interacting with a human
250: user at a terminal.
251: This mode is used when a user connects directly to \fIauthmgr\fP.
252: The user is prompted for a login name (unless \fIauthmgr\fP can determine
253: the user's login name from its environment), and then is challenged
254: to encrypt a number or enter a password.
255: The user encrypts the number using their encryption calculator and
256: in any case, enters the response.
257: \fIAuthmgr\fP tests this against the correct response, and, if it is correct,
258: prompts the user for a new destination.
259: The user enters a new destination, and \fIauthmgr\fP attempts to redial
260: the call.
261: Figure 3 shows an example of such a session.
262: .1C
263: .KF
264: .sp .5v
265: .DS B
266: .CW
267: coma(cohrs): con -l security.security
268: Security Authentication check
269:
270: login: cohrs
271: Enter response code for 31746735: 41a46474
272:
273: Number please: seki.whoami
274: source=dk!nj/astro/security user=cohrs line=astro2.57.27.F
275: Eof
276: coma(cohrs):
277: .R
278: .DE
279: .DS C
280: Figure 3. A simple, interactive Authentication Session
281: .DE
282: .KE
283: .2C
284: .PP
285: The second form is also interactive, but is used when the user is
286: using a Gnot terminal.
287: In this mode, the Gnot, when it is powered up,
288: automatically connects to \fIauthmgr\fP using
289: a special service name.
290: \fIAuthmgr\fP again prompts the user for a login name and a challenge.
291: However, when the user correctly enters the response, \fIauthmgr\fP
292: does not ask for another destination.
293: Instead, it redials the call to a special destination that the
294: network software understands as being an ``authentication only''
295: message.
296: When the source receives the redial message, it saves the authenticated
297: name and location of the user in a safe place, and closes the connection
298: to \fIauthmgr\fP.
299: Until the Gnot is reset,
300: all subsequent calls go out using this authenticated login name and
301: security ID.
302: .PP
303: The third form is meant to be used in conjunction with the various
304: remote login services available on the Datakit networks, especially
305: the
306: .CW dcon
307: service (used by the
308: .I con
309: program),
310: and the call rerouting option available at
311: the trunk from an untrusted domain of the network to the trusted domain.
312: Here, an untrusted user requests to connect to the remote login service of
313: a computer in the trusted domain.
314: When the call reaches the trunk to the trusted domain, the control
315: process on the trunk reroutes the call to \fIauthmgr\fP (the details of
316: this will be explained later).
317: When \fIauthmgr\fP is executed to handle the call, one of the parameters in
318: its environment is the original destination of the call, namely the
319: login service of some host in the trusted domain.
320: .PP
321: \fIAuthmgr\fP sends out a special message understood by
322: .I con .
323: .I Con
324: prompts the user for a login name, and sends this back to \fIauthmgr\fP.
325: \fIAuthmgr\fP uses the login name to find the key (or password) for this
326: user, and sends back the appropriate challenge.
327: .I Con
328: requests that the
329: user encrypt the challenge or enter a password, if this is a connection
330: inside the trusted domain.
331: Once it receives the information,
332: .I con
333: sends a message back to \fIauthmgr\fP
334: containing the response from the user.
335: If this is the correct response, the remote login protocol continues
336: as normal, otherwise, \fIauthmgr\fP again sends a challenge, and the cycle
337: repeats.
338: An example of this usage is shown in Figure 4.
339: While the actual prompts are similar, it should be noted that con
340: is prompting the user for the data in this example, not
341: \fIauthmgr\fP; \fIauthmgr\fP communicates with con over the network connection.
342: Pseudocode for \fIauthmgr\fP's side of the protocol with
343: .I con
344: is shown
345: in Figure 5.
346: .1C
347: .KF
348: .DS
349: .CW
350: fishonaplatter(cohrs): con seki
351: login: cohrs
352: Enter response for 55374202: 57406251
353: seki(cohrs):
354: .R
355: .DE
356: .DS C
357: Figure 4. A Rerouted Call to a Remote Login Service
358: .DE
359: .KE
360: .2C
361: .PP
362: \fIAuthmgr\fP is executed once for each session that requires authentication.
363: Upon startup, it reads some initial configuration information from
364: its configuration file.
365: This includes such things as the maximum number of tries a user gets
366: before \fIauthmgr\fP closes the connection, and mappings between original
367: source identifiers and new security identifiers.
368: This configuration file is explained in detail in the accompanying
369: manual page for \fIauthmgr\fP, found at the end of this paper.
370: .PP
371: The keys are also stored in a file on the security computer's disk.
372: This file contains extremely sensitive information, because the
373: keys are necessarily stored unencrypted, unlike the passwords in the
374: .UX
375: password file.
376: For this reason, access to the security computer must be severely
377: limited, not even allowing a remote login service.
378: At the present time, the key file is stored in a protected place,
379: but the file itself is not encrypted.
380: In some future version on \fIauthmgr\fP, this file could be encrypted, but
381: that would require human intervention to enter the encryption key
382: when \fIauthmgr\fP starts up.
383: For the purpose of simplicity, and to remove the need for human
384: intervention, the
385: current version relies on the physical security of the keys file.
386: .PP
387: The final aspect of \fIauthmgr\fP's operation is its use of the redial
388: feature.
389: \fIAuthmgr\fP redials the call through use of a new
390: .I ipcredial
391: library call in the Tenth Edition
392: .UX
393: IPC library.
394: \fIAuthmgr\fP generates a message containing the authenticated name of
395: the user, the new authenticated security identifier, and the
396: new destination to redial.
397: For security reasons, the ipcredial only works for the superuser.
398: Once the call has been redialed, either successfully or
399: unsuccessfully, the connection from \fIauthmgr\fP to the remote user
400: is closed, and \fIauthmgr\fP exits.
401: All in all, implementing \fIauthmgr\fP itself was straightforward,
402: and the system support was easily adapted to the redial application.
403: .1C
404: .KF bottom
405: .DS
406: .CW
407: int d;
408: char user[];
409: char response[];
410: char challenge[];
411:
412: con!"CH";\h'8n'/* the magic challenge protocol string */
413: *[
414: \h'8n':: con?user ->
415: \h'16n'challenge = makechallenge(getkeyinfo(user));
416: \h'16n'con!challenge;
417: \h'16n'con?response;
418: \h'16n'encrypt(getkeyinfo(user),challenge) == response ->
419: \h'24n'redial();\h'8n'/* \fIauthmgr\fP exits */
420: \h'16n'con!"CH";
421: \h'8n':: con?EOF ->
422: \h'16n'exit();
423: ]
424: .R
425: .DE
426: .DS C
427: Figure 5. The \fIAuthmgr\fP Remote Login Protocol
428: .DE
429: .KE
430: .2C
431: .NH 1
432: The Datakit Redial Mechanism
433: .PP
434: The redial mechanism itself is supported in the network control
435: software.
436: In the case of the Datakit, where this work was done, this
437: control software exists inside the network itself, in the
438: Datakit nodes.
439: Each Datakit node has an associated control computer; the
440: research Datakit nodes use Digital PDP-11/23 style computers for
441: the control computer, which directly controls the switch memory
442: of the Datakit node.
443: The redial mechanism is implemented as part of the software
444: running on this control computer.
445: .PP
446: Each device that connects to the Datakit network connects to
447: the Datakit node via a module, an interface card that lives
448: on the Datakit backplane.
449: A process inside the Datakit controller is in charge of
450: controlling this module.
451: In addition, if the module is multiplexed, there is a line
452: process in the Datakit controller to control each line of
453: the multiplexer (for our purposes, we can consider almost any
454: module to be multiplexed, especially the host and trunk
455: modules, in which a line is a single, logical channel on the module).
456: .PP
457: Datakit includes a standard signaling protocol, called VLP,
458: which is used
459: for setting up and taking down calls.
460: VLP defines the interactions between
461: the control processes for the source and destination modules
462: in the Datakit controller.
463: There are additional control messages between the line and
464: control processes within the same module, but these are not
465: defined as part of VLP.
466: .PP
467: Implementing the redial mechanism in the Datakit controller
468: required changing VLP, and adding two new messages,
469: CALLMOD and SIREQ.
470: These messages are defined to occur only when a connection
471: has been established; in most control processes, this is called
472: the TALKING state.
473: CALLMOD is a completely new message and is used for passing
474: the new dialstring back to the point at which the call will
475: be redialed.
476: SIREQ already exists in the generic Datakit controller,
477: and is used by the splice mechanism, but did not exist
478: in the research controller.
479: This message informs the originating point of the call (the
480: end of the original connection that still exists in the
481: new, redialed connection) that it needs to resynchronize its
482: higher level protocols with its new peer.
483: .PP
484: Basically, a redial consists of two phases.
485: The first phase uses CALLMOD messages to pass the new dialstring
486: from the module that wants to redial the call to the module
487: that will actually redial the call.
488: At the same time, this portion of the original connection is
489: closed down.
490: When the CALLMOD message reaches the
491: .I "redial point" ,
492: the module
493: that should actually redial the call, the line process for
494: this connection at that module generates a CALL message to
495: open up a new connection to the new dialstring.
496: This is the second phase of the redial.
497: The redial point eventually receives an ANSWER or a NAK message back from
498: the new destination of the call.
499: This part of the protocol works just as if this were a normal
500: call.
501: .PP
502: When the ANSWER reaches the redial point, instead of
503: propagating it back to the source, we instead send the source
504: an SIREQ message, telling it to resynchronize its protocols,
505: and the new connection is established.
506: The sending of the SIREQ message here differs from Wetzel's
507: redial implementation, which assumes that the higher level
508: protocols are using URP, and puts an URP initialization request
509: into the datastream.
510: We considered this to be incorrect, and possibly harmful to
511: correct communication, and opted for fully integrating redial
512: into the VLP protocol instead, even to the point of reinitializing
513: the source of the original call.
514: .1C
515: .KF
516: .so fig6.x
517: .DS C
518: Figure 6. Redialing a call on Datakit using VLP
519: .DE
520: .KE
521: .2C
522: .PP
523: Figure 6 shows an example of these two phases of call redial.
524: In this example, a user on the host
525: .CW coma
526: has connected to the host
527: .CW security ,
528: presumably to use \fIauthmgr\fP (this step is labeled 1 in the figure).
529: After authentication, \fIauthmgr\fP redials the call from itself to
530: the host named
531: .CW west .
532: This causes the connection from the node1 Datakit to the security
533: host to close (this step is labeled 2, and is phase 1 of the redial).
534: When the redial request reaches node1, the control process starts
535: a new call to the host
536: .CW west .
537: This call completes in step 3, and now the user on
538: .CW coma
539: is connected to
540: .CW west .
541: .PP
542: In the example, the redial took place on the originating Datakit
543: node.
544: This makes for the most optimal path from
545: .CW coma
546: to
547: .CW west .
548: If we had performed the redial at node2 instead of node1, all messages
549: between
550: .CW coma
551: and
552: .CW west
553: would have had to go through 3 Datakit
554: nodes, rather than 2, increasing the delay and increasing the
555: load on node2 unnecessarily.
556: However, in cases where the original call comes from an untrusted
557: domain, we would want the redial message (phase 1) to be intercepted
558: by the node at the edge of the trusted domain, and have the new
559: call be placed from there.
560: .PP
561: This scenario is shown in Figure 7.
562: Here,
563: .CW pokey
564: is a computer in the untrusted domain, and is connected
565: to the Datakit node, nodex.
566: Once again, the user on pokey calls the security host, and has their
567: call redialed to
568: .CW west
569: (steps 1 and 2).
570: However, node1 intercepts the redial message and performs phase 2
571: of the redial itself, rather than forwarding it on to nodex, which
572: it doesn't trust.
573: After the call is redialed from node1, the connection is resynchronized,
574: and
575: .CW pokey
576: is now connected to
577: .CW west .
578: .1C
579: .KF top
580: .so fig7.x
581: .DS C
582: Figure 7. Intercepting a redialed call
583: .DE
584: .KE
585: .2C
586: .NH 2
587: Message Flow to Implement Call Redial
588: .PP
589: The message flow to implement call redial is more involved than
590: forwarding on the CALLMOD, CALL and SIREQ message, due to the
591: software structure of the Datakit controller.
592: All VLP messages travel out-of-band of the data, and messages
593: between module pairs, such as the two sides of a trunk, must
594: travel via the control channel between these two sides.
595: This amounts to a 4 way communication to pass VLP information
596: around in the network.
597: I will first detail the messages necessary to implement
598: phase 1 of the redial, both from the host to the Datakit, and
599: between trunks, and terminating in the initiation of a new call.
600: Next, I will explain the messages necessary to resynchronize
601: the connection.
602: You may want to compare this implementation with Wetzel's.
603: .......
604: .NH 3
605: Phase 1 Host Control Module Messages
606: .PP
607: Initiating a redial from a host requires the use of two Datakit
608: channels, the host's control channel, and the data channel
609: that will be redialed.
610: All changes on the host were done in user level servers, no
611: kernel modifications were necessary, not even to the stream
612: handlers.
613: Because the host modifications were straightforward and were
614: not made by me, I will not detail them here.
615: .PP
616: The message sequence is shown in Figure 8.
617: When \fIauthmgr\fP redials its connection, it uses the
618: .I ipcredial
619: library call to pass the call back to the Datakit call
620: manager
621: .I dkmgr
622: on the security host.
623: The call manager passes a control message of type T_CHG over the
624: Datakit control
625: connection containing a D_REDIAL request and the line identifier
626: for the data channel (step 1).
627: The control process, unixcscp, notifies the line process, unixp, identified
628: in the D_REDIAL message of the redial, with an EXTFUNC (for extended
629: function) message, with subtype D_REDIAL (step 2).
630: When it receives this message, the line process changes the switch
631: setting in the Datakit so when the host sends data on the data channel,
632: the line process will receive this data, rather than having the data
633: sent to the originating end of the call.
634: The line process notifies
635: .I dkmgr
636: that it is ready for the dialstring
637: by sending an ``O'' character as a dialtone (step 3).
638: The host responds with the dialstring, and closes its end of the
639: data channel (step 4).
640: The dialstring sent by the host is exactly the same as the dialstring
641: used when placing new calls; no changes were made to the format.
642: .1C
643: .KF bottom
644: .so fig8.x
645: .DS C
646: Figure 8. Phase 1 Host Control Messages
647: .DE
648: .KE
649: .2C
650: .PP
651: Unixp is not the process that should actually perform the redial,
652: because it was the destination of the old call, so it must forward
653: the new dialstring back along the path of the call to the process
654: that originated the call, or a trunk process that will intercept
655: the redial.
656: It does this in step 5, by sending a CALLMOD message, which contains
657: the new dialstring, to the module that originated the call.
658: Unixp then hangs up its end of the old connection by sending a
659: HANGUP message to unixcscp in step 6.
660: This ends the host's involvement in phase 1 of the redial.
661: .NH 3
662: Phase 1 Trunk Control Module Messages
663: .PP
664: The redial in the trunk is even more complicated than that of the
665: host, because the trunk must be able to both pass a redial through,
666: if it is not the redial point, or intercept the redial message,
667: if this trunk goes to an untrusted domain.
668: Once again, there are four processes involved, the control processes
669: on each side of the trunk, tdkp, and the line processes, tdktrkp,
670: which control the data channel of this connection.
671: .PP
672: Figure 9 shows the control flow for a trunk that passes CALLMOD
673: requests through, unchanged.
674: First, the tdktrkp on the redialing side receives a CALLMOD from
675: a unixp or another tdktrkp.
676: It wants to pass this on through the trunk, but must use the
677: control process, tdkp to do so, and sends tdkp an EXTFUNC/D_REDIAL
678: message (step 2).
679: Tdkp responds to this by sending a T_CHG/D_REDIAL message to
680: its peer on the other side of the trunk, along with the line
681: identifier for the data channel (step 3).
682: The remote tdkp sends an EXTFUNC/D_REDIAL message down to
683: the correct line process (step 4), which causes that tdktrkp
684: to give a dialtone for the new dialstring (step 5).
685: The redialing tdktrkp responds by sending the dialstring (step 6).
686: It is now completed with this call, but waits for the remote
687: tdktrkp to complete sending the dialstring on.
688: .1C
689: .KF
690: .so fig9.x
691: .DS C
692: Figure 9. Phase 1 Trunk Control Messages
693: .DE
694: .KE
695: .2C
696: .PP
697: The remote tdktrkp once again packages up the dialstring in a
698: CALLMOD message, which it sends on to its peer (presumably the
699: line process for another trunk or a host) in step 7.
700: The remote tdktrkp is also finished with this call
701: and sends a CLOSE to its trkp (step 8).
702: This causes the normal tear down to take place between the trunk
703: processes, which eventually causes an ONHOOK message to be received
704: by the other tdktrkp (step 9),
705: which then finishes cleaning up this connection.
706: In this way, the CALLMOD gets forwarded through the network,
707: and the old portion of the call gets torn down at the same time.
708: .NH 3
709: Phase 2 Trunk Control Module Messages
710: .PP
711: Eventually, the CALLMOD reaches the originating host control
712: process or a trunk to an untrusted domain, and phase 2 begins.
713: Because phase 2 is more interesting in the intercept case,
714: the trunk intercept case is described here
715: The host redial case is similar, and somewhat simpler.
716: .PP
717: Figure 10 shows the messages involved in phase 2 of a trunk
718: that intercepts the redial message.
719: The trunk first receives the CALLMOD message from its peer, just
720: like it would if it were forwarding the redial.
721: However, when it checks its administrative database, it determines
722: that it should intercept the redial.
723: It sends out a new CALL message to the new destination (step 2)
724: and waits for a response.
725: In this example, the call succeeds, and the tdktrkp receives
726: an ANSWER message from its new peer (step 3).
727: .1C
728: .KF
729: .so fig10.x
730: .DS C
731: Figure 10. Phase 2 Trunk Control Messages
732: .DE
733: .KE
734: .2C
735: .PP
736: In Wetzel's redial implementation, phase two ends here.
737: However, we really need to send back to the originating host,
738: via the control channels, a resynchronization message.
739: Wetzel's method of inserting control bytes into the data stream
740: is unacceptable \- a trunk process cannot know the high level
741: protocol the endpoints were using, and assuming that they use URP,
742: while correct in the current state of the Datakit, may not work
743: in the long run.
744: In addition, this choice violates the abstraction presented by VLP.
745: .PP
746: Phase 2 continues by telling the originating host to resynchronize
747: its high level protocols with the new peer.
748: Tdktrkp, after it receives the ANSWER, notifies its tdkp about
749: this with an SIREQ message (step 4).
750: The tdkp then sends a T_CHG/D_XINIT message across the control channel
751: to its peer on the other side of the trunk (step 5), along with
752: the line identifier for the data channel that needs resynchronization.
753: The remote tdkp notifies the correct tdktrkp line process with an
754: SIREQ message as well (step 6).
755: The receiving tdktrkp forwards the synchronization message along
756: by sending an SIREQ message to its peer module (step 7).
757: If step 1 were the receipt of an SIREQ rather than a CALLMOD, the
758: sequence would be the same, without the CALL or ANSWER.
759: .NH 3
760: Phase 2 Host Control Module Messages at the Originating Host
761: .PP
762: When a line process on a host interface module receives an SIREQ
763: message from its peer (either a trunk or another host module),
764: it must notify the host itself of the synchronization request.
765: This message sequence is shown in Figure 11.
766: The unixp process receives the SIREQ (step 1), and sends an
767: SIREQ to its controlling unixcscp (step 2).
768: In the generic Datakit, the splice operation resynchronizes a host
769: by sending it a T_SRV/D_XINIT message.
770: Because this message does not depend on the splice operation at
771: all, we use it here.
772: Unixcscp sends the host a T_SRV/D_XINIT message over the control
773: channel.
774: A modification was necessary in the streams modules in the
775: kernel to process this message.
776: This message is intercepted by the streams modules,
777: and causes the data channel to resynchronize (it resets sequence
778: numbers and any other necessary end-to-end negotiations).
779: At this point, the redial is completed.
780: .1C
781: .KF bottom
782: .so fig11.x
783: .DS C
784: Figure 11. Phase 2 Host Control Messages
785: .DE
786: .KE
787: .2C
788: .NH 2
789: Administrative Changes to Implement Call Redial
790: .PP
791: The redial mechanism, by itself, is not enough to support \fIauthmgr\fP.
792: Additional changes were necessary in the administrative and
793: configuration portions of the Datakit control software.
794: One of these changes, the redial intercept, has already been mentioned.
795: This and other changes will be detailed in this section.
796: .PP
797: In order to restrict the use of the redial operation, a new option
798: was added to the host module configuration description.
799: This option is a simple boolean, which says whether the host is
800: allowed to issue redial operations or not.
801: There are two reasons for this.
802: First, to support \fIauthmgr\fP, the redial dialstring from the host includes
803: not only the name of the new destination, but an authenticated
804: username and the authenticated security ID for \fIauthmgr\fP.
805: Only the security host should be allowed to send out such messages.
806: In general, only the Datakit is allowed to put the security ID into
807: the dialstring.
808: Furthermore, allowing anyone to perform a redial confuses the
809: authentication system already in place.
810: A redialed call from anyone but \fIauthmgr\fP would contain the username
811: of the
812: .I redialer ,
813: not the username of the original caller (the other end of the connection),
814: and the security ID of the redialed call would be that of the
815: redialer as well.
816: This would foil the authentication checks made by the recipient of
817: the redialed call, making the redialed call appear as if it came from
818: the host that redialed the call, rather than from the original caller.
819: For this reason, redial is completely restricted to specific, secure
820: hosts, and only the superuser (\fIauthmgr\fP runs as the superuser) can
821: take full advantage of the redial feature.
822: .PP
823: Another boolean option was added to the host module configuration
824: description to support the authentication of Gnots.
825: In this case, we wish the entire module to retain the knowledge that
826: this Gnot is currently authenticated.
827: Therefore, on a module that is connected to a Gnot rather than a
828: regular,
829: .UX
830: host, the Datakit administrator can set this option to retain the
831: authentication information.
832: When a CALLMOD request comes into a unixp line process on such a
833: module, it stores the authenticated username and security ID in
834: the control database.
835: All further calls from the Gnot use these values for the username
836: and security ID instead of anything the Gnot or the normal database
837: entries contain.
838: When the Gnot is reset, or its power is cycled, this information is
839: erased, and the next user will have to be re-authenticated.
840: .PP
841: The previously mentioned redial intercept option was added to the
842: trunk module configuration description.
843: This is also a boolean, and, if set, marks the trunk as
844: untrusted.
845: If a CALLMOD arrives from another module on this side of the
846: trunk, it will be intercepted, and the redial will take place
847: at the trunk, rather than being forwarded.
848: .PP
849: Two more configuration options are available for the trunk.
850: The first is necessary to guarantee the authenticity of \fIauthmgr\fP's
851: security ID.
852: The Datakit administrator can enter \fIauthmgr\fP's security ID into
853: one of the fields in
854: the configuration for an untrusted trunk.
855: When a call comes in over the untrusted trunk, the security ID
856: on the call is compared with the security ID of \fIauthmgr\fP.
857: If it is the same, the security ID on the call is changed to
858: be that of someone who is completely unknown and untrusted.
859: This keeps unscrupulous people in the untrusted domain from
860: making fake, ``authenticated'' calls through the trunk.
861: .PP
862: The other option protects the integrity of the trusted domain.
863: Here, the Datakit administrator can define a destination through
864: which all calls from the untrusted trunk should be
865: .I rerouted .
866: When this field is set (this is known as the Predefined Destination
867: field) on a trunk, any call arriving from the trunk will be
868: rerouted to this predefined destination.
869: The name of the old destination, as specified in the dialstring,
870: is also passed along.
871: This is used, for example, to reroute all calls from an untrusted
872: domain to \fIauthmgr\fP.
873: In this way, no service in the trusted domain can be accessed from
874: outside without authenticating the untrusted user
875: first.
876: .NH 2
877: Experience
878: .PP
879: In implementing call redial, a good portion of the time was spent reading
880: the existing code to implement other parts of VLP in the host and
881: trunk control modules and also studying Wetzel's call redial implementation.
882: Implementing the basic call redial itself was straightforward,
883: especially given the references.
884: Making the administrative modifications work and integrating
885: them with the
886: control processes themselves was the most challenging.
887: .PP
888: The worst part of the implementation
889: was in saving the authentication information for the Gnots.
890: The database inside the Datakit control computer is highly structured,
891: and is not extendible.
892: That is, it is impossible, without making major changes to the database
893: code and structure, to add new data types and objects to the database.
894: Therefore, the authenticated username and security ID were stored
895: in two database objects that were otherwise unused for the database
896: information on host interface modules.
897: The actual purpose of these objects was meant to be somewhat
898: different than the
899: way they have been applied in this case.
900: A better solution would have been to modify the database structure,
901: but there was no time for such a major job this summer.
902: .NH 1
903: Conclusions
904: .PP
905: \fIAuthmgr\fP is, as far as I know, the first major application of call
906: redial in Datakit.
907: It allows a trusted domain to interact with a number of untrusted
908: domains, while not compromising the trust implicit inside
909: the trusted domain.
910: The additional use of \fIauthmgr\fP in authenticating Gnots shows its
911: versatility, and that it can centralize the authentication tasks
912: inside the trusted domain as well.
913: The re-implemented redial mechanism points out a problem with
914: resynchronization in the generic datakit
915: redial mechanism that should be addressed at some point.
916: The ease with which \fIauthmgr\fP and call redial fit into the large
917: body of existing networking and datakit control code was
918: extremely encouraging, and the structure difficulties within
919: the control database should be fixable in future versions of
920: the datakit control software.
921: .NH 1
922: Acknowledgements
923: .PP
924: This work would have been impossible to complete in one summer
925: without the direction of my mentor, David Presotto, and the
926: help of Bill Marshall and Caryl Carr.
927: I extend my thanks to them and to the various other members
928: of 1127 that helped make this happen.
929: .NH
930: References
931: .LP
932: |reference_placement
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.