Re: [Otpasswd-talk] Using OTP to kind of fix MITM.

[Hannes Beinert]

On Tue, Dec 22, 2009 at 03:58, Tomasz bla Fortuna <address@hidden> wrote:
>
> Heh. Reconsidering it's kind of not well-thought idea. :P This can
> help some attacks but certainly not MITM.

The problem of guarding against a MITM attack is definitely not
trivial, and traditionally involves the creation of an encrypted
channel using either pre-shared keys (which also serve to authenticate
the remote host), or keys derived from an anonymous key exchange
scheme, such as Diffie-Hellman, coupled with authentication of the
host.

I think that any knowledge of the passcode sequence would serve as
host authentication for PPP purposes, however this "secret" would need
to be shielded from the MITM with encryption.  AFAIK most anonymous
key exchanges use some type of public key crypto, and since that
involves computation it isn't really suited for a user without a
mobile device.  OTOH, one could potentially use an old-world
pen-and-paper cipher with a pre-shared key.

For example, the server could issue a challenge of the form 2C4:XXXX,
where 2C4 is a standard passcode identifier and XXXX is the result of
an encryption function on that passcode, ie, XXXX = E(PSK,PC(2C4)).
Since the user has the passcode sequence, s/he could decrypt this
PC(2C4) = D(PSK,XXXX) and thereby authenticate the host.  Then, the
user could send a response of YYYY = E(PSK,PC(3C4)), ie, the
encryption of the next passcode in the sequence.  An alternative
scheme might be to respond with YYYY = E(PC(2C4),PC(3C4)), where the
passcode used in the challenge is used to encrypt the response.

Since this concept is based on using techniques which don't involve
mobile devices, the crypto functions would need to be relatively
simple.  There are old-world ciphers which would work in this
situation, but it would still require the user to do some scribbling
on a piece of paper.

Ultimately, though, the question becomes whether this is worthwhile.
Most of the time PPP would presumably be used to protect a shell
login, in which case we may have implemented a (somewhat)
MITM-resistant login, but the result would be a shell prompt which the
MITM could then easily take over completely by disconnecting the user.
 OTOH, if this MITM-resistant login results in the creation of an
encrypted tunnel which is also MITM-resistant, then we are at the
point where we couldn't continue the session without a computing
device on the user's end to support the crypto.  I think it ultimately
boils down to a question of application for this system (PPP/otpasswd)
and the threat model.

Interesting thought, though.  I'm always interested in ways to make
this system more robust!  :-)

Hannes.