[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment problems
Derek,
>Stephen Kent <kent@bbn.com> writes:
>
>> Yes, but most recent attacks have not been of this flavor, and we
>> have a variety of alternate authentication mechanisms that can be
>> used when people are concerned about passive wiretapping. I'm not
>> opposed to using encryption, but we see lots of attacks that exploit
>> buffer overflows and other bugs that will not be countered by
>> encryption. Moreover, use of encryption does adversely affect use of
>> net-based IDS and one has to decide where this negative side effect
>> outweighs the benefits.
>
>I'm not sure how an authentication system can prevent a buffer
>overflow attack, either, except you know authoritatively which host
>originated the attack on you. But that might not help any, because
>you don't know whether that other host started it or not. Besides,
>spoofing TCP connections nowadays is pretty hard, so you can be fairly
>certain of the source IP of someone attacking with a buffer overrun
>(code red, anyone?). How does authentication help?
It helps if we know the source of the traffic that caused the
overflow, and if we use the authenticated identities to constrain
communication, i.e., for access control, then it may limit the set of
folks who can effect the overflow, a priori. But, it's not a panacea,
since we have many apps (e.g., mail) where we are willing to talk to
just about anyone ...
>
>> Maybe. Since encryption can also interfere with our ability to detect
>> and track attacks, it's use is not purely beneficial. In recent
>> experiments sponsored by DARPA, we observed that use of encryption
>> with faulty authentication techniques allowed attackers to gain
>> unauthorized access and to hop from system to system without
>> detection, under cover of the encryption used on a host-to-host basis
>> in a LAN environment.
>
>Perhaps this means we need better, distributed tracking tools.
>Insteading of a centralized overseer, perhaps network elements need to
>communicate their attack status to their peers.
There are R&D projects underway (we have one at BBN, for example)
that take this approach for tracing, but it's still a research
problem and would be a long time before any of them are deployed.
Also, net-based IDS clearly suffers in the face of encryption. Now,
I'm not saying that net-based IDS is the best or only approach to
IDS, but it is a tool that is widely used, and we must be aware of
the adverse effects of widespread encryption, especially host-to-host
in a LAN context.
> > >We cannot build a panacea. No such beast exists, and looking for that
>> >perfect solution will, in the end, cause us to have none.
>>
>> We agree on the principle, but may differ on where to draw the line.
>
>Indeed. At least we're heading in the same general direction. :)
>
yep!
Steve
References: