Re: Ostiary
On Tue, 2 Aug 2005, Udhay Shankar N wrote: > Sounds interesting. Has anybody used this, and are there any comments? For similar purpose I used to use .qmail based system: the script started from .qmail when a message to some special address arrives, the script checks the digital signature on the message, compare the first line with stored counter (to avoid replay attacks) and executes the needed command. The positive side of this technique is that it is very simple (just few lines to code), does not need to open a port (and so it is firewall-friendly, no need to talk with sysadmins, ...), very unlikely to introduce security holes (qmail has quite good records, and in my case the mail was needed anyway). -- Regards, ASK P.S. If the moderator is troubled with spam let us agree on some special word in subject so that he can automatically reject the messages which do not have it. [Moderator's note: blocking messages from non-subscribers has been 100% effective already. --Perry] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Ostiary
* Karl Chen <[EMAIL PROTECTED]> [2005-08-02 09:24 -0700]: > As an authentication protocol, it looks vulnerable to a time > synchronization attack: an attacker that can desynchronize the server > and client's clocks predictably can block the client's authentication > and use it as his own. (Assuming the server's clock is monotonically I don't see where the client's time is used. What am I missing? Nicolas PS: Why is this list blocking my mail if the envelope-from is not subscribed? [Moderator's note: there is this little known phenomenon called "spam" we like to avoid... it is much harder to moderate a list if you have to wade through 400 garbage messages a day... --Perry] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Ostiary
As an authentication protocol, it looks vulnerable to a time synchronization attack: an attacker that can desynchronize the server and client's clocks predictably can block the client's authentication and use it as his own. (Assuming the server's clock is monotonically increasing, the command can only be used once.) If the command utilizes the IP address (e.g. as a port knock), this is a security hole. Karl On Tue, 2005-08-02 at 17:56 +0530, Udhay Shankar N wrote: > Sounds interesting. Has anybody used this, and are there any comments? > > Udhay > > http://ingles.homeunix.org/software/ost/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Ostiary
On Tuesday 02 August 2005 13:26, Udhay Shankar N wrote: > Sounds interesting. Has anybody used this, and are there any comments? > > Udhay > > http://ingles.homeunix.org/software/ost/ > ... > Perhaps you only really need to remotely initiate a limited set of > operations. In this case, you don't need a shell prompt, just a way to > securely kick off scripts from elsewhere. > > Enter 'Ostiary'. It is designed to allow you to run a fixed set of commands > remotely, without giving everyone else access to the same commands. It is > designed to do exactly and only what is necessary for this, and no more. I recently wrote this as a login program that was hard coded to run the commands concerned. The reason for doing this instead of the Ostiary approach is that SSH had to be running anyway, and SSH provides the key management regime. Without that, I'd have to invent my own which in Ostiary's case was the Hashing mechanisms. So on this point it would come down to whether we cared enough to replace SSH's authentication regime, which I'd think would be rarer (perhaps in the embedded market where Unix doesn't need maintaining??). Also, efficiency of command sending was not an issue - each send was about 10 seconds in my tests. > * Keep things simple. I'm no crypto expert; I know I'm not capable of > coming up with an ssh replacement. So I need to keep things so utterly > simple that I can be sure I'm not missing anything important. I think it is smart to keep things simple regardless of ones expertise :) Also, I wouldn't overdo the "hackability" argument. If flaws are found, you'll find time to fix them, and for the cost of a few hacked boxes, you'll have the benefit of a lot more secured boxes. iang -- Advances in Financial Cryptography, Issue 2: https://www.financialcryptography.com/mt/archives/000498.html Mark Stiegler, An Introduction to Petname Systems Nick Szabo, Scarce Objects Ian Grigg, Triple Entry Accounting - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Ostiary
Sounds interesting. Has anybody used this, and are there any comments? Udhay http://ingles.homeunix.org/software/ost/ Tools like ssh and lsh are great for allowing secure remote access to your system. They offer essentially full, flexible remote control of a machine, in an ecrypted and authenticated manner. But they are complex pieces of software; there's no way to do what they do without being complex. And with complexity comes bugs. Tools like ssh and lsh, and VPNs like CIPE, PPTP, and more have all had serious flaws that would allow an attacker to get full control over your system. If you leave such programs running all the time, you take the risk that someone is going to use an exploit on you before you have a chance to apply a patch. For some purposes, this is an acceptable - even necessary - tradeoff, but it would be nice to enable them only when actually needed, to minimize the risk. And for other purposes, ssh et. al. are overkill. Perhaps you only really need to remotely initiate a limited set of operations. In this case, you don't need a shell prompt, just a way to securely kick off scripts from elsewhere. Enter 'Ostiary'. It is designed to allow you to run a fixed set of commands remotely, without giving everyone else access to the same commands. It is designed to do exactly and only what is necessary for this, and no more. The only argument given to the command is the IP address of the client, and only if the authentication is successful. The following are the key design goals: * "First, do no harm." It should not be possible to use the Ostiary system itself to damage the host it's running on. In particular, it's willing to accept false negatives (denying access to legitimate users) in order to prevent false positives (allowing access to invalid users). * Insofar as possible, eliminate any possibility of bugs causing undesired operations. Buffer overflows, timing attacks, etc. should be impossible for an external attacker to execute. There's no point in installing security software if it makes you less secure. * Be extremely modest in memory and CPU requirements. I want to be able to fire off commands on my webserver (running on a Mac SE/30, a 16MHz 68030 machine) from my Palm Pilot (a 16MHz 68000 machine). Things like ssh already take 30 seconds or more to start up - I can't afford anything too fancy. * Keep things simple. I'm no crypto expert; I know I'm not capable of coming up with an ssh replacement. So I need to keep things so utterly simple that I can be sure I'm not missing anything important. -- ((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com)) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
