Re: NSI again removes services
TAC as in tacacs? Around 09:43 AM 10/19/1999 -0700, rumor has it that hardie@equinix.com said:
Wow, this looks like the SRI-era VOID database query result. The impname and tacreq, in particular, look like they did back in the days when SRI was still doing tac cards out of the same database as whois. (TAC cards had user names and passwords which gave dial-up access to a pool of terminal access controllers run by DCA)
Ken Harrenstein wrote VOID to serve as the whois database for the SRI-NIC and it had some useful bits that never made it in to later implementations. I've always suspected that this was the influence of augment, one of Doug Engelbart's data storage brainstorms (for the TOPS 2065 platform). One of the useful bits was that you could specify query type by sort algorithm as well as by key. So you got wierd search commands like "li fi boo htype=h and netname=sri-net". (That specified a last in, first out boolean query, which was the most common type.)
Sorry if the nostalgia break is off topic for you,
Ted Hardie
John wrote:
(0) htype: D | (1) handle: SERVICES5-DOM| (2) name: Network Services Clearinghouse| (3) hostname: | (4) netname: | (5) domainame: SERVICES.NET| (6) netaddress: | (7) address: c/o I.E.C.C. PO Box 640 Trumansburg, NY 14886 US| (8) admincontact: HOS228-ORG| (9) alternatepoc: | (10) activation_date: 21-Jan-1997| (11) billcontact: HOS228-ORG| (12) comments: | (13) connectype: | (14) coordinator: | (15) cputype: | (16) groups: | (17) hostadmin: | (18) host: | (19) impname: | (20) impnetnumber: | (21) impnumber: | (22) inaddrserver: | (23) usgpolicy: | (24) mailbox: | (25) netnumber: | (26) netblock: | (27) nicknames: | (28) opsys: | (29) parentdom: NET | (30) phone: | (31) protocols: | (32) servercontact: IVAN-HST LIGHT3-HST| (33) tacid: | (34) mctacnumber: | (35) techcontact: HOS228-ORG| (36) tissuedate: | (37) updated: 19970121-111213 dawnf=| (38) user_name: | (39) validcard: | (40) tacreq: | (41) zonecontact: HOS228-ORG| (42) registrar: | (43) asn_name: | (44) asn_number: | (45) asn_block: | -- John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 387 6869 johnl@iecc.com, Village Trustee and Sewer Commissioner, http://iecc.com/johnl, Member, Provisional board, Coalition Against Unsolicited Commercial E-mail
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TAC as in tacacs?
that's the "terminal access controller access control system", right? -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth."
TAC as in tacacs?
Yep. The original TACACS specification was in a BBN technical memo, CC-0045; RFC 1492 contains an informal specification of the extended version that Cisco implemented. The background section of RFC 1492 gives a bit of the history: Background There used to be a network called ARPANET. This network consisted of end nodes (hosts), routing nodes (IMPs) and links. There were (at least) two types of IMPs: those that connected dedicated lines only and those that could accept dial up lines. The latter were called "TIPs." People being what they were, there was a desire to control who could use the dial up lines. Someone invented a protocol, called "TACACS" (Terminal Access Controller Access Control System?), which allowed a TIP to accept a username and password and send a query to a TACACS authentication server, sometimes called a TACACS daemon or simply TACACSD. This server was normally a program running on a host. The host would determine whether to accept or deny the request and sent a response back. The TIP would then allow access or not, based upon the response. While TIPs are -- shall we say? -- no longer a major presence on the Internet, terminal servers are. Cisco Systems terminal servers implement an extended version of this TACACS protocol. Thus, the access control decision is delegated to a host. In this way, the process of making the decision is "opened up" and the algorithms and data used to make the decision are under the complete control of whoever is running the TACACS daemon. For example, "anyone with a first name of Joe can only login after 10:00 PM Mon-Fri, unless his last name is Smith or there is a Susan already logged in." The extensions to the protocol provide for more types of authentication requests and more types of response codes than were in the original specification. The original TACACS protocol specification does exist. However, due to copyright issues, I was not able to obtain a copy of this document and this lack of access is the main reason for the writing of this document. This version of the specification was developed with the assistance of Cisco Systems, who has an implementation of the TACACS protocol that is believed to be compatible with the original specification. To be precise, the Cisco Systems implementation supports both the simple (non-extended) and extended versions. It is the simple version that would be compatible with the original. Please keep in mind that this is an informational RFC and does not specify a standard, and that more information may be uncovered in the future (i.e., the original specification may become available) that could cause parts of this document to be known to be incorrect. This RFC documents the extended TACACS protocol use by the Cisco Systems terminal servers. This same protocol is used by the University of Minnesota's distributed authentication system. regards, Ted Hardie
participants (3)
-
Andrew Brown -
Dean Anderson -
hardie＠equinix.com