Fwd: Re: [LinkSec] New Authentication paper
>Date: Fri, 08 Aug 2003 08:52:27 -0400
>To: Sai Dattathrani <saidatta@in.ibm.com>
>From: Robert Moskowitz <rgm@trusecure.com>
>Subject: Re: [LinkSec] New Authentication paper
>
>At 06:10 PM 8/8/2003 +0530, Sai Dattathrani wrote:
>
>
>
>
>>Hi,
>> I would like to know how the proposed model avoids the hacking of the
>>certificate itself during authentication.
>
>This model does not address issues like this, or rather puts them squarely
>where they belong, in the actual authentication exchange, not in any
>lower, supporting protocol.
>
>>There are situations where a
>>hacker can relay the identity request from one trusted system to another
>>trusted system. It also relays the response from one trusted system to
>>another trusted system and this way it spoofs the identity.
>>
>>Trusted system A to Hacker -> What's your identity?
>>Hacker to trusted system B -> What is your identity?
>>Trusted system B sends the response to the hacker assuming the request is
>>from Trusted system A.
>>Truster system B to Hacker -> My identity is x
>>Hacker to trusted system A -> my identity is x
>>Trusted system A to Hacker -> my certificate is y
>>Message digest has been used to avoid the above scenario I suppose. But
>>Message digest only avoids tampering of data to my knowledge. Does it avoid
>>sniffing too?
>
>It is important to see this as an issue for protection in the
>authentication algorithm, and NOT to expect a mechanism that moves the
>algorithm exchange between the parties to take this task on.
>
>>My basic question is, the authentication and encryption protocols can
>>themselves be hacked. How are we going to avoid sniffing with loopholes in
>>the encryption and authentication protocols?
>
>Eric Rescola has an Internet Draft: draft-iab-auth-mec-01.txt, that
>addresses the points about strengths and weaknesses in authentication
>algorithms. I have made some editorial comments on this ID to Eric and
>the IAB.
>
>One of the knots that the 802 community is getting tied up in is to try
>and solve problems at layers that cannot be responsible for the
>problem. You HAVE to choose your algorithms with care.
Robert Moskowitz
Senior Technical Director
ICSA Labs, a division of TruSecure Corp.
(248) 968-9809
Fax: (248) 968-2824
rgm@icaslabs.com
There's no limit to what can be accomplished
if it doesn't matter who gets the credit