From owner-freebsd-hackers Sat Feb 19 9:10:27 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from netfinity.nxos.com (firewall.nxos.com [209.166.45.226]) by hub.freebsd.org (Postfix) with ESMTP id 9117037BC01 for ; Sat, 19 Feb 2000 09:10:23 -0800 (PST) (envelope-from jja@nxos.com) Received: from 0001 ([209.166.45.232]) by netfinity.nxos.com (8.9.3+Sun/8.9.1) with SMTP id RAA24803 for ; Sat, 19 Feb 2000 17:10:13 GMT Message-ID: <006c01bf7afc$c0e2a790$e82da6d1@nxos.com> From: "Jason Allum" To: References: <20000218220138.0BD819B@woodstock.monkey.net> <38AE34D8.F7F88DBA@softweyr.com> Subject: Re: Crypto progress! (And a Biiiig TODO list) Date: Sat, 19 Feb 2000 12:14:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Wes Peters" To: "Jon Hamilton" Cc: "Lyndon Nerenberg" ; Sent: Saturday, February 19, 2000 1:14 AM Subject: Re: Crypto progress! (And a Biiiig TODO list) > And how exactly are they supposed to tell the difference between answering > slowly due to breakin evasion vs. answering slowly because the system is > a 386sx/16? > > You would want to answer all "mistakes" slowly, but valid logins quickly. > yup... and any reasonably-malicious software would timeout well before that, and try something else... think multi-threaded, with a "work queue" of tester-threads and a few control threads that "think up" the requests... now imagine a distributed system. ;) i think a better approach might be to "pre-qualify" the requesting-host before even looking at the request itself. this could be done with diffie-hellman in a relatively straight forward manner... and then the door is open to symmetric encryption of the entire challenge/response exchange. if a "qualified" host is ever compromised, and it's dh-key becomes known, the malicious-user still doesn't have access to any other machines... all she has gained is the right to test login/password combinations herself... (which is already offered in the currently-proposed system.) replay attacks could be thwarted by adding timestamps to the exchange. unless a "qualified" hosts key is compromised, the only method that should be open to our DoS friends is at the protocol level (syn-flooding, pipe-filling, etc.) ...and another idea: if the secure connection is kept up over a period of time, additional authentications could be performed... the log information could also be routed over the connection... the authentication server would also have a simple method of determining whether a given host is up or down: do i have a connection, or not? just a thought. - jason allum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message