(a proposal of light-weight iTrace authentication) Re: Potential agenda for SF meeting

Hi,

On the subject of cryptographic support of iTrace, one of my
students finished a MS thesis on a weak authentication method
for iTrace, which requires no public key or any format of
secret key exchanges. The overhead is two extra messages for
some interesting iTrace messages. And, yes, this certainly can
be optional.

Before I submit this idea as a draft to the working group, I
would like to briefly explain how it works and whether this
working group feels that this is something we should pursue
at all:

	Each router supporting this feature will generate two
	keys, and these two keys will never need to reveal to
	anybody else, at least, conceptually.

	I will call them: key_FAST and key_SLOW.

Preprocessing:

	When the router starts, it will use key_FAST and some
	secure hash function (such HMAC-SHA1) to produce a table
	of digests on some portion of IP addresses (this part is
	kind of hard to explain quickly but I will try).

	For example, a very simple way will be to choose the first
	8 bits of the IP address. Since we have 2^8 different
	values for the first 8 bits, then we will have 256 (2^8)
	different digests in the table. (BTW, this table is used
	mainly for denial of service attacks on the iTrace
	authentication mechanism itself.)

On each iTraced packet:

	We use key_SLOW (or some hash-chained version of key_SLOW)
	to authenticate the whole iTrace message.

	Then, use the first 8 bits of the "source IP address" of
	the iTraced packet as the index and do a table lookup. And,
	include the digest into the iTrace message as well.

	So, in each iTrace message, we have two level of protection:
	one guarded by key_SLOW on the whole packet, while the second
	guarded by key_FAST only on a small portion of the source
	IP address of the original packet.

On receiving the iTraced packet (by the destination):

	Now the receiver will need to decide whether this iTrace
	message is at all interesting -- in a lot of cases, the
	receiver will not even bother to look at the message, and
	they should simply drop it.

	In case that the receiver is indeed interested in finding
	out whether this iTrace message is indeed valid, it can
	do one of the following:

	(1). It can produce a challenge (a nouce) and send the
	     received iTrace message back to the producer of this
	     iTrace message. If the producer then sends back a
	     "Yes" message (with the correct nouce) to validate
	     the message, then we will "trust in the weak sense"
	     this iTrace message.

	     On the producer side, when it receives such an
	     authentication request, it will first use the
	     original packet's IP address to check the digest
	     table (by key_FAST). This is to prevent malicious
	     attackers trying to flood this iTrace router.

	     If the digest table match is OK, then it will
	     further use key_SLOW to validate the whole iTrace
	     message. If everything is OK, an YES will be sent
	     back to the receiver.

	(2). Since many of the tracing activities might involve
	     some human intervention after the fact, a human
	     administrator can then try to use their human
	     channels (with administrators in another ISP for
	     example) to validate those iTrace messages.

In both scenarios, we try very hard to avoid any public key
infrastructure or pre-shared key management (or any kind of
key exchange) because I personally believe, at least in short
term, this avoidance will eliminate many difficult problems in
deployment of iTrace to everywhere.

Any comments?
-Felix


Pekka Savola wrote:
> 
> On Wed, 5 Feb 2003, Tom Taylor wrote:
> > I figure I can recycle the document incorporating comments received, within the next
> > week.  I will flag the big issue with key disclosure.
> 
> Also, I sent some comments on the list about two weeks ago, no replies
> yet.
> 
> The biggest thing I'd like to have w.g. discuss is whether cryptographic
> parts of iTrace could be optional in the implementations -- even specified
> separately.
> 
> Those seem to have a lot of weight in the spec and make implementing seem
> like a lot more complex task; I'm not sure if the tradeoffs are worth
> that.
> 
> > Leech, Marcus [CAR:W669:EXCH] wrote:
> > > "Leech, Marcus [CAR:W669:EXCH]" wrote:
> > >
> > >>I'd like to discuss a couple of things at the upcoming SF meeting:
> > >>
> > >>  1) Problems with current document, with solutions
> > >>       o actual problems
> > >>       o ommissions that reduce document clarity
> > >>       o stuff that makes implementations a lot harder
> > >>
> > >>  2) Definitions of public-key data in XML
> > >>
> > >>I'd like a couple of people to step forward to lead the discussion on these items
> > >>  at the meeting.
> > >>
> > >
> > > So far, Don Eastlake has said he could talk about XML public-key data representations,
> > >   but noone has come forward for the other item.  If I don't hear from anybody
> > >   by Friday, I *won't* schedule a WG meeting for SF.
> > >
> >
> 
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings