Date: Sat, 19 Feb 2000 12:14:17 -0500 From: "Jason Allum" <jja@nxos.com> To: <freebsd-hackers@freebsd.org> Subject: Re: Crypto progress! (And a Biiiig TODO list) Message-ID: <006c01bf7afc$c0e2a790$e82da6d1@nxos.com> References: <20000218220138.0BD819B@woodstock.monkey.net> <38AE34D8.F7F88DBA@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- From: "Wes Peters" <wes@softweyr.com> To: "Jon Hamilton" <hamilton@pobox.com> Cc: "Lyndon Nerenberg" <lyndon@orthanc.ab.ca>; <current@FreeBSD.ORG> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?006c01bf7afc$c0e2a790$e82da6d1>