home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / vmsnet / networks / tcpip / multinet / 1827 < prev    next >
Encoding:
Text File  |  1992-07-29  |  4.8 KB  |  116 lines
  1. X-Gateway-Source-Info: INTERNET
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!network.ucsd.edu!mvb.saic.com!tgv.com!info-multinet
  3. Date: 29 JUL 92 22:57:54 GMT
  4. Newsgroups: vmsnet.networks.tcp-ip.multinet
  5. X-Return-path: <info-multinet-relay@TGV.COM>
  6. X-RFC822-From:    FORREST@RIGEL.TAMU.EDU (Bob Forrest, Academic Computing Services)
  7. From: FORREST@RIGEL.TAMU.EDU
  8. Subject: Re: RFC931 support?
  9. X-Vmsmail-To: SMTP%"info-multinet@tgv.com"
  10. Organization: The INFO-MULTINET Community
  11. Message-ID: <238052D629JUL92225754@TGV.COM>
  12. Nntp-Posting-Host: Mvb.Saic.Com
  13. Lines: 101
  14.  
  15. -> From:    SMTP%"Adelman@TGV.COM" 29-JUL-1992 14:25:20.18
  16. -> To:    Don.Rainwater@UC.Edu
  17. -> CC:    
  18. -> Subj:    Re: RFC931 support?
  19. -> 
  20. -> Date:     Wed, 29 Jul 92 11:26:22 PDT
  21. -> From:     adelman@TGV.COM (Kenneth Adelman)
  22. -> Reply-To: Adelman@TGV.COM (Kenneth Adelman)
  23. -> Message-Id: <920729111738.25e00294@TGV.COM>
  24. -> Subject:  Re: RFC931 support?
  25. -> In-Reply-To: Your message <1992Jul29.121720.1580@ucbeh.san.uc.edu> dated 29-Jul-1992
  26. -> To:       Don.Rainwater@UC.Edu
  27. -> cc:       info-multinet@TGV.COM
  28. -> 
  29. -> >      Some people (from other sites even) have been asking about support
  30. -> > for RFC931, which provides for the authentication of a connection between
  31. -> > two systems.    For example, it would allow you to find out who that person
  32. -> > is that has a telnet connection open to your system from across the
  33. -> > country.
  34. -> 
  35. -> >      Are there any plans to support this in Multinet?
  36. -> 
  37. ->     Absolutely none.  RFC931 is NOT an authentication protocol, it is
  38. -> a protocol which allows a user on a machine to claim that a particular
  39. -> connection is owned by a particular user.  It doesn't provide any
  40. -> additional security, and a substantial false sense of security.
  41.  
  42.     There is on-going work on revisions to what was previously known as
  43. RFC931 and the 'authentication protocol'.  The new revisions are known
  44. as the 'Identity protocol'.   I think most people agree with the possible
  45. problems associated with 'authentication' (there has been a lot of debate
  46. on the  ident mailing list...).   However, I think that it has been argued
  47. fairly well that the upcoming Identity protocol is *quite* useful in
  48. tracking down forged e-mail and possibly in other forgery attempts.
  49.  
  50.    In a campus environment such as ours, we have a significant problem
  51. with e-mail forgeries.   The platform management is quite trustworthy;
  52. however,   $ TELNET/PORT=SMTP nodename.TAMU.EDU
  53. kind of bypasses that...     Having the ability to provide identification
  54. to tcp connections would be very worthwhile.  While for most applications
  55. we would not in any way be interested in using the tcp identification
  56. information in authentication, it would be quite helpful as an 
  57. 'after the fact' method of trying to track down forgers and have student 
  58. affairs (or some other appropriate organization on campus) deal with that 
  59. person.
  60.  
  61.    Don't consider the RFC931 idea as an 'authentication only' scheme and
  62. blow it off.  There are quite legitimate applications that would use the
  63. information for auditing purposes!   (Yes, the auditing information
  64. would have to be interpreted, but then doesn't *ALL* auditing information
  65. have to be interpreted? :) .
  66.  
  67. -> 
  68. ->     We'd be happy to implement a protocol which did what RFC931 does
  69. -> if someone could point out some value to it (other than security
  70. -> through obscurity), and only if it weren't titled "Authentication
  71. -> Server".
  72.  
  73.    Auditing is not security through obscurity.  Any means of trying to
  74. track down forgeries would be better than the current method...
  75.  
  76.   Also, the title is changing.  The new protocol will not be called the
  77. "Authentication Server" :)
  78.  
  79.  
  80. -> 
  81. ->                             Ken
  82. -> 
  83. -> 
  84. -> 
  85. -> 
  86.  
  87.    How about TGV providing an interface callable from VAX C to return the
  88. process id associated with a given tcp socket pair between a remote tcp
  89. host and the host the call is made on?   As for 'locking the kernel down'
  90. being a reason not to implement this, don't  --- just return the best 
  91. estimate (we can code other checks to see what the process is doing
  92. if we really need to).   This would be quite helpful!
  93.  
  94.   Or if that doesn't go over, how about giving hints as to how to use
  95. the nlist(...) calls to obtain the information necessary to determine the
  96. process id?
  97.  
  98.  
  99.  Thanks.
  100.  
  101.  
  102.  Bob Forrest 
  103.  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  104.  Programmer/Analyst I              HEPnet:    FNBIT::UTDAL::RIGEL::FORREST
  105.  Texas A&M University              SPAN:      UTSPAN::UTADNX::RIGEL::FORREST
  106.  Academic Computing Services       THEnet:    RIGEL::FORREST                
  107.  WERC Room #020                    BITnet:    FORREST@TAMRIGEL              
  108.  Mail Stop 3154                    SESquinet: FORREST@RIGEL.TAMU.EDU        
  109.  College Station, Texas 77843-3154 Phone:     409-845-9577
  110.  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  111.  
  112.  
  113.  
  114.  
  115.    
  116.