Slide 19 of 21
Notes:
Encrypted identd came as a surprise to me.
I had been familiar with identd , and the fact that it could potentially compromise ones own security by giving away the identity of callers to any called party who asked for it. This we certainly didnt want, indeed I had been disabling finger for similar reasons.
However, if a remote site believes they are under attack from one of your users (or from someone who has hacked into your site), then it can be useful if they can get some kind of handle on who is calling them. Ergo, the encrypted identd. This is an option of the widely available pidentd package.
When someone suspects they are a victim, they can request an encrypted token from your identd server. This is made freely available, but does not mean anything to them. However, when they contact you with this identifier, you can not only decrypt it to identify the user account involved and other relevant details, but the fact that they were able to present this token guarantees to you that the user in question had been accessing their system at the time, i.e that the accusation isnt a fabrication. This sounds rather useful when it happens, although as the scheme doesnt seem to me to be particularly widely known, I can only guess what proportion of incidents are actually going to benefit from such a service.