Date: 29 JUL 92 22:57:54 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From:    FORREST@RIGEL.TAMU.EDU (Bob Forrest, Academic Computing Services)
From: FORREST@RIGEL.TAMU.EDU
Subject: Re: RFC931 support?
X-Vmsmail-To: SMTP%"info-multinet@tgv.com"
Organization: The INFO-MULTINET Community

-> From:	SMTP%"Adelman@TGV.COM" 29-JUL-1992 14:25:20.18
-> To:	Don.Rainwater@UC.Edu
-> CC:	
-> Subj:	Re: RFC931 support?
-> 
-> Date:     Wed, 29 Jul 92 11:26:22 PDT
-> From:     adelman@TGV.COM (Kenneth Adelman)
-> Reply-To: Adelman@TGV.COM (Kenneth Adelman)
-> Message-Id: <920729111738.25e00294@TGV.COM>
-> Subject:  Re: RFC931 support?
-> In-Reply-To: Your message <1992Jul29.121720.1580@ucbeh.san.uc.edu> dated 29-Jul-1992
-> To:       Don.Rainwater@UC.Edu
-> cc:       info-multinet@TGV.COM
-> 
-> >	  Some people (from other sites even) have been asking about support
-> > for RFC931, which provides for the authentication of a connection between
-> > two systems.	For example, it would allow you to find out who that person
-> > is that has a telnet connection open to your system from across the
-> > country.
-> 
-> >	  Are there any plans to support this in Multinet?
-> 
->     Absolutely none.  RFC931 is NOT an authentication protocol, it is
-> a protocol which allows a user on a machine to claim that a particular
-> connection is owned by a particular user.  It doesn't provide any
-> additional security, and a substantial false sense of security.

    There is on-going work on revisions to what was previously known as
RFC931 and the 'authentication protocol'.  The new revisions are known
as the 'Identity protocol'.   I think most people agree with the possible
problems associated with 'authentication' (there has been a lot of debate
on the  ident mailing list...).   However, I think that it has been argued
fairly well that the upcoming Identity protocol is *quite* useful in
tracking down forged e-mail and possibly in other forgery attempts.

   In a campus environment such as ours, we have a significant problem
with e-mail forgeries.   The platform management is quite trustworthy;
however,   $ TELNET/PORT=SMTP nodename.TAMU.EDU
kind of bypasses that...     Having the ability to provide identification
to tcp connections would be very worthwhile.  While for most applications
we would not in any way be interested in using the tcp identification
information in authentication, it would be quite helpful as an 
'after the fact' method of trying to track down forgers and have student 
affairs (or some other appropriate organization on campus) deal with that 
person.

   Don't consider the RFC931 idea as an 'authentication only' scheme and
blow it off.  There are quite legitimate applications that would use the
information for auditing purposes!   (Yes, the auditing information
would have to be interpreted, but then doesn't *ALL* auditing information
have to be interpreted? :) .

-> 
->     We'd be happy to implement a protocol which did what RFC931 does
-> if someone could point out some value to it (other than security
-> through obscurity), and only if it weren't titled "Authentication
-> Server".

   Auditing is not security through obscurity.  Any means of trying to
track down forgeries would be better than the current method...

  Also, the title is changing.  The new protocol will not be called the
"Authentication Server" :)


-> 
-> 							Ken
-> 
-> 
-> 
-> 

   How about TGV providing an interface callable from VAX C to return the
process id associated with a given tcp socket pair between a remote tcp
host and the host the call is made on?   As for 'locking the kernel down'
being a reason not to implement this, don't  --- just return the best 
estimate (we can code other checks to see what the process is doing
if we really need to).   This would be quite helpful!

  Or if that doesn't go over, how about giving hints as to how to use
the nlist(...) calls to obtain the information necessary to determine the
process id?


 Thanks.


 Bob Forrest 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Programmer/Analyst I              HEPnet:    FNBIT::UTDAL::RIGEL::FORREST
 Texas A&M University              SPAN:      UTSPAN::UTADNX::RIGEL::FORREST
 Academic Computing Services       THEnet:    RIGEL::FORREST                
 WERC Room #020                    BITnet:    FORREST@TAMRIGEL              
 Mail Stop 3154                    SESquinet: FORREST@RIGEL.TAMU.EDU        
 College Station, Texas 77843-3154 Phone:     409-845-9577
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




   
X-Gateway-Source-Info: INTERNET