Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!stanford.edu!sco.COM!davided
From: davided@sco.COM (Dave Edmondson)
Newsgroups: comp.protocols.kerberos
Subject: re: Kerberos and two ethernet ports
Message-ID: <6608.674990013@sco.com>
Date: 23 May 91 09:13:33 GMT
Sender: news@shelby.stanford.edu (USENET News System)
Organization: Internet-USENET Gateway at Stanford University
Lines: 38

jaw# I believe that the problem is caused by the Sequent having two
jaw# ethernet ports and kerberos is seeing a request coming from the
jaw# secondary enet port with the IP address of the primary enet port
jaw# in the authenticator and so rejects the request thinking that
jaw# someone is trying to masquerade as the host.
i have seen this problem too, and i recall that people at athena knew
about it.

jaw# Has anyone else seen this problem? Does anybody have any ideas as
jaw# to what could be happening and how I could fix it or work around
jaw# it?
three solutions suggest thenselves:
	1) get v5.  as i understand it (not read the v5 spec for quite
	a while) v5 will allow multiple addresses, and even multiple
	protocol families to be passed around in tickets.
	2) somewhere in libkrb (krb_rd_req springs to mind) is the
	place where the address check is performed.  you could add a
	reverse lookup here and check all of the hosts addresses
	against that which originated the packet.  the problem with
	this is that the name server is not a secure service, so it's
	reasonably easy to start spoofing.  the was a paper written
	about doing a secure nameserver, but i don't know if it ever
	got anywhere.
	3) fix your kernel.  somewhere in the code which emits ip
	packets is that part which inserts the correct ip address for
	the port from which the packet will travel.  it seems quite an
	easy change to make all packets be transmitted with the same
	address (ie the principal one).  i recall hearing that 4.4bsd
	does this.  this could introduce problems (inefficiencies
	really) when routing replies though.
last time i hit the problem, i went for solution 2, and just had to
cope with the occasional loss in security where multi-interface hosts
were concerned.

dave.
---
          Dave Edmondson, Santa Cruz Operation, davided@sco.com
  ``All those lines and circles, to me a mystery.'' -- Ten Thousand Maniacs