Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!jon From: jon@athena.mit.edu (Jon A. Rochlis) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP based authentication of hosts Message-ID: <10526@bloom-beacon.MIT.EDU> Date: 11 Apr 89 20:28:45 GMT References: <376@ists.ists.ca> <29416@bu-cs.BU.EDU> <29455@bu-cs.BU.EDU> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: jon@mit.edu (Jon A. Rochlis) Organization: Massachusetts Institute of Technology Lines: 33 In article <29455@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes: > I would not want to allow someone with genuine >Kerberos-authenticated access to login from an "open" subnet. I would >want some assurance that the data stream is following routes >controlled by the routers and not by the hosts. (Another argument >against source routing :-) > > Is this reasonable? I don't think so. What does an "open" subnet mean? Remember the model we're working with here. The path from client to server may span several networks and pass through several (many) routers each possibly under different (and potentially hostile) administrative control. You cannot say (now or for very long in the future) that you only allow access to your campus resources from some "secure" subnets which you in some fashion control. If a professor from BU wants to log into an MIT colleague's machine using Kerberos am I supposed to disallow that because I don't control the BU subnet he's coming from, the routers in the path on the BU backbone, or the NEARNet backbone/routers? What if he's coming in over the NSFnet? It's the "principal" who's accessing the data, not the machine he's currently using. Where the ends of the converstation or the path the packets take shouldn't matter. [Some information may be too sensitive for this, but that should be the exception for quite a while. No classified on the Internet, right!] The only real solution is an end-to-end approach using something other than addresses for authentication. -- Jon