[EMAIL PROTECTED] writes: > > Oh. I though that pidentd was supposed to resolve UIDs locally. > > That's one of the features of the protocol; it provides "here's who > > *I* think the user is" information back to the requester. > > Of course, that's why I thought IDENT was a fairly bogus mechanism > since you're asking the remote system to report on its own users and > someone who controls that machine can report whatever their heart > desires.
It has its value, you just have to know how to use it. > Or has the mechanism changed over the years? Has there been any work > in the IETF, for example, to try and develop something more useful than > identd? No. The value is this: it provides you a way to ask for a durable but unauthenticated identifier of some sort (doesn't really matter what sort -- it's opaque as far as the receiver is concerned) to associate with that connection. The purpose is for debug and hunting down abusers with cooperating admins. It's no more or less secure than the source port number. In other words, instead of saying "I saw a connection at 2:34PM yesterday from 10.0.0.1:5678, and it looks like he was trying to hack into my system; can you talk to this user?" You can say "I saw a connection at 2:34PM yesterday from 10.0.0.1:5678 from someone your system identifies as 'FooBar,' and it looks like he was trying to hack into my system; can you talk to this user?" If that *remote* admin is himself useful (he may not be) and if he trusts the value from his own IDENT report (he should), then it'll give him an easier time tracking down the offender. If you don't do this, then the only thing that poor remote admin has to go on is the socket parameters, and that's very little data for a multiuser system. It's effectively useless, unless that remote admin is a weirdo who is logging every single packet along with local UID. It all hinges on cooperating system administrators for multiuser systems. If you don't have that, then you have to go to higher layers (using address alone, assuming single-user systems, uRPF, and address assignment that relates to the user) or higher still (service providers). -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ zones-discuss mailing list [email protected]
