home *** CD-ROM | disk | FTP | other *** search
/ DP Tool Club 15 / CD_ASCQ_15_070894.iso / vrac / tc14_246.zip / TC14-246.TXT < prev   
Text File  |  1994-06-07  |  29KB  |  654 lines

  1. TELECOM Digest     Tue, 24 May 94 00:43:00 CDT    Volume 14 : Issue 246
  2.  
  3. Inside This Issue:                           Editor: Patrick A. Townson
  4.  
  5.     Book Review: "Getting Online" by Wood (Rob Slade)
  6.     Followup: Connect a Card Reader to a Cell Phone? (Andrew C. Green)
  7.     Local Call Billing in the UK (Richard Cox)
  8.     CNID *Can* be Spoofed! (Andrew Robson)
  9.     Documents for AT&T Model 1539? (Bob Keller)
  10.     Urgently Request For Help With Research (Ali Tianero)
  11.     PCBX Systems (Paul Barratt)
  12.     Speech Recognition "Word Spotting" (p.bflower@uts.edu.au)
  13.     900 mhz Cordless Phone; Any Information? (Jason Chou)
  14.     Re: 800 Number Billback (Charles Chambers)
  15.     Re: Information Wanted on Large Digital Data Exchange (D. Devereaux-Weber)
  16.     Re: Cellular Phone Timers (Shawn Gordhamer)
  17.     Re: NPA Optional in 818 - it Works! (sameer@atlas.com)
  18.     Re: New (Lame) Directory Assistance From GTE Mobilnet (Marty Brenneis)
  19.     Re: Wanted: Hand-Held Challenge/Response Units (Paul Robinson)
  20.  
  21. TELECOM Digest is an electronic journal devoted mostly but not
  22. exclusively to telecommunications topics. It is circulated anywhere
  23. there is email, in addition to various telecom forums on a variety of
  24. public service systems and networks including Compuserve and GEnie.
  25. It is also gatewayed to Usenet where it appears as the moderated
  26. newsgroup 'comp.dcom.telecom'. 
  27.  
  28. Subscriptions are available at no charge to qualified organizations
  29. and individual readers. Write and tell us how you qualify:
  30.  
  31.                  * telecom-request@eecs.nwu.edu *
  32.  
  33. The Digest is edited, published and compilation-copyrighted by Patrick
  34. Townson of Skokie, Illinois USA. You can reach us by postal mail, fax 
  35. or phone at:
  36.                     9457-D Niles Center Road
  37.                      Skokie, IL USA   60076
  38.                        Phone: 708-329-0571
  39.                         Fax: 708-329-0572
  40.   ** Article submission address only: telecom@eecs.nwu.edu **
  41.  
  42. Our archives are located at lcs.mit.edu and are available by using
  43. anonymous ftp. The archives can also be accessed using our email
  44. information service. For a copy of a helpful file explaining how to
  45. use the information service, just ask.
  46.  
  47. *************************************************************************
  48. *   TELECOM Digest is partially funded by a grant from the              *
  49. * International Telecommunication Union (ITU) in Geneva, Switzerland    * 
  50. * under the aegis of its Telecom Information Exchange Services (TIES)   * 
  51. * project.  Views expressed herein should not be construed as represent-*
  52. * ing views of the ITU.                                                 *
  53. *************************************************************************
  54.  
  55. Additionally, the Digest is funded by gifts from generous readers such
  56. as yourself who provide funding in amounts deemed appropriate. Your help 
  57. is important and appreciated.
  58.  
  59. All opinions expressed herein are deemed to be those of the author. Any
  60. organizations listed are for identification purposes only and messages
  61. should not be considered any official expression by the organization.
  62. ----------------------------------------------------------------------
  63.  
  64. Date: Mon, 23 May 1994 15:30:37 MDT
  65. From: Rob Slade <roberts@decus.ca>
  66. Subject: Book Review: "Getting Online" by Wood
  67.  
  68.  
  69. BKGTONLN.RVW  940315
  70.  
  71. John Wiley & Sons, Inc.
  72. 22 Worchester Road
  73. Rexdale, Ontario  M9W 9Z9
  74. 800-263-1590  
  75. or
  76. 605 Third Avenue
  77. New York, NY   10158-0012   USA
  78. 800-263-1590   212-850-6630
  79. Fax: 212-850-6799
  80. jdemarra@wiley.com   aponnamm@jwiley.com
  81. "Get On-Line!", Wood, 1993, 0-471-58926-8, U$24.95
  82.  
  83. Most computer users do not yet have a modem, or don't use it on a
  84. regular basis.  Those who do get a modem need a fair amount of help
  85. from a knowledgeable friend.  It would be helpful to have a book which
  86. covers all of the traps of buying a modem, what you need, how to hook
  87. it up, how to set up the configuration and software, and how to
  88. connect to some outside source.  The basics of how to deal with email,
  89. file transfers, and how to use material with other programs.  This is
  90. what Wood tried to do.
  91.  
  92. He only partially succeeds.  First, you had better have a PC and
  93. either Procomm Plus, Crosstalk XVI, Smartcom EZ or Windows Terminal.
  94. The descriptions of functions are written strictly for field
  95. independent people: those who don't care what is going on, they just
  96. want to know what key to press.  As long as nothing goes wrong with
  97. the communications session, this is fine. Online devotees will know
  98. that the chances of nothing going wrong are extremely slim.
  99.  
  100. Wood's material is quite dated.  It is very odd that any book written
  101. in the past two years and purporting to advise on modem purchase does
  102. not mention 14400 bps modems.  Also odd is the recommendation to buy
  103. MNP 3 or 4 modems: I haven't personally seen one with less than MNP 5
  104. in more than four years.  I also haven't seen an acoustic coupler
  105. modem available for quite some time.
  106.  
  107. The content is also quite sparse in places.  While I can appreciate
  108. the desire to write for the non-technical user, the truth is that
  109. computer communications is still a field requiring some background to
  110. set up.  Wood mentions the possible problems with COM ports and IRQ
  111. levels -- but only mentions them.  There simply isn't enough
  112. information here even to start to diagnose or rectify an interrupt
  113. conflict problem.  The book even suggests that COM ports on computers
  114. are so labelled, an unlikely eventuality.  This style follows through
  115. to the communications parameter settings.  Wood does give good
  116. suggestions for default settings, but no means of determining
  117. problems.
  118.  
  119. The book does contain a smattering of everything.  There is a bit on
  120. portable communications, online services of various types, netiquette,
  121. and so forth.  Since these are not really the main thrust of the book,
  122. one does not expect extensive discussion, but it seems a bit terse to
  123. dismiss the Internet in less than two pages as an "echo network" and
  124. "more chaotic than any of the BBS echo networks."  (There are quite a
  125. number of errors in the short piece on the Internet.  And I should
  126. also mention a section on viral programs which lists seven antiviral
  127. vendors -- four of whom are McAfee agents.)
  128.  
  129. For novices, this does give a good starting guide, but only that.  You
  130. will still need your knowledgeable friend.
  131.  
  132. copyright Robert M. Slade, 1994   BKGTONLN.RVW   940315. Distribution
  133. permitted in TELECOM Digest and associated newsgroups/mailing lists.
  134.  
  135.  
  136. Vancouver      ROBERTS@decus.ca    
  137. Institute for  Robert_Slade@sfu.ca 
  138. Research into  rslade@cue.bc.ca    
  139. User           p1@CyberStore.ca    
  140. Security       Canada V7K 2G6      
  141.  
  142. ------------------------------
  143.  
  144. Date: Mon, 23 May 1994 16:36:09 CDT
  145. From: Andrew C. Green <ACG@dlogics.com>
  146. Subject: Followup: Connect a Card Reader to a Cell Phone?
  147.  
  148.  
  149. You may remember that about a month ago, I asked for help in locating
  150. equipment that would connect a credit card authorization reader to a
  151. cellular phone, for my father's use at a concert. His organization,
  152. Symphony II, the orchestra of the Chicago Lyric Opera, was holding a
  153. "silent auction" fund-raiser, and needed a way to get credit card sale
  154. authorizations at a location where no POTS line was available.
  155.  
  156. Well, TELECOM Digest readers sent numerous recommendations and offers
  157. of assistance, and thanks are due to Macy M. Hallock, Jr., Alan
  158. Larson, Donald L. Wegeng, Henrik Rasmussen, Merrell Sheehan and Paul
  159. A. Lee for their information, and of course PAT for operating TELECOM
  160. Digest in the first place. (I apologize if I've overlooked anyone.)
  161.  
  162. As it turned out, Motorola stepped in to help. Following Paul Lee's
  163. suggestion, my father contacted Bill Cochran of Motorola, who
  164. forwarded the question on to his associate Sonya Borre' (any
  165. misspellings are mine). She showed up bang on time at 9:00 a.m. the
  166. Monday before the concert at Symphony II offices for a demonstration
  167. of the gadgetry required to connect the cell phone to the reader. All
  168. went well, and Motorola graciously loaned the necessary equipment at
  169. no charge. The concert was held on Sunday afternoon, May 22nd, at
  170. Pick-Staiger Concert Hall at Northwestern University in Evanston, IL,
  171. and all the credit-card authorizations during the auction went through
  172. with no problems.
  173.  
  174. So, readers of TELECOM Digest have been instrumental in solving the
  175. problem for us. We thought you'd like to know.
  176.  
  177.  
  178. Regards,
  179.  
  180. Andrew C. Green    Datalogics, Inc.  Internet: acg@dlogics.com
  181. 441 W. Huron   Chicago, IL  60610-3498   
  182.  
  183. ------------------------------
  184.  
  185. Date: Mon, 23 May 1994 16:02:59 -0700
  186. From: richard@mandarin.com
  187. Subject: Local Call Billing in the UK
  188.  
  189.  
  190. RANDY@MPA15AB.mv-oc.Unisys.COM said:
  191.  
  192. >>  These were local toll calls from the East End to the West End, which I
  193. >>  assume are expensive calls.
  194.  
  195. {Chuckle} It is claimed that local phone calls in the UK are more
  196. expensive than in most countries ... one UK pound buys about 38
  197. minutes of call (before UK tax).  The fact that this call was made
  198. from the East End to the West End (about six miles in distance) is
  199. completely immaterial -- the charge would have been exactly the *same*
  200. as the charge for a call to next door.
  201.  
  202. Calls on the BT network (the dominant provider both as LEC and IXC in
  203. the UK) are currently charged in "units" and on most COs, calls of
  204. more than nine units can be itemised irrespective of the distance/des-
  205. tination of the call.  The duration of a unit depends on the distance
  206. and type of call, as well as the time the call is made.  The price of
  207. a unit depends on the calling plan of the individual customer, which
  208. is known in BT-speak as a "customer option".
  209.  
  210. There are plans to abolish the unit-charging over the next few years.
  211. Before STD ("DDD") was introduced here, local calls were charged as
  212. one, two, three or four unit fee calls, depending on distance: but the
  213. calls were untimed.
  214.  
  215. >>  Did the U.K. implement itemized local billing?
  216.  
  217. Local billing in the UK has been part of the national ("STD") billing
  218. scheme ever since STD was introduced in the various areas (from 1958
  219. onwards).  The option for itemised billing was more recently
  220. introduced, but treats local & long-distance in identical ways.  In
  221. fact the trend here is for the cost of local calls to increase, and
  222. the cost of long-distance to drop ... for just the same reasons that
  223. charges for intra-LATA long distance in the USA, are so much higher
  224. than for inter-LATA long distance.  And the costs involved are mostly
  225. for the switching, as bit-haulage is getting cheaper all the time!
  226.  
  227.  
  228. Richard D G Cox
  229.  
  230. Mandarin Technology, P.O. Box 111, Penarth, South Glamorgan, Wales:  CF64 3YG
  231. Voice: 0956 700111 Fax: 0956 700110  VoiceMail: 0941 151515 Pager 0941 115555
  232. E-mail address: richard@mandarin.com - PGP2.3 public key available on request
  233.  
  234. ------------------------------
  235.  
  236. From: uswnvg!arobson@uunet.UU.NET (Andrew Robson)
  237. Subject: CNID *Can* be Spoofed!
  238. Date: Mon, 23 May 1994 18:32:22 PDT
  239.  
  240.  
  241. It would appear that Calling Number Identification can be spoofed, at
  242. least for some applications.
  243.  
  244. My most valuable, though low key, use of CNID was as an aid to keeping
  245. track of my teenage children.  If they are supposed to be at some partic-
  246. ular location (e.g. spending the night at a friend's house), their
  247. knowledge of the service assists them in resisting the temptation to
  248. lie about their location when checking in.  This weekend we inadvertently 
  249. discovered a weakness in the system.
  250.  
  251. We received a call for one of the children from a friend (call her K)
  252. which appeared to come from a different friend's (call her A) home.
  253. Since I had a message for A, I asked if she could be put on the line
  254. since K was calling from A's house.  K denied vehemently being at A's
  255. house so the call ended poorly.
  256.  
  257. I later found out what apparently had happened.  A had been talking to
  258. K and they decided to add my child to the conversation. So A placed a
  259. 3-way call to my house, added K, but was then called away from the
  260. phone.  K was there when I answered, and was indeed at home, not at
  261. A's house.
  262.  
  263. So CNID can be spoofed if there is a willing collaborator at the
  264. desired apparent origin of the call.  Since my kids participated in
  265. figuring out what happened, they know how it is done.  I now have only
  266. a little more assurance of their location than my parents did of mine. :-)
  267.  
  268.  
  269. Andy
  270.  
  271.  
  272. [TELECOM Digest Editor's Note: But it isn't the CNID which is being, as
  273. you put it, 'spoofed'. Telco *is* reporting to you where the call you
  274. received originated at. The fact that another party to the three-way
  275. call was not identified on the display can hardly be termed a weakness.
  276. You say that 'K' vehemently denied being at the home of 'A'; while she
  277. was telling the truth she was doing so out of context obviously, and
  278. as the conversation continued I am surprised that she did not mention
  279. the fact that the call was three-wayed through 'A'. In a way, it seems
  280. odd that 'A' was called away from the phone just as the three-way
  281. connection was established and was unable (or chose not) to return to
  282. the line for the duration of the call. Don't forget, you are also free
  283. to place a call back to the number shown on the display; either your call
  284. back to the number shown will result in a straight forward connection to
  285. your daughter or it will result in clicking on the line while the call
  286. is being forwarded or your being placed on hold while another three-way
  287. call is set up. 
  288.  
  289. Most folks can tell by the sounds they hear as a call is being established 
  290. whether or not it is in fact being forwarded (listen for extra clicks
  291. or the slightest delay not usually there, etc) and in the event the
  292. call does go through as dialed a simple request 'do not put me on hold
  293. while you call my child to the phone' would either result in your
  294. child answering forthwith or the other end's inability to produce your
  295. child (since you have forbade the use of hold they can't very well
  296. flash and get another three-way connection up.) Still not perfect, I
  297. realize, but with a callback from your end you've added the need for
  298. more complicity on *their* end(s), and the risk that among them,
  299. someone's parent is likely to answer the phone, or come on the line,
  300. etc. In other words, you can add to the obstacle course and increase
  301. the likelyhood one or more of them will be caught in a lie.  PAT]
  302.  
  303. ------------------------------
  304.  
  305. Date: Mon, 23 May 1994 22:06:56 EDT
  306. From: Bob Keller <rjk@telcomlaw.com>
  307. Subject: Documents for AT&T Model 1539?
  308.  
  309.  
  310. Does anyone have the documentation (manual, instructions, etc.) for an
  311. AT&T Model 1539?  This is a single line telephone with a built-in
  312. digital (non-tape) remote answering system.  I picked one up (or most
  313. of one anyway -- it was missing a few cables, mounting brackets, etc.)
  314. "as is" out of a "bargain bin" at a local office supply store.  If
  315. anyone has whatever booklet explains the ins and outs of this thing,
  316. I'll gladly reimburse any reasonable expense incurred in copying and
  317. mailing/faxing it to me.  Thanks!
  318.  
  319.  
  320. Bob Keller <KY3R>        Robert J. Keller, P.C.        Tel +1 301 229 5208
  321. rjk@telcomlaw.com    Federal Telecommunications Law    Fax +1 301 229 6875
  322. finger me for daily FCC info + see ftp.clark.net:/pub/rjk/ for other files
  323.  
  324. ------------------------------
  325.  
  326. Date: Tue, 24 May 94 09:57:59 JST
  327. From: ali@ntep.tmg.nec.co.jp (Ali Tianero)
  328. Subject: Urgent Request For Help With Research
  329.  
  330.  
  331. Hello, Patrick!
  332.  
  333. I already wrote to the telecom listserv and asked for the index.
  334.  
  335. I couldn't find any information on cross connect equipments. I decided
  336. to mail you personally in the hope that you can help me with my problem.
  337.  
  338. We are studying XC equipment classes and attributes for an incoming
  339. project but we lack the needed data for a thorough study. In my
  340. opinion, it would help us with our project if we get to know more
  341. about the actual equipment so that the XC classes and attributes we
  342. are dealing with would become more concrete.
  343.  
  344. Once again, thanks for any help you can extend.
  345.  
  346.  
  347. Azaleah S. Tianero           | email : ali@ntep.tmg.nec.co.jp
  348. NEC Technologies Phils.,Inc. | tel(voice)  : +63 (32) 400-451
  349. MEPZ, Lapu-Lapu City         | tel(fax)    : +63 (32) 400-457
  350. 6015 Cebu, PHILIPPINES       | telnet(voice) : 8-0063-21-1653
  351.                              | telnet(fax)   : 8-0063-21-1607
  352.  
  353.  
  354. [TELECOM Digest Editor's Note: This party wrote essentially the same
  355. note originally to the Digest mailbox, and I did nothing with it. He
  356. then today wrote me at my personal maibox; I still don't really know
  357. how to answer him. If anyone wants to take a crack at it, please do
  358. so, writing Mr. Tianero personally.   PAT]
  359.  
  360. ------------------------------
  361.  
  362. From: paulb@iconz.co.nz (Paul Barratt)
  363. Subject: PCBX Systems
  364. Date: 24 May 1994 01:26:49 GMT
  365. Organization: Public Access Internet, Auckland New Zealand
  366.  
  367.  
  368. I had a look today at a system from PCBX, a small business PBX based
  369. on 386 / 486 DOS platform.  Does anybody have any user experience with
  370. this technology?  Looks pretty tidy, only not quite %100 for NZ
  371. telephony network.  
  372.  
  373.  
  374. Thanks, 
  375.  
  376. paulb@iconz.co.nz
  377.  
  378. ------------------------------
  379.  
  380. From: pbflower@uts.EDU.AU (-s89432566-p.bflower-ele-500-)
  381. Subject: Speech Recognition "Word Spotting"
  382. Date: 23 May 1994 23:43:02 GMT
  383. Organization: University of Technology, Sydney
  384.  
  385.  
  386. I'm looking for info on Word Spotting. Any info on developing a HMM to
  387. do this would be much appreciated. Please mail information or names of
  388. books, papers etc. that will do this.
  389.  
  390. ------------------------------
  391.  
  392. From: jay@kaiwan.com (Jason Chou)
  393. Subject: 900 mhz Cordless Phone; Any Information?
  394. Date: 20 May 1994 11:00:03 -0700
  395. Organization: KAIWAN Internet, CA
  396.  
  397.  
  398. Is there any information about 900 mhz cordless phones?  Has anyone
  399. heard of Micro 900 MHz by Bel-Tronics Limited?  Any good?  Thanks!
  400.  
  401.  
  402. Jason Chou   |   internet:jay@kaiwan.com   |   compuserve:70254,3706
  403.  
  404. ------------------------------
  405.  
  406. From: chambers@uh.edu (Charles Chambers)
  407. Subject: Re: 800 Number Billback
  408. Date: Fri, 20 May 1994 15:59:08 -0500
  409. Organization: University of Houston
  410.  
  411.  
  412. Based on the way these LD companies are handling charge back billing
  413. based on your ANI, what would the problem with having your ANI blocks
  414. from all LD companies (thus they can not bill back to it). I know that
  415. this currently can not be done, but rather, if it could be done, what
  416. would be the problems?
  417.  
  418.  
  419. Charles Chambers     University of Houston
  420. Telecommunications Department  Manager of Network Services
  421.  
  422.  
  423. [TELECOM Digest Editor's Note: The problem would be two-fold. First
  424. off, the rules currently say that local telcos may not withhold
  425. name and address information from long distance carriers -- even if
  426. the number is otherwise non-published -- for billing purposes. Local
  427. telcos are not in a position to evaluate the content of the connection
  428. given or the cost for same (except for stuff like billing errors, etc).
  429. So if the rule was changed where you the subscriber were allowed to 
  430. refuse any and all information to the long distance carriers, then you
  431. would wind up with no long distance service at all; after all, what
  432. carrier would want to handle your calls on the assumption that you might
  433. or might not decide reveal yourself and pay for it? You can get basically
  434. the same results now if you really want them: by not choosing any long
  435. distance carrier (or choosing 'none' if applicable) your phone will be
  436. effectively restricted from dialing long distance calls. Dialing 1 + 10
  437. digits here (except for 700,800,900 calls) with no carrier default on 
  438. your line causes the call to go to an intercept (cannot be completed as
  439. dialed). That still allows subscribers to deliberatly force a call out
  440. using 10xxx + 1 + 10 digits, but it takes a conscious decision on the
  441. subscriber's part; he is hardly in a position later to demand that the
  442. carrier not bill him or collect on the charges. Another more call-proof
  443. option available to subscribers -- at least here in Illinois Bell terr-
  444. itory -- is to have the Business Office completely toll-restrict your
  445. line. It can be set up in the central office with no overrides possible
  446. at all. With complete toll-restriction, even dialing through the operator
  447. won't work since she won't be able to complete the call for you either. 
  448. Double zero (for the long distance operator) will go to an intercept.
  449. You *will* be able to place collect, credit card or third-party billing
  450. calls however ... just no direct dial or operator assisted paid calls.  PAT]
  451.  
  452. ------------------------------
  453.  
  454. Date: Mon, 23 May 94 14:02:27 CST
  455. From: David Devereaux-Weber <weberdd@clover.macc.wisc.edu>
  456. Reply-To: David Devereaux-Weber <weberdd@macc.wisc.edu>
  457. Subject: Re: Information Wanted on Large Digital Data Exchange
  458.  
  459.  
  460. We have a set of rack mounted modems from: 
  461.  
  462. Multitech Systems
  463. 2205 Wooddale Dr.
  464. Mounds View, MN  55112
  465. (800) 328-9717   (612) 785-3500
  466.  
  467. We have about 400 on-line now, with plans to expand to 1000.
  468.  
  469.  
  470. David Devereaux-Weber, P.E.             weberdd@macc.wisc.edu (Internet)
  471. The University of Wisconsin - Madison   (608)262-3584 (voice) 
  472. Division of Information Technology      (608)262-4679 (FAX)
  473. Network Engineering
  474.  
  475. ------------------------------
  476.  
  477. From: shawnlg@netcom.com (Shawn Gordhamer)
  478. Subject: Re: Cellular Phone Timers
  479. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  480. Date: Mon, 23 May 1994 23:47:16 GMT
  481.  
  482.  
  483. Tony Harminc <EL406045@BROWNVM.brown.edu> writes:
  484.  
  485. >the phone has to be told by the network when charging starts and ends
  486. > -- a supervision signal, if you will.
  487.  
  488. One big problem is that just knowing when charging starts and ends
  489. won't be enough.  There would also need to be a "charge cancel"
  490. signal.  When you dial someone, the charge starts immediately, while
  491. the other phone is ringing (yes, you are charged ring time, at least
  492. at Cellular One).  But, if you hang up before they answer, the charge
  493. is canceled.  Therefore, there needs to be three signals to your phone:
  494.  
  495. - charge start pending
  496. - chargable call
  497. - charge end
  498.  
  499. I'd be happy if there was a way to subtract the last call from the
  500. total time timer on my phone.  I know if a charge is real or not, so
  501. at the end of the call, I can hit the "undo charge" function, and get
  502. an accurate total timer.
  503.  
  504.  
  505. Shawn Gordhamer    shawnlg@netcom.com   Rochester, Minnesota  USA
  506.  
  507. ------------------------------
  508.  
  509. From: sameer@atlas.com
  510. Subject: Re: NPA Optional in 818 - it Works!
  511. Organization: Atlas Telecom Inc.
  512. Date: Mon, 23 May 1994 22:21:51 GMT
  513.  
  514.  
  515. In article <telecom14.231.12@eecs.nwu.edu> dasher@netcom.com (Anton
  516. Sherwood) writes:
  517.  
  518. > I just tried it in 415.  Hooray!
  519.  
  520. It works for the 503 Area Code as well in Portland, OR.  
  521.  
  522.  
  523. Sameer
  524.  
  525. ------------------------------
  526.  
  527. Date: Mon, 23 May 1994 23:13:31 PDT
  528. From: Marty Brenneis <droid@kerner.com>
  529. Subject: Re: New (Lame) Directory Assistance From GTE Mobilnet (Bay Area)
  530.  
  531.  
  532. On Tue, 17 May 1994 Henry Mensch wrote:
  533.  
  534. > Moral of the story: to use GTE's new gimmicky directory assistance dial 411 
  535. > or 555 1212 ... to get the real stuff dial *6543. Your mileage may vary, 
  536. > especially outside the Bay Area.
  537.  
  538. And TELECOM Digest Editor noted in response:
  539.  
  540. > [TELECOM Digest Editor's Note: Henry, a question and a comment: exactly
  541. > what does this *6543 hook get you into?  You said 'new, gimmicky directory
  542. > assistance' which leads me to wonder, did not GTE offer directory assist-
  543. > ance like any other telco until recently, i.e. 'new'?. Is the cellular
  544. > division of the company offering a new service and intercepting calls to
  545. > 411 or 555-1212 which formerly had gone to a full directory bureau and
  546. > providing some limited sub-set of the directory?  
  547.  
  548. We are not talking GTE landline service here, we are talking GTE
  549. Mobilenet cellular service. They have decided to do their own DA
  550. service with people who don't have a clue how to look up a number.
  551. Once they look up the number for you they just connect you to it. Of
  552. course they nick you a little more for this "service".  You pay the
  553. airtime while the person takes five times longer to find the wrong
  554. number than a professional DA. The only good side is that they handle
  555. DA for all of the GTE calling area, this way you can just dial 411 and
  556. not worry about what the NPA is for your target party. Pac*Bell is the
  557. local DA service from the landline side and they do an excellent job.
  558. Perhaps the next time Pac*Bell lays off some DAs, GTE should hire
  559. them.
  560.  
  561. Yo! You operating companies out there! I know that the DA centers have
  562. been merging for many years. When I dial 411 in the 415 area the DA I
  563. speak with really is taking calls for 415,510,707,408 and perhaps many
  564. more. The ones in Sub California handle a bunch of NPAs. Why can't
  565. they give the number that is outside the NPA that I dialed? It would
  566. reduce traffic load.
  567.  
  568.  
  569. Marty 'The Droid' Brenneis                      ...!uupsi!kerner!droid
  570. Industrial Magician                                   droid@kerner.com
  571. (415)258-2105     ~~~   KAE7616 - 462.700 - 162.2      ~~~      KC6YYP
  572.  
  573. ------------------------------
  574.  
  575. Date: Mon, 23 May 1994 15:18:35 EDT
  576. From: Paul Robinson <PAUL@TDR.COM>
  577. Reply-To: Paul Robinson <PAUL@TDR.COM>
  578. Subject: Re: WANTED: Hand-Held Challenge/Response Units
  579. Organization: Tansin A. Darcos & Company, Silver Spring, MD USA
  580.  
  581.  
  582. > I'm looking for suppliers of hand-held challenge/response 
  583. > cipher key systems ...
  584.  
  585. > I envisage they'll work as follows:
  586.  
  587. > 1.      User connects via public network to our system;
  588. > 2.      Our system lets them log in as normal, but they then
  589. >         are "challenged" with a long code.
  590. > 3.      The user must enter the code into the hand-held unit,
  591. >         which provides the "response" using RSA or similar.
  592. > 4.      The user then enters the "response", which is validated
  593. >         against the expected value.  This may involve the use
  594. >         of a public/private key system also, for encryption
  595. >         of transmitted material.
  596.  
  597. > I'm very hopeful that units such as I've just described exist -- if no
  598. > perhaps someone wants to make them?  (e.g. based on HP-100LX).
  599.  
  600. You need nothing near this complicated or expensive.  A simple, and
  601. free system for doing the exact thing you have described, called
  602. "skey" is already available.  The user can either preprint the
  603. one-time usage passwords or run a short program on his own PC to
  604. compute them.  Any time prior to running out of passwords he can
  605. generate some more.
  606.  
  607. The following is from the documentation for the program:
  608.  
  609.    Description of The S/KEY One-Time Password System
  610.   
  611.      Neil M. Haller nmh@thumper.bellcore.com
  612.      Philip R. Karn karn@chicago.qualcomm.com
  613.   
  614.    ABSTRACT
  615.  
  616. The S/KEY one-time password system provides authentication over
  617. networks that are subject to eavesdropping/reply attacks. This system
  618. has several advantages compared with other one-time or multi-use
  619. authentication systems.  The user's secret password never crosses the
  620. network during login, or when executing other commands requiring
  621. authentication such as the UNIX passwd or su commands.  No secret
  622. information is stored anywhere, including the host being protected,
  623. and the underlying algorithm may be (and it fact, is) public
  624. knowledge. The remote end of this system can run on any locally
  625. available computer.  The host end could be integrated into any
  626. application requiring authentication.
  627.  
  628.                 --------------------------
  629.  
  630. Had people been using this for network logins, that "password grabber"
  631. program that was circulating a few months back would have been useless
  632. and all people would have gotten was a lot of used and worthless
  633. passcodes that no longer work.
  634.  
  635. A person who has it on their system told me that:
  636.  
  637.    Generating the keys is a painless process of running a command or 
  638.    two and typing in a password; the program(s) then generate a certain 
  639.    number of keys which can be printed out and carried in a person's 
  640.    wallet.  No extra hardware is required. 
  641.  
  642. The files for this system can be obtained via anonymous ftp to 
  643.  
  644. thumper.bellcore.com:  /pub/skey
  645.  
  646.  
  647. Paul Robinson - Paul@TDR.COM
  648.  
  649. ------------------------------
  650.  
  651. End of TELECOM Digest V14 #246
  652. ******************************
  653.  
  654.