Hi, From: "Karl E. Jorgensen" <[EMAIL PROTECTED]> Subject: Re: service enablement via mail and otp? Date: Thu, 1 Aug 2002 01:20:46 +0100
... I wrote: > > > I've downloaded a copy and taken a quick look at the man page -- I > > didn't notice anything about mechanisms for dealing w/ replay attacks > > in the man page -- are there any? > > No. I have to admit that I hadn't even thought about replay attacks :-(. > > I'll have to see what methods others have employed to avoid them (or > think up a probably-less-secure method myself). Right. There are a few obvious ones that come to mind: -Get an appropriate time stamp [1] and include that in the request -- the server can keep the stamp around for some time after completing the request and delete after some period of time. The server can be configured to only execute requests that have valid time stamps that have times w/in a certain "distance" compared to the current time. Presumably you want a time stamp that can't be or is extremely difficult to forge -- you need a way of verifying it too. For various reasons (e.g. existing technologies, complexity, etc.), I don't think this approach is currently doable -- a full discussion would be way off-topic and long, so I think we should steer clear of this. -Challenge-response: server sends a challenge in encrypted form, you decrypt it and include it in your encrypted reply. The server checks this and has a mechanism for checking whether it has already processed a request w/ that challenge in the past. [ It's nice to employ a method that doesn't require keeping around a lot of state information. ] > > The reason I like the OTP design for my particular situation is that I > > don't want to carry around a PGP key [1] and I don't want to mess w/ > > doing some kind of round-trip-challenge-response thing via mail to > > deal w/ potential replay attacks. > > Hm... GPG *does* have a --symmetric option, which seems to not use keys > at all. Assuming that a suitable method for generating (and > keeping-in-sync) passphrases between your PDA and smash, do you think > that would be suitable for you? This probably implies storing/generating > acceptable passphases locally (for smash) in clear-text... Hmmm, I'm not sure what you mean here. When you say "not use keys" I presume you mean doesn't use public key crypto keys but does use symmetric key crypto keys... One of the nice things about OTPs (as per the IETF RFCs) is that there is a calculation mechanism (based on a common seed) that's simple and fast enough to be implemented on many PDAs. You can store the seed in encrypted form on your PDA and only decrypt it when you need to calculate some OTPs. ... > But it should be reasonably simple to add extensions to check the > script immediately before execution. I'd prefer to implement such > extensions as separate scripts. I like that idea. One more on my > TODO list. (-; > > [1] I've got OTP calculators for my PDA which I'm fine w/ carrying. > > Actually, what I don't want is to carry around a secret key and a > > corresponding device to do the encryption/signing/decryption > > (perhaps some day PDAs will do this comfortably). I'm not about > > to place a secret key of mine on someone else's machine... > > Which OTP calculator (and PDA) do you use? I've got a PDA too, and this > might be handy for me too... [ This is probably OT for this list...] I use a Palm-compatible device. The OTP calculator I've been using is pilOTP. I've also tried PalmKey and Pilot/OTP, but I remember experiencing a bug in one of them and I don't remember what problem I had w/ the other. IIRC, either Keyring or Strip (but not both) has some kind of OTP support too. P.S. Feel free to mail me directly for further discussion. [1] Much harder than one might imagine (-;