Re: ``WHY TAP?'': A White Paper

["Daniel J. Bernstein" <[e-mail]>]

In message <[e-mail]> you write:
> I may not have understood what Dan wrote in his paper.

Sounds like you understood it fine.

> Sigh. Here is a very simple quick and dirty security analysis:

You have concluded that NH has subverted the TAP server on a multi-user
machine. One of your assumptions is that NH has subverted the entire
machine. Why do I fail to see the relevance of this ``analysis''?

``Here is a very simple quick and dirty security analysis: Some nasty
hacker (NH) with a PC breaks into and subverts a Kerberos master. He
then controls all keys stored on the master. He uses this to attack the
network.''

> Assertion: The above shows that TAP does not provide any information
> 	   that is not already available when it is not present.

This conclusion is totally unjustified.

``Assertion: The above shows that Kerberos does not provide any
information that is not already available when it is not present.''

> The only way that a person or process would be able to
> know that an active forgery is in progress, is if it interprets the
> value returned from TAP.

So? Nothing in the white paper talks about knowing ``that an active
forgery is in progress.'' Section 2 is about *auditing*.

> It is a very bad idea to assign blame only based on TAP server
> information.

You bring up the orthogonal problem that TAP identifiers may not be
strongly associated with real people. What you should have said is
``Although TAP server information may let you assign blame to
*identifiers*, it is a very bad idea to assign blame to *users*, unless
your machine is so secure that you're sure about the connection between
identifiers and users.''

Actually, there are many sites where a user is given responsibility for
all actions performed by his account, whether or not they were his
actions. Mark, who are you to tell these sites that this is a ``very bad
idea''? Maybe they know a lot more about security than you do.

> Concerning '3. Selective blocking'.
> Nothing in TAP says that a host which is generating an encrypted
> userid needs to return the same value each time that a remote host
> makes a query. Yet, in '3. Selective blocking' these lines
> 	Or---if the remote host runs TAP---you can cut off the one
> 	userid causing trouble, and watch to make sure that other
> 	identifiers don't start attacking.
> seems to indicate that TAP clients are able to be selective (access
> control) about the behavior of the TAP client.

If you cut off the one id causing trouble, and watch for other
identifiers from the same host, and it happens that the host provides
different identifiers for each connection, then indeed you will see
other identifiers and you will have to cut off the entire host.

So what's your point? Yes, if you add timestamps to your identifiers,
you will no longer get any benefit from selective blocking. Why is this
``inconsistent''?

> Note: I am personally against ANY/ALL active uses of TAP or Ident.

Tough luck. There is absolutely nothing wrong with selective blocking.
You may not like it but you don't have the right to stop other people
from using it.

---Dan