[371] in Kerberos
Kerberos and host addresses
daemon@TELECOM.MIT.EDU (kazar+@andrew.cmu.edu)
Sun Apr 24 21:38:53 1988
From: kazar+@andrew.cmu.edu
Resent-From: Mike Kazar <kazar+@ANDREW.CMU.EDU>
Resent-To: kerberos@ATHENA.MIT.EDU
To: Mike Kazar <kazar+@ANDREW.CMU.EDU>
Mike,
Here's a copy of a recent discussion on the "kerberos" mail
list which may be of interest.
Jennifer
------- Forwarded Message
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA08666; Tue, 19 Apr 88 18:02:03 EST
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA09827; Tue, 19 Apr 88 17:49:26 EST
Received: by ucbarpa.Berkeley.EDU (5.59/1.28)
id AA11331; Tue, 19 Apr 88 15:48:44 PDT
Date: Tue, 19 Apr 88 15:48:44 PDT
From: jordan@ucbarpa.Berkeley.EDU (Jordan Hayes)
Message-Id: <8804192248.AA11331@ucbarpa.Berkeley.EDU>
To: sdsu!vinge@ucsd.edu
Subject: Re: kerberos question
Cc: kerberos@ATHENA.MIT.EDU
From: sdsu!vinge@ucsd.edu (Vernor Vinge)
Why is it necessary to include the client's IP address in
the tickets and authenticators? Wouldn't the client's name
suffice?
I don't think there's a big problem just using the name, except
that it's probably easier to code using an IP address, since it's
a fixed length. The other problem is that you may not be able to
resolve the name correctly all the time. Probably it's just easier.
I'm not sure what the system does about gateways (those machines
that have more than one IP address), but it probably checks all
the addresses.
Why is it necessary to include the server's name in the
ticket?
To make sure you get the right server? You need to tell the
ticket-granting service which server you want, so I assume it's in
the initial request.
Who on the kerberos design-team is on this list?
/jordan
----------
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA09143; Tue, 19 Apr 88 19:33:39 EST
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA11308; Tue, 19 Apr 88 19:32:57 EST
Received: by STEVE-DALLAS.MIT.EDU (5.45/4.7) id AA05954; Tue, 19 Apr 88 20:32:31 EDT
Date: Tue, 19 Apr 88 20:32:31 EDT
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Message-Id: <8804200032.AA05954@STEVE-DALLAS.MIT.EDU>
To: jordan@ucbarpa.berkeley.edu
Cc: sdsu!vinge@ucsd.edu, kerberos@ATHENA.MIT.EDU
Subject: Re: client name vs. client IP address.
The IP address is sealed into the ticket in an attempt to increase
security by a small amount. Someone attempting an attack by replay
must be able to forge the `from' address of an IP packet, which is
(marginally) harder than just sending packets, and is more likely to
be noticed.
The hostname is not in there because doing a nameserver/host table
lookup will impose a pretty large network delay on the server end; in
the current setup, the server side never blocks for I/O (not counting
looking up the service key).
Also, the domain nameserver is eminently spoofable, since its requests
aren't authenticated...
With respect to multi-homed clients (clients with more than one net
address): this is a problem which hasn't really been resolved, as
there is only one address in the packet. If the client binds all its
outgoing sockets to its `primary' address, this ceases to be a
problem, but this requires special code in each client application
using kerberos.
I suspect that there will be some sort of protocol rearrangement in
the future which should include (a) having a list of addresses sealed
in the ticket and (b) tagging each address with some sort of address
family code (I'm pretty sure that DEC, IBM, and Apollo are all
interested in using kerberos over their own proprietary protocols, and
ISO is looming somewhere over the horizon...).
The _service_ name is included in the ticket as an extra check to
make sure that the ticket was decrypted correctly.
- Bill
------------
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA13767; Wed, 20 Apr 88 13:16:43 EST
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA24456; Wed, 20 Apr 88 13:08:50 EST
Received: from relay2.cs.net by RELAY.CS.NET id ac00397; 20 Apr 88 10:26 EDT
Received: from cs.brown.edu by RELAY.CS.NET id ab29151; 20 Apr 88 10:09 EDT
Received: by cs.brown.edu (5.51/1.00)
id AA28389; Wed, 20 Apr 88 09:29:58 EST
From: Jim Bloom <jb%cs.brown.edu@RELAY.CS.NET>
Message-Id: <8804201329.AA15527@archer.cs.brown.edu>
To: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Cc: jordan@UCBARPA.BERKELEY.EDU, sdsu!vinge@UCSD.EDU, kerberos@ATHENA.MIT.EDU
Subject: Re: client name vs. client IP address.
In-Reply-To: Your message of Tue, 19 Apr 88 20:32:31 EDT.
<8804200032.AA05954@STEVE-DALLAS.MIT.EDU>
Date: Wed, 20 Apr 88 09:29:11 EDT
Those problem with multiply homed hosts are a real pain. When I
initially installed kerberos, I found that gethostid(2) was used
to determine the primary address. I didn't have the hostid set
and the call returned zero. The IPC worked fine, but the protocol
broke because different "addresses" were used. These problems
occured on a host with only one interface.
Using one address as primary on a multiply homed host and only
using that address may lead to problems. Communication might be
only one direction due to routing differences. At Brown, we have
a host on network 128.148 and 128.121. I have seen cases where
the route selected might go through some other machine, out to the
internet and return. Selection of the correct address by the
kernel would totally avoid the problem. For whatever reason,
the hostid might be set to the wrong interface.
Jim
------- End of Forwarded Message
