|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Suggestion for improved identD
On Tue, 19 May 1998, Ehud Gavron wrote: > Suggestion: PPP access devices intercept identD requests > and return the authenticated access string. Reasonable idea in -some- network settings. > Methods: 1: identD v2, new port, intercepted by access devices > which support it. Bad choice. Time to adoption would kill the idea. We're already on a second run of the AUTH protocol as it is. ;-) > 2: modification to hosts requirement RFCs, making > access devices responsible for intercepting identD > requests to their PPP clients. > > 3: a security RFC ``suggesting'' 1 or 2 Both a bad idea. This is not something necessary in most settings; some people are simply not interested in giving up this information. I'd oppose any such attempt to make it a host requirement. Read the auth/ident protocol RFC: the data retrieved using it is inherently untrustable, and cannot be relied upon to be even remotely correct. In some circumstances, you may not even be able to determine what the information means; that identification information may have absolutely no meaning to you since you have no control over how the network you retrieved the information from operates. However, the idea does have merits for closed environments, or for open environments which desire accountability for their dialup users when dealing with external abuse or bug reporting. I would recommend a slightly more sophisticated approach, however: a semi-configurable identd running on the terminal server, which either: a) returns the auth'd data, or b) hands the request off to a server running on another machine, which can do interesting things with the information before returning a response. The reason for this is that this idea would need to be adopted by NAS vendors; frankly, I don't trust them to get the implementation right, and would rather they just proxy the request to me, along with the necessary host and internal authentication information, which I can then process in my own way, and return what -I- consider to be a unique identifier for that user. But frankly, a timestamp and an IP address are all the "unique identifier" you need for tracking down an abuser on any relatively modern network doing a reasonable level of logging. -- -------------------. emarshal at logic.net .--------------------------------- Edward S. Marshall `-----------------------' http://www.logic.net/~emarshal/ Linux labyrinth 2.1.101 #2 SMP Sun May 10 22:34:20 GMT 1998 i586 unknown 9:55pm up 1 day, 23:26, 4 users, load average: 0.02, 0.11, 0.15
|