Phil Howard writes:
There isn't necessarily just a single user on the other end of a PPP connection. Many things will break if the actual user and the user that PPP intercepted identd asserts do not match.
Providing such information may be a violation of confidentiality if it gives information about a person or that person's account, especially if the person does not want to give it out.
Then do the hash thing that I suggested earlier. (I'm not taking credit for the idea btw.. it wasn't mine.)
Because the PPP access device cannot know, unless it also tracks all the traffic involved, what ports are in fact in use, it would have to give the response for any port, even if not in use. This means anyone can get the ID only by knowing the IP. This will be very VERY easy to abuse by spammers trolling for addresses, under the notion that the ident data generally would match the e-mail address for that domain.
Then do the hash thing.
I believe you misunderstand the purpose of identd. It was intended to supplement the IP address on a multi-user system to narrow the focus of trust in cases where the system itself was trusted (not longer a valid assumption these days).
The system might not be trusted.. but the NAS is. Why bother with ident in any case if most of the dialup users can spoof it? Far far too many applications still send off an ident request and log it.
Why do you want this data? And would you really want the correct userid from a multi-user system or a masqueraded network of multiple machines which the PPP device cannot know?
If you really needed this, then have the NAS configureable so: * You can send a RADIUS/TACACS tag specifying "no ident spoofing" * It doesn't spoof ident on IPS that aren't in the specified IP pools That provides ident support for dialup clients, but passes through ident requests for static clients. You can't get the contact details directly from the hash, but you can use it to deny access to services (eg sendmail, nntp, irc) that run ident checks. Adrian