Re: service enablement via mail and otp?

[sen_ml@eccosys.com]

Hi,

From: "Karl E. Jorgensen" <karl@jorgensen.com>
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 (-;