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

["Mark D. Baushke" <[e-mail]>]

A few comments on Dan's white paper.

I may not have understood what Dan wrote in his paper. However, I will
comment from my understanding of what I read. These are my opinions
and reasoning alone.

In section 1, Dan says:

	It is occasionally stated that TAP is useless on the Internet
	as a whole, or that it is useful in stopping attacks only
	because attackers (supposedly) don't know about it, or that it
	provides no ``real'' security at all. 

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

Postulate: The entire universe is running TAP on every machine capable
	   of establishing a connection to a another machine.

Assume:    Nasty Hacker (NH) owns a PC. Installs his own TAP which
	   returns any information he wants at any time. (TAP is a
	   simple protocol right?)

Attack:    NH attacks, breaks into and subverts another machine. He
	   may or may not be able to nuke all TAP information on his
	   attack, but it is useless to identify him. You need to fall
	   back to existing methods of tracing IP packets.

Subverted: Now that NH has subverted your machine, he may use it to
	   attack other machines by installing his own version of TAP
	   on the subverted machine.

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

Note:      TAP and IDENT *may* be useful in the case of a failed
	   attack, but using something like tcp_logger would be as
	   effective and not warn the NH with an active challenge that
	   you might be keeping logs on his attempts.

Don't get me wrong, I believe that TAP/Ident have useful features, but
I don't believe that this introduction represents objective
information of what has gone on in previous criticisms.

	These criticisms are usually justified by repetition rather
	than by a proper security analysis. 

Hmmm... Is something wrong with the above trivial analysis that I am
missing? 	
	
	At their heart they are based on the assumption that a host
	running a TAP server is trying to benefit the rest of the
	community.

This is not my assumption. A TAP server can also collect information
on MY users network usage patterns (but that is an implementation
detail). In fact, I am surprised that Dan did not include this benefit
in his analysis. Keeping track of WHO is getting queries may be a
reasonable way to audit outgoing connectivity in order to plan for
added capacity and know who to charge for the added capacity. :-)
	
	In fact the benefits of a TAP server _accrue to the host
	running the server_. This theme will show up again in the
	examples below.

The benefits of TAP/Ident servers and clients exist. However, I do not
necessarily concur with Dan regarding the nature of those benefits.

Concerning '2. Remote auditing'. I have no problems with the first two
paragraphs. I just wish to note that the third paragraph seems to be
inconsistent with section 3 (see below):

	You may not want to give away free information about your
	users. You may also want to verify, without having to keep
	your own logs, that the guy on the other end is telling the
	truth about what he heard from your TAP server. An easy
	solution to both problems is to encrypt your usernames (along
	with a timestamp, perhaps) in a secret key.

More on using an encrypted TAP identifier below under discussion of
section 3.

The next paragraph:	
	
	Of course the scenario outlined above is a worst case. Less
	serious cases in which remote auditing is useful include mail
	forgery via SMTP and news forgery via NNTP. Or perhaps your
	host is the TCP Toaster, and you want an easy way to track
	down malfunctions. In all of these cases TAP at least removes
	the minor nuisances which constitute 99% of all network
	problems. In particular, it completely stops the problem of
	above-TCP mail forgery. Anyone can send an anonymous message
	(through the post office if all else fails!), but, with TAP,
	normal users on your machine can't send messages which look
	like they came from other users.

bothers me. 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. I can agree that if a user suspects a message
may be a forgery, he could ask the administrator of the TAP site to
peek into the TAP data and tell him if it really was user xyz that
sent the message or posted the article.

Finally, I have a problem with

	Notice that the benefit of running a TAP server comes right
	back to you.  Certainly the security officer on the other end
	can't tell whether your TAP server is providing useful
	information---but if you are running a valid TAP server then
	you can assign blame properly. If you run a TAP server which
	provides useless information then you don't get this benefit.
 
It is a very bad idea to assign blame only based on TAP server
information. The only thing that TAP will tell you is that a
particular 'user account' left a TAP trail. If you are unable to
verify that the 'user' who was assigned to the account could have left
the trail, then it might have been someone who hacked that users
account (solent password) or hacked another TAP server somewhere to
make it look like stuff was coming from your machine.

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. It was my understanding
that TAP returned a black box answer that only the administrator of
the TAP server machine was qualified to point back to a user.

In fact, it seems likely to me that an encrypted TAP answer would be
unique most of the time if it is carrying timestamp and port
information in addition to user information. This kind of filtering
seems unlikely to be useful in this situation.

Note: I am personally against ANY/ALL active uses of TAP or Ident. (We
don't need to rehash this now, we already spent too much time
discussing it previously.)

	-- Mark
	[e-mail]