![[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.